From arnt@gulbrandsen.priv.no Tue Jul 3 02:44:59 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2921F87E0 for ; Tue, 3 Jul 2012 02:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kky1Y+T8qSu for ; Tue, 3 Jul 2012 02:44:59 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EFA21F873D for ; Tue, 3 Jul 2012 02:44:58 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5DC7DF8D93B; Tue, 3 Jul 2012 09:45:05 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341308704-2232-2232/11/14; Tue, 3 Jul 2012 09:45:04 +0000 Message-Id: <4FF2BF2C.2080707@gulbrandsen.priv.no> Date: Tue, 3 Jul 2012 11:45:16 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> In-Reply-To: <4FEE1FD8.3060104@flaska.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] MOVEUID X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 09:44:59 -0000 On 06/29/2012 11:36 PM, Jan Kundr=E1t wrote: > I recognize that the UID COPY & UID STORE & UID EXPUNGE has the very > same problem as I'm presenting here, but I'd like to (re)propose an > untagged variant of the COPYUID response code I think you're right. It feels hackish, but I think you're right. I'll add it to the draft and repost in a few days, unless anyone has a=20 strong opinion on the matter? I think what I'll add is a MOVEUID that's sent untagged, defined from=20 first principles, does not say things like "if both UIDPLUS and MOVE",=20 may be sent by the server at its discretion, and if sent should be sent=20 before any EXPUNGEs. Arnt From arnt@gulbrandsen.priv.no Tue Jul 3 02:49:44 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC8621F87E1 for ; Tue, 3 Jul 2012 02:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnOoBoqwKnfV for ; Tue, 3 Jul 2012 02:49:44 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E9B21F86B8 for ; Tue, 3 Jul 2012 02:49:43 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0A7FFF8D941; Tue, 3 Jul 2012 09:49:51 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341308990-2232-2232/11/15; Tue, 3 Jul 2012 09:49:50 +0000 Message-Id: <4FF2C04B.5050001@gulbrandsen.priv.no> Date: Tue, 3 Jul 2012 11:50:03 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Subject: [imapext] =?utf-8?q?imap_move_=E2=80=94_msn_or_just_uid=3F?= X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 09:49:44 -0000 That's the great open issue. I do not have a strong opinion on the issue, except that I want to avoid controversy. My own opinion is that MSN move is mildly desirable, because most IMAP commands offer both and uniformity is a desirable trait, and quite likely possible for everyone (I'm assuming that if any servers have problems, then probably one of the nine I've spoken to will have problems.) Adrien told me earlier that it would be tricky to implement, but then that it might be doable after all. Would you mind checking again? Cyrus told me he wanted it, but I think he too wants a trouble-free discussion period more than he wants MSN-based move. However, we should decide. Arnt From tss@iki.fi Tue Jul 3 04:24:11 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8F21F8829 for ; Tue, 3 Jul 2012 04:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTVfbT+bMtGz for ; Tue, 3 Jul 2012 04:24:10 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id A84E221F8826 for ; Tue, 3 Jul 2012 04:24:10 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 2B4D31AE8803 for ; Tue, 3 Jul 2012 14:24:17 +0300 (EEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Timo Sirainen In-Reply-To: <4FF2BF2C.2080707@gulbrandsen.priv.no> Date: Tue, 3 Jul 2012 14:24:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0FDBCAD8-30D1-4A4A-8156-8466BC616246@iki.fi> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <4FF2BF2C.2080707@gulbrandsen.priv.no> To: imapext@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [imapext] MOVEUID X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 11:24:11 -0000 On 3.7.2012, at 12.45, Arnt Gulbrandsen wrote: > On 06/29/2012 11:36 PM, Jan Kundr=E1t wrote: >> I recognize that the UID COPY & UID STORE & UID EXPUNGE has the very >> same problem as I'm presenting here, but I'd like to (re)propose an >> untagged variant of the COPYUID response code >=20 > I think you're right. It feels hackish, but I think you're right. >=20 > I'll add it to the draft and repost in a few days, unless anyone has a = strong opinion on the matter? >=20 > I think what I'll add is a MOVEUID that's sent untagged, defined from = first principles, does not say things like "if both UIDPLUS and MOVE", = may be sent by the server at its discretion, and if sent should be sent = before any EXPUNGEs. Looks like there was no problem implementing this change to Dovecot. I = don't know if other servers might have extra trouble with delaying = sending EXPUNGE replies. Probably shouldn't give server the choice of sending COPYUID instead of = MOVEUID (I guess you didn't mean that but just to be sure). From arnt@gulbrandsen.priv.no Tue Jul 3 04:35:35 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C621F8823 for ; Tue, 3 Jul 2012 04:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rivRhkv3E02t for ; Tue, 3 Jul 2012 04:35:35 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0667A21F8813 for ; Tue, 3 Jul 2012 04:35:29 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5CA18F8DCE1; Tue, 3 Jul 2012 11:35:36 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341315335-2232-2232/11/16; Tue, 3 Jul 2012 11:35:35 +0000 Message-Id: <4FF2D913.8050102@gulbrandsen.priv.no> Date: Tue, 3 Jul 2012 13:35:47 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <4FF2BF2C.2080707@gulbrandsen.priv.no> <0FDBCAD8-30D1-4A4A-8156-8466BC616246@iki.fi> In-Reply-To: <0FDBCAD8-30D1-4A4A-8156-8466BC616246@iki.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] MOVEUID X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 11:35:36 -0000 On 07/03/2012 01:24 PM, Timo Sirainen wrote: > Looks like there was no problem implementing this change to Dovecot. I = don't know if other servers might have extra trouble with delaying = sending EXPUNGE replies. I would think not. > Probably shouldn't give server the choice of sending COPYUID instead = of MOVEUID (I guess you didn't mean that but just to be sure). Haven't done the detailed work yet. My basic inclination is to suggest=20 sending MOVEUID when practically possible, and to not send COPYUID if=20 MOVEUID has been sent. But I'll read the UIDPLUS document before I write=20 the text. Arnt From dkarp@zimbra.com Tue Jul 3 07:55:32 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A606821F86C2 for ; Tue, 3 Jul 2012 07:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc-KBorxQLEE for ; Tue, 3 Jul 2012 07:55:32 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [205.140.197.62]) by ietfa.amsl.com (Postfix) with ESMTP id EDADE21F8691 for ; Tue, 3 Jul 2012 07:55:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id D18BA7C0036; Tue, 3 Jul 2012 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.com Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMVZWuzkIivP; Tue, 3 Jul 2012 07:55:18 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.113.63.59]) by mta02.zimbra.com (Postfix) with ESMTP id 8F00F7C0030; Tue, 3 Jul 2012 07:55:18 -0700 (PDT) Date: Tue, 3 Jul 2012 07:55:16 -0700 (PDT) From: Dan Karp To: Jan =?utf-8?Q?Kundr=C3=A1t?= Message-ID: <604272625.323719.1341327316521.JavaMail.root@zimbra.com> In-Reply-To: <4FEE1FD8.3060104@flaska.net> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_BETA5_5277 (ZimbraWebClient - GC20 (Mac)/8.0.0_BETA5_5277) Thread-Topic: I-D ACTION:draft-ietf-imapmove-command-00.txt Thread-Index: T3EO58Dp+7kzJNWu3LALLnA650gVQg== Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:55:33 -0000 > I recognize that the UID COPY & UID STORE & UID EXPUNGE has the very > same problem as I'm presenting here, but I'd like to (re)propose an > untagged variant of the COPYUID response code working like this one: > > S: * OK [MOVEUID a 432432 1202:1205] Messages moved > > "Client implementors shall keep in mind that the EXPUNGE or VANISHED > responses precede delivery the COPYUID response code. In case the > clients want to make use of the returned information, they should > postpone removing the affected messages from their cache until the > tagged response is processed." Why is MOVEUID necessary? UIDPLUS-capable clients already handle COPYUID for their UID COPY operations, and UID COPY allows for sending untagged EXPUNGEs -- including those of the copied messages. Isn't UID MOVE just a specific case where the EXPUNGE responses are (much) more likely? - Dan From arnt@gulbrandsen.priv.no Tue Jul 3 08:02:15 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3D21F8839 for ; Tue, 3 Jul 2012 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAwxpt4UYusb for ; Tue, 3 Jul 2012 08:02:14 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2419621F8836 for ; Tue, 3 Jul 2012 08:02:11 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 26847F8DF4E; Tue, 3 Jul 2012 15:02:17 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341327736-2232-2232/11/21; Tue, 3 Jul 2012 15:02:16 +0000 Message-Id: <4FF30985.7090700@gulbrandsen.priv.no> Date: Tue, 3 Jul 2012 17:02:29 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <604272625.323719.1341327316521.JavaMail.root@zimbra.com> In-Reply-To: <604272625.323719.1341327316521.JavaMail.root@zimbra.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:02:16 -0000 On 07/03/2012 04:55 PM, Dan Karp wrote: > Why is MOVEUID necessary? UIDPLUS-capable clients already handle > COPYUID for their UID COPY operations, and UID COPY allows for sending > untagged EXPUNGEs -- including those of the copied messages. Isn't > UID MOVE just a specific case where the EXPUNGE responses are (much) > more likely? It's also a case where UIDCOPY invariably arrives after the EXPUNGE. In unix terms: You can't create a new hardlink if you've just removed the only known hardlink to that file. Arnt From dkarp@zimbra.com Tue Jul 3 08:12:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E2121F853F for ; Tue, 3 Jul 2012 08:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6FIAzYpH46Q for ; Tue, 3 Jul 2012 08:12:55 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [205.140.197.62]) by ietfa.amsl.com (Postfix) with ESMTP id A3BA021F852E for ; Tue, 3 Jul 2012 08:12:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id C8B6C7C0030; Tue, 3 Jul 2012 08:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.com Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFRZ6A1+jZNM; Tue, 3 Jul 2012 08:12:33 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.113.63.59]) by mta02.zimbra.com (Postfix) with ESMTP id 16FDD7C0002; Tue, 3 Jul 2012 08:12:33 -0700 (PDT) Date: Tue, 3 Jul 2012 08:12:30 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <624345161.385297.1341328350930.JavaMail.root@zimbra.com> In-Reply-To: <4FF30985.7090700@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <604272625.323719.1341327316521.JavaMail.root@zimbra.com> <4FF30985.7090700@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_BETA5_5277 (ZimbraWebClient - GC20 (Mac)/8.0.0_BETA5_5277) Thread-Topic: I-D ACTION:draft-ietf-imapmove-command-00.txt Thread-Index: UEvNHXgqZs2SCPDuaTm96Gs4tA7lmw== Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:12:56 -0000 > > Why is MOVEUID necessary? UIDPLUS-capable clients already handle > > COPYUID for their UID COPY operations, and UID COPY allows for > > sending untagged EXPUNGEs -- including those of the copied messages. > > Isn't UID MOVE just a specific case where the EXPUNGE responses are > > (much) more likely? > > It's also a case where UIDCOPY invariably arrives after the EXPUNGE. Yes, but COPYUID already can arrive after an untagged EXPUNGE in UID COPY. Clients already need to handle this case. > In unix terms: You can't create a new hardlink if you've just removed > the only known hardlink to that file. True. This is the same problem that already exists for for EXPUNGE/ COPYUID. - Dan From arnt@gulbrandsen.priv.no Tue Jul 3 08:29:39 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6EE21F8790 for ; Tue, 3 Jul 2012 08:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El4H1q+Og0nX for ; Tue, 3 Jul 2012 08:29:38 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2021F877C for ; Tue, 3 Jul 2012 08:29:38 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 52777F8DF5D; Tue, 3 Jul 2012 15:29:46 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341329385-2232-2232/11/22; Tue, 3 Jul 2012 15:29:45 +0000 Message-Id: <4FF30FF6.60505@gulbrandsen.priv.no> Date: Tue, 3 Jul 2012 17:29:58 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <604272625.323719.1341327316521.JavaMail.root@zimbra.com> <4FF30985.7090700@gulbrandsen.priv.no> <624345161.385297.1341328350930.JavaMail.root@zimbra.com> In-Reply-To: <624345161.385297.1341328350930.JavaMail.root@zimbra.com> Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:29:40 -0000 On 07/03/2012 05:12 PM, Dan Karp wrote: > Yes, but COPYUID already can arrive after an untagged EXPUNGE in UID > COPY. Clients already need to handle this case. It can, but it rarely happens with COPY, so all it does is add a few cache misses. With MOVE t happens every time, so the cache hit ratio drops to zero, and COPYUID is pointless. It's possible to get around it. The client can make a new reference to each message when it issues the move command and hold the references in a command issuer object. When copyuid arrives, the client can create new cache references in the target mailbox based on the references held by the move command issuer rather than based on the references in the source mailbox cache. That complicated explanation puts me off. Arnt From dkarp@zimbra.com Tue Jul 3 09:43:23 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14B21F861C for ; Tue, 3 Jul 2012 09:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oNLYAT21tuS for ; Tue, 3 Jul 2012 09:43:22 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [205.140.197.62]) by ietfa.amsl.com (Postfix) with ESMTP id C3EA821F8610 for ; Tue, 3 Jul 2012 09:43:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id A168C7C0049; Tue, 3 Jul 2012 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.com Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uILS2la+BHF1; Tue, 3 Jul 2012 09:43:19 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.113.63.59]) by mta02.zimbra.com (Postfix) with ESMTP id 751AA7C0047; Tue, 3 Jul 2012 09:43:19 -0700 (PDT) Date: Tue, 3 Jul 2012 09:43:17 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <1671459198.391770.1341333797586.JavaMail.root@zimbra.com> In-Reply-To: <4FF30FF6.60505@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <604272625.323719.1341327316521.JavaMail.root@zimbra.com> <4FF30985.7090700@gulbrandsen.priv.no> <624345161.385297.1341328350930.JavaMail.root@zimbra.com> <4FF30FF6.60505@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_BETA5_5277 (ZimbraWebClient - GC20 (Mac)/8.0.0_BETA5_5277) Thread-Topic: I-D ACTION:draft-ietf-imapmove-command-00.txt Thread-Index: 6cCv5u+2EczXIuvRhxs5nI9HYM1DLw== Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 16:43:23 -0000 > It's possible to get around it. The client can make a new reference > to each message when it issues the move command and hold the references > in a command issuer object. When copyuid arrives, the client can create > new cache references in the target mailbox based on the references held > by the move command issuer rather than based on the references in the > source mailbox cache. You've got a good point. There are legitimate response ordering issues with putting MOVEUID last. It just kinda puts me off from an aesthetic perspective that COPYUID and APPENDUID come on the tagged OK, while MOVEUID would come on an untagged response mid-stream with the tag inlined in the response code. It'd be good to hew to the precedent set by UIDPLUS unless the burden on client implementors is too great. (Honestly, I'd even lean towards reusing COPYUID for MOVE responses. But that won't work if we need the tag in the response code.) - Dan From tss@iki.fi Tue Jul 3 13:42:02 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2EA11E8162 for ; Tue, 3 Jul 2012 13:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.166 X-Spam-Level: X-Spam-Status: No, score=-110.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZozCEoMLZ7Q5 for ; Tue, 3 Jul 2012 13:42:02 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 15F6711E8156 for ; Tue, 3 Jul 2012 13:42:01 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 9C4241AE8664; Tue, 3 Jul 2012 23:42:09 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <1671459198.391770.1341333797586.JavaMail.root@zimbra.com> Date: Tue, 3 Jul 2012 23:42:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <906CF794-88F1-4217-AF16-379C667A2F63@iki.fi> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <604272625.323719.1341327316521.JavaMail.root@zimbra.com> <4FF30985.7090700@gulbrandsen.priv.no> <624345161.385297.1341328350930.JavaMail.root@zimbra.com> <4FF30FF6.60505@gulbrandsen.priv.no> <1671459198.391770.1341333797586.JavaMail.root@zimbra.com> To: Dan Karp X-Mailer: Apple Mail (2.1084) Cc: Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 20:42:02 -0000 On 3.7.2012, at 19.43, Dan Karp wrote: > (Honestly, I'd even lean towards reusing COPYUID for MOVE responses. = But > that won't work if we need the tag in the response code.) The COPYUID/MOVEUID specifies both source and destination UIDs. There's = no need to match them to a specific tagged command. Although there = should then be a MUST that if either of them is sent as untagged, the = MOVE command MUST reply with OK. From arnt@gulbrandsen.priv.no Wed Jul 4 00:25:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381CF11E8101 for ; Wed, 4 Jul 2012 00:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtFxGVqluvKI for ; Wed, 4 Jul 2012 00:25:11 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA9821F86D9 for ; Wed, 4 Jul 2012 00:25:11 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 631C9F8DB18; Wed, 4 Jul 2012 07:25:20 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341386719-2232-2232/11/26; Wed, 4 Jul 2012 07:25:19 +0000 Message-Id: <4FF3EFED.4040004@gulbrandsen.priv.no> Date: Wed, 4 Jul 2012 09:25:33 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <604272625.323719.1341327316521.JavaMail.root@zimbra.com> <4FF30985.7090700@gulbrandsen.priv.no> <624345161.385297.1341328350930.JavaMail.root@zimbra.com> <4FF30FF6.60505@gulbrandsen.priv.no> <1671459198.391770.1341333797586.JavaMail.root@zimbra.com> <906CF794-88F1-4217-AF16-379C667A2F63@iki.fi> In-Reply-To: <906CF794-88F1-4217-AF16-379C667A2F63@iki.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 07:25:12 -0000 How about this text? "COPYUID is normally sent as part of the tagged OK. Since some clients have problems using COPYUID after EXPUNGE (they remove the messages from their cache at EXPUNGE, and so cannot update the cache at COPYUID), the server SHOULD send COPYUID in an untagged OK just before it sends the the first EXPUNGE." Well, it needs wordsmithing. I can see that. Arnt From adrien@qbik.com Thu Jul 5 01:15:14 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB2621F8437 for ; Thu, 5 Jul 2012 01:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goKra6gZTwE9 for ; Thu, 5 Jul 2012 01:15:12 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF7E21F8468 for ; Thu, 5 Jul 2012 01:15:10 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019122187@smtp.qbik.com>; Thu, 05 Jul 2012 20:15:20 +1200 From: "Adrien W. de Croy" To: "Arnt Gulbrandsen" , "imapext@ietf.org" Date: Thu, 05 Jul 2012 08:15:20 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <4FF3EFED.4040004@gulbrandsen.priv.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 08:15:14 -0000 Hi we're currently already sending COPYUID on the tagged response to the=20 UID MOVE, and have done this for about a year. I don't know if clients=20 rely on the COPYUID response. I think there is a bug report against TB=20 for not using it (it rediscovers). 26975 29670 5/07/2012 18:10:12.551 121.74.33.191 Activation IMAP4=20 Server 888 19736 Debug 0 C=3D>: 13 uid move 21030 "Trash" 26976 29671 5/07/2012 18:10:12.566 121.74.33.191 Activation IMAP4=20 Server 888 19736 Debug 0 <=3DS: * 4537 EXPUNGE 26978 29673 5/07/2012 18:10:12.769 121.74.33.191 Activation IMAP4=20 Server 888 19736 Debug 0 <=3DS: 13 OK [COPYUID 1301566381 21030 20068]=20 command completed So you're saying this should change to MOVEUID with tag so that it can=20 come in an untagged response prior to EXPUNGE responses just to make life a little easier for client devs who use a particular=20 method? What about server devs? It's much easier to re-use the existing copy=20 etc processing code, and therefore leave the COPYUID as is. Why can't the client devs just know they did a move so defer EXPUNGE=20 processing if they can't just cope with it? Also, if this is going to be called MOVE, then how do we as a server=20 deal with clients that use the old MOVE vs the new one? We'd need to call this new method NEWMOVE or something. Adrien ------ Original Message ------ From: "Arnt Gulbrandsen" To: "imapext@ietf.org" Sent: 4/07/2012 7:25:33 p.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >How about this text?=20 > >"COPYUID is normally sent as part of the tagged OK. Since some clients=20 >have problems using COPYUID after EXPUNGE (they remove the messages=20 >from their cache at EXPUNGE, and so cannot update the cache at=20 >COPYUID), the server SHOULD send COPYUID in an untagged OK just before=20 >it sends the the first EXPUNGE."=20 > >Well, it needs wordsmithing. I can see that.=20 > >Arnt=20 >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From dkarp@zimbra.com Thu Jul 5 10:03:09 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3C621F8703 for ; Thu, 5 Jul 2012 10:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urYMjwzfPyca for ; Thu, 5 Jul 2012 10:03:08 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [205.140.197.62]) by ietfa.amsl.com (Postfix) with ESMTP id 93C1E21F86D6 for ; Thu, 5 Jul 2012 10:03:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id 0BB6F7C0030; Thu, 5 Jul 2012 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.com Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3BWwolm1oRo; Thu, 5 Jul 2012 10:03:03 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.113.63.59]) by mta02.zimbra.com (Postfix) with ESMTP id 29ADF7C002F; Thu, 5 Jul 2012 10:03:03 -0700 (PDT) Date: Thu, 5 Jul 2012 10:03:01 -0700 (PDT) From: Dan Karp To: "Adrien W. de Croy" Message-ID: <439633808.517391.1341507781014.JavaMail.root@zimbra.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_BETA5_5277 (ZimbraWebClient - GC20 (Mac)/8.0.0_BETA5_5277) Thread-Topic: I-D ACTION:draft-ietf-imapmove-command-00.txt Thread-Index: HV5SecusO7YGU09wIUwqeOfYXnDaGw== Cc: Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 17:03:09 -0000 > Also, if this is going to be called MOVE, then how do we as a server > deal with clients that use the old MOVE vs the new one? > > We'd need to call this new method NEWMOVE or something. You really shouldn't have implemented a command called "MOVE" without having gone through the standardization process. You needed to call it "XMOVE" or the like. As RFC 3501 section 6.5.1 says: Any command prefixed with an X is an experimental command. Commands which are not part of this specification, a standard or standards-track revision of this specification, or an IESG-approved experimental protocol, MUST use the X prefix. - Dan From adrien@qbik.com Thu Jul 5 17:19:18 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1711E808F for ; Thu, 5 Jul 2012 17:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpqOvPC+PtB0 for ; Thu, 5 Jul 2012 17:19:17 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 00E7811E8096 for ; Thu, 5 Jul 2012 17:19:16 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019123422@smtp.qbik.com>; Fri, 06 Jul 2012 12:19:28 +1200 From: "Adrien W. de Croy" To: "Dan Karp" Date: Fri, 06 Jul 2012 00:19:28 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <439633808.517391.1341507781014.JavaMail.root@zimbra.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 00:19:18 -0000 that's a fair comment, however you saw the log, it came from=20 thunderbird. You could say the same thing to them. But that's a big problem, since there are a lot of thunderbird installs=20 out there. =20 Basically anything you do to MOVE which breaks compatibility will=20 potentially have some impact on those using TB (e.g. if their server=20 advertises MOVE - new or old). We just saw the list of IMAP extensions supported by TB and went from=20 there. I don't know if other server vendors did the same or not. https://wiki.mozilla.org/MailNews:Supported_IMAP_extensions which points to=20 http://tools.ietf.org/html/draft-krecicki-imap-move So I don't really know how big a problem it is, but I do know that at=20 least TB uses it as currently defined in Witold's draft. Personally I don't see what this previous draft is really missing, and=20 why it needs to be re-written. It's possible changing the tagged response with COPYUID to an untagged=20 MOVEUID will have no impact. But I don't think we know that. Adrien ------ Original Message ------ From: "Dan Karp" To: "Adrien W. de Croy" Cc: "Arnt Gulbrandsen" ;"imapext@ietf.org"=20 Sent: 6/07/2012 5:03:01 a.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >> >>Also, if this is going to be called MOVE, then how do we as a server >>deal with clients that use the old MOVE vs the new one? >> >>We'd need to call this new method NEWMOVE or something. >> > > >You really shouldn't have implemented a command called "MOVE" without >having gone through the standardization process. You needed to call >it "XMOVE" or the like. As RFC 3501 section 6.5.1 says: > > Any command prefixed with an X is an experimental command. > Commands which are not part of this specification, a standard or > standards-track revision of this specification, or an > IESG-approved experimental protocol, MUST use the X prefix. > >- Dan >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From adrien@qbik.com Thu Jul 5 21:42:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984BC11E8123 for ; Thu, 5 Jul 2012 21:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VokheHIpBdVi for ; Thu, 5 Jul 2012 21:42:11 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4728211E8153 for ; Thu, 5 Jul 2012 21:42:11 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019123721@smtp.qbik.com>; Fri, 06 Jul 2012 16:42:25 +1200 From: "Adrien W. de Croy" To: "Adrien W. de Croy" , "Dan Karp" Date: Fri, 06 Jul 2012 04:42:26 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 04:42:12 -0000 hi all I've been thinking a bit more about this. If we are to allow the potential for other connected clients to delete=20 messages from a mailbox whilst one client is doing a move on multiple=20 messages, then it's possible that some messages may not be movable at=20 the time the server tries to move them. The problem then is that in either the COPYUID or MOVEUID proposal, the=20 client can't tell which source messages mapped to the UIDs specified,=20 since COPYUID/MOVEUID only provides a new UID sequence for the messages=20 that were moved, and if the size of this sequence is not the same as=20 the size of the original requested sequence, then there's no way to=20 tell which one didn't get moved. ALSO, since it will be a real pain in the neck for a server to defer=20 sending EXPUNGE to the mover until after it collected all the UIDs for=20 the target mailbox, and since this is new, why don't we do something=20 entirely different. E.g.=20 t UID MOVE 1:2 "target" * MOVED 1 "target" * MOVED 2 t OK move completed, 2 messages moved to other connected clients we'd just send the EXPUNGE responses. This way it's completely explicit what was moved and what wasn't. =20 Note: 1. to distinguish new MOVE (this) from old style, client must ENABLE=20 MOVE 2. only send target and uidvalidity on first untagged MOVED response=20 (since it is the same for all messages in the move). 3. clients must not pipeline move commands so that there's no need to=20 send the tag in each untagged response. 4. If a client indicates it supports move (ENABLE MOVE), then can=20 indicate MOVED responses instead of EXPUNGED responses. Adrien ------ Original Message ------ From: "Adrien W. de Croy" To: "Dan Karp" Cc: "Arnt Gulbrandsen" ;"imapext@ietf.org"=20 Sent: 6/07/2012 12:19:28 p.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt > >that's a fair comment, however you saw the log, it came from=20 >thunderbird. You could say the same thing to them.=20 > >But that's a big problem, since there are a lot of thunderbird=20 >installs out there.=20 >Basically anything you do to MOVE which breaks compatibility will=20 >potentially have some impact on those using TB (e.g. if their server=20 >advertises MOVE - new or old).=20 > >We just saw the list of IMAP extensions supported by TB and went from=20 >there. I don't know if other server vendors did the same or not.=20 > >https://wiki.mozilla.org/MailNews:Supported_IMAP_extensions=20 > >which points to=20 >http://tools.ietf.org/html/draft-krecicki-imap-move=20 > >So I don't really know how big a problem it is, but I do know that at=20 >least TB uses it as currently defined in Witold's draft.=20 > >Personally I don't see what this previous draft is really missing, and=20 >why it needs to be re-written.=20 > >It's possible changing the tagged response with COPYUID to an untagged=20 >MOVEUID will have no impact. But I don't think we know that.=20 > >Adrien=20 > > > >------ Original Message ------=20 >From: "Dan Karp" =20 >To: "Adrien W. de Croy" =20 >Cc: "Arnt Gulbrandsen" ;"imapext@ietf.org"=20 >=20 >Sent: 6/07/2012 5:03:01 a.m.=20 >Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt=20 >>> >>>Also, if this is going to be called MOVE, then how do we as a server=20 >>>deal with clients that use the old MOVE vs the new one?=20 >>> >>>We'd need to call this new method NEWMOVE or something.=20 >>> >> >> >>You really shouldn't have implemented a command called "MOVE" without=20 >>having gone through the standardization process. You needed to call=20 >>it "XMOVE" or the like. As RFC 3501 section 6.5.1 says:=20 >> >> Any command prefixed with an X is an experimental command.=20 >> Commands which are not part of this specification, a standard or=20 >> standards-track revision of this specification, or an=20 >> IESG-approved experimental protocol, MUST use the X prefix.=20 >> >>- Dan=20 >>_______________________________________________=20 >>imapext mailing list=20 >>imapext@ietf.org=20 >>https://www.ietf.org/mailman/listinfo/imapext=20 >> >> > >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From tss@iki.fi Thu Jul 5 22:16:20 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD8021F87E0 for ; Thu, 5 Jul 2012 22:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.274 X-Spam-Level: X-Spam-Status: No, score=-110.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjnqiJEso7oW for ; Thu, 5 Jul 2012 22:16:19 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1782821F87E1 for ; Thu, 5 Jul 2012 22:16:19 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 3F39D1AE8664; Fri, 6 Jul 2012 08:16:33 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Fri, 6 Jul 2012 08:16:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1084) Cc: Arnt Gulbrandsen , "imapext@ietf.org" , Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 05:16:20 -0000 On 6.7.2012, at 7.42, Adrien W. de Croy wrote: > The problem then is that in either the COPYUID or MOVEUID proposal, = the client can't tell which source messages mapped to the UIDs = specified, since COPYUID/MOVEUID only provides a new UID sequence for = the messages that were moved, and if the size of this sequence is not = the same as the size of the original requested sequence, then there's no = way to tell which one didn't get moved. MOVE is specified as COPY+STORE+EXPUNGE. COPY already requires that the = server MUST abort in such situation: If the COPY command is unsuccessful for any reason, server implementations MUST restore the destination mailbox to its state before the COPY attempt. From tss@iki.fi Thu Jul 5 22:19:02 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCB321F87E0 for ; Thu, 5 Jul 2012 22:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.339 X-Spam-Level: X-Spam-Status: No, score=-110.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLswzAKAI5Yz for ; Thu, 5 Jul 2012 22:19:01 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 61C1A21F857A for ; Thu, 5 Jul 2012 22:19:01 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 4DF951AE8664; Fri, 6 Jul 2012 08:19:16 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Fri, 6 Jul 2012 08:19:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <20702852-4D14-4262-A38A-27111287A6EA@iki.fi> References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1084) Cc: Arnt Gulbrandsen , "imapext@ietf.org" , Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 05:19:02 -0000 On 6.7.2012, at 3.19, Adrien W. de Croy wrote: > Basically anything you do to MOVE which breaks compatibility will = potentially have some impact on those using TB (e.g. if their server = advertises MOVE - new or old). Didn't you just say that TB doesn't use COPYUID with MOVE? If we change = COPYUID behavior how is that making anything worse? From adrien@qbik.com Thu Jul 5 22:37:57 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA8821F85A0 for ; Thu, 5 Jul 2012 22:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSWt4ODZfvzj for ; Thu, 5 Jul 2012 22:37:57 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id E55FD21F850D for ; Thu, 5 Jul 2012 22:37:56 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019123799@smtp.qbik.com>; Fri, 06 Jul 2012 17:38:11 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" Date: Fri, 06 Jul 2012 05:38:11 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <20702852-4D14-4262-A38A-27111287A6EA@iki.fi> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , "imapext@ietf.org" , Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 05:37:58 -0000 as at April 2011 it didn't, I don't know about now Adrien ------ Original Message ------ From: "Timo Sirainen" To: "Adrien W. de Croy" Cc: "Dan Karp" ;"Arnt Gulbrandsen"=20 ;"imapext@ietf.org" Sent: 6/07/2012 5:19:16 p.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >On 6.7.2012, at 3.19, Adrien W. de Croy wrote: > > >> >>Basically anything you do to MOVE which breaks compatibility will potenti= ally have some impact on those using TB (e.g. if their server advertises= MOVE - new or old). >> > > >Didn't you just say that TB doesn't use COPYUID with MOVE? If we change= COPYUID behavior how is that making anything worse? > > > From adrien@qbik.com Thu Jul 5 22:45:19 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0262121F8751 for ; Thu, 5 Jul 2012 22:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm6L0UXn-vyd for ; Thu, 5 Jul 2012 22:45:18 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 03A4E21F8740 for ; Thu, 5 Jul 2012 22:45:17 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019123810@smtp.qbik.com>; Fri, 06 Jul 2012 17:45:31 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" Date: Fri, 06 Jul 2012 05:45:32 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , Dan Karp , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 05:45:19 -0000 =EF=BB=BF Well... how useful is this? If I select a bunch of messages and drag them onto another folder, I=20 want it to happen. =20 If one message won't move for some reason, I want the rest to move. =20 Otherwise you put a big burden back on the user to sort out issues that=20 the server is perfectly capable of handling in a useful fashion. I also think that only sending EXPUNGED to other connected clients is=20 lame. Why not just send them everything they need to know so they can=20 know what happened (as long as they indicated support for it). =20 Otherwise all they know is some mail disappeared. They don't know it=20 was moved. To them the mail ils gone, not moved. That's why I suggest=20 making what we tell other clients as useful as possible. Whether or not a server mandates that all moves must succeed or none=20 will, should be an implementation decision. the protocol should not=20 mandate it either way IMO. A server author that wants to make life=20 easier for their mail users should not be prohibited from doing so just=20 because it was deemed to hard to do something useful in this case by=20 the spec writers? E.g. you select 1000 messages and drag them somewhere. 1 fails. Do=20 you really want to have to figure out which one by trial and error=20 (move smaller and smaller selections until they succeed)? If the other=20 999 were moved, it would become blindingly obvious which one, then the=20 user can do something about it. Otherwise we set up an awful user experience. Adrien ------ Original Message ------ From: "Timo Sirainen" To: "Adrien W. de Croy" Cc: "Arnt Gulbrandsen" ;"imapext@ietf.org"=20 ;"Dan Karp" Sent: 6/07/2012 5:16:25 p.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >On 6.7.2012, at 7.42, Adrien W. de Croy wrote: > > >> >>The problem then is that in either the COPYUID or MOVEUID proposal, the= client can't tell which source messages mapped to the UIDs specified, sinc= e COPYUID/MOVEUID only provides a new UID sequence for the messages that= were moved, and if the size of this sequence is not the same as the size= of the original requested sequence, then there's no way to tell which one= didn't get moved. >> > > >MOVE is specified as COPY+STORE+EXPUNGE. COPY already requires that the= server MUST abort in such situation: > > If the COPY command is unsuccessful for any reason, server > implementations MUST restore the destination mailbox to its state > before the COPY attempt. > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From arnt@gulbrandsen.priv.no Fri Jul 6 00:40:57 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7689221F8738 for ; Fri, 6 Jul 2012 00:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRo0Vuv04IRC for ; Fri, 6 Jul 2012 00:40:56 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id B917B21F873B for ; Fri, 6 Jul 2012 00:40:56 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2AC68F8D926; Fri, 6 Jul 2012 07:41:11 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341560470-14868-14868/10/3; Fri, 6 Jul 2012 07:41:10 +0000 Message-Id: <4FF696A8.2030804@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 09:41:28 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <20702852-4D14-4262-A38A-27111287A6EA@iki.fi> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 07:40:57 -0000 On 07/06/2012 07:38 AM, Adrien W. de Croy wrote: > as at April 2011 it didn't, I don't know about now Let me guess: It processes the EXPUNGEs as they arrive, and by the time the COPYUID arrives there's nothing left to process. Arnt From arnt@gulbrandsen.priv.no Fri Jul 6 01:00:14 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658B921F8755 for ; Fri, 6 Jul 2012 01:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB1r39h-p4rZ for ; Fri, 6 Jul 2012 01:00:13 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37721F86F7 for ; Fri, 6 Jul 2012 01:00:08 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 73706F8D937; Fri, 6 Jul 2012 08:00:23 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341561622-14868-14868/10/4; Fri, 6 Jul 2012 08:00:22 +0000 Message-Id: <4FF69B27.20708@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 10:00:39 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <4FEE1FD8.3060104@flaska.net> <604272625.323719.1341327316521.JavaMail.root@zimbra.com> <4FF30985.7090700@gulbrandsen.priv.no> <624345161.385297.1341328350930.JavaMail.root@zimbra.com> <4FF30FF6.60505@gulbrandsen.priv.no> <1671459198.391770.1341333797586.JavaMail.root@zimbra.com> <906CF794-88F1-4217-AF16-379C667A2F63@iki.fi> <4FF3EFED.4040004@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 08:00:14 -0000 On 07/05/2012 10:15 AM, Adrien W. de Croy wrote: > we're currently already sending COPYUID on the tagged response to the > UID MOVE, and have done this for about a year. I don't know if clients > rely on the COPYUID response. I think there is a bug report against TB > for not using it (it rediscovers). I'm not well acquainted with the tb bug tracker. Could you look up that but and see if has been fixed? > Why can't the client devs just know they did a move so defer EXPUNGE > processing if they can't just cope with it? The tb developers are well placed to answer that. Jan probably can comment, too. Arnt From adrien@qbik.com Fri Jul 6 03:01:11 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE62921F8707 for ; Fri, 6 Jul 2012 03:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LusfdAMdAQRq for ; Fri, 6 Jul 2012 03:01:11 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id B2FE221F8700 for ; Fri, 6 Jul 2012 03:01:10 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124045@smtp.qbik.com>; Fri, 06 Jul 2012 22:01:24 +1200 From: "Adrien W. de Croy" To: "Alexey Melnikov" Date: Fri, 06 Jul 2012 10:01:24 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Timo Sirainen , Arnt Gulbrandsen , "imapext@ietf.org" , Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 10:01:11 -0000 =EF=BB=BF ------ Original Message ------ From: "Alexey Melnikov" To: "Adrien W. de Croy" Cc: "Timo Sirainen" ;"Arnt Gulbrandsen"=20 ;"Dan Karp"=20 ;"imapext@ietf.org" Sent: 6/07/2012 8:55:59 p.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >Not a protocol problem: MOVE one message at a time if you care about this,= or MOVE many and handle error cases gracefully. This probably deserves = some text in the document. > >On 6 Jul 2012, at 06:45, "Adrien W. de Croy" wrote: > > >> >> >>Well... >> >>how useful is this? >> >>If I select a bunch of messages and drag them onto another folder, I want= it to happen. >>If one message won't move for some reason, I want the rest to move. Othe= rwise you put a big burden back on the user to sort out issues that the = server is perfectly capable of handling in a useful fashion. >> >>I also think that only sending EXPUNGED to other connected clients is = lame. Why not just send them everything they need to know so they can know= what happened (as long as they indicated support for it). Otherwise all= they know is some mail disappeared. They don't know it was moved. To = them the mail ils gone, not moved. That's why I suggest making what we = tell other clients as useful as possible. >> >>Whether or not a server mandates that all moves must succeed or none will= , should be an implementation decision. the protocol should not mandate= it either way IMO. A server author that wants to make life easier for = their mail users should not be prohibited from doing so just because it = was deemed to hard to do something useful in this case by the spec writers? >> > > >Disagree. We need to define specific behaviour (don't particularly care= which). > at the end of the day, whether the client requests a move of single=20 messages at a time, or multiple, the server cannot say. If the client wants the server to just move everything and report=20 whatever it couldn't, then that's a reasonable client wish. If the client wants to take on that burden itself, that's also=20 reasonable. We don't need to decide beforehand (in the spec) one way or another=20 whether any single move in a range of messages should fail the whole=20 bunch. Why not make it explicit, the client indicates error handling, e.g. t UID move 1:1000000 "target" ON_ERROR_REVERT The poor server will start moving files. If it gets to 999999 and the=20 last one fails, does it really really have to move everything back? =20 that's 99.999% likely to be a complete waste of server and client=20 effort and operator time. the operator already clearly indicated a=20 desire for the messages to be moved. Failure of 1, is extremely=20 unlikely IME to alter that desire. As long as errors can be properly reported in a way that allows a=20 client to recover and know what happened, then taking the optimistic=20 approach by default should be ok? This is equally a problem with COPY. If the server cannot properly=20 report errors (e.g. which messages failed) then sure, it only has 1=20 option, and that's to roll back. But this is new. We can make it so=20 that it reports errors properly. Adrien >> >> >>E.g. you select 1000 messages and drag them somewhere. 1 fails. Do you= really want to have to figure out which one by trial and error (move small= er and smaller selections until they succeed)? If the other 999 were moved= , it would become blindingly obvious which one, then the user can do someth= ing about it. >> >>Otherwise we set up an awful user experience. >> >>Adrien >> >> >> >> >> >>------ Original Message ------ >>From: "Timo Sirainen" >>To: "Adrien W. de Croy" >>Cc: "Arnt Gulbrandsen" ;"imapext@ietf.org" ;"Dan Karp" >>Sent: 6/07/2012 5:16:25 p.m. >>Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >> >>> >>>On 6.7.2012, at 7.42, Adrien W. de Croy wrote: >>> >>> >>> >>>> >>>> >>>>The problem then is that in either the COPYUID or MOVEUID proposal, = the client can't tell which source messages mapped to the UIDs specified,= since COPYUID/MOVEUID only provides a new UID sequence for the messages= that were moved, and if the size of this sequence is not the same as the= size of the original requested sequence, then there's no way to tell which= one didn't get moved. >>>> >>>> >>> >>> >>> >>>MOVE is specified as COPY+STORE+EXPUNGE. COPY already requires that the= server MUST abort in such situation: >>> >>> If the COPY command is unsuccessful for any reason, server >>> implementations MUST restore the destination mailbox to its state >>> before the COPY attempt. >>> >>>_______________________________________________ >>>imapext mailing list >>>imapext@ietf.org >>>https://www.ietf.org/mailman/listinfo/imapext >>> >>> >>> >> >> >>_______________________________________________ >>imapext mailing list >>imapext@ietf.org >>https://www.ietf.org/mailman/listinfo/imapext >> > From arnt@gulbrandsen.priv.no Fri Jul 6 03:11:48 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D989221F8750 for ; Fri, 6 Jul 2012 03:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNAXSIivY1PF for ; Fri, 6 Jul 2012 03:11:48 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54E21F86F5 for ; Fri, 6 Jul 2012 03:11:48 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 13A60F8DE4E; Fri, 6 Jul 2012 10:12:04 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341569523-14868-14868/10/5; Fri, 6 Jul 2012 10:12:03 +0000 Message-Id: <4FF6BA05.9080909@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 12:12:21 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <439633808.517391.1341507781014.JavaMail.root@zimbra.com> In-Reply-To: <439633808.517391.1341507781014.JavaMail.root@zimbra.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 10:11:49 -0000 On 07/05/2012 07:03 PM, Dan Karp wrote: > You needed to call > it "XMOVE" or the like To join the other four extensions by that name? Formally it's correct, but I dare say that in this case following the rules does not confer good karma. Arnt From arnt@gulbrandsen.priv.no Fri Jul 6 05:52:45 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4815621F85F3 for ; Fri, 6 Jul 2012 05:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCl8fxKWtATe for ; Fri, 6 Jul 2012 05:52:44 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id C01B321F8470 for ; Fri, 6 Jul 2012 05:52:44 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 929BCF8C72F; Fri, 6 Jul 2012 12:53:00 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341579179-14868-14868/10/7; Fri, 6 Jul 2012 12:52:59 +0000 Message-Id: <4FF6DFBC.1010204@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 14:53:16 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: Alexey Melnikov References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: "Adrien W. de Croy" , Timo Sirainen , imapext@ietf.org, Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 12:52:45 -0000 On 07/06/2012 10:55 AM, Alexey Melnikov wrote: > This probably deserves some text in the document. Will add. Arnt From arnt@gulbrandsen.priv.no Fri Jul 6 05:54:27 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0162821F86A2 for ; Fri, 6 Jul 2012 05:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tt2xSzoX6iH for ; Fri, 6 Jul 2012 05:54:26 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 693A121F8663 for ; Fri, 6 Jul 2012 05:54:26 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 67B63F8C72F; Fri, 6 Jul 2012 12:54:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341579281-14868-14868/10/8; Fri, 6 Jul 2012 12:54:41 +0000 Message-Id: <4FF6E023.1090405@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 14:54:59 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 12:54:27 -0000 On 07/06/2012 12:01 PM, Adrien W. de Croy wrote: > Why not make it explicit, the client indicates error handling, e.g. > > t UID move 1:1000000 "target" ON_ERROR_REVERT I've seen almost ten different move proposals and x- implementations. None of them contained this feature, which makes me think that it probably would not be used very often. Arnt From cyrus@daboo.name Fri Jul 6 06:45:04 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380EF21F86C1 for ; Fri, 6 Jul 2012 06:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5XRutYaFh+h for ; Fri, 6 Jul 2012 06:45:02 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9E13621F86C6 for ; Fri, 6 Jul 2012 06:45:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9D3492AA4A28; Fri, 6 Jul 2012 09:45:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoUpZuuGQACD; Fri, 6 Jul 2012 09:45:16 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 023692AA4A1B; Fri, 6 Jul 2012 09:45:14 -0400 (EDT) Date: Fri, 06 Jul 2012 09:45:09 -0400 From: Cyrus Daboo To: "Adrien W. de Croy" , Dan Karp Message-ID: <2E35798ABF0F8B76B64E8C1F@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1201 Cc: Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 13:45:05 -0000 Hi Adrien, --On July 6, 2012 4:42:26 AM +0000 "Adrien W. de Croy" wrote: > The problem then is that in either the COPYUID or MOVEUID proposal, the > client can't tell which source messages mapped to the UIDs specified, > since COPYUID/MOVEUID only provides a new UID sequence for the messages > that were moved, and if the size of this sequence is not the same as the > size of the original requested sequence, then there's no way to tell > which one didn't get moved. That is wrong, from UIDPLUS (RFC2359): The COPYUID response code contains as an argument the UIDVALIDITY of the appended-to mailbox, a message set containing the UIDs of the messages copied to the destination mailbox, in the order they were copied, and a message containing the UIDs assigned to the copied messages, in the order they were assigned. resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE set So the server gives the client an explicit mapping of "old UID" to "new UID". So if some messages were not moved they would simply not appear in the "old UID" set and there would be no corresponding entry in the "new UID" set. There is no problem here! -- Cyrus Daboo From cyrus@daboo.name Fri Jul 6 06:58:31 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29C121F8608 for ; Fri, 6 Jul 2012 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqXQY5yGbpkc for ; Fri, 6 Jul 2012 06:58:30 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 75D1C21F85F8 for ; Fri, 6 Jul 2012 06:58:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B54C52AA4CAD; Fri, 6 Jul 2012 09:58:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0l9fjEhWCpNT; Fri, 6 Jul 2012 09:58:45 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 47ED12AA4C97; Fri, 6 Jul 2012 09:58:42 -0400 (EDT) Date: Fri, 06 Jul 2012 09:58:40 -0400 From: Cyrus Daboo To: "Adrien W. de Croy" , Dan Karp Message-ID: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1090 Cc: Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 13:58:31 -0000 Hi Adrien, --On July 6, 2012 4:42:26 AM +0000 "Adrien W. de Croy" wrote: > t UID MOVE 1:2 "target" > * MOVED 1 "target" > * MOVED 2 > t OK move completed, 2 messages moved OK, so there is one big benefit to having MOVE responses - the server could send those unsolicited to other clients that have a mailbox selected, where another client is doing a MOVE. That way the other clients also have the option of moving the messages in their local cache, rather than doing a local cache expunge, followed sometime later by a fetch of the new messages in the target mailbox. For people accessing their IMAP store from multiple devices, that would be a big benefit. In order for that to work and be backwards compatible the server would have to send a MOVE followed by an EXPUNGE for the moved messages. I think it would make sense to design the MOVE (or MOVEUID) response to look like COPYUID in that a single response should be able to identify moves of multiple messages (to cut down on the total number of responses). -- Cyrus Daboo From adrien@qbik.com Fri Jul 6 07:19:08 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59B621F8669 for ; Fri, 6 Jul 2012 07:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKJeC0OSLMKi for ; Fri, 6 Jul 2012 07:19:08 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id AA50E21F8663 for ; Fri, 6 Jul 2012 07:19:07 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124316@smtp.qbik.com>; Sat, 07 Jul 2012 02:19:23 +1200 From: "Adrien de Croy" To: "Cyrus Daboo" , "Dan Karp" Date: Fri, 06 Jul 2012 14:19:22 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:19:09 -0000 =EF=BB=BFHi ------ Original Message ------ From: "Cyrus Daboo" To: "Adrien W. de Croy" ;"Dan Karp" Cc: "Arnt Gulbrandsen" ;"imapext@ietf.org"=20 Sent: 7/07/2012 1:58:40 a.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >Hi Adrien,=20 > >--On July 6, 2012 4:42:26 AM +0000 "Adrien W. de Croy"=20 > wrote:=20 > >>t UID MOVE 1:2 "target"=20 >>* MOVED 1 "target" =20 >>* MOVED 2 =20 >>t OK move completed, 2 messages moved=20 > >OK, so there is one big benefit to having MOVE responses - the server=20 >could send those unsolicited to other clients that have a mailbox=20 >selected, where another client is doing a MOVE. That way the other=20 >clients also have the option of moving the messages in their local=20 >cache, rather than doing a local cache expunge, followed sometime=20 >later by a fetch of the new messages in the target mailbox. For people=20 >accessing their IMAP store from multiple devices, that would be a big=20 >benefit.=20 yes, this happens a lot. Most moves are from inbox (junk or filter processing). This is also=20 the mailbox that most often clients have connections to for a long=20 time. So I think if a client supported unsolicited MOVED responses,=20 there could be some good benefit. If you have a lot of mailboxes, and one client moves a message, it can=20 be effectively lost to the other clients. You basically need to go to=20 the client that did the move to see where it went (unless the other=20 clients regularly poll ALL mailboxes for changes). > > >In order for that to work and be backwards compatible the server would=20 >have to send a MOVE followed by an EXPUNGE for the moved messages. I=20 >think it would make sense to design the MOVE (or MOVEUID) response to=20 >look like COPYUID in that a single response should be able to identify=20 >moves of multiple messages (to cut down on the total number of=20 >responses).=20 OK, so it would need to be untagged so it could be unsolicited to=20 others. e.g.=20 t UID MOVE 1,3:10,46,48:900 "target" * MOVED UID 1,3:10,48:898,900 "target" 2:863 t MOVE 861 messages moved, 2 messages vanished no expunges back to the requestor are required, all the information is=20 there. And all the information is in the untagged response for any=20 other observer to perform the same move in their cache. Adrien p.s. point taken on my misinterpretation of the UIDPLUS COPYUID=20 response. I shouldn't rely on my memory it seems! > > >-- Cyrus Daboo=20 > >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From tss@iki.fi Fri Jul 6 07:25:32 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1A821F8753 for ; Fri, 6 Jul 2012 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.382 X-Spam-Level: X-Spam-Status: No, score=-110.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxTVdTxu68vi for ; Fri, 6 Jul 2012 07:25:31 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id E846621F8749 for ; Fri, 6 Jul 2012 07:25:30 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id F3EFC1AE8664; Fri, 6 Jul 2012 17:25:45 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> Date: Fri, 6 Jul 2012 17:25:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> References: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1084) Cc: "Adrien W. de Croy" , Arnt Gulbrandsen , imapext@ietf.org, Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:25:32 -0000 On 6.7.2012, at 16.58, Cyrus Daboo wrote: >> t UID MOVE 1:2 "target" >> * MOVED 1 "target" >> * MOVED 2 >> t OK move completed, 2 messages moved >=20 > OK, so there is one big benefit to having MOVE responses - the server = could send those unsolicited to other clients that have a mailbox = selected, where another client is doing a MOVE. That way the other = clients also have the option of moving the messages in their local = cache, rather than doing a local cache expunge, followed sometime later = by a fetch of the new messages in the target mailbox. For people = accessing their IMAP store from multiple devices, that would be a big = benefit. Way, way too much work to be worth it. I very much wouldn't like to = implement that. From adrien@qbik.com Fri Jul 6 07:31:35 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859BA21F879A for ; Fri, 6 Jul 2012 07:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXAaTvFWRDtN for ; Fri, 6 Jul 2012 07:31:35 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8092D21F858A for ; Fri, 6 Jul 2012 07:31:34 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124339@smtp.qbik.com>; Sat, 07 Jul 2012 02:31:49 +1200 From: "Adrien de Croy" To: "Timo Sirainen" , "Cyrus Daboo" Date: Fri, 06 Jul 2012 14:31:48 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , Dan Karp , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:31:35 -0000 ------ Original Message ------ From: "Timo Sirainen" To: "Cyrus Daboo" Cc: "Adrien W. de Croy" ;"Arnt Gulbrandsen"=20 ;"imapext@ietf.org" ;"Dan=20 Karp" Sent: 7/07/2012 2:25:40 a.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >On 6.7.2012, at 16.58, Cyrus Daboo wrote: > > >>> >>>t UID MOVE 1:2 "target" >>>* MOVED 1 "target" >>>* MOVED 2 >>>t OK move completed, 2 messages moved >>> >> >> >>OK, so there is one big benefit to having MOVE responses - the server = could send those unsolicited to other clients that have a mailbox selected,= where another client is doing a MOVE. That way the other clients also have= the option of moving the messages in their local cache, rather than doing= a local cache expunge, followed sometime later by a fetch of the new messa= ges in the target mailbox. For people accessing their IMAP store from multi= ple devices, that would be a big benefit. >> > > > >Way, way too much work to be worth it. I very much wouldn't like to implem= ent that. > really? Would be hardly any work for us. Anyway I prefer Cyrus' proposal of a=20 single agreggated MOVED response. Which in fact is no more or less=20 work than current proposal (except to allow unsolicited moved responses=20 to others who indicate support. But that's trivially simple with=20 ENABLE). As for benefit, I guess you don't have many mail folders or use many=20 clients then. It would save me a bunch of work. But I'm not a typical=20 user. > > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From cyrus@daboo.name Fri Jul 6 07:39:38 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AC621F86B6 for ; Fri, 6 Jul 2012 07:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtOkWsCxFNz3 for ; Fri, 6 Jul 2012 07:39:38 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB221F8573 for ; Fri, 6 Jul 2012 07:39:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4C5732AA56A3; Fri, 6 Jul 2012 10:39:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVMabsuc4ElX; Fri, 6 Jul 2012 10:39:53 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 414DC2AA5698; Fri, 6 Jul 2012 10:39:52 -0400 (EDT) Date: Fri, 06 Jul 2012 10:39:49 -0400 From: Cyrus Daboo To: Timo Sirainen Message-ID: <714C9CC0368197CF848B3B7F@caldav.corp.apple.com> In-Reply-To: <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> References: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1004 Cc: "Adrien W. de Croy" , Arnt Gulbrandsen , imapext@ietf.org, Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:39:38 -0000 Hi Timo, --On July 6, 2012 5:25:40 PM +0300 Timo Sirainen wrote: >> OK, so there is one big benefit to having MOVE responses - the server >> could send those unsolicited to other clients that have a mailbox >> selected, where another client is doing a MOVE. That way the other >> clients also have the option of moving the messages in their local >> cache, rather than doing a local cache expunge, followed sometime later >> by a fetch of the new messages in the target mailbox. For people >> accessing their IMAP store from multiple devices, that would be a big >> benefit. > > > Way, way too much work to be worth it. I very much wouldn't like to > implement that. > I figured that would be the reaction from server developers :-) I would like to hear whether client implementors think unsolicited MOVE/MOVEUID would be beneficial - if not then we can punt on it entirely. However, the more we do to reduce the need for clients to re-download messages, the better. -- Cyrus Daboo From tss@iki.fi Fri Jul 6 07:41:47 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01321F86F4 for ; Fri, 6 Jul 2012 07:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdDnLskdGh2u for ; Fri, 6 Jul 2012 07:41:47 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0A57621F86EC for ; Fri, 6 Jul 2012 07:41:47 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 476EB1AE8664; Fri, 6 Jul 2012 17:42:02 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Fri, 6 Jul 2012 17:42:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrien de Croy X-Mailer: Apple Mail (2.1084) Cc: Cyrus Daboo , Arnt Gulbrandsen , "imapext@ietf.org" , Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:41:47 -0000 On 6.7.2012, at 17.31, Adrien de Croy wrote: >>> OK, so there is one big benefit to having MOVE responses - the = server could send those unsolicited to other clients that have a mailbox = selected, where another client is doing a MOVE. That way the other = clients also have the option of moving the messages in their local = cache, rather than doing a local cache expunge, followed sometime later = by a fetch of the new messages in the target mailbox. For people = accessing their IMAP store from multiple devices, that would be a big = benefit. >>=20 >> Way, way too much work to be worth it. I very much wouldn't like to = implement that. >>=20 >=20 > really? >=20 > Would be hardly any work for us. Sounds like you have a single process multithreaded server. Dovecot can = run in a cluster of multiple servers, each server possibly handling the = same user. All communication goes through the filesystem. What this = would need is that for each MOVE command it would have to write about it = to mailbox's log file (or alternatively a new method of communicating = between servers - simply for this feature). Possible, but I think it = would be mostly a waste of effort. From arnt@gulbrandsen.priv.no Fri Jul 6 07:43:16 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A68F21F864B for ; Fri, 6 Jul 2012 07:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMY2ufWZ4wmV for ; Fri, 6 Jul 2012 07:43:15 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F8D21F8622 for ; Fri, 6 Jul 2012 07:43:15 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 943F8F8CAB5; Fri, 6 Jul 2012 14:43:31 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341585809-14868-14868/10/9; Fri, 6 Jul 2012 14:43:29 +0000 Message-Id: <4FF6F9A4.606@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 16:43:48 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> In-Reply-To: <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:43:16 -0000 Timo answers Cyrus: >>> t UID MOVE 1:2 "target" >>> * MOVED 1 "target" >>> * MOVED 2 >>> t OK move completed, 2 messages moved >> >> OK, so there is one big benefit to having MOVE responses - the server = could send those unsolicited to other clients that have a mailbox = selected, where another client is doing a MOVE. That way the other = clients also have the option of moving the messages in their local = cache, rather than doing a local cache expunge, followed sometime later = by a fetch of the new messages in the target mailbox. For people = accessing their IMAP store from multiple devices, that would be a big = benefit. > > Way, way too much work to be worth it. I very much wouldn't like to = implement that. Easy in some architectures, but I don't think it's a win no matter how=20 easy it is. How often to people read messages one device, then move=20 messages from other mailboxes on another device, then change back to the=20 first device and read them again? Arnt From tss@iki.fi Fri Jul 6 07:45:06 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4087B21F864D for ; Fri, 6 Jul 2012 07:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMaCYHCgLlWi for ; Fri, 6 Jul 2012 07:45:05 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 51CB221F8652 for ; Fri, 6 Jul 2012 07:45:05 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 38A211AE8664; Fri, 6 Jul 2012 17:45:21 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <714C9CC0368197CF848B3B7F@caldav.corp.apple.com> Date: Fri, 6 Jul 2012 17:45:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> <714C9CC0368197CF848B3B7F@caldav.corp.apple.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1084) Cc: "Adrien W. de Croy" , Arnt Gulbrandsen , Dan Karp , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:45:06 -0000 On 6.7.2012, at 17.39, Cyrus Daboo wrote: > However, the more we do to reduce the need for clients to re-download = messages, the better. This could be done in a more generic way by adding a GUID extension to = IMAP protocol. APPEND returns you GUIDs of saved mails. When you see new = mails you could FETCH GUID for them and if the GUID is already cached = you wouldn't have to download it. From adrien@qbik.com Fri Jul 6 07:48:14 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263A821F8602 for ; Fri, 6 Jul 2012 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQvbxzct5GMp for ; Fri, 6 Jul 2012 07:48:13 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5335221F85FF for ; Fri, 6 Jul 2012 07:48:13 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124371@smtp.qbik.com>; Sat, 07 Jul 2012 02:48:28 +1200 From: "Adrien de Croy" To: "Cyrus Daboo" , "Timo Sirainen" Date: Fri, 06 Jul 2012 14:48:26 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <714C9CC0368197CF848B3B7F@caldav.corp.apple.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , Dan Karp , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:48:14 -0000 =EF=BB=BF ------ Original Message ------ From: "Cyrus Daboo" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >Hi Timo,=20 > >--On July 6, 2012 5:25:40 PM +0300 Timo Sirainen wrote:=20 >> >>Way, way too much work to be worth it. I very much wouldn't like to=20 >>implement that.=20 >> >>I figured that would be the reaction from server developers :-) I=20 >>would like to hear whether client implementors think unsolicited=20 >>MOVE/MOVEUID would be beneficial - if not then we can punt on it=20 >>entirely. However, the more we do to reduce the need for clients to=20 >>re-download messages, the better.=20 >> Actually it's a worse problem than that. I have something like 600 folders/mailboxes in my login. I have filter=20 rules to sort the mail incoming into these folders. If something moves a message to another folder, basically it can be=20 months before other clients would by chance open that folder and see=20 it. Unless I go to the client that did the move, I generally don't see=20 it. To all intents and purposes it may as well have been deleted. This means I close my work email when I leave, and also means I have to=20 constantly keep maintaining rules across multiple email clients. This=20 is a pain in the neck. I know server-side SEIVE is supposed to solve=20 that, but that actually just means it would effectively ALWAYS be=20 something else doing the move, and none of the clients would know where=20 the mail went. So telling everyone enough information about the move seems like a=20 no-brainer to me. And it would also reduce bandwidth consumption, since bystanders=20 wouldn't get a zillion EXPUNGE untagged responses any more (if they=20 supported the untagged moved one). For mobile clients especially it=20 would be good. But maybe some server architectures make this more difficult than=20 others. Adrien From adrien@qbik.com Fri Jul 6 07:51:24 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970E321F8667 for ; Fri, 6 Jul 2012 07:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b06HHSGGb9qV for ; Fri, 6 Jul 2012 07:51:24 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7C21F8666 for ; Fri, 6 Jul 2012 07:51:23 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124380@smtp.qbik.com>; Sat, 07 Jul 2012 02:51:38 +1200 From: "Adrien de Croy" To: "Timo Sirainen" Date: Fri, 06 Jul 2012 14:51:36 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Cyrus Daboo , Arnt Gulbrandsen , Dan Karp , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:51:24 -0000 ------ Original Message ------ From: "Timo Sirainen" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >On 6.7.2012, at 17.31, Adrien de Croy wrote: > > >>>> >>>>OK, so there is one big benefit to having MOVE responses - the server= could send those unsolicited to other clients that have a mailbox selected= , where another client is doing a MOVE. That way the other clients also = have the option of moving the messages in their local cache, rather than= doing a local cache expunge, followed sometime later by a fetch of the = new messages in the target mailbox. For people accessing their IMAP store= from multiple devices, that would be a big benefit. >>>> >>> >>> >>>Way, way too much work to be worth it. I very much wouldn't like to impl= ement that. >>> >>> >> >> >>really? >> >>Would be hardly any work for us. >> > > >Sounds like you have a single process multithreaded server. > you got me there. Haven't gone to clustering yet. Adrien. >Dovecot can run in a cluster of multiple servers, each server possibly = handling the same user. All communication goes through the filesystem. What= this would need is that for each MOVE command it would have to write about= it to mailbox's log file (or alternatively a new method of communicating= between servers - simply for this feature). Possible, but I think it would= be mostly a waste of effort. > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From adrien@qbik.com Fri Jul 6 07:53:39 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C5621F8665 for ; Fri, 6 Jul 2012 07:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klRvnaDvwHvA for ; Fri, 6 Jul 2012 07:53:38 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 54EAE21F862B for ; Fri, 6 Jul 2012 07:53:38 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124386@smtp.qbik.com>; Sat, 07 Jul 2012 02:53:53 +1200 From: "Adrien de Croy" To: "Arnt Gulbrandsen" , "imapext@ietf.org" Date: Fri, 06 Jul 2012 14:53:51 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <4FF6F9A4.606@gulbrandsen.priv.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:53:39 -0000 ------ Original Message ------ From: "Arnt Gulbrandsen" bject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >Timo answers Cyrus:=20 >>>>t UID MOVE 1:2 "target"=20 >>>>* MOVED 1 "target" =20 >>>>* MOVED 2=20 >>>>t OK move completed, 2 messages moved=20 >>> >>>OK, so there is one big benefit to having MOVE responses - the=20 >>>server could send those unsolicited to other clients that have a=20 >>>mailbox selected, where another client is doing a MOVE. That way the=20 >>>other clients also have the option of moving the messages in their=20 >>>local cache, rather than doing a local cache expunge, followed=20 >>>sometime later by a fetch of the new messages in the target mailbox.=20 >>>For people accessing their IMAP store from multiple devices, that=20 >>>would be a big benefit.=20 >> >>Way, way too much work to be worth it. I very much wouldn't like to=20 >>implement that.=20 > >Easy in some architectures, but I don't think it's a win no matter how=20 >easy it is. How often to people read messages one device, then move=20 >messages from other mailboxes on another device, then change back to=20 >the first device and read them again?=20 for me all the time. I have my office desktop, home desktop and iPhone. All hitting the=20 same account. With the rise of "smart" phones, more and more people have multiple=20 agents hitting the same mailbox. So it would actually be useful for me. Regards Adrien > > >Arnt=20 >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From cyrus@daboo.name Fri Jul 6 07:55:37 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412E921F86B6 for ; Fri, 6 Jul 2012 07:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V21IbvcEyJjT for ; Fri, 6 Jul 2012 07:55:36 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2C81221F862B for ; Fri, 6 Jul 2012 07:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 709682AA5A2D; Fri, 6 Jul 2012 10:55:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKD-5LVRhrbJ; Fri, 6 Jul 2012 10:55:50 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 8F7122AA5A13; Fri, 6 Jul 2012 10:55:48 -0400 (EDT) Date: Fri, 06 Jul 2012 10:55:45 -0400 From: Cyrus Daboo To: Adrien de Croy , Timo Sirainen Message-ID: <5AC0364FD2B9748A4C7211E4@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1478 Cc: Arnt Gulbrandsen , Dan Karp , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:55:37 -0000 Hi Adrien, --On July 6, 2012 2:48:26 PM +0000 Adrien de Croy wrote: > Actually it's a worse problem than that. > > I have something like 600 folders/mailboxes in my login. I have filter > rules to sort the mail incoming into these folders. > > If something moves a message to another folder, basically it can be > months before other clients would by chance open that folder and see it. > Unless I go to the client that did the move, I generally don't see it. > To all intents and purposes it may as well have been deleted. > > This means I close my work email when I leave, and also means I have to > constantly keep maintaining rules across multiple email clients. This is > a pain in the neck. I know server-side SEIVE is supposed to solve that, > but that actually just means it would effectively ALWAYS be something > else doing the move, and none of the clients would know where the mail > went. > > So telling everyone enough information about the move seems like a > no-brainer to me. Well one could argue that clients and servers should support some existing extensions to help with that. Most notably the NOTIFY extension (RFC 5465). Or perhaps status-in-list (RFC 5819). Both of those would allow a client to monitor multiple (or all) mailboxes for changes. Perhaps rather than having unsolicited MOVE/MOVEUID, we define a new NOTIFY event type for "MessageMove" and then make use of that. Is NOTIFY widely implemented? -- Cyrus Daboo From adrien@qbik.com Fri Jul 6 07:57:37 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8DA21F8738 for ; Fri, 6 Jul 2012 07:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SktcGTOt+NTv for ; Fri, 6 Jul 2012 07:57:36 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6D821F8715 for ; Fri, 6 Jul 2012 07:57:36 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124396@smtp.qbik.com>; Sat, 07 Jul 2012 02:57:51 +1200 From: "Adrien de Croy" To: "Timo Sirainen" , "Cyrus Daboo" Date: Fri, 06 Jul 2012 14:57:49 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , Dan Karp , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:57:37 -0000 ------ Original Message ------ From: "Timo Sirainen" To: "Cyrus Daboo" Cc: "Adrien W. de Croy" ;"Arnt Gulbrandsen"=20 ;"imapext@ietf.org" ;"Dan=20 Karp" Sent: 7/07/2012 2:45:20 a.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >On 6.7.2012, at 17.39, Cyrus Daboo wrote: > > >> >>However, the more we do to reduce the need for clients to re-download = messages, the better. >> > > >This could be done in a more generic way by adding a GUID extension to = IMAP protocol. APPEND returns you GUIDs of saved mails. When you see new= mails you could FETCH GUID for them and if the GUID is already cached you= wouldn't have to download it. > > > GUID would be great for detecting moves after the fact, but unless the=20 client looks at the target mailbox at some stage, they won't notice the=20 new messages there. what about if the MOVE extension were split in 2. 1 for single client mode, and another extension for the unsolicited=20 responses to others. E.g advertise MOVE and MOVEPLUS. I know it's major CAPABILITY=20 bloat.... and hate it for that... but it solves the problem for servers=20 whose architecture doesn't lend itself easily to notifying other=20 clients of moves. They then can do MOVE. Or maybe the notification part of it should be handled by the=20 notification RFC. Adrien > From dkarp@zimbra.com Fri Jul 6 08:05:43 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111CE21F8622 for ; Fri, 6 Jul 2012 08:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.08 X-Spam-Level: X-Spam-Status: No, score=-6.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2lkS3LV4P7i for ; Fri, 6 Jul 2012 08:05:42 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [205.140.197.62]) by ietfa.amsl.com (Postfix) with ESMTP id 11D0821F85CD for ; Fri, 6 Jul 2012 08:05:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id 66ADF7C0010; Fri, 6 Jul 2012 08:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.com Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCVXM7EDtuIf; Fri, 6 Jul 2012 08:05:39 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.113.63.59]) by mta02.zimbra.com (Postfix) with ESMTP id CE4D77C001E; Fri, 6 Jul 2012 08:05:39 -0700 (PDT) Date: Fri, 6 Jul 2012 08:05:38 -0700 (PDT) From: Dan Karp To: Cyrus Daboo Message-ID: <752946283.635345.1341587138636.JavaMail.root@zimbra.com> In-Reply-To: <5AC0364FD2B9748A4C7211E4@caldav.corp.apple.com> References: <5AC0364FD2B9748A4C7211E4@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_BETA5_5277 (ZimbraWebClient - GC20 (Mac)/8.0.0_BETA5_5277) Thread-Topic: I-D ACTION:draft-ietf-imapmove-command-00.txt Thread-Index: uTb6RD34CFWbThNYvQXft9uEgxlKGg== Cc: Adrien de Croy , Timo Sirainen , Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:05:43 -0000 > Perhaps rather than having unsolicited MOVE/MOVEUID, we define a new > NOTIFY event type for "MessageMove" and then make use of that. Is > NOTIFY widely implemented? Unfortunately, I don't believe it is. Neither by clients nor servers, though there's chickens and eggs there. - Dan From arnt@gulbrandsen.priv.no Fri Jul 6 08:07:39 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD09721F8622 for ; Fri, 6 Jul 2012 08:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYSLcvRFVrFs for ; Fri, 6 Jul 2012 08:07:39 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4321F85CD for ; Fri, 6 Jul 2012 08:07:39 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 94F59F8CAB5; Fri, 6 Jul 2012 15:07:55 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341587274-14868-14868/10/10; Fri, 6 Jul 2012 15:07:54 +0000 Message-Id: <4FF6FF5C.4080404@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 17:08:12 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> <4FF6F9A4.606@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:07:39 -0000 On 07/06/2012 04:53 PM, Adrien de Croy wrote: > for me all the time. > > I have my office desktop, home desktop and iPhone. All hitting the same > account. AOL, but once I've read a message on one, I hardly ever reread on the others. So the others would update their caches devoutly, but uselessly. Arnt From tss@iki.fi Fri Jul 6 08:08:24 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D7E21F8697 for ; Fri, 6 Jul 2012 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 601YGP99Amud for ; Fri, 6 Jul 2012 08:08:23 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3196A21F8685 for ; Fri, 6 Jul 2012 08:08:20 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id D59971AE8664; Fri, 6 Jul 2012 18:08:35 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <5AC0364FD2B9748A4C7211E4@caldav.corp.apple.com> Date: Fri, 6 Jul 2012 18:08:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5AC0364FD2B9748A4C7211E4@caldav.corp.apple.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1084) Cc: Adrien de Croy , Arnt Gulbrandsen , Dan Karp , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:08:24 -0000 On 6.7.2012, at 17.55, Cyrus Daboo wrote: > Perhaps rather than having unsolicited MOVE/MOVEUID, we define a new = NOTIFY event type for "MessageMove" and then make use of that. There is no MessageCopy either. > Is NOTIFY widely implemented? No. I've so far scanned 34% of public IPs' IMAP ports and zero servers = have advertised NOTIFY. Although I've almost finished writing it for = Dovecot. http://openemailsurvey.org/ if anyone's interested :) From adrien@qbik.com Fri Jul 6 08:08:38 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376DD21F8697 for ; Fri, 6 Jul 2012 08:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrV2ySbrGX8I for ; Fri, 6 Jul 2012 08:08:37 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8E721F8685 for ; Fri, 6 Jul 2012 08:08:37 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124415@smtp.qbik.com>; Sat, 07 Jul 2012 03:08:52 +1200 From: "Adrien de Croy" To: "Arnt Gulbrandsen" , "imapext@ietf.org" Date: Fri, 06 Jul 2012 15:08:46 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <4FF6FF5C.4080404@gulbrandsen.priv.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:08:38 -0000 the filtering happens before it's read. now, if the email clients could filter after reading/replying then=20 sure...=20 ------ Original Message ------ From: "Arnt Gulbrandsen" To: "imapext@ietf.org" Sent: 7/07/2012 3:08:12 a.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >On 07/06/2012 04:53 PM, Adrien de Croy wrote:=20 >>for me all the time.=20 >> >>I have my office desktop, home desktop and iPhone. All hitting the=20 >>same=20 >>account.=20 > >AOL, but once I've read a message on one, I hardly ever reread on the=20 >others.=20 > >So the others would update their caches devoutly, but uselessly.=20 > >Arnt=20 >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From dkarp@zimbra.com Fri Jul 6 08:13:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EBB21F85A1 for ; Fri, 6 Jul 2012 08:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju-VN7Xg+UgS for ; Fri, 6 Jul 2012 08:13:10 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [205.140.197.62]) by ietfa.amsl.com (Postfix) with ESMTP id F0FB621F8565 for ; Fri, 6 Jul 2012 08:13:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id AFAEC7C0029; Fri, 6 Jul 2012 08:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.com Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oipjB3COj13L; Fri, 6 Jul 2012 08:13:05 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.113.63.59]) by mta02.zimbra.com (Postfix) with ESMTP id 042EF7C000C; Fri, 6 Jul 2012 08:13:05 -0700 (PDT) Date: Fri, 6 Jul 2012 08:13:03 -0700 (PDT) From: Dan Karp To: Timo Sirainen Message-ID: <561795006.635977.1341587583542.JavaMail.root@zimbra.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_BETA5_5277 (ZimbraWebClient - GC20 (Mac)/8.0.0_BETA5_5277) Thread-Topic: I-D ACTION:draft-ietf-imapmove-command-00.txt Thread-Index: giq3N1litxrj9I1Qp7gj5xlkQpUrHA== Cc: "Adrien W. de Croy" , Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:13:12 -0000 > > The problem then is that in either the COPYUID or MOVEUID proposal, > > the client can't tell which source messages mapped to the UIDs > > specified, since COPYUID/MOVEUID only provides a new UID sequence > > for the messages that were moved, and if the size of this sequence > > is not the same as the size of the original requested sequence, > > then there's no way to tell which one didn't get moved. Actually, COPYUID contains both the source and target UIDs, in order. Followed by the UIDVALIDITY of the destination mailbox, a UID set containing the UIDs of the message(s) in the source mailbox that were copied to the destination mailbox and containing the UIDs assigned to the copied message(s) in the destination mailbox, indicates that the message(s) have been copied to the destination mailbox with the stated UID(s). The source UID set is in the order the message(s) were copied; the destination UID set corresponds to the source UID set and is in the same order. Neither of the UID sets may contain extraneous UIDs or the symbol "*". > MOVE is specified as COPY+STORE+EXPUNGE. COPY already requires that > the server MUST abort in such situation: > > If the COPY command is unsuccessful for any reason, server > implementations MUST restore the destination mailbox to its > state before the COPY attempt. The MOVE extension does not give this guarantee. First, each message SHOULD either be moved or unaffected. The server SHOULD NOT leave a message in neither or both mailboxes afterwards (even if the server returns a tagged NO response). I asked about whether you could have a mix of moved and non-moved messages, and Bron answered: | > Can there be a situation where some messages in the set are moved and | > others are unaffected? | | I suspect it's going to be implementation dependent. Worst cases are | always things like crashes and filesystem corruption, where all bets | are a bit off... - Dan From arnt@gulbrandsen.priv.no Fri Jul 6 08:15:47 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F0D21F8753 for ; Fri, 6 Jul 2012 08:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zJhhe9InWtg for ; Fri, 6 Jul 2012 08:15:47 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 100D421F8752 for ; Fri, 6 Jul 2012 08:15:47 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4FE1FF8CAB5; Fri, 6 Jul 2012 15:16:03 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341587762-14868-14868/10/11; Fri, 6 Jul 2012 15:16:02 +0000 Message-Id: <4FF70144.6090803@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 17:16:20 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <0268E7BA15D042DF4B48213C@caldav.corp.apple.com> <043C7834-5A8E-4271-840B-CB4BFA061593@iki.fi> <4FF6F9A4.606@gulbrandsen.priv.no> <4FF6FF5C.4080404@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:15:47 -0000 So it's not really about client cache update at all, it's about the particular way in which you're doing delivery. Would it be fair to say that you're really after a server-push equivalent of STATUS (UNSEEN)? Arnt From tss@iki.fi Fri Jul 6 08:19:34 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6209821F8755 for ; Fri, 6 Jul 2012 08:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAYqINWDxqQx for ; Fri, 6 Jul 2012 08:19:34 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id C157E21F86D7 for ; Fri, 6 Jul 2012 08:19:33 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id CF4621AE8664; Fri, 6 Jul 2012 18:19:49 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <561795006.635977.1341587583542.JavaMail.root@zimbra.com> Date: Fri, 6 Jul 2012 18:19:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9586B5A5-4E63-4A33-A75B-39F009483541@iki.fi> References: <561795006.635977.1341587583542.JavaMail.root@zimbra.com> To: Dan Karp X-Mailer: Apple Mail (2.1084) Cc: "Adrien W. de Croy" , Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:19:34 -0000 On 6.7.2012, at 18.13, Dan Karp wrote: >> MOVE is specified as COPY+STORE+EXPUNGE. COPY already requires that >> the server MUST abort in such situation: >>=20 >> If the COPY command is unsuccessful for any reason, server >> implementations MUST restore the destination mailbox to its >> state before the COPY attempt. >=20 > The MOVE extension does not give this guarantee. >=20 > First, each message SHOULD either be moved or unaffected. The server > SHOULD NOT leave a message in neither or both mailboxes afterwards > (even if the server returns a tagged NO response). I think this text was about what happens if the (atomic) COPY part = succeeds but EXPUNGE part fails. But I guess if servers wanted to = implement MOVE using rename()-like functions the problem would be = different. So I guess it should be explicitly mentioned also. From adrien@qbik.com Fri Jul 6 08:23:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB7121F8638 for ; Fri, 6 Jul 2012 08:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRa-PFHRU-yd for ; Fri, 6 Jul 2012 08:23:53 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8307421F85FD for ; Fri, 6 Jul 2012 08:23:51 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124447@smtp.qbik.com>; Sat, 07 Jul 2012 03:24:06 +1200 From: "Adrien de Croy" To: "Arnt Gulbrandsen" , "imapext@ietf.org" Date: Fri, 06 Jul 2012 15:24:00 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <4FF70144.6090803@gulbrandsen.priv.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:23:56 -0000 =EF=BB=BFHi ------ Original Message ------ From: "Arnt Gulbrandsen" To: "imapext@ietf.org" Sent: 7/07/2012 3:16:20 a.m. Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >So it's not really about client cache update at all, it's about the=20 >particular way in which you're doing delivery. Would it be fair to say=20 >that you're really after a server-push equivalent of STATUS (UNSEEN)?=20 I'm not sure. Basically if you have multiple clients sitting on the INBOX, when a=20 message is delivered to it (e.g. incoming from SMTP) the race is on. All the clients will get the notification about the new message, and=20 one or more will try and "filter" it. So it's possible that it could be a cache update for the clients who=20 did learn of its existence but didn't move it. But server push of STATUS could also be very interesting. That=20 probably is covered in NOTIFY. If Dovecot is going to roll out NOTIFY, and some clients pick it up,=20 we'd definitely look at rolling it in as well. The more clients can be=20 told about things rather than polling the better, and if they can be=20 told about everything over a single connection, that greatly reduces=20 the number of average connections a client needs to keep open to the=20 server. I don't know enough about NOTIFY though. Adrien > > >Arnt=20 >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From tss@iki.fi Fri Jul 6 08:25:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B6F21F8666 for ; Fri, 6 Jul 2012 08:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHUbEeei6sbf for ; Fri, 6 Jul 2012 08:25:56 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3221F8650 for ; Fri, 6 Jul 2012 08:25:56 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 3092B1AE8664 for ; Fri, 6 Jul 2012 18:26:12 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Timo Sirainen In-Reply-To: <9586B5A5-4E63-4A33-A75B-39F009483541@iki.fi> Date: Fri, 6 Jul 2012 18:26:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <561795006.635977.1341587583542.JavaMail.root@zimbra.com> <9586B5A5-4E63-4A33-A75B-39F009483541@iki.fi> To: imapext@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:25:56 -0000 On 6.7.2012, at 18.19, Timo Sirainen wrote: >>> MOVE is specified as COPY+STORE+EXPUNGE. COPY already requires that >>> the server MUST abort in such situation: >>>=20 >>> If the COPY command is unsuccessful for any reason, server >>> implementations MUST restore the destination mailbox to its >>> state before the COPY attempt. >>=20 >> The MOVE extension does not give this guarantee. >>=20 >> First, each message SHOULD either be moved or unaffected. The server >> SHOULD NOT leave a message in neither or both mailboxes afterwards >> (even if the server returns a tagged NO response). >=20 > I think this text was about what happens if the (atomic) COPY part = succeeds but EXPUNGE part fails. But I guess if servers wanted to = implement MOVE using rename()-like functions the problem would be = different. So I guess it should be explicitly mentioned also. Although really: It's going to be extremely rare for the MOVE to = partially fail. There's no good reason for that normally. Other than = filesystem corruption, running out of disk space, software bugs and = such, the only reason I can think of MOVE to partially fail in normally = operating systems is if it's implemented as filesystem rename(), = filesystem quotas are used and the destination directory needs to grow = and that would bring the user over the quota. So I don't think we need to worry about partial MOVE case much. Specify = that it SHOULD NOT happen, and that's about it.= From adrien@qbik.com Fri Jul 6 08:28:21 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EADE21F8712 for ; Fri, 6 Jul 2012 08:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bhqUUr6G1Dt for ; Fri, 6 Jul 2012 08:28:20 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7C20621F8711 for ; Fri, 6 Jul 2012 08:28:20 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.147.47]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3417)) with SMTP id <0019124453@smtp.qbik.com>; Sat, 07 Jul 2012 03:28:35 +1200 From: "Adrien de Croy" To: "Timo Sirainen" , "imapext@ietf.org" Date: Fri, 06 Jul 2012 15:28:28 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:28:21 -0000 ------ Original Message ------ From: "Timo Sirainen" >On 6.7.2012, at 18.19, Timo Sirainen wrote: > > >>>> >>>>MOVE is specified as COPY+STORE+EXPUNGE. COPY already requires that >>>>the server MUST abort in such situation: >>>> >>>> If the COPY command is unsuccessful for any reason, server >>>> implementations MUST restore the destination mailbox to its >>>> state before the COPY attempt. >>>> >>> >>> >>>The MOVE extension does not give this guarantee. >>> >>> First, each message SHOULD either be moved or unaffected. The server >>> SHOULD NOT leave a message in neither or both mailboxes afterwards >>> (even if the server returns a tagged NO response). >>> >> >> >>I think this text was about what happens if the (atomic) COPY part succee= ds but EXPUNGE part fails. But I guess if servers wanted to implement MOVE= using rename()-like functions the problem would be different. So I guess= it should be explicitly mentioned also. >> > > >Although really: It's going to be extremely rare for the MOVE to partially= fail. There's no good reason for that normally. Other than filesystem corr= uption, running out of disk space, software bugs and such, the only reason= I can think of MOVE to partially fail in normally operating systems is = if it's implemented as filesystem rename(), filesystem quotas are used and= the destination directory needs to grow and that would bring the user over= the quota. > I think it's more likely that move would fail because some other agent=20 expunges something in the meantime. Regards Adrien > > >So I don't think we need to worry about partial MOVE case much. Specify= that it SHOULD NOT happen, and that's about it. >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From cyrus@daboo.name Fri Jul 6 08:31:40 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4106021F8714 for ; Fri, 6 Jul 2012 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtU-pyz1o7Zv for ; Fri, 6 Jul 2012 08:31:39 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD0221F8712 for ; Fri, 6 Jul 2012 08:31:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id CD8A22AA62FF; Fri, 6 Jul 2012 11:31:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnexhmAxLUVs; Fri, 6 Jul 2012 11:31:52 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 0B06A2AA62F4; Fri, 6 Jul 2012 11:31:50 -0400 (EDT) Date: Fri, 06 Jul 2012 11:31:47 -0400 From: Cyrus Daboo To: Timo Sirainen Message-ID: <2B96051DF0E54A51BD688F0F@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=627 Cc: "Adrien W. de Croy" , Arnt Gulbrandsen , Dan Karp , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:31:40 -0000 Hi Timo, --On July 6, 2012 5:45:20 PM +0300 Timo Sirainen wrote: >> However, the more we do to reduce the need for clients to re-download >> messages, the better. > > This could be done in a more generic way by adding a GUID extension to > IMAP protocol. APPEND returns you GUIDs of saved mails. When you see new > mails you could FETCH GUID for them and if the GUID is already cached you > wouldn't have to download it. > Except the client may have already received an expunge for the message if it had that source mailbox selected, or if it "syncs" the source before it "syncs" the target. -- Cyrus Daboo From tss@iki.fi Fri Jul 6 08:48:18 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BC721F879A for ; Fri, 6 Jul 2012 08:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.191 X-Spam-Level: X-Spam-Status: No, score=-110.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+iHA1Ofbazo for ; Fri, 6 Jul 2012 08:48:18 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4669321F86BA for ; Fri, 6 Jul 2012 08:48:18 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 21A451AE8664; Fri, 6 Jul 2012 18:48:34 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Fri, 6 Jul 2012 18:48:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrien de Croy X-Mailer: Apple Mail (2.1084) Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:48:19 -0000 On 6.7.2012, at 18.28, Adrien de Croy wrote: >> Although really: It's going to be extremely rare for the MOVE to = partially fail. There's no good reason for that normally. Other than = filesystem corruption, running out of disk space, software bugs and = such, the only reason I can think of MOVE to partially fail in normally = operating systems is if it's implemented as filesystem rename(), = filesystem quotas are used and the destination directory needs to grow = and that would bring the user over the quota. >>=20 >=20 > I think it's more likely that move would fail because some other agent = expunges something in the meantime. Oh, right, I keep forgetting that since I implemented MOVE as = copy+expunge, and if copy is missing a message it reverts everything. From arnt@gulbrandsen.priv.no Fri Jul 6 09:23:29 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D3621F86D9 for ; Fri, 6 Jul 2012 09:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+Z0AZT0If3H for ; Fri, 6 Jul 2012 09:23:28 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D4221F8665 for ; Fri, 6 Jul 2012 09:23:28 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6F056F8DD69; Fri, 6 Jul 2012 16:23:44 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1341591823-14868-14868/10/12; Fri, 6 Jul 2012 16:23:43 +0000 Message-Id: <4FF71121.7040308@gulbrandsen.priv.no> Date: Fri, 6 Jul 2012 18:24:01 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <5AC0364FD2B9748A4C7211E4@caldav.corp.apple.com> In-Reply-To: <5AC0364FD2B9748A4C7211E4@caldav.corp.apple.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 16:23:32 -0000 On 07/06/2012 04:55 PM, Cyrus Daboo wrote: > Perhaps rather than having unsolicited MOVE/MOVEUID, we define a new > NOTIFY event type for "MessageMove" and then make use of that. Perhaps, although I lean towards Timo's suggestion of a GUID. > Is NOTIFY > widely implemented? No, not at all. http://rant.gulbrandsen.priv.no/good-bad-rfc Arnt From alexey.melnikov@isode.com Fri Jul 6 01:55:53 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECD821F86F4 for ; Fri, 6 Jul 2012 01:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU1y4kykQ0LD for ; Fri, 6 Jul 2012 01:55:52 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3CB21F86F8 for ; Fri, 6 Jul 2012 01:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1341564963; d=isode.com; s=selector; i=@isode.com; bh=6M86hgT5Rd+QJBkQnWK7UuUjFLmhu61avnRLQM92aNA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uOcMZFG5OgFw4kTX4pbfnCM9BBGneGWWT6cpAcJFPfJpZ8Gn2OXmvo/S5IeDL27g1PqSgh SakinagGCBjlvwru2zQKiHA6GXyhb67ZESged3Alpts3yBI/6p/IE2IKHPwHlpu6mmQj1S XAuGNPKC5atYEcBza0x5nDoN9auMIqM=; Received: from [188.28.205.162] (188.28.205.162.threembb.co.uk [188.28.205.162]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 6 Jul 2012 09:56:02 +0100 References: In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Fri, 6 Jul 2012 09:55:59 +0100 To: "Adrien W. de Croy" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 07 Jul 2012 08:52:09 -0700 Cc: Timo Sirainen , Arnt Gulbrandsen , "imapext@ietf.org" , Dan Karp Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 08:55:53 -0000 Not a protocol problem: MOVE one message at a time if you care about this, o= r MOVE many and handle error cases gracefully. This probably deserves some t= ext in the document. On 6 Jul 2012, at 06:45, "Adrien W. de Croy" wrote: >=20 > Well... >=20 > how useful is this? >=20 > If I select a bunch of messages and drag them onto another folder, I want i= t to happen. =20 > If one message won't move for some reason, I want the rest to move. Other= wise you put a big burden back on the user to sort out issues that the serve= r is perfectly capable of handling in a useful fashion. >=20 > I also think that only sending EXPUNGED to other connected clients is lame= . Why not just send them everything they need to know so they can know what= happened (as long as they indicated support for it). Otherwise all they kn= ow is some mail disappeared. They don't know it was moved. To them the mai= l ils gone, not moved. That's why I suggest making what we tell other clien= ts as useful as possible. >=20 > Whether or not a server mandates that all moves must succeed or none will,= should be an implementation decision. the protocol should not mandate it e= ither way IMO. A server author that wants to make life easier for their mai= l users should not be prohibited from doing so just because it was deemed to= hard to do something useful in this case by the spec writers? Disagree. We need to define specific behaviour (don't particularly care whic= h). >=20 > E.g. you select 1000 messages and drag them somewhere. 1 fails. Do you r= eally want to have to figure out which one by trial and error (move smaller a= nd smaller selections until they succeed)? If the other 999 were moved, it w= ould become blindingly obvious which one, then the user can do something abo= ut it. >=20 > Otherwise we set up an awful user experience. >=20 > Adrien >=20 >=20 >=20 >=20 >=20 > ------ Original Message ------ > From: "Timo Sirainen" > To: "Adrien W. de Croy" > Cc: "Arnt Gulbrandsen" ;"imapext@ietf.org" ;"Dan Karp" > Sent: 6/07/2012 5:16:25 p.m. > Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt >> On 6.7.2012, at 7.42, Adrien W. de Croy wrote: >>=20 >>=20 >>>=20 >>> The problem then is that in either the COPYUID or MOVEUID proposal, the c= lient can't tell which source messages mapped to the UIDs specified, since C= OPYUID/MOVEUID only provides a new UID sequence for the messages that were m= oved, and if the size of this sequence is not the same as the size of the or= iginal requested sequence, then there's no way to tell which one didn't get m= oved. >>>=20 >>=20 >>=20 >> MOVE is specified as COPY+STORE+EXPUNGE. COPY already requires that the s= erver MUST abort in such situation: >>=20 >> If the COPY command is unsuccessful for any reason, server >> implementations MUST restore the destination mailbox to its state >> before the COPY attempt. >>=20 >> _______________________________________________ >> imapext mailing list >> imapext@ietf.org >> https://www.ietf.org/mailman/listinfo/imapext >>=20 >>=20 >=20 > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From jkt@flaska.net Sat Jul 21 10:14:25 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E500421F8505 for ; Sat, 21 Jul 2012 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He4vXv+8F0NR for ; Sat, 21 Jul 2012 10:14:25 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id B00AD21F84F4 for ; Sat, 21 Jul 2012 10:14:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADrjClCT5xpZ/2dsb2JhbABFhW+zbYEHgkoVQDYCBRMDCwILAwIBAgFYCAEBiAkEB51CjkGSNoEgikYBhSeBEgOVSYEUjnmCYYFd X-IronPort-AV: E=Sophos;i="4.77,630,1336341600"; d="scan'208";a="50452" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 21 Jul 2012 19:15:16 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 0B0343DA82 for ; Sat, 21 Jul 2012 19:15:16 +0200 (CEST) Message-ID: <500AE394.3010504@flaska.net> Date: Sat, 21 Jul 2012 19:15:00 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 17:14:26 -0000 Hi, there's been quite a few requests for adding e-mail submission to IMAP. Arnt's response last time was "Write draft-gondwana-imap-send, make it cover 99%, submit it for publication without support for all the corner cases", Mark's reaction to that was "That way, we can point to the document whenever anyone in the future brings up this bad idea...along with the fact that nobody implements it and why.". I've tried to follow (and re-read) the resulting discussion many times, looked at various concerns raised in the previous rounds, dug a bit into the history of various proposals and tried to come up with my version of the proposal. It is available for reading at [1], source at [2] (I don't know why that tool doesn't render in the "tools" HTML format of RFCs, sorry). A few comments for that: - Using Postfix, it can be trivially implemented using its `sendmail` interface - It suppoorts Bcc just fine - DSNs are specified - When new ESMTP extensions appear, they can be integrated using traditional IMAP capabilities - It doesn't require clients to speak (E)SMTP at all I've implemented this version on a client side in Trojita [3] (but you'll need the git version for this feature). There are no server implementations that I'm aware of. I have one open question -- right now, it can send a message only if it is in the currently opened mailbox. It's done this way to fit into the general IMAP picture (I suspect I'll receive quite some feedback for this comment, anyway). However, given how the APPEND command operates, at least my client would perform much more smoothly if the syntax was not "UID SUBMIT ", but instead "UID SUBMIT " -- that way, I would not have to explicitly SELECT another mailbox just to send mail. If there's a consensus on this, I can easily change the definition. I'd like to receive your opinion on this draft. I'm especially looking for server vendors who might want to implement it. I'm offering a special bounty of one $beverage to anyone who can first come up with a patch acceptable for upstream inclusion into any open source IMAP server project. Alternatively, for those proprietary serve vendors among us, a publicly available demo making this feature available qualifies as well. However, even if your opinion is "your idea will never fly", I'd still like to hear it -- preferably with a reason about why it cannot work. I'm afraid I'm not familiar with IETF's process when it comes to draft submission (I got confused by the bit saying that drafts aimed for the standards track cannot be individually submitted) -- that's why it's an unofficial page on my private web instead of a proper draft, although it's written in the officially recommended format for RFCs. I'd love to hear advice about proper process here as well. With kind regards Jan [1] http://trojita.flaska.net/draft-imap-sendmail-00.html [2] https://gitorious.org/trojita/trojita/blobs/drafts/draft-imap-sendmail-00/docs/proposed-extensions/draft-imap-sendmail.xml [3] http://trojita.flaska.net/ -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From adrien@qbik.com Sat Jul 21 16:40:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA2121F8548 for ; Sat, 21 Jul 2012 16:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=-2.598, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29K7Z6b6iq5R for ; Sat, 21 Jul 2012 16:40:54 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6602A21F852C for ; Sat, 21 Jul 2012 16:40:54 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.154.179]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3440)) with SMTP id <0019152416@smtp.qbik.com>; Sun, 22 Jul 2012 11:41:51 +1200 From: "Adrien de Croy" To: =?utf-8?q?Jan=20Kundr=c3=a1t?= , "imapext@ietf.org" Date: Sat, 21 Jul 2012 23:41:46 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <500AE394.3010504@flaska.net> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 23:40:56 -0000 Hi Jan thanks for putting this together, I for one am very keen to see message=20 submission in IMAP for the reasons you state (user email client=20 configuration simplification, and support reduction), especially issues=20 relating to inability to connect on normal submission ports. I've=20 fielded so many countless support queries of the kind "I can read mail=20 but not send it" that I firmly believe IMAP is long overdue for this=20 feature, and submission via IMAP is a zillion times easier for everyone=20 (clients and servers) to implement than BURL over SMTP. I have a few comments though. 1. name. SENDMAIL is already a name of a product. I don't know if the=20 name is trademarked. There could be all sorts of issues calling it=20 SENDMAIL, I'd recommend calling it SUBMIT instead. 2. FROM. I'm not certain if this should be settable at submission time=20 or not. It's the sort of thing that may be best handled with=20 server-side association of the account with a return path. 3. SENDER. I'm not sure what SMTP envelope part this relates to, is it=20 superfluous? If it's already in the message headers, why do we need to=20 specify it again here? It's not needed for SMTP delivery (only need=20 return path and forward path(s)) 4. RECIPIENT processing. Can't we just specify a list? e.g.=20 x UID SUBMIT 123 (FROM "return-path@example.com" RECIPIENT=20 ("1@example.com", "2@example.com") DSN (delay failure)) 5. $submitted and $submitpending. Actually I would remove all of this. One should not be prohibited from submitting a message more than once? =20 It's not the end of the world if a message is sent more than once?=20 Better than not at all? Or is this to prevent loss of information about to whom a message has=20 been sent? E.g. one would need to copy first then submit the copy. In=20 which case COPY should NOT copy the $submitted flag. 6. BCC processing. Presumably on submission, the BCC header should be=20 stripped? 7. Atomicity. I understand this is just when submitted, if there is=20 any recipient checking. Upon actual delivery, some recipients may work=20 or not, but this would be handled by other mechanisms? I can implement this if you want a server to test against, we don't do=20 BURL, so don't have CATENATE though. Regards Adrien ------ Original Message ------ From: "Jan Kundr=C3=A1t" To: "imapext@ietf.org" Sent: 22/07/2012 5:15:00 a.m. Subject: [imapext] Mail submission over IMAP >Hi,=20 >there's been quite a few requests for adding e-mail submission to=20 >IMAP. Arnt's response last time was "Write draft-gondwana-imap-send,=20 >make it cover 99%, submit it for publication without support for all=20 >the corner cases", Mark's reaction to that was "That way, we can point=20 >to the document whenever anyone in the future brings up this bad=20 >idea...along with the fact that nobody implements it and why.". I've=20 >tried to follow (and re-read) the resulting discussion many times,=20 >looked at various concerns raised in the previous rounds, dug a bit=20 >into the history of various proposals and tried to come up with my=20 >version of the proposal. It is available for reading at [1], source at=20 >[2] (I don't know why that tool doesn't render in the "tools" HTML=20 >format of RFCs, sorry).=20 > >A few comments for that:=20 > >- Using Postfix, it can be trivially implemented using its `sendmail`=20 >interface=20 >- It suppoorts Bcc just fine=20 >- DSNs are specified=20 >- When new ESMTP extensions appear, they can be integrated using=20 >traditional IMAP capabilities=20 >- It doesn't require clients to speak (E)SMTP at all=20 > >I've implemented this version on a client side in Trojita [3] (but=20 >you'll need the git version for this feature). There are no server=20 >implementations that I'm aware of.=20 > >I have one open question -- right now, it can send a message only if=20 >it is in the currently opened mailbox. It's done this way to fit into=20 >the general IMAP picture (I suspect I'll receive quite some feedback=20 >for this comment, anyway). However, given how the APPEND command=20 >operates, at least my client would perform much more smoothly if the=20 >syntax was not "UID SUBMIT ", but instead "UID SUBMIT =20 > " -- that way, I would not have to explicitly=20 >SELECT another mailbox just to send mail. If there's a consensus on=20 >this, I can easily change the definition.=20 > >I'd like to receive your opinion on this draft. I'm especially looking=20 >for server vendors who might want to implement it. I'm offering a=20 >special bounty of one $beverage to anyone who can first come up with a=20 >patch acceptable for upstream inclusion into any open source IMAP=20 >server project. Alternatively, for those proprietary serve vendors=20 >among us, a publicly available demo making this feature available=20 >qualifies as well.=20 > >However, even if your opinion is "your idea will never fly", I'd still=20 >like to hear it -- preferably with a reason about why it cannot work.=20 > >I'm afraid I'm not familiar with IETF's process when it comes to draft=20 >submission (I got confused by the bit saying that drafts aimed for the=20 >standards track cannot be individually submitted) -- that's why it's=20 >an unofficial page on my private web instead of a proper draft,=20 >although it's written in the officially recommended format for RFCs.=20 >I'd love to hear advice about proper process here as well.=20 > >With kind regards=20 >Jan=20 > >[1] http://trojita.flaska.net/draft-imap-sendmail-00.html=20 >[2]=20 >https://gitorious.org/trojita/trojita/blobs/drafts/draft-imap-sendmail-00/= docs/proposed-extensions/draft-imap-sendmail.xml=20 > >[3] http://trojita.flaska.net/=20 > >-- Trojita, a fast e-mail client -- http://trojita.flaska.net/=20 > >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From jkt@flaska.net Sun Jul 22 06:48:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89A921F8562 for ; Sun, 22 Jul 2012 06:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwWF5-badC7e for ; Sun, 22 Jul 2012 06:48:12 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3DE21F85DD for ; Sun, 22 Jul 2012 06:48:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKUEDFCT5xpZ/2dsb2JhbABEhW+zbYEHgiABAQQBIw8BBTYKBgsLGAICBQwHAwsCAgkDAgECAUUTBgIBAReHbAYEB6xAkWCBIIpHgxGCFoESA5VJgRSOeYJhgV0 X-IronPort-AV: E=Sophos;i="4.77,633,1336341600"; d="scan'208";a="53359" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 22 Jul 2012 15:48:53 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 133663DA82 for ; Sun, 22 Jul 2012 15:48:53 +0200 (CEST) Message-ID: <500C04B5.3030206@flaska.net> Date: Sun, 22 Jul 2012 15:48:37 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 13:48:12 -0000 Hi Adrien, thanks for your review. Answers below. On 07/22/12 01:41, Adrien de Croy wrote: > 1. name. SENDMAIL is already a name of a product. I don't know if the > name is trademarked. There could be all sorts of issues calling it > SENDMAIL, I'd recommend calling it SUBMIT instead. I don't have much of a preference -- given that the most obvious server-side implementation would call `sendmail` directly, the name "UID SENDMAIL" felt good. I can change this if more people suggest so. > 2. FROM. I'm not certain if this should be settable at submission time > or not. It's the sort of thing that may be best handled with > server-side association of the account with a return path. The ESMTP allows for this, and I believe that there are legitimate reasons for envelope-From being different than header-From or even account-id (think mailing list managers). If this feature was out, I'd immediately get "you solution doesn't allow $foo" complaints, and I'd agree with them. Anyway, if the server doesn't allow overriding the FROM parameter, it shall return a POLICYDENIED response code -- so the biggest problem is that such a server MUST check that the FROM header (if present) matches the account name. That sounds acceptable to me -- what about you? Furthermore, there's currently no way for a client to see whether the denial was through "you've specified an envelope-FROM different from the header-From" or due to "your message looks like SPAM". Do you have a use case for making this a machine-readable (i.e. through the response code) identifier? (Both situations sounds very similar to me, though -- a spoofed sender can be a contributing factor for marking as spam, etc.) > 3. SENDER. I'm not sure what SMTP envelope part this relates to, is it > superfluous? If it's already in the message headers, why do we need to > specify it again here? It's not needed for SMTP delivery (only need > return path and forward path(s)) Oops, good catch -- the SENDER should not be there at all. I'll fix this in my next update. > 4. RECIPIENT processing. Can't we just specify a list? > > e.g. > x UID SUBMIT 123 (FROM "return-path@example.com" RECIPIENT > ("1@example.com", "2@example.com") DSN (delay failure)) This is to match how the ESMTP transaction looks like. Furthermore, if the grammar used a list syntax, some client would inevitably try "RECIPIENT one-address-here" without the parentheses, and if we wanted to plan for that, the grammar would have to allow for both types of syntax, which feels ugly. That's why I prefer the duplicate RECIPIENT bits. > 5. $submitted and $submitpending. Actually I would remove all of this. > > One should not be prohibited from submitting a message more than once? > It's not the end of the world if a message is sent more than once? > Better than not at all? > Or is this to prevent loss of information about to whom a message has > been sent? E.g. one would need to copy first then submit the copy. In > which case COPY should NOT copy the $submitted flag. This is to conform with Lemonade's recommendations [1] and in order to guarantee that mail-submission is reasonably "atomic" from the client point of view -- sure, if there's a server crash, a message can be improperly flagged, but that's inherent problem in any multi-service environment. Would you still strip out this section after reading what Lemonade has to say? It feels to me that these headers are meant to be manipulated by the party doing the actual submission, which is the IMAP server in the context of this extension. > 6. BCC processing. Presumably on submission, the BCC header should be > stripped? This is actually explicitly stated in the draft -- there's no requirement on payload manipulation in this case. I was afraid that mandating explicit removal of Bcc would prove to be hard to implement, but it looks like it's already mandated by RFC5321, appendix B [2]. I'll change the draft to include any requirements from RFC 5321/5322 and that the Bcc headers MUST be "handled". > 7. Atomicity. I understand this is just when submitted, if there is any > recipient checking. Upon actual delivery, some recipients may work or > not, but this would be handled by other mechanisms? Yes. The IMAP server shall either take the message with all recipients obtained from submission options or from the headers and try to deliver to all of them, or to none. > I can implement this if you want a server to test against, we don't do > BURL, so don't have CATENATE though. CATENATE is very useful on its own, even without BURL. In fact, it is an excellent feature to have along this UID SUBMIT draft. I'll be happy to test against your implementation even in absence of CATENATE, of course. Cheers, Jan [1] http://tools.ietf.org/html/rfc5550#section-5.10 [2] http://tools.ietf.org/html/rfc5321#appendix-B -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From arnt@gulbrandsen.priv.no Sun Jul 22 07:53:05 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F044F21F8609 for ; Sun, 22 Jul 2012 07:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzE+a4x-kW6B for ; Sun, 22 Jul 2012 07:53:04 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C0E21F8608 for ; Sun, 22 Jul 2012 07:53:04 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 38EF1F8E41F; Sun, 22 Jul 2012 14:54:05 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342968844-12416-12415/10/2; Sun, 22 Jul 2012 14:54:04 +0000 Message-Id: <500C140D.2010000@gulbrandsen.priv.no> Date: Sun, 22 Jul 2012 16:54:05 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <500C04B5.3030206@flaska.net> In-Reply-To: <500C04B5.3030206@flaska.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 14:53:05 -0000 On 07/22/2012 03:48 PM, Jan Kundr=E1t wrote: > The ESMTP allows for this, and I believe that there are legitimate > reasons for envelope-From being different than header-From or even > account-id (think mailing list managers). Suggest some that are legitimate in the context of an IMAP client? IMO, envelope from more or less has to match the header addresses. The=20 exceptions are firmly in server or service land, not in IMAP client land. Arnt From adrien@qbik.com Sun Jul 22 15:41:35 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83921F85C3 for ; Sun, 22 Jul 2012 15:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-3.022, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgQiRo+Aawca for ; Sun, 22 Jul 2012 15:41:34 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id CF04721F85BB for ; Sun, 22 Jul 2012 15:41:30 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3440)) with SMTP id <0019153460@smtp.qbik.com>; Mon, 23 Jul 2012 10:41:26 +1200 From: "Adrien W. de Croy" To: =?utf-8?q?Jan=20Kundr=c3=a1t?= , "imapext@ietf.org" Date: Sun, 22 Jul 2012 22:41:26 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <500C04B5.3030206@flaska.net> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 22:41:35 -0000 =EF=BB=BFHi Jan ------ Original Message ------ From: "Jan Kundr=C3=A1t" >Hi Adrien, thanks for your review. Answers below.=20 > >On 07/22/12 01:41, Adrien de Croy wrote:=20 >>1. name. SENDMAIL is already a name of a product. I don't know if the=20 >>name is trademarked. There could be all sorts of issues calling it=20 >>SENDMAIL, I'd recommend calling it SUBMIT instead.=20 > >I don't have much of a preference -- given that the most obvious=20 >server-side implementation would call `sendmail` directly, the name=20 >"UID SENDMAIL" felt good. I can change this if more people suggest so.=20 > >>2. FROM. I'm not certain if this should be settable at submission=20 >>time=20 >>or not. It's the sort of thing that may be best handled with=20 >>server-side association of the account with a return path.=20 > >The ESMTP allows for this, and I believe that there are legitimate=20 >reasons for envelope-From being different than header-From or even=20 >account-id (think mailing list managers). If this feature was out, I'd=20 >immediately get "you solution doesn't allow $foo" complaints, and I'd=20 >agree with them.=20 understand re mailing list manager. I was thinking maybe the server needs to advertise whether FROM (smtp=20 return-path) is settable, otherwise it is set by the mail server admin. >Anyway, if the server doesn't allow overriding the FROM parameter, it=20 >shall return a POLICYDENIED response code -- so the biggest problem is=20 >that such a server MUST check that the FROM header (if present)=20 >matches the account name. That sounds acceptable to me -- what about=20 >you?=20 could be difficult for the client to figure out what went wrong, unless=20 you put special return codes in so the client can know why the=20 submission was bounced. > > >Furthermore, there's currently no way for a client to see whether the=20 >denial was through "you've specified an envelope-FROM different from=20 >the header-From" or due to "your message looks like SPAM". Do you have=20 >a use case for making this a machine-readable (i.e. through the=20 >response code) identifier? (Both situations sounds very similar to me,=20 >though -- a spoofed sender can be a contributing factor for marking as=20 >spam, etc.)=20 the alternative to machine-readable responses is either generic (e.g.=20 pretty much useless) or localized which has other issues. So I always=20 prefer machine-readable. There could be a number of reasons why=20 submission is rejected. However, things like spam (AV) filtering could=20 be done at APPEND or CATENATE time? > > >>3. SENDER. I'm not sure what SMTP envelope part this relates to, is=20 >>it=20 >>superfluous? If it's already in the message headers, why do we need=20 >>to=20 >>specify it again here? It's not needed for SMTP delivery (only need=20 >>return path and forward path(s))=20 > >Oops, good catch -- the SENDER should not be there at all. I'll fix=20 >this in my next update.=20 I'm thinking if we have to parse and process headers anyway to deal=20 with BCC, then Sender could be useful still. >From my understanding, the main issue is that some record needs to be=20 kept somewhere in the mail client about what email was sent to whom. =20 This means if a message was BCCed to someone, then in the sent items=20 folder, the BCC header should remain visible. However, it needs to be=20 removed for actual delivery. Therefore the server needs to parse and remove the BCC header.=20 Other things should be done by the client, such as copying or moving to=20 say sent items folder,=20 > > >>4. RECIPIENT processing. Can't we just specify a list?=20 >> >>e.g.=20 >>x UID SUBMIT 123 (FROM "return-path@example.com" RECIPIENT=20 >>("1@example.com", "2@example.com") DSN (delay failure))=20 > >This is to match how the ESMTP transaction looks like. Furthermore, if=20 >the grammar used a list syntax, some client would inevitably try=20 >"RECIPIENT one-address-here" without the parentheses, and if we wanted=20 >to plan for that, the grammar would have to allow for both types of=20 >syntax, which feels ugly. That's why I prefer the duplicate RECIPIENT=20 >bits.=20 This is a new proposal, so I think we can assume people would implement=20 it properly. In fact having the tokens for RECIPIENT, FROM etc is just bloat. Also,=20 lists (even empty ones) are much easier to parse than token value=20 pairs, and easier to deal with corner cases (e.g. missing "RECIPIENT"=20 or missing recipient value) If you look at the BODYSTRUCTURE response, it's perfectly fine to=20 specify like submit =3D "SUBMIT" SP submit-params submit-params =3D "(" uniqueid SP forward-path [SP return-path] [SP=20 dsn-spec] ")" return-path =3D nstring forward-path =3D "HEADERS" / "(" string [*(SP string)] ")" dsn-spec =3D "(" dsn-token [*(SP dsn-token)] ")" dsn-token =3D "DELAY" / "FAILURE" / "SUCCESS" this solves several issues as well, e.g. the BNF doesn't allow multiple=20 dsn-spec, or sub-option-from options (return-path). =20 Since dsn-spec is optional, it makes no sense to allow a NIL value. =20 Also, since it's a list, it is distinguishable from return-path. If return-path is omitted, the server would use the return-path=20 associated with the mail account. in forward-path, if value is "HEADERS", then the forward path is taken=20 from the email headers To and BCC, otherwise it's a non-empty list of=20 non nil strings. > > >>5. $submitted and $submitpending. Actually I would remove all of=20 >>this.=20 >> >>One should not be prohibited from submitting a message more than=20 >>once?=20 >>It's not the end of the world if a message is sent more than once?=20 >>Better than not at all?=20 >>Or is this to prevent loss of information about to whom a message has=20 >>been sent? E.g. one would need to copy first then submit the copy. In=20 >>which case COPY should NOT copy the $submitted flag.=20 > >This is to conform with Lemonade's recommendations [1] and in order to=20 >guarantee that mail-submission is reasonably "atomic" from the client=20 >point of view -- sure, if there's a server crash, a message can be=20 >improperly flagged, but that's inherent problem in any multi-service=20 >environment.=20 > >Would you still strip out this section after reading what Lemonade has=20 >to say?=20 probably not. Otherwise you'd need some meta-storage to keep information about all=20 the submissions that have been performed on a message, and that doesn't=20 really fit into most email client modes of operation - they just add a=20 copy to sent items. >It feels to me that these headers are meant to be manipulated by the=20 >party doing the actual submission, which is the IMAP server in the=20 >context of this extension.=20 > >>6. BCC processing. Presumably on submission, the BCC header should be=20 >>stripped?=20 > >This is actually explicitly stated in the draft -- there's no=20 >requirement on payload manipulation in this case. I was afraid that=20 >mandating explicit removal of Bcc would prove to be hard to implement,=20 >but it looks like it's already mandated by RFC5321, appendix B [2].=20 It's not hard compared to implementing SEARCH. So I wouldn't be=20 concerned about that. > > >I'll change the draft to include any requirements from RFC 5321/5322=20 >and that the Bcc headers MUST be "handled".=20 > >>7. Atomicity. I understand this is just when submitted, if there is=20 >>any=20 >>recipient checking. Upon actual delivery, some recipients may work or=20 >>not, but this would be handled by other mechanisms?=20 > >Yes. The IMAP server shall either take the message with all recipients=20 >obtained from submission options or from the headers and try to=20 >deliver to all of them, or to none.=20 > >>I can implement this if you want a server to test against, we don't=20 >>do=20 >>BURL, so don't have CATENATE though.=20 > >CATENATE is very useful on its own, even without BURL. In fact, it is=20 >an excellent feature to have along this UID SUBMIT draft.=20 How would it be used without some way to deliver the result somewhere? =20 Or maybe only useful in that case with shared folders or something? Anyway, CATENATE will be on our roadmap soon, esp if SUBMIT / SENDMAIL=20 gets any traction. Regards Adrien > > >I'll be happy to test against your implementation even in absence of=20 >CATENATE, of course.=20 > >Cheers,=20 >Jan=20 > >[1] http://tools.ietf.org/html/rfc5550#section-5.10=20 >[2] http://tools.ietf.org/html/rfc5321#appendix-B=20 >-- Trojita, a fast e-mail client -- http://trojita.flaska.net/=20 > >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From adrien@qbik.com Mon Jul 23 00:35:28 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AF221F866C for ; Mon, 23 Jul 2012 00:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-2.935, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9twNy5b9s2Ew for ; Mon, 23 Jul 2012 00:35:28 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0521F866B for ; Mon, 23 Jul 2012 00:35:27 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.154.179]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3441)) with SMTP id <0019154187@smtp.qbik.com>; Mon, 23 Jul 2012 19:35:23 +1200 From: "Adrien de Croy" To: =?utf-8?q?Jan=20Kundr=c3=a1t?= , "imapext@ietf.org" Date: Mon, 23 Jul 2012 07:35:20 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <500C04B5.3030206@flaska.net> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 07:35:28 -0000 ------ Original Message ------ From: "Jan Kundr=C3=A1t" >Hi Adrien, thanks for your review. Answers below.=20 > >On 07/22/12 01:41, Adrien de Croy wrote:=20 >>1. name. SENDMAIL is already a name of a product. I don't know if the=20 >>name is trademarked. There could be all sorts of issues calling it=20 >>SENDMAIL, I'd recommend calling it SUBMIT instead.=20 > >I don't have much of a preference -- given that the most obvious=20 >server-side implementation would call `sendmail` directly, the name=20 >"UID SENDMAIL" felt good. I can change this if more people suggest so.=20 > from http://www.sendmail.org/~ca/email/sm-X/LICENSE clause 4 The name "sendmail" is a registered trademark and service mark of Sendmail, Inc. I wouldn't use the name SENDMAIL, can possibly cause all sorts of=20 problems for mail server vendors who may wish to advertise support for=20 this extension etc etc etc Adrien From jkt@flaska.net Mon Jul 23 01:25:58 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E030721F8687 for ; Mon, 23 Jul 2012 01:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI3ZwTYTXHFF for ; Mon, 23 Jul 2012 01:25:57 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6621F850C for ; Mon, 23 Jul 2012 01:25:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACUJDVCT5xpZ/2dsb2JhbABEhW+zRYEHgiABAQUjDwEFNgoRCxgCAgUMCgsCAgkDAgECAUUTBgIBAYgJq2iReoEgikYBgxEMggqBEgOVSYEUjnmCYYFd X-IronPort-AV: E=Sophos;i="4.77,638,1336341600"; d="scan'208";a="56348" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 23 Jul 2012 10:25:41 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id 018003DA82 for ; Mon, 23 Jul 2012 10:25:41 +0200 (CEST) Message-ID: <500D0A76.9020805@flaska.net> Date: Mon, 23 Jul 2012 10:25:26 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: <500C04B5.3030206@flaska.net> <500C140D.2010000@gulbrandsen.priv.no> In-Reply-To: <500C140D.2010000@gulbrandsen.priv.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:25:59 -0000 On 07/22/12 16:54, Arnt Gulbrandsen wrote: > Suggest some that are legitimate in the context of an IMAP client? > > IMO, envelope from more or less has to match the header addresses. The > exceptions are firmly in server or service land, not in IMAP client land. A group of friends is going on a vacation and for some reason they haven't set up a mailing list for coordination. Alice sent a mail to all of them, but Bob's mailbox was broken at the time of submission and his mail server refused to accept this message (or Alice just used Bob's old e-mail address which he no longer reads -- yes, I've seen such a situation). Now Alice and the rest of the team has left for a short pre-vacation vacation and I'm the only one hard working guy left to "forward" the mail to Bob. I'd still like to retain the original Message-Id etc for threading, but I also want to be able to use DSN to see whether the message made it this time. Hence I take the original message from Alice as delivered to my mailbox and issue `UID SUBMIT x (FROM "jkt@flaska.net" RECIPIENT "bob@example.org")`. This requires support for return-path not matching the original From header. This is admittedly a rather convoluted example, but I think that it is actually a valid use case. Or maybe it should be done by just taking the message as-is, prepending the Sender header and letting the MTA perform its extraction -- is that the case? If the MTA always used a return-path matching my account credentials, that would work as well. That would have a disadvantage of requiring knowledge of the authenticated user at the MTA layer, though; I can imagine deployments where this would imply extra work for the sysadmin. Opinions? Cheers, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From arnt@gulbrandsen.priv.no Mon Jul 23 01:28:11 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8E321F8687 for ; Mon, 23 Jul 2012 01:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVATJIKHH2YP for ; Mon, 23 Jul 2012 01:28:11 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2017821F86C8 for ; Mon, 23 Jul 2012 01:28:11 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 38666F8E5A8; Mon, 23 Jul 2012 08:28:10 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343032089-12416-12415/10/4; Mon, 23 Jul 2012 08:28:09 +0000 Message-Id: <500D0B1B.6030401@gulbrandsen.priv.no> Date: Mon, 23 Jul 2012 10:28:11 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <500C04B5.3030206@flaska.net> <500C140D.2010000@gulbrandsen.priv.no> <500D0A76.9020805@flaska.net> In-Reply-To: <500D0A76.9020805@flaska.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:28:11 -0000 On 07/23/2012 10:25 AM, Jan Kundr=E1t wrote: > Opinions? Yes, a strong one: Worry more about the common case and less about edge=20 cases. Arnt From jkt@flaska.net Mon Jul 23 02:12:06 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DC721F8681 for ; Mon, 23 Jul 2012 02:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.979 X-Spam-Level: X-Spam-Status: No, score=0.979 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, SARE_RAND_1=2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+MQkgD44uZJ for ; Mon, 23 Jul 2012 02:12:05 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 522AF21F8687 for ; Mon, 23 Jul 2012 02:12:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFABIVDVCT5xpZ/2dsb2JhbAA8CYVvr26DWIEHgiABAQQBIxU1EQsLGAICBQwVAgIPAkYQAwgBAYgDBqtgkgCBIIo+CYMRghaBEgOVSZANgmGBXQ X-IronPort-AV: E=Sophos;i="4.77,638,1336341600"; d="scan'208";a="56885" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 23 Jul 2012 11:11:58 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id A74C13DA82 for ; Mon, 23 Jul 2012 11:11:58 +0200 (CEST) Message-ID: <500D154F.20809@flaska.net> Date: Mon, 23 Jul 2012 11:11:43 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 09:12:06 -0000 Hi Adrien, On 07/23/12 00:41, Adrien W. de Croy wrote: > I was thinking maybe the server needs to advertise whether FROM (smtp > return-path) is settable, otherwise it is set by the mail server admin. [...] > could be difficult for the client to figure out what went wrong, unless > you put special return codes in so the client can know why the > submission was bounced. s/bounced/rejected/, I guess (failing UID SUBMIT MUST NOT cause an SMTP-level bounce) -- just to prevent a possible misunderstanding, I'm sure you haven't meant an actual bounce. The question is whether it's worth the cost of yet another response code to be able to tell the client the difference between "your message text looks like spam" and "you attempted to fake the envelope FROM". I tend to think this is not worth the cost (otherwise we'd have to add a special response code for "virus detected", "you used too much $random-drug advertisements", "looks like spam", "you've sent way too many messages in the last hour", "looks like you're faking the Received headers" etc) -- but I'm open to discussion and want to reach a consensus here. I just don't want to come up with something overly complex. If we add an explicit response code, clients will assume that servers will use it, and that raises the bar for servers to implement. What shall the client do when it sees the proposed INVALIDRETURNPATH? Is there any difference in the desired behavior compared to handling of POLICYDENIED? Honestly, I don't know and am interested in other people's opinion. > However, things like spam (AV) filtering could be done at APPEND or CATENATE time? I strongly object to that. If this filtering was done "globally", how could I possibly import data from my previous account to my new "spam-collection-for-auto-learning" folder? >>> 3. SENDER. I'm not sure what SMTP envelope part this relates to, is >>> it superfluous? If it's already in the message headers, why do we >>> need to specify it again here? It's not needed for SMTP delivery >>> (only need return path and forward path(s)) >> >> Oops, good catch -- the SENDER should not be there at all. I'll fix >> this in my next update. > I'm thinking if we have to parse and process headers anyway to deal with > BCC, then Sender could be useful still. You've suggested that in ESMTP, there's no such thing like a distinct "FROM" and "SENDER". I've amended my (currently unpublished) copy of the draft to only use a single "FROM" field for this purpose. Arguably, if the client didn't use this submission option field, a compliant server implementation MUST set it to a value obtained from the message contents. A good order of where to get the value from might be Resent-From, Sender, From (but I won't try to pretend that I've read the relevant RFC about these headers yet, so please take this order with a big grain of salt). > From my understanding, the main issue is that some record needs to be > kept somewhere in the mail client about what email was sent to whom. > This means if a message was BCCed to someone, then in the sent items > folder, the BCC header should remain visible. However, it needs to be > removed for actual delivery. > > Therefore the server needs to parse and remove the BCC header. > Other things should be done by the client, such as copying or moving to > say sent items folder, Agreed. Client is responsible for building the actual message, including all of its headers. These headers should contain information about where it was sent to. This message body MUST be stored on the IMAP server completely unchanged (if only to guarantee the usual IMAP requirements about immutability). OTOH, I agree that MTAs MUST "process Bcc headers correctly", i.e. the identity of any recipient listed in Bcc MUST NOT be revealed to any other recipient. This means that the party handling the UID SUBMIT command (be it the IMAP server, the `sendmail` binary or the first ESMTP MTA to which the IMAP server submits the message) MUST rewrite message headers. I've verified that Postfix (RHEL's postfix-2.6.6-2.2.el6_1) behaves that way. I don't have any experience with any other MTA. > This is a new proposal, so I think we can assume people would implement > it properly. > > In fact having the tokens for RECIPIENT, FROM etc is just bloat. Also, > lists (even empty ones) are much easier to parse than token value pairs, > and easier to deal with corner cases (e.g. missing "RECIPIENT" or > missing recipient value) > > If you look at the BODYSTRUCTURE response, it's perfectly fine to > specify like Please tell that to Google who still produces invalid BODYSTRUCTURE responses on e-mails with attached message/rfc822 parts (last checked a few months ago, anyway). As a client developer, I can assure you that it is NOT FUN to try to guess what five fields out of a sequence of twenty mandatory fields are missing today. I won't willingly inflict the same on any other programmer unless I'm in a really, really nasty mood. > submit = "SUBMIT" SP submit-params > submit-params = "(" uniqueid SP forward-path [SP return-path] [SP > dsn-spec] ")" > return-path = nstring > forward-path = "HEADERS" / "(" string [*(SP string)] ")" > dsn-spec = "(" dsn-token [*(SP dsn-token)] ")" > dsn-token = "DELAY" / "FAILURE" / "SUCCESS" This command can indeed be specified in many possible ways. I don't see much value in putting the UID in the same parenthesized list as the rest of the data, for example, but that's just a very, very minor point. I will, however, always prefer a self-describing structure (i.e. with the superfluous "FROM", "DSN" and "RECIPIENT" headers) over something which is more compact for the reasons stated above. It will take a well-explained technical reason to change my opinion on this one. > this solves several issues as well, e.g. the BNF doesn't allow multiple > dsn-spec, or sub-option-from options (return-path). That would indeed be a nice benefit, but not something I consider a requirement. > Since dsn-spec is optional, it makes no sense to allow a NIL value. > Also, since it's a list, it is distinguishable from return-path. You have to be able to specify DSN of: 1) default, implementation defined behavior (i.e. "DSN not specified at all" in my proposal) 2) no DSN at all, even for failures (i.e. DSN NIL in my proposal) 3) a non-empty subset of the three available options with possibility to include all of them Your grammar doesn't allow for option two. Maybe my draft should make this distinction more obvious, given you interpreted it in a wrong way. >> CATENATE is very useful on its own, even without BURL. In fact, it is >> an excellent feature to have along this UID SUBMIT draft. > How would it be used without some way to deliver the result somewhere? > Or maybe only useful in that case with shared folders or something? There are three steps in today's mode of e-mail sending where significant amounts of data are transferred: 1) create the message somehow (you might have to download attachments of existing messages if you're forwarding them) 2) upload the message to the IMAP server 3) send the message through SMTP CATENATE can significantly reduce the amount of data in steps 1) and 2) -- if you're e.g. forwarding a big message, you can compose its copy for the Sent folder with almost no data transfers at all. If the original message contained a small text/plain part with a huge attachment, a good client will not have to download said attachment at all. Another case for CATENATE is being able to strip-out attachments from existing mail. If the user clicks on "delete this attachment", client can issue APPEND ... CATENATE that refers to all other message parts, again reducing the amount of data to transfer. Cheers, Jan From adrien@qbik.com Mon Jul 23 03:51:58 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBCC21F8699 for ; Mon, 23 Jul 2012 03:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=-2.109, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQWefHNsOVWY for ; Mon, 23 Jul 2012 03:51:57 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id CDDD921F8670 for ; Mon, 23 Jul 2012 03:51:56 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.154.179]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3441)) with SMTP id <0019154371@smtp.qbik.com>; Mon, 23 Jul 2012 22:51:55 +1200 From: "Adrien de Croy" To: =?utf-8?q?Jan=20Kundr=c3=a1t?= , "imapext@ietf.org" Date: Mon, 23 Jul 2012 10:51:54 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <500D0A76.9020805@flaska.net> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 10:51:58 -0000 ------ Original Message ------ From: "Jan Kundr=C3=A1t" >On 07/22/12 16:54, Arnt Gulbrandsen wrote:=20 >>Suggest some that are legitimate in the context of an IMAP client?=20 >> >>IMO, envelope from more or less has to match the header addresses.=20 >>The=20 >>exceptions are firmly in server or service land, not in IMAP client=20 >>land.=20 > >A group of friends is going on a vacation and for some reason they=20 >haven't set up a mailing list for coordination. Alice sent a mail to=20 >all of them, but Bob's mailbox was broken at the time of submission=20 >and his mail server refused to accept this message (or Alice just used=20 >Bob's old e-mail address which he no longer reads -- yes, I've seen=20 >such a situation).=20 > >Now Alice and the rest of the team has left for a short pre-vacation=20 >vacation and I'm the only one hard working guy left to "forward" the=20 >mail to Bob. I'd still like to retain the original Message-Id etc for=20 >threading, but I also want to be able to use DSN to see whether the=20 >message made it this time.=20 > >Hence I take the original message from Alice as delivered to my=20 >mailbox and issue `UID SUBMIT x (FROM "jkt@flaska.net" RECIPIENT=20 >"bob@example.org")`. This requires support for return-path not=20 >matching the original From header.=20 I think what you would do is make a copy, edit the header so that From=20 is from you, and edit the subject so it's obviously a forward from you=20 of the original message. > >This is admittedly a rather convoluted example, but I think that it is=20 >actually a valid use case. Or maybe it should be done by just taking=20 >the message as-is, prepending the Sender header and letting the MTA=20 >perform its extraction -- is that the case?=20 > >If the MTA always used a return-path matching my account credentials,=20 >that would work as well. That would have a disadvantage of requiring=20 >knowledge of the authenticated user at the MTA layer, though; I can=20 >imagine deployments where this would imply extra work for the=20 >sysadmin.=20 I was planning on getting the IMAP server to edit the headers etc=20 before submitting to the MTA. It should have all the information it=20 needs, since the submitter is logged into it. Adrien > > >Opinions?=20 > >Cheers,=20 >Jan=20 >-- Trojita, a fast e-mail client -- http://trojita.flaska.net/=20 > >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From adrien@qbik.com Mon Jul 23 04:12:25 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1483521F8620 for ; Mon, 23 Jul 2012 04:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-4.352, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, SARE_RAND_1=2, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHWY+lB1adCJ for ; Mon, 23 Jul 2012 04:12:23 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5C82C21F8505 for ; Mon, 23 Jul 2012 04:12:23 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.154.179]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3441)) with SMTP id <0019154384@smtp.qbik.com>; Mon, 23 Jul 2012 23:12:21 +1200 From: "Adrien de Croy" To: =?utf-8?q?Jan=20Kundr=c3=a1t?= , "imapext@ietf.org" Date: Mon, 23 Jul 2012 11:12:19 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <500D154F.20809@flaska.net> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:12:25 -0000 ------ Original Message ------ From: "Jan Kundr=C3=A1t" >Hi Adrien,=20 > >On 07/23/12 00:41, Adrien W. de Croy wrote:=20 >>I was thinking maybe the server needs to advertise whether FROM (smtp=20 >>return-path) is settable, otherwise it is set by the mail server=20 >>admin.=20 >[...]=20 >>could be difficult for the client to figure out what went wrong,=20 >>unless=20 >>you put special return codes in so the client can know why the=20 >>submission was bounced.=20 > >s/bounced/rejected/, I guess (failing UID SUBMIT MUST NOT cause an=20 >SMTP-level bounce) -- just to prevent a possible misunderstanding, I'm=20 >sure you haven't meant an actual bounce.=20 yes sorry, I meant submission rejected by the IMAP server. IMAP server=20 can only do a certain amount of checking when validating submission,=20 and the MTA will do some more. The IMAP server can report errors to=20 the SUBMIT command, whereas the MTA will deal with issues in another=20 way (outside the scope of this) >The question is whether it's worth the cost of yet another response=20 >code to be able to tell the client the difference between "your=20 >message text looks like spam" and "you attempted to fake the envelope=20 >FROM". I tend to think this is not worth the cost (otherwise we'd have=20 >to add a special response code for "virus detected", "you used too=20 >much $random-drug advertisements", "looks like spam", "you've sent way=20 >too many messages in the last hour", "looks like you're faking the=20 >Received headers" etc) --=20 I don't think I'd bother with that many. I'd use invariant tokens for=20 the types of errors, and some may include some reason text. What are=20 the main expected failure cases? * syntax error * User may not submit * return path rejected * one or more forward paths rejected * system error (e.g. out of disk). * etc ? >but I'm open to discussion and want to reach a consensus here. I just=20 >don't want to come up with something overly complex. If we add an=20 >explicit response code, clients will assume that servers will use it,=20 >and that raises the bar for servers to implement.=20 these are not hard things to do surely? > >What shall the client do when it sees the proposed INVALIDRETURNPATH?=20 >Is there any difference in the desired behavior compared to handling=20 >of POLICYDENIED? Honestly, I don't know and am interested in other=20 >people's opinion.=20 I foresee a setting in email clients which are like=20 [x] submit messages using IMAP [x] use return-path associated with your IMAP account or similar type of concept (wording would likely be quite different). So the response code has a big impact on what the user does next. If=20 it's policy denied, they need to see their sys admin, or turn off=20 submission through IMAP. If it's invalid return path, they need to alter their return-path=20 settings. Tech support will want to be able to distinguish for debugging /=20 rectification of the issue. > > >>However, things like spam (AV) filtering could be done at APPEND or=20 >>CATENATE time?=20 > >I strongly object to that. If this filtering was done "globally", how=20 >could I possibly import data from my previous account to my new=20 >"spam-collection-for-auto-learning" folder?=20 It's already done. If you don't like it I guess you'd have to get it=20 turned off on your mailbox. It's not a particularly wide-spread requirement to store viruses in=20 your mailbox, and I don't think we should deny others of AV protection=20 so you can do so. > > >>>>3. SENDER. I'm not sure what SMTP envelope part this relates to, is=20 >>>>it superfluous? If it's already in the message headers, why do we=20 >>>>need to specify it again here? It's not needed for SMTP delivery=20 >>>>(only need return path and forward path(s))=20 >>> >>>Oops, good catch -- the SENDER should not be there at all. I'll fix=20 >>>this in my next update.=20 >>I'm thinking if we have to parse and process headers anyway to deal=20 >>with=20 >>BCC, then Sender could be useful still.=20 > >You've suggested that in ESMTP, there's no such thing like a distinct=20 >"FROM" and "SENDER". I've amended my (currently unpublished) copy of=20 >the draft to only use a single "FROM" field for this purpose.=20 > >Arguably, if the client didn't use this submission option field, a=20 >compliant server implementation MUST set it to a value obtained from=20 >the message contents.=20 are you talking about the compliant server scraping return-path out of=20 headers, or providing a Sender field into the headers? >A good order of where to get the value from might be Resent-From,=20 >Sender, From (but I won't try to pretend that I've read the relevant=20 >RFC about these headers yet, so please take this order with a big=20 >grain of salt).=20 I would make it optional on the server maybe, where it can just=20 optionally use some pre-determined value associated with the IMAP=20 account. e.g. user is logged into IMAP as bob, submits a message so return path=20 is bob@example.org > > >> From my understanding, the main issue is that some record needs to=20 >>be=20 >>kept somewhere in the mail client about what email was sent to whom.=20 >>This means if a message was BCCed to someone, then in the sent items=20 >>folder, the BCC header should remain visible. However, it needs to be=20 >>removed for actual delivery.=20 >> >> Therefore the server needs to parse and remove the BCC header.=20 >>Other things should be done by the client, such as copying or moving=20 >>to=20 >>say sent items folder,=20 > >Agreed. Client is responsible for building the actual message,=20 >including all of its headers. These headers should contain information=20 >about where it was sent to. This message body MUST be stored on the=20 >IMAP server completely unchanged (if only to guarantee the usual IMAP=20 >requirements about immutability).=20 > >OTOH, I agree that MTAs MUST "process Bcc headers correctly", i.e. the=20 >identity of any recipient listed in Bcc MUST NOT be revealed to any=20 >other recipient. This means that the party handling the UID SUBMIT=20 >command (be it the IMAP server, the `sendmail` binary or the first=20 >ESMTP MTA to which the IMAP server submits the message) MUST rewrite=20 >message headers.=20 that can be up to the implementation to decide how. Our MTA doesn't do=20 BCC processing, so the IMAP server would do it on behalf of the client.=20 It may mean multiple copies are made for delivery. > > >I've verified that Postfix (RHEL's postfix-2.6.6-2.2.el6_1) behaves=20 >that way. I don't have any experience with any other MTA.=20 > >>This is a new proposal, so I think we can assume people would=20 >>implement=20 >>it properly.=20 >> >>In fact having the tokens for RECIPIENT, FROM etc is just bloat.=20 >>Also,=20 >>lists (even empty ones) are much easier to parse than token value=20 >>pairs,=20 >>and easier to deal with corner cases (e.g. missing "RECIPIENT" or=20 >>missing recipient value)=20 >> >>If you look at the BODYSTRUCTURE response, it's perfectly fine to=20 >>specify like=20 > >Please tell that to Google who still produces invalid BODYSTRUCTURE=20 >responses on e-mails with attached message/rfc822 parts (last checked=20 >a few months ago, anyway). As a client developer, I can assure you=20 >that it is NOT FUN to try to guess what five fields out of a sequence=20 >of twenty mandatory fields are missing today. I won't willingly=20 >inflict the same on any other programmer unless I'm in a really,=20 >really nasty mood.=20 Even if I ask nicely? It's servers that need to parse this. I'm just saying it's easier to=20 deal with a list of recipients than have to match token value etc. Your BNF will be a lot more code for me, and more corner cases. It=20 shouldn't be any more or less difficult for a client to generate the=20 request. > > >>submit =3D "SUBMIT" SP submit-params=20 >>submit-params =3D "(" uniqueid SP forward-path [SP return-path] [SP=20 >>dsn-spec] ")"=20 >>return-path =3D nstring=20 >>forward-path =3D "HEADERS" / "(" string [*(SP string)] ")"=20 >>dsn-spec =3D "(" dsn-token [*(SP dsn-token)] ")"=20 >>dsn-token =3D "DELAY" / "FAILURE" / "SUCCESS"=20 > >This command can indeed be specified in many possible ways. I don't=20 >see much value in putting the UID in the same parenthesized list as=20 >the rest of the data sure, it doesn't matter if it's in the list or not. > for example, but that's just a very, very minor point. I will,=20 >however, always prefer a self-describing structure (i.e. with the=20 >superfluous "FROM", "DSN" and "RECIPIENT" headers) over something=20 >which is more compact for the reasons stated above.=20 problem is you use tags like that, it means order becomes variable. =20 It's much easier to deal with fixed order of parameters. Once you fix order of parameters, and use a list for recipients to=20 remove corner cases about missing or duplicate tags etc etc, you end up=20 with a structure something like I proposed. Google may have trouble generating BODYSTRUCTURE (we did too for a long=20 time), but this structure is much more simple, and furthermore, servers=20 parse it, rather than generate it. > > >It will take a well-explained technical reason to change my opinion on=20 >this one.=20 > >>this solves several issues as well, e.g. the BNF doesn't allow=20 >>multiple=20 >>dsn-spec, or sub-option-from options (return-path).=20 > >That would indeed be a nice benefit, but not something I consider a=20 >requirement.=20 > >>Since dsn-spec is optional, it makes no sense to allow a NIL value.=20 >>Also, since it's a list, it is distinguishable from return-path.=20 > >You have to be able to specify DSN of:=20 > >1) default, implementation defined behavior (i.e. "DSN not specified=20 >at all" in my proposal)=20 >2) no DSN at all, even for failures (i.e. DSN NIL in my proposal)=20 OK I missed that case. So Nil has some meaning by its presence that is different to its=20 absence. Absense =3D default behaviour, Nil =3D no DSN. That's fine. Could be more obvious maybe if you added some more tokens, such as=20 dsn-spec =3D "NONE" / "DEFAULT" / "(" dsn-token [*(SP dsn-token)] ")"=20 dsn-token =3D "DELAY" / "FAILURE" / "SUCCESS"=20 > >3) a non-empty subset of the three available options with possibility=20 >to include all of them=20 > >Your grammar doesn't allow for option two. Maybe my draft should make=20 >this distinction more obvious, given you interpreted it in a wrong=20 >way.=20 > >>>CATENATE is very useful on its own, even without BURL. In fact, it=20 >>>is=20 >>>an excellent feature to have along this UID SUBMIT draft.=20 >>How would it be used without some way to deliver the result=20 >>somewhere?=20 >>Or maybe only useful in that case with shared folders or something?=20 > >There are three steps in today's mode of e-mail sending where=20 >significant amounts of data are transferred:=20 > >1) create the message somehow (you might have to download attachments=20 >of existing messages if you're forwarding them)=20 >2) upload the message to the IMAP server=20 >3) send the message through SMTP=20 > >CATENATE can significantly reduce the amount of data in steps 1) and=20 >2) -- if you're e.g. forwarding a big message, you can compose its=20 >copy for the Sent folder with almost no data transfers at all. If the=20 >original message contained a small text/plain part with a huge=20 >attachment, a good client will not have to download said attachment at=20 >all.=20 OK, thanks for that. Regards Adrien > > >Another case for CATENATE is being able to strip-out attachments from=20 >existing mail. If the user clicks on "delete this attachment", client=20 >can issue APPEND ... CATENATE that refers to all other message parts,=20 >again reducing the amount of data to transfer.=20 > >Cheers,=20 >Jan=20 >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From arnt@gulbrandsen.priv.no Mon Jul 23 09:14:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C4E21F8637 for ; Mon, 23 Jul 2012 09:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW4X26qDsvIz for ; Mon, 23 Jul 2012 09:14:55 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BC621F8629 for ; Mon, 23 Jul 2012 09:14:53 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 41375F8DCFA; Mon, 23 Jul 2012 16:14:52 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343060091-12416-12415/11/6; Mon, 23 Jul 2012 16:14:51 +0000 Message-Id: <500D787D.2090509@gulbrandsen.priv.no> Date: Mon, 23 Jul 2012 18:14:53 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: Ned Freed References: <500C04B5.3030206@flaska.net> <500C140D.2010000@gulbrandsen.priv.no> <01OI6KIY5A200006TF@mauve.mrochek.com> In-Reply-To: <01OI6KIY5A200006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 16:14:56 -0000 On 07/23/2012 04:54 PM, Ned Freed wrote: > Off the top of my head: MDNs (required to have a null MAIL FROM), Good point. Sufficient, perhaps. > some > send-on-behalf-of scenarios, client-side mailing lists, some DSN > correlation mechanisms, and some multi-author scenarios. I've seen software to do all of that, but not IMAP clients. "An IMAP extension to allow the current user to send mail as himself" is one thing. "An IMAP extension to do everything a SUBMIT server can" is quite another, and IMO problematic. Jan, what do you want your document to be? Arnt From adrien@qbik.com Mon Jul 23 17:26:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25AC11E80F6 for ; Mon, 23 Jul 2012 17:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-2.495, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTW7j1YEIAM9 for ; Mon, 23 Jul 2012 17:26:41 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id EDC3A11E80F3 for ; Mon, 23 Jul 2012 17:26:40 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3441)) with SMTP id <0019155755@smtp.qbik.com>; Tue, 24 Jul 2012 12:26:36 +1200 From: "Adrien W. de Croy" To: "imapext@ietf.org" Date: Tue, 24 Jul 2012 00:26:36 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <500D787D.2090509@gulbrandsen.priv.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 00:26:42 -0000 =EF=BB=BF Hi all was just reading through CATENATE RFC, and it mentioned hard limit of=20 4GB for any message in any mailbox. The time where this will be a problem is fast approaching. It already=20 is for some people apparently. What is actually stopping current BNF=20 from handling larger sizes? Since we always transmit and receive=20 (parse) textual representations of numbers, then moving to 64 bit is=20 simply a matter of using a different conversion function? Is this something we should write an extension for? >From 3501 the issues are with=20 number =3D 1*DIGIT ; Unsigned 32 bit number and nz-number =3D 1*DIGIT ; Non-zero unsigned 32-bit integer which are used for msgnos, body parts / sections, ranges, searches=20 (e.g. SMALLER), counts of things. We could either upgrade number and nz-number to 64 bit, or introduce a=20 big-number production which would be a lot more work but possibly lower=20 impact on implementors. In fact the 32 bit limit is only a comment in the BNF, I can't find it=20 anywhere else. Regards Adrien From adrien@qbik.com Mon Jul 23 18:21:57 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB12311E8085 for ; Mon, 23 Jul 2012 18:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=-1.724, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv2okKqBNa18 for ; Mon, 23 Jul 2012 18:21:57 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9F63E11E80FF for ; Mon, 23 Jul 2012 18:21:56 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3441)) with SMTP id <0019155837@smtp.qbik.com>; Tue, 24 Jul 2012 13:21:54 +1200 From: "Adrien W. de Croy" To: "Lyndon Nerenberg" Date: Tue, 24 Jul 2012 01:21:54 +0000 Content-Type: multipart/alternative; boundary="------=_MB6F89EB28-8DD4-44D5-9826-BC6F7D2CDA4F" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 01:21:57 -0000 --------=_MB6F89EB28-8DD4-44D5-9826-BC6F7D2CDA4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 ------ Original Message ------ From: "Lyndon Nerenberg" >On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote: > > >> >>In fact the 32 bit limit is only a comment in the BNF, I can't find it= anywhere else. >> > > >Comments in the BNF are sometimes used to outline restrictions on the prot= ocol. These 'comments' have equal standing with the BNF itself. > >32-bits is core to the protocol, and isn't going to change. > Forever is a long time. Messages continue to get bigger and bigger. Links get faster. People=20 use mail for more things. 32 bits is not a requirement of the protocol itself. Moses didn't come=20 down from the mountain with a bit of stone that said "thou shalt not=20 make emails larger than 4GB". It was an implementation decision that polluted the protocol. I'm sure=20 4GB seemed like an inconceivably enormous message size back in the=20 early 80's. It's still enormous, but not inconceivable now. FWIW, we already support 64 bit sizes. So if anyone sends a > 4GB=20 message to a WinGate IMAP mailbox, it will go in, and the size will be=20 reported correctly. I guess the clients will barf on that if they=20 don't support > 32 bit sizes. So actually, it already did change. What's the alternative you suggest? a) we should for eternity reject any message > 4GB destined for IMAP? b) advertise a CAPABILITY of 64BIT or something, and "hide" big=20 messages from small clients? c) make IMAP5 64 bit by default... d) do nothing and wait. Adrien > > >--lyndon > > > --------=_MB6F89EB28-8DD4-44D5-9826-BC6F7D2CDA4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
------ Original Message ------
From: "Lynd= on Nerenberg" <lyndon@orthanc.ca>
On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote:



In fact the 32 bit limit is only a comment in the BNF, I can't find it anyw=
here else.



Comments in the BNF are sometimes used to outline restrictions on the proto=
col. These 'comments' have equal standing with the BNF itself.

32-bits is core to the protocol, and isn't going to change.
 
Forever is a long time.
 
Messages continue to get bigger and= bigger.  Links get faster.  People use mail for more things.
 
32 bits is not a requirement of the= protocol itself.  Moses didn't come down from the mountain with= a bit of stone that said "thou shalt not make emails larger than 4GB".
 
It was an implementation decision = that polluted the protocol.  I'm sure 4GB seemed like an inconceivably= enormous message size back in the early 80's.  It's still enormous,= but not inconceivable now.
 
FWIW, we already support 64 bit sizes= .  So if anyone sends a > 4GB message to a WinGate IMAP mailbox,= it will go in, and the size will be reported correctly.  I guess the= clients will barf on that if they don't support > 32 bit sizes.
 
So actually, it already did change.
 
What's the alternative you suggest?
 
a) we should for eternity reject any= message > 4GB destined for IMAP?
b) advertise a CAPABILITY of 64BIT= or something, and "hide" big messages from small clients?
c) make IMAP5 64 bit by default...
d) do nothing and wait.
 
Adrien
 

 

--lyndon
--------=_MB6F89EB28-8DD4-44D5-9826-BC6F7D2CDA4F-- From randy@qualcomm.com Mon Jul 23 18:48:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1582B11E8104 for ; Mon, 23 Jul 2012 18:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pUKkooICy0n for ; Mon, 23 Jul 2012 18:48:11 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1F011E80F3 for ; Mon, 23 Jul 2012 18:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1343094492; x=1374630492; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=6nfaTWlnr4MmVGlkwqq00DpOBEQrjdpxgEEKDrn5Gqo=; b=Qn2z3Ggpkzg8kozfngUfPLSGJeoepvT8Tky0Q/WT4Jyv/1JeUdS+XutN v1Z0HIwwKNvQkFmCpJlIPzyUFPLu2lhtaQcJ22C0BN3MVvKrMG/N55HR+ qj9Pr0bGzCG0sWF4/vLP1y8j31RlacyVWqwXsanSgdwU4y6nkk5yv3yxn M=; X-IronPort-AV: E=McAfee;i="5400,1158,6781"; a="211416153" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 23 Jul 2012 18:48:11 -0700 X-IronPort-AV: E=Sophos;i="4.77,641,1336374000"; d="scan'208";a="160161752" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jul 2012 18:48:11 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 23 Jul 2012 18:48:10 -0700 Received: from loud.pensive.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 23 Jul 2012 18:48:09 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 23 Jul 2012 18:43:31 -0700 To: "Adrien W. de Croy" , Lyndon Nerenberg From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Cc: "imapext@ietf.org" Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 01:48:12 -0000 At 1:21 AM +0000 7/24/12, Adrien W. de Croy wrote: > 32 bits is not a requirement of the protocol itself. Moses didn't > come down from the mountain with a bit of stone that said "thou > shalt not make emails larger than 4GB". > > It was an implementation decision that polluted the protocol. I'm > sure 4GB seemed like an inconceivably enormous message size back in > the early 80's. It's still enormous, but not inconceivable now. As an aside, back in the early days of IMAP, I tried to push for larger UID sizes, since I was trying to design a mail system capable of handling very large mailboxes, and thought 32 bits was not enough (the system I used then had 48-bit words). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Automobile: A four-wheeled vehicle that runs up hills and down pedestrians. From randy@qualcomm.com Mon Jul 23 19:20:30 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1627721F85C9 for ; Mon, 23 Jul 2012 19:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDWPho9pJn1u for ; Mon, 23 Jul 2012 19:20:29 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1893721F85C7 for ; Mon, 23 Jul 2012 19:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1343096429; x=1374632429; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type: content-transfer-encoding:x-random-sig-tag: x-originating-ip; bh=8uDFQ0iVN9B3mUoNLruWAOvMZLddwRKD2yddAzfVWKo=; b=MT5gCJ4UORpIJ/qaKHEZ5IzGB7r2N37ibkTYDfMxcSLkxTzsE6aK+l1B eYpOcGtSMVIxk1qUnLzV0j1j09SIttNcBD/C89UudLrwBpE1o6K1/ZiKd lu1KscLhFoRd6hgyeKQWpPHVWA2D9LhDaFvzFNvekMBQO94xnSCVv9CAX E=; X-IronPort-AV: E=McAfee;i="5400,1158,6781"; a="211423602" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 23 Jul 2012 19:20:29 -0700 X-IronPort-AV: E=Sophos;i="4.77,641,1336374000"; d="scan'208";a="295315550" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jul 2012 19:20:16 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 23 Jul 2012 19:20:09 -0700 Received: from loud.pensive.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 23 Jul 2012 19:20:09 -0700 Message-ID: In-Reply-To: <500C140D.2010000@gulbrandsen.priv.no> References: <500C04B5.3030206@flaska.net> <500C140D.2010000@gulbrandsen.priv.no> X-Mailer: Eudora for Mac OS X Date: Mon, 23 Jul 2012 19:10:04 -0700 To: Arnt Gulbrandsen , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 02:20:30 -0000 At 4:54 PM +0200 7/22/12, Arnt Gulbrandsen wrote: > On 07/22/2012 03:48 PM, Jan Kundr=E1t wrote: >> The ESMTP allows for this, and I believe that there are legitimate >> reasons for envelope-From being different than header-From or even >> account-id (think mailing list managers). > > Suggest some that are legitimate in the context of an IMAP client? > > IMO, envelope from more or less has to match=20 > the header addresses. The exceptions are firmly=20 > in server or service land, not in IMAP client=20 > land. I rely heavily on Eudora's ability to allow=20 free-form editing of the header 'From' field,=20 because I use one-off addresses in many contexts,=20 and don't want to bother creating new=20 accounts/personalities for each. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- No man is a hero to his wife's psychiatrist. --Eric Berne From adrien@qbik.com Tue Jul 24 00:12:28 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484C211E811C for ; Tue, 24 Jul 2012 00:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=-1.681, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmyoX9oNu+t3 for ; Tue, 24 Jul 2012 00:12:27 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5786811E8119 for ; Tue, 24 Jul 2012 00:12:26 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.154.179]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3441)) with SMTP id <0019156178@smtp.qbik.com>; Tue, 24 Jul 2012 19:12:23 +1200 From: "Adrien de Croy" To: "Lyndon Nerenberg" Date: Tue, 24 Jul 2012 07:12:22 +0000 Content-Type: multipart/alternative; boundary="------=_MB30657854-C8B6-4878-8C82-B5B95F3FE5E3" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 07:12:28 -0000 --------=_MB30657854-C8B6-4878-8C82-B5B95F3FE5E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 =EF=BB=BF ------ Original Message ------ From: "Lyndon Nerenberg" >On 2012-07-23, at 18:21 PM, Adrien W. de Croy wrote: > > >> >>What's the alternative you suggest? >> > > >As you alluded, moving beyond 32 bits means a new protocol beyond IMAP4. > >But first I ask, where are these 4 GB email messages you keep sending arou= nd? > I did ask myself that. then I decided I wouldn't try to answer that for everyone else. The recording studio below us commonly deals with files much bigger=20 than that. Why should email be the poor cousin of other protocols and be unable to=20 deal with files of that size. I'm pretty sure a POP3 server can serve an email over 4GB. I checked=20 RFC1939 and didn't see any limits in there. So it's a bit sad that IMAP has this limit, when actually it could be=20 argued that the size of numbers is an implementation issue rather than=20 a protocol issue, and implementors could be guided to think about the=20 future (e.g. support bigger numbers). Adrien >Is sending them in and out of email mailboxes the most efficient way of= sending this data around? Before looking at ways to copy terabytes of = data back and forth, might a way of exchanging pointers to the data not = be more efficient use of resources? > >--lyndon > > > --------=_MB30657854-C8B6-4878-8C82-B5B95F3FE5E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
------ Original Message ------
From: "Lynd= on Nerenberg" <lyndon@orthanc.ca>
On 2012-07-23, at 18:21 PM, Adrien W. de Croy wrote:



What's the alternative you suggest?



As you alluded, moving beyond 32 bits means a new protocol beyond IMAP4.

But first I ask, where are these 4 GB email messages you keep sending aroun=
d?
I did ask myself that.
 
then I decided I wouldn't try to answ= er that for everyone else.
 
The recording studio below us commonl= y deals with files much bigger than that.
 
Why should email be the poor cousin= of other protocols and be unable to deal with files of that size.
 
I'm pretty sure a POP3 server can = serve an email over 4GB.  I checked RFC1939 and didn't see any limits= in there.
 
So it's a bit sad that IMAP has this= limit, when actually it could be argued that the size of numbers is an = implementation issue rather than a protocol issue, and implementors could= be guided to think about the future (e.g. support bigger numbers).
 
Adrien
Is sending them in and out of email mailboxes the most efficient way=
 of sending this data around?  Before looking at ways to copy terabytes =
of data back and forth, might a way of exchanging pointers to the data not=
 be more efficient use of resources?

--lyndon
--------=_MB30657854-C8B6-4878-8C82-B5B95F3FE5E3-- From arnt@gulbrandsen.priv.no Tue Jul 24 01:11:43 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265D421F84D6 for ; Tue, 24 Jul 2012 01:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgB5OMoKJZQd for ; Tue, 24 Jul 2012 01:11:42 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA9521F84D5 for ; Tue, 24 Jul 2012 01:11:42 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 55503FA031C; Tue, 24 Jul 2012 08:11:41 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343117500-24130-24129/10/1; Tue, 24 Jul 2012 08:11:40 +0000 Message-Id: <500E58C0.20408@gulbrandsen.priv.no> Date: Tue, 24 Jul 2012 10:11:44 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 08:11:43 -0000 On 07/24/2012 03:43 AM, Randall Gellens wrote: > As an aside, back in the early days of IMAP, I tried to push for larger > UID sizes, since I was trying to design a mail system capable of > handling very large mailboxes, and thought 32 bits was not enough (the > system I used then had 48-bit words). 31 bits (what I use, for fear of lurking signed ints) are enough in this case. If the mailbox is small but with high turnover, you can renumber quickly and issue a new uidvalidity. If the mailbox is big, what you have is an accident waiting to happen. I've tried various clients with million-message mailboxes, and... shall we say that I saw no point in trying ten-million mailboxes? Mailboxes that big can work, but only until someone tries to open it with the wrong client, and practically all clients are wrong. An accident waiting to happen. Arnt PS: Actually, maybe a went a little further than a million. Two, four, I don't know. A long way from two billion anyway. From tss@iki.fi Tue Jul 24 01:37:43 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D67121F8648 for ; Tue, 24 Jul 2012 01:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.476 X-Spam-Level: X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1grW9xVibW6b for ; Tue, 24 Jul 2012 01:37:42 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6B32D21F8645 for ; Tue, 24 Jul 2012 01:37:42 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id F41CB1AE87EC for ; Tue, 24 Jul 2012 11:37:40 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Timo Sirainen In-Reply-To: Date: Tue, 24 Jul 2012 11:37:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <686F6BB5-CD64-4A85-A85E-8AA35127C4F1@iki.fi> References: To: imapext@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 08:37:43 -0000 On 24.7.2012, at 4.21, Adrien W. de Croy wrote: > FWIW, we already support 64 bit sizes. So if anyone sends a > 4GB = message to a WinGate IMAP mailbox, it will go in, and the size will be = reported correctly. I guess the clients will barf on that if they don't = support > 32 bit sizes. Same for Dovecot since the first version. From alexey.melnikov@isode.com Tue Jul 24 02:22:43 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27C021F8602 for ; Tue, 24 Jul 2012 02:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.245 X-Spam-Level: X-Spam-Status: No, score=-101.245 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t77ee0F40HVr for ; Tue, 24 Jul 2012 02:22:42 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6021F8619 for ; Tue, 24 Jul 2012 02:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343121810; d=isode.com; s=selector; i=@isode.com; bh=1GcETeYZTuDQSSlFLLMu7iHV/6qhspjsd0zpJjDI6rc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=afDL+cvoRk1lpue57C98LIHHhSQgbXuH2TSWhijCOaE7ZJydiynKPwRlao0cWLWeDcQ/ww PAH/EmrA1KqabO6LmvVHNo2eYIR7/dsejhRPw3Z4QxjwDi5mrolL0TZjLro7MHYRL2bJi6 hmX7o8shaY/pAmkJjk+7/Cz0z5bzcbA=; Received: from [188.28.141.90] (188.28.141.90.threembb.co.uk [188.28.141.90]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 24 Jul 2012 10:23:30 +0100 References: In-Reply-To: Message-Id: <595A38B5-BC64-4131-8298-7D3C972BEE2A@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Tue, 24 Jul 2012 10:22:30 +0100 To: "Adrien W. de Croy" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-B716E1E3-5878-437C-B857-F3D69632EEF3 Content-Transfer-Encoding: 7bit Cc: Lyndon Nerenberg , "imapext@ietf.org" Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 09:22:43 -0000 --Apple-Mail-B716E1E3-5878-437C-B857-F3D69632EEF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Adrien, On 24 Jul 2012, at 02:21, "Adrien W. de Croy" wrote: > ------ Original Message ------ > From: "Lyndon Nerenberg" >> On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote: >>=20 >>>=20 >>> In fact the 32 bit limit is only a comment in the BNF, I can't find it a= nywhere else. >>=20 >>=20 >> Comments in the BNF are sometimes used to outline restrictions on the pro= tocol. These 'comments' have equal standing with the BNF itself. >>=20 >> 32-bits is core to the protocol, and isn't going to change. > =20 > Forever is a long time. > =20 > Messages continue to get bigger and bigger. Links get faster. People use= mail for more things. > =20 > 32 bits is not a requirement of the protocol itself. Moses didn't come do= wn from the mountain with a bit of stone that said "thou shalt not make emai= ls larger than 4GB". > =20 > It was an implementation decision that polluted the protocol. I'm sure 4G= B seemed like an inconceivably enormous message size back in the early 80's.= It's still enormous, but not inconceivable now. Actually I believe it improved interoperability at the time. > =20 > FWIW, we already support 64 bit sizes. So if anyone sends a > 4GB message= to a WinGate IMAP mailbox, it will go in, and the size will be reported cor= rectly. I guess the clients will barf on that if they don't support > 32 bi= t sizes. > =20 > So actually, it already did change. > =20 > What's the alternative you suggest? > =20 > a) we should for eternity reject any message > 4GB destined for IMAP? > b) advertise a CAPABILITY of 64BIT or something, and "hide" big messages f= rom small clients? Do something like that. Use ENABLE 64BIT to let clients see all messages. And I hope we are talking about message sizes (+ possibly quotas) and nothin= g else at this time... > c) make IMAP5 64 bit by default... > d) do nothing and wait. > =20 > Adrien >=20 >>=20 >> --lyndon >>=20 > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext --Apple-Mail-B716E1E3-5878-437C-B857-F3D69632EEF3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Hi Adrien,

On 24 Jul 2012, at 02:21, "Adrien W. de Croy" <adrien@qbik.com> wrote:

------ Original Message ------
From: "Lyndon Nerenberg" <lyndon@orthanc.ca>
On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote:



In fact the 32 bit limit is only a comment in the BNF, I can't find it anywhere else.



Comments in the BNF are sometimes used to outline restrictions on the protocol. These 'comments' have equal standing with the BNF itself.

32-bits is core to the protocol, and isn't going to change.
 
Forever is a long time.
 
Messages continue to get bigger and bigger.  Links get faster.  People use mail for more things.
 
32 bits is not a requirement of the protocol itself.  Moses didn't come down from the mountain with a bit of stone that said "thou shalt not make emails larger than 4GB".
 
It was an implementation decision that polluted the protocol.  I'm sure 4GB seemed like an inconceivably enormous message size back in the early 80's.  It's still enormous, but not inconceivable now.

Actually I believe it improved interoperability at the time.

 
FWIW, we already support 64 bit sizes.  So if anyone sends a > 4GB message to a WinGate IMAP mailbox, it will go in, and the size will be reported correctly.  I guess the clients will barf on that if they don't support > 32 bit sizes.
 
So actually, it already did change.
 
What's the alternative you suggest?
 
a) we should for eternity reject any message > 4GB destined for IMAP?
b) advertise a CAPABILITY of 64BIT or something, and "hide" big messages from small clients?

Do something like that. Use ENABLE 64BIT to let clients see all messages.

And I hope we are talking about message sizes (+ possibly quotas) and nothing else at this time...

c) make IMAP5 64 bit by default...
d) do nothing and wait.
 
Adrien

--lyndon
_______________________________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext
--Apple-Mail-B716E1E3-5878-437C-B857-F3D69632EEF3-- From arnt@gulbrandsen.priv.no Tue Jul 24 02:32:15 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A240621F85E4 for ; Tue, 24 Jul 2012 02:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUEQuuhuuAht for ; Tue, 24 Jul 2012 02:32:15 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B56421F8554 for ; Tue, 24 Jul 2012 02:32:15 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 582C2FA0B2D; Tue, 24 Jul 2012 09:32:14 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343122333-24130-24129/11/5; Tue, 24 Jul 2012 09:32:13 +0000 Message-Id: <500E6BA1.3040101@gulbrandsen.priv.no> Date: Tue, 24 Jul 2012 11:32:17 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <595A38B5-BC64-4131-8298-7D3C972BEE2A@isode.com> In-Reply-To: <595A38B5-BC64-4131-8298-7D3C972BEE2A@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 09:32:15 -0000 On 07/24/2012 11:22 AM, Alexey Melnikov wrote: > And I hope we are talking about message sizes (+ possibly quotas) and > nothing else at this time... Quotas may be 32-bit, but their fundamental unit is 1k blocks, so there's quite a bit of headroom there. Arnt From adrien@qbik.com Tue Jul 24 05:02:36 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94621F8636 for ; Tue, 24 Jul 2012 05:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=-1.640, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNPQFBHI1IyD for ; Tue, 24 Jul 2012 05:02:35 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBBD21F8627 for ; Tue, 24 Jul 2012 05:02:34 -0700 (PDT) Received: From [192.168.1.25] (unverified [122.57.154.179]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.3 (Build 3441)) with SMTP id <0019156489@smtp.qbik.com>; Wed, 25 Jul 2012 00:02:31 +1200 From: "Adrien de Croy" To: "Alexey Melnikov" Date: Tue, 24 Jul 2012 12:02:36 +0000 Content-Type: multipart/alternative; boundary="------=_MBE64ED12D-47F1-4DE6-BE23-E80EBFEE2513" Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Lyndon Nerenberg , "imapext@ietf.org" Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 12:02:36 -0000 --------=_MBE64ED12D-47F1-4DE6-BE23-E80EBFEE2513 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 =EF=BB=BF ------ Original Message ------ From: "Alexey Melnikov" >Hi Adrien, > >On 24 Jul 2012, at 02:21, "Adrien W. de Croy" wrote: > >>------ Original Message ------ >>From: "Lyndon Nerenberg" >>>On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote: >>> >>> >>>> >>>>In fact the 32 bit limit is only a comment in the BNF, I can't find = it anywhere else. >>>> >>> >>> >>>Comments in the BNF are sometimes used to outline restrictions on the= protocol. These 'comments' have equal standing with the BNF itself. >>> >>>32-bits is core to the protocol, and isn't going to change. >>> >>Forever is a long time. >>Messages continue to get bigger and bigger. Links get faster. =20 >>People use mail for more things. >>32 bits is not a requirement of the protocol itself. Moses didn't=20 >>come down from the mountain with a bit of stone that said "thou shalt=20 >>not make emails larger than 4GB". >>It was an implementation decision that polluted the protocol. I'm=20 >>sure 4GB seemed like an inconceivably enormous message size back in=20 >>the early 80's. It's still enormous, but not inconceivable now. > >Actually I believe it improved interoperability at the time.=20 I can believe it. I guess some people wanted to use 16 bit for some of=20 these things at the time. > >>FWIW, we already support 64 bit sizes. So if anyone sends a > 4GB=20 >>message to a WinGate IMAP mailbox, it will go in, and the size will=20 >>be reported correctly. I guess the clients will barf on that if they=20 >>don't support > 32 bit sizes. >>So actually, it already did change. >>What's the alternative you suggest? >>a) we should for eternity reject any message > 4GB destined for IMAP? >>b) advertise a CAPABILITY of 64BIT or something, and "hide" big=20 >>messages from small clients? > >Do something like that. Use ENABLE 64BIT to let clients see all=20 >messages. > >And I hope we are talking about message sizes (+ possibly quotas) and=20 >nothing else at this time... I can only really think of a use case for message sizes and quotas. =20 But creating another number type could be a pain in the neck. Another idea may be to report size in a separate attribute if it's over=20 4GB. E.g. report something like RFC822.SIZE 0 RFC822.SIZE64 5000000000 then "small" clients would still see the message, but only part of it=20 (or none). Hiding the message would be a pain, since you'd need to adjust msgnos Adrien > >>c) make IMAP5 64 bit by default... >>d) do nothing and wait. >>Adrien >> >>>--lyndon >>> >>> >>> >>_______________________________________________ >>imapext mailing list >>imapext@ietf.org >>https://www.ietf.org/mailman/listinfo/imapext --------=_MBE64ED12D-47F1-4DE6-BE23-E80EBFEE2513 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
------ Original Message = ------
From: "Alexey Melnikov" <alexey.melnikov@isode.= com>
Hi Adrien,

On 24 Jul 2012, at 02:21, "Adrien W. de Croy" <adrien@qbik.com> wrote:

------ Original Message ------
From: "Lyndon Nerenberg" <lyndon@orthanc.ca>
On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote:



In fact the 32 bit limit is only a comment in the BNF, I can't find it anyw=
here else.



Comments in the BNF are sometimes used to outline restrictions on the proto=
col. These 'comments' have equal standing with the BNF itself.

32-bits is core to the protocol, and isn't going to change.
 
Forever is a long time.
 
Messages continue to get bigger and bigger.  Links get faster.&nb= sp; People use mail for more things.
 
32 bits is not a requirement of the protocol itself.  Moses= didn't come down from the mountain with a bit of stone that said "thou = shalt not make emails larger than 4GB".
 
It was an implementation decision that polluted the protocol. = I'm sure 4GB seemed like an inconceivably enormous message size back in= the early 80's.  It's still enormous, but not inconceivable now.

Actually I believe it improved interoperability at the time.=
 
I can believe it.  I guess some people wanted to use 16 bit for= some of these things at the time.
 

 
FWIW, we already support 64 bit sizes.  So if anyone sends a >= 4GB message to a WinGate IMAP mailbox, it will go in, and the size will= be reported correctly.  I guess the clients will barf on that if they= don't support > 32 bit sizes.
 
So actually, it already did change.
 
What's the alternative you suggest?
 
a) we should for eternity reject any message > 4GB destined for = IMAP?
b) advertise a CAPABILITY of 64BIT or something, and "hide" big messag= es from small clients?

Do something like that. Use ENABLE 64BIT to let clients see= all messages.

And I hope we are talking about message sizes (+ possibly quotas) and= nothing else at this time...
 
I can only really think of a use case for message sizes and quotas.&nb= sp;
 
 But creating another number type could be a pain in the neck.
 
Another idea may be to report size in a separate attribute if it's = over 4GB.
 
E.g. report something like
 
RFC822.SIZE 0 RFC822.SIZE64 5000000000
 
then "small" clients would still see the message, but only part of = it (or none).
 
Hiding the message would be a pain, since you'd need to adjust msgnos<= /DIV>
 
Adrien

 

c) make IMAP5 64 bit by default...
d) do nothing and wait.
 
Adrien

--lyndon
_______________________________________________
= imapext mailing list
imape= xt@ietf.org
https://www= .ietf.org/mailman/listinfo/imapext
--------=_MBE64ED12D-47F1-4DE6-BE23-E80EBFEE2513-- From cyrus@daboo.name Tue Jul 24 07:00:40 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0560821F8631 for ; Tue, 24 Jul 2012 07:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6ELFC1Dnmkc for ; Tue, 24 Jul 2012 07:00:39 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 75DFE21F8629 for ; Tue, 24 Jul 2012 07:00:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C8B752BCB443; Tue, 24 Jul 2012 10:00:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bZV1+pccP3z; Tue, 24 Jul 2012 10:00:37 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 567962BCB436; Tue, 24 Jul 2012 10:00:36 -0400 (EDT) Date: Tue, 24 Jul 2012 10:00:33 -0400 From: Cyrus Daboo To: Adrien de Croy , Lyndon Nerenberg Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1247 Cc: imapext@ietf.org Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 14:00:40 -0000 Hi Adrien, --On July 24, 2012 7:12:22 AM +0000 Adrien de Croy wrote: > But first I ask, where are these 4 GB email messages you keep sending > around? > > > I did ask myself that. > > then I decided I wouldn't try to answer that for everyone else. > > The recording studio below us commonly deals with files much bigger than > that. > > Why should email be the poor cousin of other protocols and be unable to > deal with files of that size. > > I'm pretty sure a POP3 server can serve an email over 4GB. I checked > RFC1939 and didn't see any limits in there. > > So it's a bit sad that IMAP has this limit, when actually it could be > argued that the size of numbers is an implementation issue rather than a > protocol issue, and implementors could be guided to think about the > future (e.g. support bigger numbers). Are people really sending files that big via email as opposed to using a file sharing service like e.g. DropBox? File sharing service is going to be a lot more efficient at upload/download than email. Perhaps it is a shame that no one really supports message/external-body because that could have really helped the process of sending attachments "by reference" instead of "by value". -- Cyrus Daboo From atlauren@me.com Tue Jul 24 10:47:20 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E59D21F855F for ; Tue, 24 Jul 2012 10:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv-JBPJPH-Yw for ; Tue, 24 Jul 2012 10:47:19 -0700 (PDT) Received: from ismtp1.es.uci.edu (ismtp1.es.uci.edu [128.195.153.31]) by ietfa.amsl.com (Postfix) with ESMTP id E05F621F855E for ; Tue, 24 Jul 2012 10:47:19 -0700 (PDT) Received: from jungleland.nac.uci.edu (jungleland.nac.uci.edu [128.200.62.106]) (authenticated bits=0) by ismtp1.es.uci.edu (8.13.8/8.13.8) with ESMTP id q6OHl49S011039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jul 2012 10:47:07 -0700 X-UCInetID: atlauren Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Laurence In-Reply-To: Date: Tue, 24 Jul 2012 10:47:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cyrus Daboo X-Mailer: Apple Mail (2.1278) Cc: Adrien de Croy , Lyndon Nerenberg , imapext@ietf.org Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 17:47:20 -0000 On Jul 24, 2012, at 7:00 AM, Cyrus Daboo wrote: > --On July 24, 2012 7:12:22 AM +0000 Adrien de Croy = wrote: >=20 >> But first I ask, where are these 4 GB email messages you keep sending >> around? > > Are people really sending files that big via email as opposed to using = a file sharing service like e.g. DropBox? File sharing service is going = to be a lot more efficient at upload/download than email.=20 Many years ago, a couple of wiseacres here emailed a CD-ROM disk image = to each other, in order to see if it would arrive. It eventually did, = but took days to wind its way through the various queues. (I suppose = this was before a maximum message size limit was imposed on the central = systems.) Now that people routinely handle ISOs and video files, I = think it's entirely likely for someone to try sending a DVD-size file = via email. The mental association of "I am sending information to you" = does not carry a gate point of size vs delivery mechanism. > Perhaps it is a shame that no one really supports = message/external-body because that could have really helped the process = of sending attachments "by reference" instead of "by value". Over in vendorland, slipstream products such as Symantec Enterprise = Vault (an acquisition, used to be called something else) decouple the = binary payloads from message content parts. The former are stored = outside the mailstore, with just references stored in the mailstore. = These solutions are pricey, but the core email system is left smaller, = faster, and more manageable. --=20 Andrew Laurence Office of Information Technology=20 atlauren@uci.edu University of California, Irvine From arnt@gulbrandsen.priv.no Tue Jul 24 12:55:18 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6012621F85D8 for ; Tue, 24 Jul 2012 12:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn+P7pv3dFsx for ; Tue, 24 Jul 2012 12:55:18 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A0621F84D5 for ; Tue, 24 Jul 2012 12:55:17 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 31877F8E553; Tue, 24 Jul 2012 19:55:16 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343159714-24130-24129/10/5; Tue, 24 Jul 2012 19:55:14 +0000 Message-Id: <500EFDA8.1000704@gulbrandsen.priv.no> Date: Tue, 24 Jul 2012 21:55:20 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 19:55:18 -0000 On 07/24/2012 07:47 PM, Andrew Laurence wrote: > Many years ago, a couple of wiseacres here emailed a CD-ROM disk image = to each other, in order to see if it would arrive. It eventually did, = but took days to wind its way through the various queues. I did that in May, 1992. Laid waste to the NZ university network's=20 satellite link from Friday to the following Monday. A month or two later=20 the nation of South Africa upgraded its internet link from 9600 bps to=20 64kbps, only to encounter me on the first evening. Is there something to learn from this? Really big mail happens, and it's=20 not good for anything? Arnt From atlauren@me.com Tue Jul 24 13:45:55 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AE711E80AD for ; Tue, 24 Jul 2012 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpBH8MU+IWCS for ; Tue, 24 Jul 2012 13:45:54 -0700 (PDT) Received: from ismtp1.es.uci.edu (ismtp1.es.uci.edu [128.195.153.31]) by ietfa.amsl.com (Postfix) with ESMTP id DE69511E80A4 for ; Tue, 24 Jul 2012 13:45:54 -0700 (PDT) Received: from jungleland.nac.uci.edu (jungleland.nac.uci.edu [128.200.62.106]) (authenticated bits=0) by ismtp1.es.uci.edu (8.13.8/8.13.8) with ESMTP id q6OKjkhK032081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jul 2012 13:45:47 -0700 X-UCInetID: atlauren Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Laurence In-Reply-To: <500EFDA8.1000704@gulbrandsen.priv.no> Date: Tue, 24 Jul 2012 13:45:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500EFDA8.1000704@gulbrandsen.priv.no> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1278) Cc: imapext@ietf.org Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 20:45:55 -0000 On Jul 24, 2012, at 12:55 PM, Arnt Gulbrandsen wrote: > Is there something to learn from this? Really big mail happens, and = it's not good for anything? I don't know about that. These trail breakers cleared the path for = crazy uncles to email conspiracy video clips to everyone they've ever = met. :-) Nearly twenty years into an IT career, my takeaway is that the layperson = will never sufficiently associate the notion of storage quantity with a = file they want to send to another person. We will never win the battle = of educating users to not use email for sending files. While I find it = annoying, I don't dispute that sending files via email happens, and (for = the user) is useful and efficient. So long as messaging is email as we know it includes the ability for = users to bundle fat payloads with the transport of message content, we = will battle this problem. As disks and pipes get bigger it becomes less = of a problem, but there is always a point at which transport of a given = payload is destructive to the transport systems. Getting back to the original question, I think a size limit inherent to = the protocol should be corrected. There will always be a point at which = what was once absurdly large becomes commonplace. Leave it to the = operators to enforce limits that make sense for their site. (This site imposes a 30-million-byte limit.) -Andrew From alexey.melnikov@isode.com Tue Jul 24 13:57:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2611E80BB for ; Tue, 24 Jul 2012 13:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.218 X-Spam-Level: X-Spam-Status: No, score=-101.218 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxeqEVBsiqOC for ; Tue, 24 Jul 2012 13:57:11 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 241F211E80A4 for ; Tue, 24 Jul 2012 13:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343163484; d=isode.com; s=selector; i=@isode.com; bh=33PqpNNh4En3breaFSbRm8QhNrasjq6mIaQGohBGBm4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cukhmxSRnM/1tkrVs54vxlGciKM3TSBjkCDEBRfBUSNKRdR4CvMXG6tvYTFy+CHYvdHT2t VRO4sFLO2vu8SfvxkV3aH5gPt/wLmI1gzDm8GDIiDpDHRlih8Ri+992LcIcqVyk+rOVJ7n 5raG/QmTabaqBPelhrkdh9Ywo/WGvTk=; Received: from [188.29.131.120] (188.29.131.120.threembb.co.uk [188.29.131.120]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 24 Jul 2012 21:58:03 +0100 References: In-Reply-To: Message-Id: <23C162E4-BB41-44B7-B76F-DF652663C533@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Tue, 24 Jul 2012 21:57:05 +0100 To: Adrien de Croy MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-BA88C4A6-1E54-470B-A301-F4330235B17A Content-Transfer-Encoding: 7bit Cc: "imapext@ietf.org" Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 20:57:12 -0000 --Apple-Mail-BA88C4A6-1E54-470B-A301-F4330235B17A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 Jul 2012, at 13:02, "Adrien de Croy" wrote: >=20 > ------ Original Message ------ > From: "Alexey Melnikov" >> Hi Adrien, >>=20 >> On 24 Jul 2012, at 02:21, "Adrien W. de Croy" wrote: >>=20 >>> ------ Original Message ------ >>> From: "Lyndon Nerenberg" >>>> On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote: (snip) > =20 >>=20 >>> =20 >>> FWIW, we already support 64 bit sizes. So if anyone sends a > 4GB messa= ge to a WinGate IMAP mailbox, it will go in, and the size will be reported c= orrectly. I guess the clients will barf on that if they don't support > 32 b= it sizes. >>> =20 >>> So actually, it already did change. >>> =20 >>> What's the alternative you suggest? >>> =20 >>> a) we should for eternity reject any message > 4GB destined for IMAP? >>> b) advertise a CAPABILITY of 64BIT or something, and "hide" big messages= from small clients? >>=20 >> Do something like that. Use ENABLE 64BIT to let clients see all messages.= >>=20 >> And I hope we are talking about message sizes (+ possibly quotas) and not= hing else at this time... > =20 > I can only really think of a use case for message sizes and quotas.=20 > =20 > But creating another number type could be a pain in the neck. I think extending existing "number" and "nz-number" would be easier. However= the impact of the change still need to be studied, maybe changing some more= specific ABNF productions would be better. We only want literal sizes and v= alues returned in FETCH to change. > =20 > Another idea may be to report size in a separate attribute if it's over 4G= B. > =20 > E.g. report something like > =20 > RFC822.SIZE 0 Probably better to return non 0 size. > RFC822.SIZE64 5000000000 > =20 > then "small" clients would still see the message, but only part of it (or n= one). This might be Ok. But use of ENABLE would be required for the server to star= t sending these. > =20 > Hiding the message would be a pain, since you'd need to adjust msgnos > =20 Yes, that is true. > Adrien >=20 > =20 >>=20 >>> c) make IMAP5 64 bit by default... >>> d) do nothing and wait. >>> =20 >>> Adrien --Apple-Mail-BA88C4A6-1E54-470B-A301-F4330235B17A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
On 24 Jul 2012, at 13:02, "Adrien de Croy" <adrien@qbik.com> wrote:


------ Original Message ------
From: "Alexey Melnikov" <alexey.melnikov@isode.com>
Hi Adrien,

On 24 Jul 2012, at 02:21, "Adrien W. de Croy" <adrien@qbik.com> wrote:

------ Original Message ------
From: "Lyndon Nerenberg" <lyndon@orthanc.ca>
On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote:
 (snip)
 

 
FWIW, we already support 64 bit sizes.  So if anyone sends a > 4GB message to a WinGate IMAP mailbox, it will go in, and the size will be reported correctly.  I guess the clients will barf on that if they don't support > 32 bit sizes.
 
So actually, it already did change.
 
What's the alternative you suggest?
 
a) we should for eternity reject any message > 4GB destined for IMAP?
b) advertise a CAPABILITY of 64BIT or something, and "hide" big messages from small clients?

Do something like that. Use ENABLE 64BIT to let clients see all messages.

And I hope we are talking about message sizes (+ possibly quotas) and nothing else at this time...
 
I can only really think of a use case for message sizes and quotas. 
 
 But creating another number type could be a pain in the neck.

I think extending existing "number" and "nz-number" would be easier. However the impact of the change still need to be studied, maybe changing some more specific ABNF productions would be better. We only want literal sizes and values returned in FETCH to change.

 
Another idea may be to report size in a separate attribute if it's over 4GB.
 
E.g. report something like
 
RFC822.SIZE 0

Probably better to return non 0 size.

RFC822.SIZE64 5000000000
 
then "small" clients would still see the message, but only part of it (or none).

This might be Ok. But use of ENABLE would be required for the server to start sending these.

 
Hiding the message would be a pain, since you'd need to adjust msgnos
 

Yes, that is true.

Adrien

 

c) make IMAP5 64 bit by default...
d) do nothing and wait.
 
Adrien

--Apple-Mail-BA88C4A6-1E54-470B-A301-F4330235B17A-- From arnt@gulbrandsen.priv.no Tue Jul 24 14:01:20 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DC711E80BD for ; Tue, 24 Jul 2012 14:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyrs4JzTyIeT for ; Tue, 24 Jul 2012 14:01:20 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF8211E8072 for ; Tue, 24 Jul 2012 14:01:19 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 49612F8E559; Tue, 24 Jul 2012 21:01:19 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343163678-24130-24129/11/15; Tue, 24 Jul 2012 21:01:18 +0000 Message-Id: <500F0D24.4080802@gulbrandsen.priv.no> Date: Tue, 24 Jul 2012 23:01:24 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <23C162E4-BB41-44B7-B76F-DF652663C533@isode.com> In-Reply-To: <23C162E4-BB41-44B7-B76F-DF652663C533@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 21:01:20 -0000 On 07/24/2012 10:57 PM, Alexey Melnikov wrote: > This might be Ok. But use of ENABLE would be required for the server to > start sending these. Why? We've been through this in the context of EAI. Hide mail or do your best? Arnt From jkt@flaska.net Tue Jul 24 14:07:00 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12D911E80B5 for ; Tue, 24 Jul 2012 14:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJkMlnwT8as3 for ; Tue, 24 Jul 2012 14:06:59 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id B7EAE11E8072 for ; Tue, 24 Jul 2012 14:06:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAAND1CT5xpZ/2dsb2JhbABFhW+0FIEHgiABAQUOFQ8BBS0TEQsYAgIFEwMLAgIJAwIBAgFFEwgBAYgJBKgBkyeBIIpFgz6CCoESA5VJgRSOeYJhgV0 X-IronPort-AV: E=Sophos;i="4.77,648,1336341600"; d="scan'208";a="69409" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 24 Jul 2012 23:06:53 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 3274A3DA82 for ; Tue, 24 Jul 2012 23:06:53 +0200 (CEST) Message-ID: <500F0E5C.2080901@flaska.net> Date: Tue, 24 Jul 2012 23:06:36 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: <500C04B5.3030206@flaska.net> <500C140D.2010000@gulbrandsen.priv.no> <01OI6KIY5A200006TF@mauve.mrochek.com> <500D787D.2090509@gulbrandsen.priv.no> In-Reply-To: <500D787D.2090509@gulbrandsen.priv.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 21:07:00 -0000 On 07/23/12 18:14, Arnt Gulbrandsen wrote: > "An IMAP extension to allow the current user to send mail as himself" is > one thing. "An IMAP extension to do everything a SUBMIT server can" is > quite another, and IMO problematic. Jan, what do you want your document > to be? What I'd like to have is an ability to write a MUA submitting over IMAP which can do "everything that a MUA with support for ESMTP can do and would do under reasonable situations" -- so the goal is to make it possible to not use ESMTP at all for end-user clients. Mail list management is not a reasonable situation. MDNs, on the other hand, looks like a reasonable use case. That use case with Alice, Bob and me that I mentioned fall into the "reasonable" use cases category for me (albeit maybe close to the edge); other people might disagree with that. That is fine with me and I really want to reach a consensus representing what the IMAP server vendors are willing to implement, as long as it is "enough" for a "typical client" to replace its ESMTP submission. Thanks for your pointers, I agree that it's hard to find a balance between a bloated proposal and something which is too bare to be actually usable in real world. I admit that I do usually fall to the temptation of adding features "just because they are easy". With kind regards Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From alexey.melnikov@isode.com Tue Jul 24 14:08:01 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9C311E80B5 for ; Tue, 24 Jul 2012 14:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.217 X-Spam-Level: X-Spam-Status: No, score=-101.217 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5yI2c6Yu7mu for ; Tue, 24 Jul 2012 14:08:01 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 07B6C11E8072 for ; Tue, 24 Jul 2012 14:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343164133; d=isode.com; s=selector; i=@isode.com; bh=MIpzq0+R9T7ZRjPNES89ZMnCyWX9Jw2Cx49Dk3eS7rc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kaCfLwIEVsGmsCN8kaey1WxmKUxzjWsBAJ0t/afMCA30/J1ZdpdEjcEzxarHK6DuxOacw0 J/5DKeHdV1+BckbGPwEwWdHa6eD6oaoo3TRrUJm11+4C/DDd2xraLnAyXd8/uNvEFhbb3g j7MJ4Ro8i6gmQVRbXbmj/O9QF3NWT3E=; Received: from [188.29.131.120] (188.29.131.120.threembb.co.uk [188.29.131.120]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 24 Jul 2012 22:08:53 +0100 References: <23C162E4-BB41-44B7-B76F-DF652663C533@isode.com> <500F0D24.4080802@gulbrandsen.priv.no> In-Reply-To: <500F0D24.4080802@gulbrandsen.priv.no> Message-Id: <0C1B5456-9806-475F-9626-F2CAB8B81817@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Tue, 24 Jul 2012 22:07:55 +0100 To: Arnt Gulbrandsen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "imapext@ietf.org" Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 21:08:01 -0000 On 24 Jul 2012, at 22:01, Arnt Gulbrandsen wrote:= > On 07/24/2012 10:57 PM, Alexey Melnikov wrote: >> This might be Ok. But use of ENABLE would be required for the server to >> start sending these. >=20 > Why? Because IMAP servers are not supposed to send unsolicited FETCH items client= s don't know how to parse. >=20 > We've been through this in the context of EAI. Hide mail or do your best Well, maybe. It is not exactly the same case, the message is a valid RFC 532= 2 message, it is just long ;)= From jkt@flaska.net Tue Jul 24 14:32:11 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4DC21F84FB for ; Tue, 24 Jul 2012 14:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=1.232, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzVlPwLxOn7j for ; Tue, 24 Jul 2012 14:32:10 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id C235521F84F8 for ; Tue, 24 Jul 2012 14:32:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGMTD1CT5xpZ/2dsb2JhbABFhW+0FIEHgiABAQQBIwQLAQU1CwYLCxoCBQwHAwsCAgkDAgECAUUTBgIBAYgDBgSoDJMhgSCKNQ8BEYMhghaBEgOVSYEUjnmCYYFdgT4 X-IronPort-AV: E=Sophos;i="4.77,648,1336341600"; d="scan'208";a="69517" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 24 Jul 2012 23:32:07 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 931FA3DA82 for ; Tue, 24 Jul 2012 23:32:07 +0200 (CEST) Message-ID: <500F1446.3010203@flaska.net> Date: Tue, 24 Jul 2012 23:31:50 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 21:32:11 -0000 Hi Adrien, > I don't think I'd bother with that many. I'd use invariant tokens for > the types of errors, and some may include some reason text. What are > the main expected failure cases? > > * syntax error -> BAD > * User may not submit -> NO [POLICYDENIED] > * return path rejected > * one or more forward paths rejected -> NO [POLICYDENIED] in my current draft. You're proposing to make this fine grained. See below. > * system error (e.g. out of disk). -> NO (without any particular response code) >> What shall the client do when it sees the proposed INVALIDRETURNPATH? >> Is there any difference in the desired behavior compared to handling >> of POLICYDENIED? Honestly, I don't know and am interested in other >> people's opinion. > I foresee a setting in email clients which are like > [x] submit messages using IMAP Agreed so far. > [x] use return-path associated with your IMAP account This is something for which I don't see the need. Why should the user be able to toggle this settings at all? What benefits would bring that to her? >>> However, things like spam (AV) filtering could be done at APPEND or >>> CATENATE time? >> >> I strongly object to that. If this filtering was done "globally", how >> could I possibly import data from my previous account to my new >> "spam-collection-for-auto-learning" folder? > > It's already done. If you don't like it I guess you'd have to get it > turned off on your mailbox. > > It's not a particularly wide-spread requirement to store viruses in your > mailbox, and I don't think we should deny others of AV protection so you > can do so. Well, what I was objecting to was that I perceived your idea as "spam filtering should be done during APPEND, not during SUBMIT". That's something I don't agree with; in my opinion, servers WILL want to use the content filtering during UID SUBMIT. I don't care whether they do so during APPEND as well and I recognize that there are valid reasons for that. >>>>> 3. SENDER. I'm not sure what SMTP envelope part this relates to, is >>>>> it superfluous? If it's already in the message headers, why do we >>>>> need to specify it again here? It's not needed for SMTP delivery >>>>> (only need return path and forward path(s)) >>>> >>>> Oops, good catch -- the SENDER should not be there at all. I'll fix >>>> this in my next update. >>> I'm thinking if we have to parse and process headers anyway to deal >>> with BCC, then Sender could be useful still. >> >> You've suggested that in ESMTP, there's no such thing like a distinct >> "FROM" and "SENDER". I've amended my (currently unpublished) copy of >> the draft to only use a single "FROM" field for this purpose. >> Arguably, if the client didn't use this submission option field, a >> compliant server implementation MUST set it to a value obtained from >> the message contents. > are you talking about the compliant server scraping return-path out of > headers, or providing a Sender field into the headers? I actually don't understand what you're asking here (at least in the context of the quoted discussion). I've removed one superfluous item from my idea of the ESMTP envelope's equivalent in UID SENDMAIL -- an item which doesn't actually have a counterpart in ESMTP. The draft says nothing about adding data to the Sender header of the outgoing message. Content manipulation is explicitly allowed, so I guess servers are free to do so -- but I don't see an obvious reason why they should do that provided the message already contains a proper From. If there's a good reason for that, please tell me, I'll be happy to mandate that in my draft. >> A good order of where to get the value from might be Resent-From, >> Sender, From (but I won't try to pretend that I've read the relevant >> RFC about these headers yet, so please take this order with a big >> grain of salt). > I would make it optional on the server maybe, where it can just > optionally use some pre-determined value associated with the IMAP account. > > e.g. user is logged into IMAP as bob, submits a message so return path > is bob@example.org (Speaking about the ways how the IMAP server determines the return-path.) Yes, the account details can be used to set the return-path if it is not given explicitly by the client. The account details and the knowledge obtained through header scraping should both be used as an input, I guess. > that can be up to the implementation to decide how. Our MTA doesn't do > BCC processing, so the IMAP server would do it on behalf of the client. > It may mean multiple copies are made for delivery. Agreed, that would be a compliant behavior when it comes to the wording of the draft and my intention. As long as your IMAP server guarantees that it won't leak the Bcc data, there's no difference in who does the header filtering. >> Please tell that to Google who still produces invalid BODYSTRUCTURE >> responses on e-mails with attached message/rfc822 parts (last checked >> a few months ago, anyway). As a client developer, I can assure you >> that it is NOT FUN to try to guess what five fields out of a sequence >> of twenty mandatory fields are missing today. I won't willingly >> inflict the same on any other programmer unless I'm in a really, >> really nasty mood. > > Even if I ask nicely? > > It's servers that need to parse this. I'm just saying it's easier to > deal with a list of recipients than have to match token value etc. To be honest, I have seen crappy clients and crappy servers alike. Given that a huge service provider weren't able to write a compliant implementation of their server side (where they absolutely control deployment schedule, any updates etc), I don't believe at all that small client developers will be able to follow the specification to the letter. Anyway, the biggest advantage of the grammar I proposed is its future extensibility. I like that point and am afraid that this is something that breaks in the fixed-order grammar as soon as there are two future extensions. > problem is you use tags like that, it means order becomes variable. It's > much easier to deal with fixed order of parameters. I see that it is easier in case the other side of the protocol is compliant. What I've seen when testing my client, however, is that the other side is usually very creative (and I know that I'm also very often "creative" as well -- members of this list against whose software I've run Trojita could probably tell). I could live with the fixed-order syntax, but I believe that it is technically inferior (not extensible, more fragile to parse). If most of the people on this list object, it will be the fixed-order one, but what I'd like to try before that is persuading them that the varying-order identifier-based one is better technically. So far, it's a draw, I'll love to hear from other server vendors here (Timo, Bron, Alexey, others?) > OK I missed that case. > > So Nil has some meaning by its presence that is different to its > absence. Absense = default behaviour, Nil = no DSN. That's fine. > > Could be more obvious maybe if you added some more tokens, such as > dsn-spec = "NONE" / "DEFAULT" / "(" dsn-token [*(SP dsn-token)] ")" > dsn-token = "DELAY" / "FAILURE" / "SUCCESS" I'll probably make this explicit in my next draft; I suspect that this difference was not terribly obvious. Thanks for your feedback, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From adrien@qbik.com Tue Jul 24 14:55:17 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B7D11E8079 for ; Tue, 24 Jul 2012 14:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=-1.601, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUp1q-aar9cH for ; Tue, 24 Jul 2012 14:55:17 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBBD11E8072 for ; Tue, 24 Jul 2012 14:55:16 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.3 (Build 3441)) with SMTP id <0019157392@smtp.qbik.com>; Wed, 25 Jul 2012 09:55:13 +1200 From: "Adrien W. de Croy" To: "Cyrus Daboo" , "Lyndon Nerenberg" Date: Tue, 24 Jul 2012 21:55:13 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 21:55:17 -0000 We don't have such limits with other protocols such as FTP or HTTP (or=20 POP3 or SMTP). At least not baked into the protocol itself. One of the benefits of a text-based protocol, esp when communicating=20 numbers, is the protocol can transmit a number of any size. Just send=20 more digits. BNF doesn't change. What size numeric types are used by agents to transmit numbers is then=20 an implementation decision. We can and should give guidelines to make people think about the scale=20 of things, but putting a hard limit into the protocol I think has=20 issues. If developers know that they can always see a bigger number, then they=20 can code / plan accordingly. E.g. use 64 bits, and keep an eye on=20 things. Or whatever. When people have to store UIDs and sizes, then the extra 64 bits per=20 message can add up, so I understand people wanted to keep this down. =20 But disks are a lot bigger now and 32 bits is looking smaller and=20 smaller with the passage of time. We only recently added support for=20 64bit sizes to WinGate. It took about 1/2hr. We changed some atoi to=20 atou64, and some %u to %I64u and changed types. So for mainstream email clients, I don't see much of a problem moving=20 to handling 64 bits for sizes etc (maybe some cache migration issues). =20 For other IMAP clients, it's only going to be a problem talking to a=20 newer server. Most servers allow setting a max message size limit=20 administratively. I agree, "by-reference" could be very interesting. Eudora used to strip attachements out of their MBXs and store them=20 independently. IME it actually created other problems. Adrien ------ Original Message ------ From: "Cyrus Daboo" To: "Adrien de Croy" ;"Lyndon Nerenberg"=20 Cc: "imapext@ietf.org" Sent: 25/07/2012 2:00:33 a.m. Subject: Re: [imapext] IMAP message size limits >Hi Adrien,=20 > >--On July 24, 2012 7:12:22 AM +0000 Adrien de Croy =20 >wrote:=20 > >>But first I ask, where are these 4 GB email messages you keep sending=20 >>around?=20 >> >> >>I did ask myself that.=20 >> >>then I decided I wouldn't try to answer that for everyone else.=20 >> >>The recording studio below us commonly deals with files much bigger=20 >>than=20 >>that.=20 >> >>Why should email be the poor cousin of other protocols and be unable=20 >>to=20 >>deal with files of that size.=20 >> >>I'm pretty sure a POP3 server can serve an email over 4GB. I checked=20 >>RFC1939 and didn't see any limits in there.=20 >> >>So it's a bit sad that IMAP has this limit, when actually it could be=20 >>argued that the size of numbers is an implementation issue rather=20 >>than a=20 >>protocol issue, and implementors could be guided to think about the=20 >>future (e.g. support bigger numbers).=20 > >Are people really sending files that big via email as opposed to using=20 >a file sharing service like e.g. DropBox? File sharing service is=20 >going to be a lot more efficient at upload/download than email.=20 >Perhaps it is a shame that no one really supports=20 >message/external-body because that could have really helped the=20 >process of sending attachments "by reference" instead of "by value".=20 > >-- Cyrus Daboo=20 > From arnt@gulbrandsen.priv.no Wed Jul 25 00:23:08 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E94111E80B7 for ; Wed, 25 Jul 2012 00:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNGOWKrhU9br for ; Wed, 25 Jul 2012 00:23:07 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id A50F911E80B3 for ; Wed, 25 Jul 2012 00:23:07 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1725DF8E09D; Wed, 25 Jul 2012 07:23:06 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343200985-24130-24129/10/7; Wed, 25 Jul 2012 07:23:05 +0000 Message-Id: <500F9EE1.4070306@gulbrandsen.priv.no> Date: Wed, 25 Jul 2012 09:23:13 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <500C04B5.3030206@flaska.net> <500C140D.2010000@gulbrandsen.priv.no> <01OI6KIY5A200006TF@mauve.mrochek.com> <500D787D.2090509@gulbrandsen.priv.no> <500F0E5C.2080901@flaska.net> In-Reply-To: <500F0E5C.2080901@flaska.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:23:08 -0000 On 07/24/2012 11:06 PM, Jan Kundr=E1t wrote: > What I'd like to have is an ability to write a MUA submitting over IMAP > which can do "everything that a MUA with support for ESMTP can do and > would do under reasonable situations" -- so the goal is to make it > possible to not use ESMTP at all for end-user clients. That was discussed in the Lemonade context. Someone (perhaps Ned or Pete=20 Resnick?) pointed out that in that case, IMAP either needs an SMTP=20 extension passthrough (so an IMAP client can use SMTP extensions) or=20 parallel extensions (so for each SMTP extension there is an IMAP = extension). I think you'll have more luck by enumerating a requirement list needed=20 by "typical clients", and then saying that only that list is in-scope. Arnt From arnt@gulbrandsen.priv.no Thu Jul 26 02:59:07 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27BB21F8752 for ; Thu, 26 Jul 2012 02:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhmhUE6NVnRP for ; Thu, 26 Jul 2012 02:59:06 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1B21F8746 for ; Thu, 26 Jul 2012 02:59:05 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 9567FF8EFC0; Thu, 26 Jul 2012 09:59:03 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343296742-400-399/11/2; Thu, 26 Jul 2012 09:59:02 +0000 Message-Id: <501114EF.1020003@gulbrandsen.priv.no> Date: Thu, 26 Jul 2012 11:59:11 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org Content-Type: multipart/mixed; boundary=------------030705000100030500060503 Subject: [imapext] imap move -01 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 09:59:07 -0000 --------------030705000100030500060503 Content-Type: text/plain; charset=iso-8859-1; format=flowed Hi, the datatracker doesn't want to let me submit. I'll do that once the cutoff is past. I append it the -01 for your consideration. Changes since -00 - Added MSN-based move. The consensus seems mildly in favour. I think. We'll see once this is posted. - Advise sending COPYUID earlier, to help clients. Requiring out of order processing is unnecessarily nasty. It is possible that I'll add text to section 3 about it being desirable for the entire command to be atomic. Arnt --------------030705000100030500060503 Content-Type: text/plain; charset=utf-8; name=draft-ietf-imapmove-command-01.txt Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=draft-ietf-imapmove-command-01.txt Network Working Group Arnt Gulbrandsen Internet-Draft July 2012 Intended Status: Standards Track The IMAP Move Extension draft-ietf-imapmove-command-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft expires in January 2013. Gulbrandsen Expires December 2012 [Page 1] =0C Internet-draft July 2012 Abstract The MOVE extension provides commands to move one or more messages from the selected mailbox to a named mailbox. 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Formal syntax is defined by [RFC5234]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. 2. Overview This document defines an IMAP extension to move messages from one mailbox to another. This function (very common in MUA UIs) is not provided by stock IMAP, and clients have to use a combination of UID STORE, UID COPY and EXPUNGE, and cope with partial failures and side effects. 3. MOVE and UID MOVE The UID MOVE command takes two arguments: a set of UIDs and a named mailbox. The MOVE command takes a set of MSNs and a named mailbox. Both commands move each messag included in the set to the named mailbox. The UID MOVE command has the same effect as a sequence of UID COPY, UID STORE +FLAGS.SILENT \DELETED and UID EXPUNGE, with the added requirement that each message SHOULD either be moved or unaffected. The server SHOULD NOT leave a message in neither or both mailboxes afterwards (even if the server returns a tagged NO response). UID MOVE is the same as the three-command sequence in all other respects, which implies that extensions which affect the three- command sequence also affect UID MOVE, and that response codes such as COPYUID, TRYCREATE and so on should be sent as appropriate. Gulbrandsen Expires December 2012 [Page 2] =0C Internet-draft July 2012 An example: C: a UID MOVE 42:69 forble S: * OK [COPYUID 432432 42:69 1202:1229] S: * 22 EXPUNGE S: (more expunges) S: a OK Done Note that the server may send EXPUNGEs for other messages as well, if any happen to have been expunged at the same time. Implementers will need to read [RFC4315] to understand what UID EXPUNGE does. Implementing [RFC4315] is not necessary. The MOVE command performs the same actions UID MOVE. Notably, the server may send EXPUNGE (or VANISHED) messages before the tagged response, so the client cannot safely send more commands with MSN arguments while the server is processing MOVE. 4. Interaction with other extensions This section points out how other IMAP extensions interact with this. 4.1. RFC 2087, QUOTA The QUOTA extension (defined by [RFC2087]) may interact with MOVE, on some servers, in the sense that a MOVE command may succeed where COPY would cause a quota overrun. This may be user-visible, but should not be MUA-visible. 4.2. RFC 4314, ACL Since UID MOVE is defined as equivalent to UID STORE, UID COPY and UID EXPUNGE, it requires the same ACL rights as the union of those three commands. 4.3. RFC 4315, UIDPLUS Since UID MOVE is defined by reference to UID COPY, the server has to send COPYUID for UID MOVE. Servers authors who implement UIDPLUS are advised to send the COPYUID response code in an untagged OK before sending EXPUNGE for moved messages. (Sending it in the tagged OK, as described in the UIDPLUS specification, means that clients first receive an EXPUNGE for a Gulbrandsen Expires December 2012 [Page 3] =0C Internet-draft July 2012 message and afterwards the COPYUID for the same message. It can be unnecessarily difficult to process that usefully.) 4.3. RFC 5162, QRESYNC The QRESYNC extension defined by [RFC5162] directs the server to send VANISHED rather than EXPUNGE for the UID EXPUNGE command. Since UID MOVE is defined by by reference to UID EXPUNGE, UID MOVE is also affected. 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability", "command", "set" and "mailbox". Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =3D/ "MOVE" command-select =3D/ ["UID "] "MOVE" SP set SP mailbox 6. Security Considerations This document is believed to add no security problems. It does however relieve a problem with the base specification, since client authors have to devise and implement complicated algorithms to handle partial failures of the STORE/COPY/EXPUNGE trio. Problems with these algorithms can lead to mail loss. 7. IANA Considerations The IANA is requested to add MOVE to the "IMAP 4 Capabilities" registry, http://www.iana.org/assignments/imap4-capabilities. 8. Acknowledgements An extension like this has been proposed many times, by many people. This document is based on several of those, most recently that by Witold Krecicki. Witold, Alexey Melnikov, Bron Gondwana, Adrien W. de Gulbrandsen Expires December 2012 [Page 4] =0C Internet-draft July 2012 Croy, Barry Leiba and others provided valuable comments. 9. Normative References [RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [RFC3501] Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [RFC4315] Crispin, "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, University of Washington, December 2005. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. 10. Informative References [RFC2087] Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997. [RFC4315] Melnikov, "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005. [RFC5162] Melnikov, "IMAP4 Extensions for Quick Mailbox Resynchronization", RFC 5162, Isode Ltd, March 2008. 11. Author's Address Arnt Gulbrandsen Schweppermannstr. 8 D-81671 Muenchen Germany Fax: +49 89 4502 9758 Email: arnt@gulbrandsen.priv.no Gulbrandsen Expires December 2012 [Page 5] =0C Internet-draft July 2012 (RFC Editor: Please delete everything after this point) RFC Editor: If this document contains no code components when you receive it, then please remove the sentence which starts with "code components". Thank you. Open Issues Add 3501-like requirements/results paragraphs. Add text about the desirability of command atomicity. Changes since -00 - Fixed two bad nouns. Mailboxes aren't messages. - Adrien's server can easily do UID MOVE but not so easily MSN-based moves. Changes since -01 - Changed to Informative, on Barry's suggestion. Or did I ask him? Whatever. - Removed the 'reasons to avoid', it was doubleplusungood. Changes since draft-gulbrandsen-imap-move-02 - Various wording changes from Barry's review. - Open issue: Delete the \deleted rule? - Back to PS, informative didn't fly in the IESG - Turned into a WG document in order to get write access to the IMAP4 capabilities registry - Mention VANISHED in 5162 - Added bad boilerplate to please idnits. This document contains no code. Gulbrandsen Expires December 2012 [Page 6] =0C Internet-draft July 2012 Changes since -00 - Added MSN-based move. The consensus seems mildly in favour. I think. We'll see once this is posted. - Advise sending COPYUID earlier, to help clients. Requiring out of order processing is unnecessarily nasty. Gulbrandsen Expires December 2012 [Page 7] =0C --------------030705000100030500060503-- From tss@iki.fi Thu Jul 26 03:40:54 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1355321F8493 for ; Thu, 26 Jul 2012 03:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3psUy6kLYYB for ; Thu, 26 Jul 2012 03:40:53 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 353A321F8701 for ; Thu, 26 Jul 2012 03:40:53 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id A7D921AE87CF for ; Thu, 26 Jul 2012 13:40:51 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Timo Sirainen In-Reply-To: <501114EF.1020003@gulbrandsen.priv.no> Date: Thu, 26 Jul 2012 13:40:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4B703ED9-1832-45FD-A602-5C7D2CDBE497@iki.fi> References: <501114EF.1020003@gulbrandsen.priv.no> To: imapext@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [imapext] imap move -01 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 10:40:54 -0000 On 26.7.2012, at 12.59, Arnt Gulbrandsen wrote: > I append it the -01 for your consideration. One typo: "move each messag included". Otherwise looks perfect to me. > It is possible that I'll add text to section 3 about it being = desirable for the entire command to be atomic. That would be ok, but I don't think it should be a SHOULD. From arnt@gulbrandsen.priv.no Thu Jul 26 03:46:52 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D2321F86AA for ; Thu, 26 Jul 2012 03:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWFsdULsYHST for ; Thu, 26 Jul 2012 03:46:52 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E2221F869F for ; Thu, 26 Jul 2012 03:46:52 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 33CF8F8EF38; Thu, 26 Jul 2012 10:46:51 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343299610-400-399/11/3; Thu, 26 Jul 2012 10:46:50 +0000 Message-Id: <50112022.4000901@gulbrandsen.priv.no> Date: Thu, 26 Jul 2012 12:46:58 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <501114EF.1020003@gulbrandsen.priv.no> <4B703ED9-1832-45FD-A602-5C7D2CDBE497@iki.fi> In-Reply-To: <4B703ED9-1832-45FD-A602-5C7D2CDBE497@iki.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] imap move -01 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 10:46:52 -0000 Timo answers me: >> It is possible that I'll add text to section 3 about it being = desirable for the entire command to be atomic. > That would be ok, but I don't think it should be a SHOULD. I agree, "desirable", not "SHOULD". Arnt From dkarp@zimbra.com Thu Jul 26 08:09:32 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5BA21F8795 for ; Thu, 26 Jul 2012 08:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vlqm8RrawBL for ; Thu, 26 Jul 2012 08:09:31 -0700 (PDT) Received: from edge02-zcs.vmware.com (edge02-zcs.vmware.com [208.91.2.23]) by ietfa.amsl.com (Postfix) with ESMTP id A537721F8790 for ; Thu, 26 Jul 2012 08:09:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge02-zcs.vmware.com (Postfix) with ESMTP id 26DC2171F; Thu, 26 Jul 2012 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge02-zcs.vmware.com Received: from edge02-zcs.vmware.com ([127.0.0.1]) by localhost (edge02-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hcy-j5Th3psb; Thu, 26 Jul 2012 08:10:27 -0700 (PDT) Received: from mbs01-zcs.vmware.com (mbs01-zcs.vmware.com [10.113.162.14]) by edge02-zcs.vmware.com (Postfix) with ESMTP id 9A6DD16D0; Thu, 26 Jul 2012 08:10:27 -0700 (PDT) Date: Thu, 26 Jul 2012 08:10:14 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <1263857994.39788.1343315414936.JavaMail.root@zimbra.com> In-Reply-To: <501114EF.1020003@gulbrandsen.priv.no> References: <501114EF.1020003@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_GA_5361 (ZimbraWebClient - GC20 (Mac)/8.0.0_GA_5361) Thread-Topic: imap move -01 Thread-Index: 7bmB2Q5jo0cNnMHgCylcwP0U26WTSQ== Cc: imapext@ietf.org Subject: Re: [imapext] imap move -01 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 15:09:32 -0000 > Changes since -00 > > - Added MSN-based move. The consensus seems mildly in favour. I > think. We'll see once this is posted. > > - Advise sending COPYUID earlier, to help clients. Requiring out of > order processing is unnecessarily nasty. The MOVE command performs the same actions UID MOVE. Notably, the server may send EXPUNGE (or VANISHED) messages before the tagged response, so the client cannot safely send more commands with MSN arguments while the server is processing MOVE. RFC 3501 uses the term "pipelining" for this. How about "... so the client cannot safely pipeline more commands with MSN arguments until the server completes processing the MOVE"? - Dan From jkt@flaska.net Thu Jul 26 09:13:21 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60521F8625 for ; Thu, 26 Jul 2012 09:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.315 X-Spam-Level: X-Spam-Status: No, score=0.315 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTicKqpRgutz for ; Thu, 26 Jul 2012 09:13:20 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 253E621F8622 for ; Thu, 26 Jul 2012 09:13:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAABsEVCT5xpZ/2dsb2JhbABFhXGzSIEHgiUlFUA2AgUWCwILAwIBAgFYCAEBiAkLmj6OQZMqgSCKQwUBgz6CCoESA5VIgRSOeYJhgVQJ X-IronPort-AV: E=Sophos;i="4.77,659,1336341600"; d="scan'208";a="83315" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 26 Jul 2012 18:13:15 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id 35CC23DA82 for ; Thu, 26 Jul 2012 18:13:15 +0200 (CEST) Message-ID: <50116C8A.8070609@flaska.net> Date: Thu, 26 Jul 2012 18:12:58 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [imapext] Draft for server-side incremental threading X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:13:21 -0000 Hi, as the draft submission tool is still down in preparations for the upcoming IETF meeting (?), and because I generally prefer to make a fool of myself in front of a limited audience, I'm hereby proposing a draft for "incremental threading". Why is it needed: ----------------- - My client issues "UID THREAD $algo $charset ALL" and relies on server-side threading. - It doesn't fetch anything but UID and FLAGS for all messages in a mailbox. - When new message arrives, it cannot therefore "plug" it into the threading tree without performing expensive operations. How it works: ------------- - It reuses the INTHREAD search key from Arnt's draft [1] (which is an excellent idea and it contains the THREAD=REFS algorithm as well, something implemented both in Dovecot and in Trpjita) - It adds a few return options to the UID THREAD command in manner similar to how ESEARCH did it for SEARCH. - Two new kinds of ESEARCH rerutn values are defined, the "THREAD" and "INCTHREAD". - Namely, the "THREAD" return option is the same as the untagged THREAD. - The "INCTHREAD" contains a tuple of (UID-of-previous-thread-root, one-thread), i.e. it adds an explicit position about where to "plug" the message. This is needed to prevent new messages from getting "forgotten" deep down in the threading, or old messages being copied getting too much visibility among the recent threads. The complete draft is at [2], the XML source at [3]. I've also hit one interoperability problem with Arnt's draft and Dovecot -- Dovecot accepts an additional parameter specifying the threading algorithm, so it isn't really just "INTHREAD", but rather "INTHREAD REFS" for example. This is subsequently what Trojita sends. My ABNF just references the mentioned draft. If people are interested in this approach, I'd appreciate if all of Arnt's INTHREAD, THREAD=REFS and my ETHREAD & INCTHREAD made it into an RFC eventually. I'll be happy to merge the two proposals if that sounds interesting. Slightly off-topic note: ------------------------ This is the last of the three proposals which I've made when working on my thesis about "Mobile IMAP" -- that means that there won't be any further drafts from me for a few weeks. If you're interested in this topic, I'd appreciate a review of some of the points which I raise in my work, or a general remark on how you like or dislike it. The thesis lives at [4]. With kind regards Jan [1] http://tools.ietf.org/html/draft-ietf-morg-inthread-01 [2] http://trojita.flaska.net/draft-imap-incthread-00.html [3] https://gitorious.org/trojita/trojita/blobs/drafts/draft-imap-incthread-00/docs/proposed-extensions/draft-imap-incthread.xml [4] http://trojita.flaska.net/msc-thesis.pdf -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From ned.freed@mrochek.com Mon Jul 23 08:08:45 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3956721F84BD for ; Mon, 23 Jul 2012 08:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itm8Hr1LjIGR for ; Mon, 23 Jul 2012 08:08:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8516C21F84AF for ; Mon, 23 Jul 2012 08:08:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OI6KIZS73K005RQZ@mauve.mrochek.com> for imapext@ietf.org; Mon, 23 Jul 2012 08:03:42 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHZVQBJXY80006TF@mauve.mrochek.com>; Mon, 23 Jul 2012 08:03:40 -0700 (PDT) Message-id: <01OI6KIY5A200006TF@mauve.mrochek.com> Date: Mon, 23 Jul 2012 07:54:31 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 22 Jul 2012 16:54:05 +0200" <500C140D.2010000@gulbrandsen.priv.no> References: <500C04B5.3030206@flaska.net> <500C140D.2010000@gulbrandsen.priv.no> To: Arnt Gulbrandsen X-Mailman-Approved-At: Thu, 26 Jul 2012 23:35:17 -0700 Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 15:08:45 -0000 > On 07/22/2012 03:48 PM, Jan Kundrát wrote: > > The ESMTP allows for this, and I believe that there are legitimate > > reasons for envelope-From being different than header-From or even > > account-id (think mailing list managers). > Suggest some that are legitimate in the context of an IMAP client? > IMO, envelope from more or less has to match the header addresses. The > exceptions are firmly in server or service land, not in IMAP client land. Off the top of my head: MDNs (required to have a null MAIL FROM), some send-on-behalf-of scenarios, client-side mailing lists, some DSN correlation mechanisms, and some multi-author scenarios. All of these are firmly in client space, not server or service land. The first two are quite common. Oh, and submit servers are often configured to perform complex authorization checks on messages, including verification of allowed send-on-behalf-of combinations. The result is that trying to indicate what's allowed and what's not in a single bit is effectively impossible. Ned P.S. And doing this stuff "right", for some value of "right", doesn't make submission facilities in IMAP a good idea. From brong@fastmail.fm Sat Jul 28 05:19:31 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5197021F8613 for ; Sat, 28 Jul 2012 05:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.313 X-Spam-Level: X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWuFOkNuyfK0 for ; Sat, 28 Jul 2012 05:19:30 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id AB15E21F8611 for ; Sat, 28 Jul 2012 05:19:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C61F2208C7 for ; Sat, 28 Jul 2012 08:19:29 -0400 (EDT) Received: from betaweb1.nyi.mail.srv.osa ([10.202.2.10]) by compute3.internal (MEProxy); Sat, 28 Jul 2012 08:19:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= DVAEqDZJE9cTPuvtwfqP0RQyvzI=; b=qQo7EdHscKwzMGqqHZ8sRcKwodKEHWDp I2jaMn20CuLhMKvz6hNvrOO6V4SJE/FUe2O5QheQgwNvxSJsAxrqQn8UVRFLTCfu CmG+uzcC7SQTqlZA4NtDvUPd3bTj69l6FfiV5ifLgNVjqUGfSdUeN5mvTLz1adB4 ekIZZZE9ebo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=DVAEqDZJE9cTPuvtwfqP0RQyvzI=; b=NjkN2 wou6XUEjYeHKH2xrmVtYXoI+UCoJjFXRGEc+Mr48HMNYWkwXYVnGJQW5te0ffOsc JCJFd0YIgeBTAPbuDvgZlIBH0OEYe+paSyO1apM2aP8jF9iXTPv7kkCn9dwmz/vj vAkL4yMoKcujK+i+jU6/1nN1BtlVpvfNN6nAlU= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id 827C462A50D; Sat, 28 Jul 2012 08:19:29 -0400 (EDT) Message-Id: <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> X-Sasl-Enc: y+P1Um1vTX3XQgYvy5wi/yJBH6D+9NKrdaFpw8fQv/P+ 1343477969 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface Date: Sat, 28 Jul 2012 14:19:29 +0200 In-Reply-To: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 12:19:31 -0000 On Thu, Jun 28, 2012, at 11:15 PM, Internet-Drafts@ietf.org wrote: > A new Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IMAP MOVE extension Working Group of the IETF. > > Title : The IMAP Move Extension > Author(s) : A. Gulbrandsen > Filename : draft-ietf-imapmove-command > Pages : 7 > Date : June 28, 2012 > > The MOVE extension provides a new command, UID MOVE, which moves one > or more messages from the selected mailbox to a named mailbox. Here's an interesting one I just ran into in production. A bug in our web client code caused it to try to MOVE a message from "Junk Mail" to "Junk Mail". This caused an assertion failure when it tried to open the already open mailbox, which is a Cyrus IMAPd bug, and I'll fix it. I'm wondering - is it worth explicitly mentioning this in the RFC as "returns BAD" - it doesn't make sense to move messages to the same folder as you're currently selecting. Bron. From tss@iki.fi Sat Jul 28 05:32:19 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034AA21F849A for ; Sat, 28 Jul 2012 05:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtIMU7Di2GFD for ; Sat, 28 Jul 2012 05:32:18 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5976221F8464 for ; Sat, 28 Jul 2012 05:32:18 -0700 (PDT) Received: from [10.217.1.118] (unknown [193.184.212.30]) by dovecot.org (Postfix) with ESMTP id A49641AE8807; Sat, 28 Jul 2012 15:32:16 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> Date: Sat, 28 Jul 2012 15:32:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> To: Bron Gondwana X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 12:32:19 -0000 On 28.7.2012, at 15.19, Bron Gondwana wrote: > Here's an interesting one I just ran into in production. A bug in our = web client code caused it to try to MOVE a message from "Junk Mail" to = "Junk Mail". This caused an assertion failure when it tried to open the = already open mailbox, which > is a Cyrus IMAPd bug, and I'll fix it. >=20 > I'm wondering - is it worth explicitly mentioning this in the RFC as = "returns BAD" - it doesn't make sense to move messages to the same = folder as you're currently selecting. It doesn't make much sense, but I don't know if it should be disallowed = either. MOVE is defined as combination of COPY+STORE+EXPUNGE, all of = which allow source and destination being the same. One potential use = case could be to give messages new UIDs, although I don't know how = useful that is really. :) Probably worth mentioning anyway that server implementers should check = it. From arnt@gulbrandsen.priv.no Sat Jul 28 06:47:25 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C78821F8604 for ; Sat, 28 Jul 2012 06:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS3k-qYxIirz for ; Sat, 28 Jul 2012 06:47:25 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id D45DF21F85F8 for ; Sat, 28 Jul 2012 06:47:24 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5B02CF8E3CF; Sat, 28 Jul 2012 13:47:23 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343483242-26402-26401/11/1; Sat, 28 Jul 2012 13:47:22 +0000 User-Agent: Kaiten Mail In-Reply-To: <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Arnt Gulbrandsen Date: Sat, 28 Jul 2012 15:46:37 +0200 To: Bron Gondwana , imapext@ietf.org Message-Id: <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 13:47:25 -0000 It isn't bad: the client may not know the mailbox is the same. In your = code, inbox has two names, right? But i will add a note. From barryleiba.mailing.lists@gmail.com Sat Jul 28 09:57:17 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEC121F8666 for ; Sat, 28 Jul 2012 09:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN74oknuGUGQ for ; Sat, 28 Jul 2012 09:57:17 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C812421F8663 for ; Sat, 28 Jul 2012 09:57:16 -0700 (PDT) Received: by lagv3 with SMTP id v3so2805570lag.31 for ; Sat, 28 Jul 2012 09:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wwtMb4+sqRdJM9cgjDU9NIbNd+9RZaDuCLQ/UklEMdY=; b=N9P+vvfKzxQjLFmR1JA5O6f5gNoO62OfusdW14rfNbuSNficDVm7rLfkvDY9T/FnAQ VwTIgq+N5AsVQxCk6q0B9P7gCWyrgweXveCzYx1qMpK728jcORDn7mgNALJPQosdVx3O rNVO4sHT0x63MPiW86D0FhaQHJ4E455vJSicpQXDQmEB5eKI2xDqUlubAF/MGGCK4S3j w3orCxScU1fT2v2ZqP8HY0jaA88GpvUxAV8vyF0ZWKCDczShfmsWaXPvDDlKs3R/cWU4 LMsNXvx11nkM2HzE3NBphA4LH09mr17KWg8UqxLoj1K8RfQO6zKV3V3DGhfINAPMlNJ1 F2+Q== MIME-Version: 1.0 Received: by 10.112.36.130 with SMTP id q2mr2939439lbj.44.1343494635777; Sat, 28 Jul 2012 09:57:15 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sat, 28 Jul 2012 09:57:15 -0700 (PDT) In-Reply-To: <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> Date: Sat, 28 Jul 2012 12:57:15 -0400 X-Google-Sender-Auth: q5zSeGs_8uQmIgvdnD-flCEseqg Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=e0cb4efe32a285ef4204c5e6b8c5 Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 16:57:17 -0000 --e0cb4efe32a285ef4204c5e6b8c5 Content-Type: text/plain; charset=ISO-8859-1 > > It isn't bad: the client may not know the mailbox is the same. It isn't "BAD", perhaps. I continue to think that it was an unnecessary and perhaps confusing decision to make a distinction between BAD and NO. Does any client actually behave differently for those two responses types? I suggest that the text say that servers MAY respond NO in this case, and that they SHOULD include a suitable response code to indicate the situation. Perhaps ALREADYEXISTS makes sense, or you can use CANNOT... or else create a new code and register it. Barry, as participant --e0cb4efe32a285ef4204c5e6b8c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It isn't bad: the client may not know th= e mailbox is the same.

It isn't "B= AD", perhaps. =A0I continue to think that it was an unnecessary and pe= rhaps confusing decision to make a distinction between BAD and NO. =A0Does = any client actually behave differently for those two responses types?

I suggest that =A0the text say that servers MAY respond= NO in this case, and that they SHOULD include a suitable response code to = indicate the situation. =A0Perhaps ALREADYEXISTS makes sense, or you can us= e CANNOT... or else create a new code and register it.

Barry, as participant
--e0cb4efe32a285ef4204c5e6b8c5-- From brong@fastmail.fm Sat Jul 28 12:52:02 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0DC21F850B for ; Sat, 28 Jul 2012 12:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIlpHd4ucOsj for ; Sat, 28 Jul 2012 12:52:01 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 77CF621F84FC for ; Sat, 28 Jul 2012 12:52:01 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0BEFA206E8; Sat, 28 Jul 2012 15:52:01 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute4.internal (MEProxy); Sat, 28 Jul 2012 15:52:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= 6iAdcSRuq6vFHfa2pskHuFI3/Os=; b=Y3UA2LzpsHm+pFlq6T06/ev6AW5HjGZk TmF4Am15HnsFtOmohSMTPCyk5c1ENouEteyUeRlV+PbSeJ0xK3h5bPikRt2kFW6n sVxfjd3AjhWjEAumRPYoUKv3U8BLVrnOQYkcM35n6edEseoZj3hHtqyzb+ZkfCOf eZbC418ionE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=6iAdcSRuq6vFHfa2pskHuFI3/Os=; b=NnsJK iCq7JhIoPNlgUme6kwd7YvMRd8yD9SLetOb9ip/vdQAj32V4lhNv+dgT8sitAhyH 4LjhXSZEcH2vvTDatChNo5LPufkUDi6HDbHxuttL1VAgJVvua6U38Kwpsx+ZsgEy hdJ1DYydRpP/rpQVSTE+JymsVgtQkpqC1+JYtk= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id C027068446F; Sat, 28 Jul 2012 15:52:00 -0400 (EDT) Message-Id: <1343505120.31199.140661107808217.67D3C609@webmail.messagingengine.com> X-Sasl-Enc: uAM/TQCWtXBdedvVJZDLhT3dmIl9svK2YmGbG2Qzg6AQ 1343505120 From: Bron Gondwana To: Arnt Gulbrandsen , imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface Date: Sat, 28 Jul 2012 21:52:00 +0200 In-Reply-To: <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 19:52:02 -0000 On Sat, Jul 28, 2012, at 03:46 PM, Arnt Gulbrandsen wrote: > It isn't bad: the client may not know the mailbox is the same. In your code, inbox has two names, right? Actually, no. It's the same name. Though: more investigation shows it wasn't our interface: 2012-07-27T23:16:16.397496-04:00 imap15 sloti15d3p1/imap[8927]: login: frontend1.nyi.mail.srv.osa [10.202.2.160] *redacted* plaintext User logged in SESSIONID= 2012-07-27T23:16:16.912373-04:00 imap15 sloti15d3p1/imap[8927]: client id: "name" "SeaMonkey" "version" "2.11" [...] > But i will add a note. And here's part of the stack trace (we dump core on assertion errors in FastMail production to help us track down bugs faster): #9 0x000000000041f15d in cmd_copy (tag=0x18f93b0 "18", sequence=0x18f9bd0 "14350,14353,14355,14357:14359", name=0x18fa410 "inbox.Junk Mail", usinguid=1, ismove=1) Unfortunately, I don't have a record of the original name passed to the SELECT command earlier, because we don't run telemetry logging by default on users who haven't reported any issues. So what do you suggest? Just return: TAG NO can not move messages into same folder ? Bron. -- Bron Gondwana brong@fastmail.fm From brong@fastmail.fm Sat Jul 28 12:53:16 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2A21F866A for ; Sat, 28 Jul 2012 12:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjU93QDwrZKJ for ; Sat, 28 Jul 2012 12:53:15 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8F021F8667 for ; Sat, 28 Jul 2012 12:53:15 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1A94A206E8; Sat, 28 Jul 2012 15:53:15 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute3.internal (MEProxy); Sat, 28 Jul 2012 15:53:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= ruXaPBh7+GGU2mYN7SgPpXNE6oo=; b=lZ+ExBUVTKFO7EsXoJYqCbtyu7mU5ao3 J5ptXP5ZNZ+1z9Qpl7nvM0F4YkpJ2FQOOXdeJXt8jeYYteHSbCJV+3Vth2co71zL 1L6AT45ER7EWZCuKN/5FSi1LZiLy3qTAFY8wiCpiUPp23QZR/4Z/XjZ/2/vfh9dJ K5VawFlHsgo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=ruXaPBh7+GGU2mYN7SgPpXNE6oo=; b=k9sx/ fcEdCCoYitCpdmhWg1T+GFcZjisyVIOp5v0MU61VFw2KRaXKLnj3w+h4/YnOeDAz mnGbByNifzYd91V69FTczu+/ExROQ1TJgzyN6MTVSG0nUmVGr17EhDX/Feu8xrYq 5xLLw7nnz/FMl8K0ESSpCnNeIKO+R2Zy6HwZ8o= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id DC4B468446F; Sat, 28 Jul 2012 15:53:14 -0400 (EDT) Message-Id: <1343505194.31313.140661107809153.1915364F@webmail.messagingengine.com> X-Sasl-Enc: 4IkxXkY/qOou3pBIf0NUe1Bjw/sUbT8FlCxyp/xfe2KU 1343505194 From: Bron Gondwana To: Timo Sirainen MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface Date: Sat, 28 Jul 2012 21:53:14 +0200 In-Reply-To: References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 19:53:16 -0000 On Sat, Jul 28, 2012, at 02:32 PM, Timo Sirainen wrote: > On 28.7.2012, at 15.19, Bron Gondwana wrote: > > > Here's an interesting one I just ran into in production. A bug in our web client code caused it to try to MOVE a message from "Junk Mail" to "Junk Mail". This caused an assertion failure when it tried to open the already open mailbox, which > > is a Cyrus IMAPd bug, and I'll fix it. > > > > I'm wondering - is it worth explicitly mentioning this in the RFC as "returns BAD" - it doesn't make sense to move messages to the same folder as you're currently selecting. > > It doesn't make much sense, but I don't know if it should be disallowed either. MOVE is defined as combination of COPY+STORE+EXPUNGE, all of which allow source and destination being the same. One potential use case could be to give messages new UIDs, although I don't know how useful that is really. :) > > Probably worth mentioning anyway that server implementers should check it. Hmm... yeah, that's a point actually. I guess I just have to detect that special case and deal with it correctly :) Bron. -- Bron Gondwana brong@fastmail.fm From arnt@gulbrandsen.priv.no Sat Jul 28 12:53:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76F421F8671 for ; Sat, 28 Jul 2012 12:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaplEeSk+2tw for ; Sat, 28 Jul 2012 12:53:56 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id F06CC21F866A for ; Sat, 28 Jul 2012 12:53:55 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 55CEDF8E658; Sat, 28 Jul 2012 19:53:55 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343505234-26402-26401/10/2; Sat, 28 Jul 2012 19:53:54 +0000 Message-Id: <50144352.7040603@gulbrandsen.priv.no> Date: Sat, 28 Jul 2012 21:53:54 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 19:53:56 -0000 On 07/28/2012 06:57 PM, Barry Leiba wrote: > It isn't "BAD", perhaps. I continue to think that it was an unnecessary > and perhaps confusing decision to make a distinction between BAD and NO. > Does any client actually behave differently for those two responses types? No idea. (A digression. IMO, BAD is misnamed, but otherwise okay. It should have been broken down into the two cases NO [SYNTAXERROR] and NO [CANNOT].) > I suggest that the text say that servers MAY respond NO in this case, > and that they SHOULD include a suitable response code to indicate the > situation. Perhaps ALREADYEXISTS makes sense, or you can use CANNOT... > or else create a new code and register it. > > Barry, as participant I lean towards adding this sentence: "If the target mailbox is actually the same as the source (perhaps by a different name), the server MAY treat the operation as a no-op and simply return OK without doing any work, or it MAY answer NO [CANNOT]." Is it worth defining a new response code, NOOP? I think not. Arnt From tss@iki.fi Sat Jul 28 13:07:45 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE0921F8675 for ; Sat, 28 Jul 2012 13:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmEw2qApvnTh for ; Sat, 28 Jul 2012 13:07:44 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 769EA21F8674 for ; Sat, 28 Jul 2012 13:07:44 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id EAF0F1AE8809; Sat, 28 Jul 2012 23:07:42 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <50144352.7040603@gulbrandsen.priv.no> Date: Sat, 28 Jul 2012 23:07:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 20:07:45 -0000 On 28.7.2012, at 22.53, Arnt Gulbrandsen wrote: >> I suggest that the text say that servers MAY respond NO in this = case, >> and that they SHOULD include a suitable response code to indicate the >> situation. Perhaps ALREADYEXISTS makes sense, or you can use = CANNOT... >> or else create a new code and register it. >>=20 >> Barry, as participant >=20 > I lean towards adding this sentence: "If the target mailbox is = actually the same as the source (perhaps by a different name), the = server MAY treat the operation as a no-op and simply return OK without = doing any work, or it MAY answer NO [CANNOT]." I don't think it should return OK if it didn't change the UID. > Is it worth defining a new response code, NOOP? I think not. No. From barryleiba.mailing.lists@gmail.com Sat Jul 28 13:53:33 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AC821F8671 for ; Sat, 28 Jul 2012 13:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8OwoJzeXhQ5 for ; Sat, 28 Jul 2012 13:53:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA91C21F865A for ; Sat, 28 Jul 2012 13:53:31 -0700 (PDT) Received: by lagv3 with SMTP id v3so2863989lag.31 for ; Sat, 28 Jul 2012 13:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=C3WZo3nALTscFxiuJi75jMLUsHsEX6yTTeVz1ZDMUnQ=; b=LFjDiQnnk+ShK0+EZ8S+wmhbtCsrWDX/O0RLwL6zHpgkzB92Td8SLOVqdwEKJlHuMT XVxQxWcvkq7CGA5mJG5A/mLUygKV2p2aDlidprk3zgRjF7N61pXcEEIUnKi0At/uPxJR b7BsK4eZqu3gEDdBLeMLbPaZi+Tzjqgxte1ytTSugP7F45LNPgppk35p070TcEtUeCNM j/Zo1TT9vYzARmNR4JW0K9tj0WmbUy1GDpk2N9VwYd3g9w8TjZZVaGCittqDncA+gdWX h7ZtUKDmVp/rqeEJ0dXUg/P4lJiKbl31WpeFzn+oxgkXhogT/dGZ0D0p+FK+H0op3+TN /I+Q== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr6747327lab.23.1343508810973; Sat, 28 Jul 2012 13:53:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sat, 28 Jul 2012 13:53:30 -0700 (PDT) In-Reply-To: <50144352.7040603@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> Date: Sat, 28 Jul 2012 13:53:30 -0700 X-Google-Sender-Auth: qW2SunTn69SjAPRmZF6ikHUQb78 Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=f46d040715c56e41d604c5ea0548 Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 20:53:33 -0000 --f46d040715c56e41d604c5ea0548 Content-Type: text/plain; charset=ISO-8859-1 > > (A digression. IMO, BAD is misnamed, but otherwise okay. It should have > been broken down into the two cases NO [SYNTAXERROR] and NO [CANNOT].) I believe that CANNOT is not a subcase of BAD. BAD, as it's intended, means "the client should have known that it couldn't do that." In other words, the client is misusing the protocol. CANNOT can mean other things. > I suggest that the text say that servers MAY respond NO in this case, >> and that they SHOULD include a suitable response code to indicate the >> situation. Perhaps ALREADYEXISTS makes sense, or you can use CANNOT... >> or else create a new code and register it. >> >> I lean towards adding this sentence: "If the target mailbox is actually > the same as the source (perhaps by a different name), the server MAY treat > the operation as a no-op and simply return OK without doing any work, or it > MAY answer NO [CANNOT]." > I'm with Timo: I don't like the first option. Either you do *something* -- actually do the move in some way, or recognize that it's silly and just give it a new UID (and you can put text in to that effect) -- or you respond NO [CANNOT]. How about this text?: "If the target mailbox is actually the same as the source (perhaps by a different name), the server MAY optimize for this situation. If it does so, it MUST either ensure that the message gets a new UID (and respond OK), or respond NO [CANNOT]." Barry, as participant --f46d040715c56e41d604c5ea0548 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(A digression. IMO, BAD is misnamed, but oth= erwise okay. It should have been broken down into the two cases NO [SYNTAXE= RROR] and NO [CANNOT].)

I believe that CANNOT is not a subcase of BAD. =A0BAD, = as it's intended, means "the client should have known that it coul= dn't do that." =A0In other words, the client is misusing the proto= col. =A0CANNOT can mean other things.
=A0
I suggest that =A0the text say that servers MAY respond NO in this case, and that they SHOULD include a suitable response code to indicate the
situation. =A0Perhaps ALREADYEXISTS makes sense, or you can use CANNOT... or else create a new code and register it.

I lean towards adding this sentence: "If the target mailbox is actuall= y the same as the source (perhaps by a different name), the server MAY trea= t the operation as a no-op and simply return OK without doing any work, or = it MAY answer NO [CANNOT]."

I'm with Timo: I don't like the fi= rst option. =A0Either you do *something* -- actually do the move in some wa= y, or recognize that it's silly and just give it a new UID (and you can= put text in to that effect) -- or you respond NO [CANNOT]. =A0How about th= is text?:

"If the target mailbox is actually the same as the= source (perhaps by a different name), the server MAY optimize for this sit= uation. =A0If it does so, it MUST either ensure that the message gets a new= UID (and respond OK), or respond NO [CANNOT]."

Barry, as participant=A0
--f46d040715c56e41d604c5ea0548-- From arnt@gulbrandsen.priv.no Sat Jul 28 14:02:25 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2321F867F for ; Sat, 28 Jul 2012 14:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK1gD0zz8lWr for ; Sat, 28 Jul 2012 14:02:24 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id C08B921F84CE for ; Sat, 28 Jul 2012 14:02:24 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2B80AF8E66C; Sat, 28 Jul 2012 21:02:24 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343509343-26402-26401/10/3; Sat, 28 Jul 2012 21:02:23 +0000 Message-Id: <50145360.9090108@gulbrandsen.priv.no> Date: Sat, 28 Jul 2012 23:02:24 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: Barry Leiba References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 21:02:25 -0000 God, a digression thread. But I'll digress with the best of you! On 07/28/2012 10:53 PM, Barry Leiba wrote: > I believe that CANNOT is not a subcase of BAD. BAD, as it's intended, > means "the client should have known that it couldn't do that." In other > words, the client is misusing the protocol. CANNOT can mean other things. 3501 says (on almost every page): BAD - command unknown or arguments invalid The arguments invalid bit often is CANNOT land. Legal by the protocol, sometimes the client could know, but more often the user knew. C: a create "" Did I tell you about my time as listmaster? I had the thingy set to forward all unparsable -request mail to me, and one day I received the following two-line missive: subscribe crash I subscribed the originator and sent a polite message saying so, and I also said "command not supported". Then he told me that quite a few mailing list processors did indeed carry out his complete instructions. Arnt From tss@iki.fi Sat Jul 28 14:10:09 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A40A21F84AF for ; Sat, 28 Jul 2012 14:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4un6IdFCfHYX for ; Sat, 28 Jul 2012 14:10:08 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 65D2721F8470 for ; Sat, 28 Jul 2012 14:10:08 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 4900C1AE8809; Sun, 29 Jul 2012 00:10:07 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <50145360.9090108@gulbrandsen.priv.no> Date: Sun, 29 Jul 2012 00:09:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0119DD3F-E430-4154-8567-B8603620A6DC@iki.fi> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50145360.9090108@gulbrandsen.priv.no> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1084) Cc: Barry Leiba , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 21:10:09 -0000 On 29.7.2012, at 0.02, Arnt Gulbrandsen wrote: > God, a digression thread. But I'll digress with the best of you! >=20 > On 07/28/2012 10:53 PM, Barry Leiba wrote: >> I believe that CANNOT is not a subcase of BAD. BAD, as it's = intended, >> means "the client should have known that it couldn't do that." In = other >> words, the client is misusing the protocol. CANNOT can mean other = things. >=20 > 3501 says (on almost every page): >=20 > BAD - command unknown or arguments invalid >=20 > The arguments invalid bit often is CANNOT land. Legal by the protocol, = sometimes the client could know, but more often the user knew. >=20 > C: a create "" Is your point that it would be legal to reply BAD for this command? I = would disagree. From barryleiba.mailing.lists@gmail.com Sat Jul 28 14:26:01 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D763A21F85F3 for ; Sat, 28 Jul 2012 14:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMsnIqYsmBzE for ; Sat, 28 Jul 2012 14:26:01 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6021F85E4 for ; Sat, 28 Jul 2012 14:26:00 -0700 (PDT) Received: by lagv3 with SMTP id v3so2870796lag.31 for ; Sat, 28 Jul 2012 14:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Lj0qcq2NhA6/oFQXlrZBN6sDasVdXmeTi9OtJv3jY48=; b=SXryy1RjBq9VQMoJRpwYESQ1pHQX9VEWgNbnSqD/yxQNZxEkl+h6jXEw1meCuT03Kw HNrqIr60L6UNWn8jjxlyFALSHTRMREf5nDRgyeUSPsFU5Pj1siL8GONRMPndR1+lTUus ATzrESPt/FwvzjVhEfZtwEAy0scFhtufD6DK1qBo9IVRcrr7EjpBe/nya1gb/dAoJO/U N2hqQU+26L31YX0bYiNX8GafCQxhp31blgUVV4VHjbwEC+NM6q+47oZQMzI7+lnCu4dv QzRKtufDtOgglp1Os4Lyo9qt6QD73yjitmMhld4VinOoFOJwdSpJM7VjSD4Lq7vHJ2KH ncCg== MIME-Version: 1.0 Received: by 10.112.10.198 with SMTP id k6mr3277779lbb.83.1343510760057; Sat, 28 Jul 2012 14:26:00 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sat, 28 Jul 2012 14:25:59 -0700 (PDT) In-Reply-To: <50145360.9090108@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50145360.9090108@gulbrandsen.priv.no> Date: Sat, 28 Jul 2012 14:25:59 -0700 X-Google-Sender-Auth: mhq6tWtNv03NTQNqR-RO7K_wyOg Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=e0cb4efe35029aea3204c5ea791d Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 21:26:02 -0000 --e0cb4efe35029aea3204c5ea791d Content-Type: text/plain; charset=ISO-8859-1 > > BAD - command unknown or arguments invalid > > The arguments invalid bit often is CANNOT land. Legal by the protocol, > sometimes the client could know, but more often the user knew. > I'm not going to argue with you here, because it doesn't matter. I urge everyone else not to argue about this here either. Barry --e0cb4efe35029aea3204c5ea791d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0 =A0 BAD - command unknown or arguments i= nvalid

The arguments invalid bit often is CANNOT land. Legal by the protocol, some= times the client could know, but more often the user knew.
=

I'm = not going to argue with you here, because it doesn't matter. =A0I urge = everyone else not to argue about this here either.

Barry
=A0
--e0cb4efe35029aea3204c5ea791d-- From arnt@gulbrandsen.priv.no Sun Jul 29 00:03:00 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23DE11E80AE for ; Sun, 29 Jul 2012 00:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R75ZZLHT9Kcu for ; Sun, 29 Jul 2012 00:03:00 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 481FA11E8072 for ; Sun, 29 Jul 2012 00:02:59 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 174B3F8C471; Sun, 29 Jul 2012 07:02:59 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343545378-26402-26401/10/4; Sun, 29 Jul 2012 07:02:58 +0000 Message-Id: <5014E023.3070903@gulbrandsen.priv.no> Date: Sun, 29 Jul 2012 09:02:59 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50145360.9090108@gulbrandsen.priv.no> <0119DD3F-E430-4154-8567-B8603620A6DC@iki.fi> In-Reply-To: <0119DD3F-E430-4154-8567-B8603620A6DC@iki.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 07:03:01 -0000 On 07/28/2012 11:09 PM, Timo Sirainen wrote: > Is your point that it would be legal to reply BAD for this command? I = would disagree. Actually, I think that's a conservative/liberal point. The RFC doesn't=20 define validity, so you should be conservative and assume that BAD only=20 covers syntactical invalidity, but accept that others think BAD also=20 covers implementation-specific invalidity. Arnt From alexey.melnikov@isode.com Sun Jul 29 07:44:24 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A50521F86E4 for ; Sun, 29 Jul 2012 07:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNXIfzSyA+iq for ; Sun, 29 Jul 2012 07:44:23 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 67D4E21F86D9 for ; Sun, 29 Jul 2012 07:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343573129; d=isode.com; s=selector; i=@isode.com; bh=iefKbXpC954amySz0avnj3GX73L3qscSHZGQrIW7idM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KAmMVXV0lRFEJ4uI5pOK59B8fc2svjBjWSJIzCDbXH+GfFd3FUfQwlhll4yuRAMpHIqnkM BhDnSW/T4FKmRdxOCvTVDLVALcCq6u6mvNL3TPVD8vaBkcUFndYsGaBMN8cCBUqSDvRZtK CZ5VLgf0NhrqoMiEMnwfWI9bCqaTgyU=; Received: from [10.71.15.137] (209-207-95-33.ip.van.radiant.net [209.207.95.33]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Jul 2012 15:45:19 +0100 References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sun, 29 Jul 2012 07:44:09 -0700 To: Barry Leiba MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-EE7AE95E-B6B8-4033-B229-64F382A74B64 Cc: Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 14:44:24 -0000 --Apple-Mail-EE7AE95E-B6B8-4033-B229-64F382A74B64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Jul 2012, at 13:53, Barry Leiba wrote: > (A digression. IMO, BAD is misnamed, but otherwise okay. It should have be= en broken down into the two cases NO [SYNTAXERROR] and NO [CANNOT].) >=20 > I believe that CANNOT is not a subcase of BAD. BAD, as it's intended, mea= ns "the client should have known that it couldn't do that." In other words,= the client is misusing the protocol. CANNOT can mean other things. > =20 > I suggest that the text say that servers MAY respond NO in this case, > and that they SHOULD include a suitable response code to indicate the > situation. Perhaps ALREADYEXISTS makes sense, or you can use CANNOT... > or else create a new code and register it. >=20 > I lean towards adding this sentence: "If the target mailbox is actually th= e same as the source (perhaps by a different name), the server MAY treat the= operation as a no-op and simply return OK without doing any work, or it MAY= answer NO [CANNOT]." >=20 > I'm with Timo: I don't like the first option. Either you do *something* -= - actually do the move in some way, or recognize that it's silly and just gi= ve it a new UID (and you can put text in to that effect) -- or you respond N= O [CANNOT]. How about this text?: >=20 > "If the target mailbox is actually the same as the source (perhaps by a di= fferent name), the server MAY optimize for this situation. If it does so, i= t MUST either ensure that the message gets a new UID (and respond OK), or re= spond NO [CANNOT]." As a participant: why would the client want a new set of UIDs? I would rathe= r do nothing or reject the command with a NO.= --Apple-Mail-EE7AE95E-B6B8-4033-B229-64F382A74B64 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
On 28 Jul 2012, at 13:53, Barry Leiba <barryleiba@computer.org> wrote:

(A digression. IMO, BAD is misnamed, but otherwise okay. It should have been broken down into the two cases NO [SYNTAXERROR] and NO [CANNOT].)

I believe that CANNOT is not a subcase of BAD.  BAD, as it's intended, means "the client should have known that it couldn't do that."  In other words, the client is misusing the protocol.  CANNOT can mean other things.
 
I suggest that  the text say that servers MAY respond NO in this case,
and that they SHOULD include a suitable response code to indicate the
situation.  Perhaps ALREADYEXISTS makes sense, or you can use CANNOT...
or else create a new code and register it.

I lean towards adding this sentence: "If the target mailbox is actually the same as the source (perhaps by a different name), the server MAY treat the operation as a no-op and simply return OK without doing any work, or it MAY answer NO [CANNOT]."

I'm with Timo: I don't like the first option.  Either you do *something* -- actually do the move in some way, or recognize that it's silly and just give it a new UID (and you can put text in to that effect) -- or you respond NO [CANNOT].  How about this text?:

"If the target mailbox is actually the same as the source (perhaps by a different name), the server MAY optimize for this situation.  If it does so, it MUST either ensure that the message gets a new UID (and respond OK), or respond NO [CANNOT]."

As a participant: why would the client want a new set of UIDs? I would rather do nothing or reject the command with a NO.
--Apple-Mail-EE7AE95E-B6B8-4033-B229-64F382A74B64-- From barryleiba@gmail.com Sun Jul 29 07:58:04 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C433321F86DB for ; Sun, 29 Jul 2012 07:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3-zL9mchDja for ; Sun, 29 Jul 2012 07:58:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37E7A21F86B8 for ; Sun, 29 Jul 2012 07:58:04 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8262296pbc.31 for ; Sun, 29 Jul 2012 07:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SW2gZRIVTY7cs8NkbbhghCG46CU2i4yDBPRaAFIo1B8=; b=twU/QWMOXkddtIBWwOhuCoVGmctI0sVFEQueDqyW+IAjZZn1RyyXYPz9LjwnbrFqt1 EmguTCOHfCdrmFlnPOqiBZQH6g6B5Oqpnb7+/cIRawG62Tku8iJ6r8ayizanzYR6EPla czURABLx1aAvGGCsaJpbVCACq2DuD/Hbqc3Ta+PPhJzU5E4DNqNCI/K95gelkgTxkTH1 +/x9wDL95JmUf2kGB6iHcNLG489LfyfXpBrDDA7M7iWVeYnYBzJ0KwQ0sHApUUiSna4x UGPRkhnTQzTa0OFlfswGYph6kvYgwFZfhM+EGj73YRYf6fnV1VJx5LlqHRXT1EeiUI0V WInw== MIME-Version: 1.0 Received: by 10.68.203.41 with SMTP id kn9mr28861991pbc.72.1343573883909; Sun, 29 Jul 2012 07:58:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.68.64.103 with HTTP; Sun, 29 Jul 2012 07:58:03 -0700 (PDT) In-Reply-To: References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> Date: Sun, 29 Jul 2012 10:58:03 -0400 X-Google-Sender-Auth: 9hGQor3Vf0vPr6kZdtZ97VQ-BqE Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: multipart/alternative; boundary=047d7b15aee11476bd04c5f92c42 Cc: Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 14:58:04 -0000 --047d7b15aee11476bd04c5f92c42 Content-Type: text/plain; charset=ISO-8859-1 > > I'm with Timo: I don't like the first option. Either you do *something* > -- actually do the move in some way, or recognize that it's silly and just > give it a new UID (and you can put text in to that effect) -- or you > respond NO [CANNOT]. How about this text?: > > "If the target mailbox is actually the same as the source (perhaps by a > different name), the server MAY optimize for this situation. If it does > so, it MUST either ensure that the message gets a new UID (and respond OK), > or respond NO [CANNOT]." > > > As a participant: why would the client want a new set of UIDs? I would > rather do nothing or reject the command with a NO. > Indeed, you're right. So maybe we should invert this, preferring NO: << If the target mailbox is actually the same as the source (perhaps by a different name), the server MAY optimize for this situation. If it does so, it does it in one of the following two ways: 1. It SHOULD take no action, and respond "NO [CANNOT]". 2. Otherwise, it MUST ensure that the message gets a new UID, and respond "OK". >> Barry, as participant --047d7b15aee11476bd04c5f92c42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm with Timo: I don't like the first option. =A0E= ither you do *something* -- actually do the move in some way, or recognize = that it's silly and just give it a new UID (and you can put text in to = that effect) -- or you respond NO [CANNOT]. =A0How about this text?:

"If the target mailbox is actually the same as the= source (perhaps by a different name), the server MAY optimize for this sit= uation. =A0If it does so, it MUST either ensure that the message gets a new= UID (and respond OK), or respond NO [CANNOT]."

As a participant: why would the client want a n= ew set of UIDs? I would rather do nothing or reject the command with a NO.<= /div>

Indeed, you're right. =A0So= maybe we should invert this, preferring NO:
<<
If the target mailbox is actually the same as the s= ource (perhaps by a different name), the server MAY optimize for this situa= tion. =A0If it does so, it does it in one of the following two ways:
1. It SHOULD take no action, and respond "NO [CANNOT]".=A0
2. Otherwise, it MUST ensure that the message gets a new UID, and = respond "OK".
>>

Barry, = as participant
--047d7b15aee11476bd04c5f92c42-- From arnt@gulbrandsen.priv.no Sun Jul 29 10:01:15 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8479D21F86AD for ; Sun, 29 Jul 2012 10:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdtvN1IXCWxv for ; Sun, 29 Jul 2012 10:01:15 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id E26C121F86CA for ; Sun, 29 Jul 2012 10:01:14 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 379C6FA048E; Sun, 29 Jul 2012 17:01:14 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343581273-23929-23928/10/1; Sun, 29 Jul 2012 17:01:13 +0000 Message-Id: <50156C5B.2000103@gulbrandsen.priv.no> Date: Sun, 29 Jul 2012 19:01:15 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 17:01:15 -0000 I can't say why anyone would want that (other than a test suite looking for a really fast way to generate lots of \recent messages), but for some servers it would happen naturally, so allowing it is as harmless as it is useless. I added this sentence: "The behaviour when the target mailbox is the same as the source is undefined." Perhaps I should add "At least one server is known to issue new UIDs and set \recent, another is known to fail the command with NO."? Arnt From alexey.melnikov@isode.com Sun Jul 29 10:17:33 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17FB21F8712 for ; Sun, 29 Jul 2012 10:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OL1aDNBGOFjA for ; Sun, 29 Jul 2012 10:17:33 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 335AD21F8705 for ; Sun, 29 Jul 2012 10:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343582319; d=isode.com; s=selector; i=@isode.com; bh=rJLMRioSkuNHE741ShJi6nFN3WhHjqUokOFHbSoMK9c=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=okYcp0M4iwON8KeLZKtyN+452jnzTJgXykNIzyTV8vkQtuOeUuawF0Lir8LRuYaynFgTcb PC/2OlHKe1ij2e2buIBV/Vf/bnlUrPjJHArvjmxnoTRJO5Itb9oHAZmccDICyXdEQJCZid njf6+HNdzbuhCgJ3iohRNnFasJHmaS4=; Received: from [10.71.15.137] (209-207-95-33.ip.van.radiant.net [209.207.95.33]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Jul 2012 18:18:39 +0100 References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> In-Reply-To: <50156C5B.2000103@gulbrandsen.priv.no> Message-Id: <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sun, 29 Jul 2012 10:17:33 -0700 To: Arnt Gulbrandsen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 17:17:33 -0000 On 29 Jul 2012, at 10:01, Arnt Gulbrandsen wrote:= > I can't say why anyone would want that (other than a test suite looking fo= r a really fast way to generate lots of \recent messages), but for some serv= ers it would happen naturally, so allowing it is as harmless as it is useles= s. >=20 > I added this sentence: "The behaviour when the target mailbox is the same a= s the source is undefined." Perhaps I should add "At least one server is kno= wn to issue new UIDs and set \recent, another is known to fail the command w= ith NO."? >=20 I would much prefer earlier suggestions explicitly stating allowed choices (= e.g. Barry's proposal) From barryleiba.mailing.lists@gmail.com Sun Jul 29 10:54:49 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7192C21F86FF for ; Sun, 29 Jul 2012 10:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xXKBNA2eeU2 for ; Sun, 29 Jul 2012 10:54:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6DEA21F86FE for ; Sun, 29 Jul 2012 10:54:48 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3237039lbb.31 for ; Sun, 29 Jul 2012 10:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cyaqgWalic1Ws0q1hlG/AVqHEnAox6JF4IglMsgjGzg=; b=QDrubPSQ6H6namsH0zGy8BGs4vBYXk9AmpT8JR1fknVXb+Df+YcmKeLI30hpf9fkhG 0yHkArC0wEZvCdt+OwKSUqjYQh8v5eyiWK7rnUcDZFhAf/4KfOoOvsf6fwO1EfvPVBGR ckpmGah5OQs7lJFVeqgMC+ZYVDx8wIGRqjEFJyuXfysAo6D0nXgAnhO3ldMWmitvjvEk gEr6JtQ8rniab5StilU96Hxpbtsm+gEOKrUhQIR1tukuBQ6UCld/UBYfBRMzzrgRQH1G HBrhJPlor0wE4YWh/EUOSe9s10GSdmv02Qleb8fjk7TQlvVrHBU1V2nlYmvQQPkS42bk Sr+Q== MIME-Version: 1.0 Received: by 10.152.113.199 with SMTP id ja7mr8988507lab.10.1343584487598; Sun, 29 Jul 2012 10:54:47 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sun, 29 Jul 2012 10:54:47 -0700 (PDT) In-Reply-To: <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> Date: Sun, 29 Jul 2012 13:54:47 -0400 X-Google-Sender-Auth: oOasQxyS7WCFGGfWK0NKHH_REuk Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f46d04088ee51beb4b04c5fba4d8 Cc: Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 17:54:49 -0000 --f46d04088ee51beb4b04c5fba4d8 Content-Type: text/plain; charset=ISO-8859-1 > > > I added this sentence: "The behaviour when the target mailbox is the > same as the source is undefined." Perhaps I should add "At least one server > is known to issue new UIDs and set \recent, another is known to fail the > command with NO."? > > I would much prefer earlier suggestions explicitly stating allowed choices > (e.g. Barry's proposal) > Yes, I very strongly prefer normative language here, rather than leaving it entirely unspecified. There are too many vague implementation choices in IMAP already, which cause problems for client developers. Barry --f46d04088ee51beb4b04c5fba4d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I added this sentence: "The behavi= our when the target mailbox is the same as the source is undefined." P= erhaps I should add "At least one server is known to issue new UIDs an= d set \recent, another is known to fail the command with NO."?

I would much prefer earlier suggestions explicitly stating allowed choices = (e.g. Barry's proposal)

Yes, I very strongly prefer normative lang= uage here, rather than leaving it entirely unspecified. =A0There are too ma= ny vague implementation choices in IMAP already, which cause problems for c= lient developers.

Barry=A0
--f46d04088ee51beb4b04c5fba4d8-- From arnt@gulbrandsen.priv.no Sun Jul 29 13:27:42 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9011E80A3 for ; Sun, 29 Jul 2012 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCFqAOjf-LAD for ; Sun, 29 Jul 2012 13:27:42 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1D111E8097 for ; Sun, 29 Jul 2012 13:27:42 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5C952F8E648; Sun, 29 Jul 2012 20:27:41 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343593660-23929-23928/10/2; Sun, 29 Jul 2012 20:27:40 +0000 Message-Id: <50159CBE.3050308@gulbrandsen.priv.no> Date: Sun, 29 Jul 2012 22:27:42 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 20:27:42 -0000 On 07/29/2012 07:54 PM, Barry Leiba wrote: > Yes, I very strongly prefer normative language here, rather than leaving > it entirely unspecified. There are too many vague implementation > choices in IMAP already, which cause problems for client developers. I very strongly dislike writing things like "servers may optimise unimportant corner cases" (I rephrased to bring the issue out more clearly). Yes, they may, but I don't think good RFCs should say things like that, and rewording to shroud the issue doesn't remove the problem. I thought about possible rules that would satisfy both you, Alexey and myself, and I changed my own position. I now think that the only sensible behaviour is to mandate OK. Arguments: First, copystoreexpunge works that way. Do we have a good reason to fail in cases copystoreexpunge OKs? I fail to see any. Performance in corner cases doesn't matter, and the locking issue Bron brings up is a cyrus bug. Second, other move-capable systems I use support noop moves, and it's convenient. SQL servers do not reject an UPDATE ... WHERE when zero rows would be affected, they say "OK, 0 rows affected". The unix mv command also accepts noop moves, and many, many shell scripts and state machines depend on it. "mv $a $basedir/unprocessed" works even if $a happens to be in unprocessed already, "mv $(find ...) foo" works, etc. Arnt From internet-drafts@ietf.org Mon Jul 30 13:24:38 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6168F11E8134; Mon, 30 Jul 2012 13:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtvMBz-RlQAp; Mon, 30 Jul 2012 13:24:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AAB11E8126; Mon, 30 Jul 2012 13:24:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.32 Message-ID: <20120730202437.7616.44742.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 13:24:37 -0700 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-imapmove-command-01.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:24:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP MOVE extension Working Group of the = IETF. Title : The IMAP Move Extension Author(s) : Arnt Gulbrandsen Filename : draft-ietf-imapmove-command-01.txt Pages : 7 Date : 2012-07-30 Abstract: The MOVE extension provides commands to move one or more messages from the selected mailbox to a named mailbox. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-imapmove-command There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-imapmove-command-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-imapmove-command-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From arnt@gulbrandsen.priv.no Mon Jul 30 13:26:57 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08111E8134 for ; Mon, 30 Jul 2012 13:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCsNzGY20O2z for ; Mon, 30 Jul 2012 13:26:57 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id EED2411E8126 for ; Mon, 30 Jul 2012 13:26:42 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 625C5F8E1FC; Mon, 30 Jul 2012 20:26:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343680001-23929-23928/10/9; Mon, 30 Jul 2012 20:26:41 +0000 Message-Id: <5016EE07.6060301@gulbrandsen.priv.no> Date: Mon, 30 Jul 2012 22:26:47 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120730202437.7616.44742.idtracker@ietfa.amsl.com> In-Reply-To: <20120730202437.7616.44742.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-01.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:26:57 -0000 Changes since -00: - Added MSN-based move. The consensus seems mildly in favour. I think. We'll see once this is posted. - Advise sending COPYUID earlier, to help clients. Requiring out of order processing is unnecessarily nasty. - Note that moving to the source inbox has to work. I think it does have to work, but this is a draft, it says so on every page. And the third of those points refers to this: Note that moving messages to the current mailbox is well-defined, so that MOVE is defined for all the cases where the COPY/STORE/EXPUNGE sequence is. Arnt From barryleiba@gmail.com Mon Jul 30 19:17:54 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD6811E8143; Mon, 30 Jul 2012 19:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSOGgycNQo9C; Mon, 30 Jul 2012 19:17:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69A3211E8140; Mon, 30 Jul 2012 19:17:54 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10749846pbc.31 for ; Mon, 30 Jul 2012 19:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=IxMaL2oRajm1jT7NHb4MO6dK8up+n6c+iTrOlx7u4Bg=; b=s4B+82UnSU1BD3wflOlONkJQ/EfY0dX9SDNYOrcdEjGldIQCtonVWH6K2ym87Cdz0P rxGRTR8T9NADS9tOyiaG70TgHKLI3uu0U1/lOpMWVxCd3Ols0qvpQufGzZY+KY8StpfF 1d/kIksTnwiryRR6gyK8tlpWig1OC0ShUj4UwJ6A2oiLHbTVn+/svbIgCkN8ZgMNTyB1 JIXZVq0dwoWEgpy0ph32UMnxeeowss7DxfWkn1HyKjY26Hqd+U8wqNFvTEyKNh+4jMth 8BCpneOBsmndk3yne42gELv55SMU0iRUnJSpp3T0ZPA0n5LWLT0atIeHTuTO7+Leh078 RXKQ== MIME-Version: 1.0 Received: by 10.68.238.68 with SMTP id vi4mr39007576pbc.123.1343701074192; Mon, 30 Jul 2012 19:17:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.68.64.103 with HTTP; Mon, 30 Jul 2012 19:17:54 -0700 (PDT) Date: Mon, 30 Jul 2012 22:17:54 -0400 X-Google-Sender-Auth: TLpbmcv3QCEYclAKemCmWJ3mWqI Message-ID: From: Barry Leiba To: imapext@ietf.org, pop3ext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [imapext] Update to RFC 5322 to allow "group" syntax in the "from" header field X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:17:55 -0000 I have posted a message to the ietf-822 list with the same subject as this note. It has to do with an EAI issue with respect to POP and IMAP clients. You can find the message here: http://www.ietf.org/mail-archive/web/ietf-822/current/msg06635.html If you have comments, please post them to . Please do not reply to this message and don't discuss the draft on these lists. Barry