Hi all,

I am facing a problem with Yaho= o account.

Yahoo SMTP server broadcast the SIZE as= "SIZE 41697280".

So when I am trying to= send a mail with ~28.8 MB of attachment to Gmail/AOL,

sending of= the mail succeeds but I am getting a MAILER-DAEMON saying :

Remote host said:

552-5.2.3 Your message excee= ded Google's message size limits.

What should I do, as a mail client. Should i not = honor the SIZE attribute and use 25 MB as the upper limit?

Thanks & Regards

-Naren

--001a11473b449ffe880512bf5cf6-- From nobody Thu Apr 2 16:15:29 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671101A87D9 for ; Thu, 2 Apr 2015 16:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yri5iOTeOMCL for ; Thu, 2 Apr 2015 16:15:27 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 139C11A87D4 for ; Thu, 2 Apr 2015 16:15:27 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKC9YVSUKG00HLTK@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Apr 2015 16:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1428016222; bh=ki9d5yYXXw+kWSM7jFEhGKwJAca24jhge6Vc/iPg8WQ=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=p0TOTHWj/C0sfRNd7ufoHFJPZcHCjCbYDN5aZO1KBudNOccG8iTtPdjRO/7uoK6zg xf1eZ7vqA6dZXimnQT9/0VeFSKxcV1TYl3AAjEwCbf222Og1QgS7kcVzAThp3OZWdF MoK4R9DVvluS2SOuof5jurFPiOBHa4HtD7Uv+LYQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKC9H3DBZK00GZDS@mauve.mrochek.com>; Thu, 02 Apr 2015 16:10:20 -0700 (PDT) Message-id: <01PKC9YUFY9S00GZDS@mauve.mrochek.com> Date: Thu, 02 Apr 2015 16:00:47 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 02 Apr 2015 11:19:24 -0400" References: To: narendra singh bisht Archived-At: Cc: imapext@ietf.org Subject: Re: [imapext] Problem with Yahoo SMTP server SIZE attribute. X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 23:15:28 -0000 > I am facing a problem with Yahoo account. > Yahoo SMTP server broadcast the SIZE as "SIZE 41697280". Which means that Yahoo won't accept any message larger than that. It does not mean that they will accept any message that's smaller. There can be per-account limits, per-domain limits, limits due to forwarding somewhere else, etc. etc. etc. > So when I am trying to send a mail with ~28.8 MB of attachment to Gmail/AOL, > sending of the mail succeeds but I am getting a MAILER-DAEMON saying : > *Remote host said:* > *552-5.2.3 Your message exceeded Google's message size limits.* Huh? What does sending to Google have to do with sending to Yahoo? > What should I do, as a mail client. Should i not honor the SIZE attribute > and use 25 MB as the upper limit? The SIZE EHLO response is an optimization: It tells you in advance that if you have a message larger than the limit, you might as well not bother trying to send it. It does not tell you what the actual limit is on your transaction. And it most certainly does not tell you squat about what the limit is going to be somewhere else. You seem to be looking for some secret sauce here that does not and cannot exist: A limit that will magically prevent problems trying to send large messages. Your responsibility as a mail client developer is first to look at the SIZE EHLO response and not bother trying to send the message. Additionally, if the server supports the extension you should pass the message size as a SIZE parameter on MAIL FROM so that the server can apply destination-specific size limits and return appropriate responses. If, in addition to doing this, you also want to impose a local limit, by all means do that, but unless it's absurdly low it's not going to prevent messages being bounced due to size limitations. Ned From nobody Thu Apr 2 23:34:05 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8E1A910F for ; Thu, 2 Apr 2015 23:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzdQZq_TbTv1 for ; Thu, 2 Apr 2015 23:34:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423731A9109 for ; Thu, 2 Apr 2015 23:34:00 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t336XwXF017502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Apr 2015 06:33:59 GMT Received: from hermes-fe-2.easd.brm.oracle.com (hermes-fe-2.easd.brm.oracle.com [10.79.248.11]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t336Xwg4021523 for ; Fri, 3 Apr 2015 06:33:58 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from [10.159.139.214] (dhcp-whq-twvpn-3-vpnpool-10-159-231-83.vpn.oracle.com [10.159.231.83]) by hermes-fe-2.easd.brm.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPSA id <0NM700C2ZWWJYN00@hermes-fe-2.easd.brm.oracle.com> for imapext@ietf.org; Thu, 02 Apr 2015 23:33:58 -0700 (PDT) Date: Thu, 02 Apr 2015 23:33:56 -0700 From: Chris Newman To: Alexey Melnikov , IMAPEXT Message-id: In-reply-to: <551A0193.5030104@isode.com> References: <551A0193.5030104@isode.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 06:34:03 -0000 --On March 31, 2015 3:08:19 +0100 Alexey Melnikov wrote: > Hi, > > I've asked Barry earlier what he would like to do about > draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he > asked for a charter for a new short term IMAP related WG. Here is a > proposal: > > > The Internet Message Access Protocol (IMAP), defined in RFC 3501, > specifies a protocol for transferring email messages between a server > that implements a message store, and a client. It also includes commands > for manipulating the message store -- creating, deleting, and renaming > mailboxes, adding a message to a mailbox, and copying messages from one > mailbox to another. > > IMAP (RFC 3501) contains the "literal" syntactic construct for > transferring blocks of data. When sending a literal from a client to a server, > RFC 3501 requires the client to wait for the server to send a command > continuation request between sending the octet count and the string data. > This complicates client implementations and resulted in definition > of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form > of literal which does not require this network round trip. While this > extension is quite commonly supported by servers, some implementations > decided to disable it because it is frequently abused by naive clients > that try to upload big messages without checking whether servers can > accept big messages. > > The IMAP APPEND extension (imapappend) working group has two related > deliverables which are targeted at improving the current situation. One > deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03 > and defines a way for servers to announce APPEND limit for a particular > server or a particular mailbox. The second deliverable is based on > draft-melnikov-rfc2088bis-01. It describes implementation choices for > server supporting LITERAL+ extension and also defines LITERAL- extension > which have similar properties, but is easier for servers to implement > while preventing denial of service attacks from malicious and naive IMAP > clients. Both deliverables will be Standards Track documents. > > As part of the protocol development, implementation experience on both > the client and server side is highly desireable, so that the actual > operational value of this extension can be assessed. The working group > will document the results of this experience on the working group wiki. > > No other IMAP extension work is in scope for this working group. > > ------ > Comments: > > > 1) I don't particularly care if LITERAL- is standardized or not, but I would > like the problem to be solved. If we can't agree on LITERAL-, then > draft-melnikov-rfc2088bis can just become a revision of LITERAL+. > > 2) I've also heard some interest in standardizing the SNAPSHOT facility. I am > ambivalent on whether it should be added to the above. (If you think it > should, please suggest a new paragraph to add). I would like to keep the > charter to no more than 3 deliverables. > > Any opinions on the proposal? I've reviewed the append limit proposal already and will review a SNIPPET proposal if one is written up. If someone else can commit to editing a SNIPPET draft, I'll write charter text for it and review the draft. But no point writing that text if there's no document editor. - Chris From nobody Fri Apr 3 00:43:07 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428101A916F for ; Fri, 3 Apr 2015 00:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRQkH7bBcV4R for ; Fri, 3 Apr 2015 00:43:01 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868B81A916E for ; Fri, 3 Apr 2015 00:43:01 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4E79BFA00E3; Fri, 3 Apr 2015 07:42:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1428046979; bh=23vfuiGMLVKhUw2vxqgMj0nvTBsSGMO6I5k0H8VOD/w=; h=From:To:Subject:References:Date:From; b=XvgMP+dpQXoDTgZNCpahbQIj3zwV/wVjSrXOE32n2r8kBvh5A0UxMImKodIG/B94g eOi2/qEJnHV6FIs+fxQQP3aKwLrpwL1mehs2/NOq8eoDqDY585iA0g5xflbA0XRZEX Q61Skijv+IxcZNS8yu3Ljhj4RZiM6Fd0wFbls8R8= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1428046978-31136-31135/12/174; Fri, 3 Apr 2015 07:42:58 +0000 From: Gulbrandsen To: narendra singh bisht , imapext@ietf.org, Ned Freed Message-Id: References: <01PKC9YUFY9S00GZDS@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Date: Fri, 3 Apr 2015 07:42:58 +0000 Archived-At: Subject: Re: [imapext] Problem with Yahoo SMTP server SIZE attribute. X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 07:43:06 -0000 There are two size limits here: the size limit at the submission server (yahoo) and that at the final destination (gmail). The second is smaller than the first, which leads to a DSN. There is nothing to do about that. It is regrettable, but no action by an SMTP client or server in one hop will affect that later hop. Arnt From nobody Mon Apr 6 04:26:18 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703171A8798 for ; Mon, 6 Apr 2015 04:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZNjf_FaGFtY for ; Mon, 6 Apr 2015 04:26:15 -0700 (PDT) Received: from wursti.dovecot.fi (wursti.dovecot.fi [87.106.245.223]) by ietfa.amsl.com (Postfix) with ESMTP id D48031A8793 for ; Mon, 6 Apr 2015 04:26:14 -0700 (PDT) Received: from [10.231.191.95] (zz2012427835719DFD84.userreverse.dion.ne.jp [113.157.253.132]) by wursti.dovecot.fi (Postfix) with ESMTPSA id 516A6201A9; Mon, 6 Apr 2015 13:26:11 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Timo Sirainen In-Reply-To: <665A59F00F13516FA9C0E981@96B2F16665FF96BAE59E9B90> Date: Mon, 6 Apr 2015 20:26:06 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02454F842DD7B449B96715A2AD90C036510B8C55@exMB5.telecom.sna.samsung.com> <665A59F00F13516FA9C0E981@96B2F16665FF96BAE59E9B90> To: Chris Newman X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: imapext@ietf.org, Jayantheesh S B Subject: Re: [imapext] The IMAP APPENDLIMIT Extension - version 04 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 11:26:16 -0000 On 04 Mar 2015, at 10:32, Chris Newman wrote: >=20 > Q for list: If the server has a message larger than UINT32_MAX in the = store and > a client tries to fetch it, should the server just go ahead and = violate the > base-spec's UINT32_MAX limit Dovecot has already been doing this for the last 10 years or so. If it = has been compiled with 64bit off_t support (default) it has allowed = >32bit APPENDs and FETCHing will always return the full message. I doubt = anybody has actually attempted using that, but if this becomes more = commonly used there is already a large number of Dovecots happily = serving such content without extra extensions.. I guess this isn't ideal = from protocol purity point of view, but it's probably going to work fine = in practise whenever such emails are actually becoming used. From nobody Mon Apr 6 04:34:54 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB78C1A87A2 for ; Mon, 6 Apr 2015 04:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnO_9P03ByN4 for ; Mon, 6 Apr 2015 04:34:51 -0700 (PDT) Received: from wursti.dovecot.fi (wursti.dovecot.fi [87.106.245.223]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8DD1A87A5 for ; Mon, 6 Apr 2015 04:34:51 -0700 (PDT) Received: from [10.231.191.95] (zz2012427835719DFD84.userreverse.dion.ne.jp [113.157.253.132]) by wursti.dovecot.fi (Postfix) with ESMTPSA id E9201201A9; Mon, 6 Apr 2015 13:34:48 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F57B2440-51EA-4381-AE28-E17446A155AD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Timo Sirainen In-Reply-To: <54FD9063.40700@isode.com> Date: Mon, 6 Apr 2015 20:34:42 +0900 Message-Id: <2A905656-7DA3-4F9F-8D65-6034CA2F886E@iki.fi> References: <20150309121833.13100.15011.idtracker@ietfa.amsl.com> <54FD9063.40700@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-04.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 11:34:52 -0000 --Apple-Mail=_F57B2440-51EA-4381-AE28-E17446A155AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 09 Mar 2015, at 21:21, Alexey Melnikov = wrote: >=20 > I've just posted -03 and 04 (fixed a few things in 03 which I haven't = noticed before posting). The main change to LITERAL- is to allow non = synchronizing literals <=3D 4096 bytes in APPEND (instead of just = prohibiting them). > Comments are very welcome. I'm badly lagging behind my emails, so I'm not sure if this comment has = been made: > "LITERAL-" extension is almost identical to "LITERAL+", with one > exception: when "LITERAL-" is advertised, non synchronizing = literals > used in APPEND (and extensions to APPEND such as MULTIAPPEND > [RFC3502 ] and CATENATE = [RFC4469 ]) MUST NOT be larger than = 4096 bytes. What about ANNOTATE and METADATA, which could potentially be large as = well? --Apple-Mail=_F57B2440-51EA-4381-AE28-E17446A155AD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252 Hi,

On 09 Mar 2015, at 21:21, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

I've just posted -03 and 04 (fixed a few things in 03 which I haven't noticed before posting). The main change to LITERAL- is to allow non synchronizing literals <= 4096 bytes in APPEND (instead of just prohibiting them).
Comments are very welcome.

I'm badly lagging behind my emails, so I'm not sure if this comment has been made:

   "LITERAL-" extension is almost identical to "LITERAL+", with one
   exception: when "LITERAL-" is advertised, non synchronizing literals
   used in APPEND (and extensions to APPEND such as MULTIAPPEND
   [RFC3502] and CATENATE [RFC4469]) MUST NOT be larger than 4096 bytes.

What about ANNOTATE and METADATA, which could potentially be large as well?

--Apple-Mail=_F57B2440-51EA-4381-AE28-E17446A155AD-- From nobody Tue Apr 7 03:39:32 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CBC1B3403 for ; Tue, 7 Apr 2015 03:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJruEd8ilbM8 for ; Tue, 7 Apr 2015 03:39:29 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id EED171B3402 for ; Tue, 7 Apr 2015 03:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1428403167; d=isode.com; s=selector; i=@isode.com; bh=zX+B5Gyyc8TM/XdkjVXE0vYWdCXH0Dx8Gg5bckPngBc=; 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=bAnMP1acBi6Oq+88sontnC7QGF1BKkNh2O4X14Q1N5hRNEYvxQaTUNkLhwUg9TLE1svXR1 3+fBB1sR9GKU9fsA6z9RC9CQXNg8txE4BuZvpelVfpEF+RWv389Go76zX0QJ3vkwZBm5Mu fZbzRJ4eE2BncEQoyz/Satb6cVZtbmQ=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Apr 2015 11:39:27 +0100 Message-ID: <5523B3D5.4060901@isode.com> Date: Tue, 07 Apr 2015 11:39:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 To: imapext@ietf.org References: <20150309121833.13100.15011.idtracker@ietfa.amsl.com> <54FD9063.40700@isode.com> <2A905656-7DA3-4F9F-8D65-6034CA2F886E@iki.fi> In-Reply-To: <2A905656-7DA3-4F9F-8D65-6034CA2F886E@iki.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060602090901030702060608" Archived-At: Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-04.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 10:39:30 -0000 This is a multi-part message in MIME format. --------------060602090901030702060608 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Timo, On 06/04/2015 12:34, Timo Sirainen wrote: > Hi, > > On 09 Mar 2015, at 21:21, Alexey Melnikov > wrote: >> >> I've just posted -03 and 04 (fixed a few things in 03 which I haven't >> noticed before posting). The main change to LITERAL- is to allow non >> synchronizing literals <= 4096 bytes in APPEND (instead of just >> prohibiting them). >> Comments are very welcome. > > I'm badly lagging behind my emails, so I'm not sure if this comment > has been made: > >> "LITERAL-" extension is almost identical to "LITERAL+", with one >> exception: when "LITERAL-" is advertised, non synchronizing literals >> used in APPEND (and extensions to APPEND such as MULTIAPPEND >> [RFC3502 ] and CATENATE [RFC4469 ]) MUST NOT be larger than 4096 bytes. > What about ANNOTATE and METADATA, which could potentially be large as well? I would be happy to apply the same (or different) limit to them as well. --------------060602090901030702060608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Timo,

On 06/04/2015 12:34, Timo Sirainen wrote:

Hi,

On 09 Mar 2015, at 21:21, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

I've just posted -03 and 04 (fixed a few things in 03 which I haven't noticed before posting). The main change to LITERAL- is to allow non synchronizing literals <= 4096 bytes in APPEND (instead of just prohibiting them).
Comments are very welcome.

I'm badly lagging behind my emails, so I'm not sure if this comment has been made:
   "LITERAL-" extension is almost identical to "LITERAL+", with one
   exception: when "LITERAL-" is advertised, non synchronizing literals
   used in APPEND (and extensions to APPEND such as MULTIAPPEND
   [RFC3502] and CATENATE [RFC4469]) MUST NOT be larger than 4096 bytes.
What about ANNOTATE and METADATA, which could potentially be large as well?

I would be happy to apply the same (or different) limit to them as well.

--------------060602090901030702060608-- From nobody Tue Apr 7 04:44:32 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91981B349A for ; Tue, 7 Apr 2015 04:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcq2qlQ6vBXy for ; Tue, 7 Apr 2015 04:44:30 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id F1C741B3478 for ; Tue, 7 Apr 2015 04:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1428407069; d=isode.com; s=selector; i=@isode.com; bh=wP0rKZurJlMlrgwh99j2/9rhj2KEjdXDiZSzvv5g6LQ=; 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=DUKEc0IXGg9BN/tKWc+88Jl1PBB47m95nyuVTl69CJYKnYBO4QLOYhy5RA6WRI7Y1KbQxH svIqmUpyC/rqtSu8fu27aezM5Aaqquir5GDNPVJhlF6fedPIdRnuouWveV0DIISsKb29Zw tXrhS6Bn6IYdPW+jHcDBlCYum9Uuv3Q=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Apr 2015 12:44:29 +0100 Message-ID: <5523C310.8050101@isode.com> Date: Tue, 07 Apr 2015 12:44:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 To: Timo Sirainen , Chris Newman References: <02454F842DD7B449B96715A2AD90C036510B8C55@exMB5.telecom.sna.samsung.com> <665A59F00F13516FA9C0E981@96B2F16665FF96BAE59E9B90> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jayantheesh S B , imapext@ietf.org Subject: Re: [imapext] The IMAP APPENDLIMIT Extension - version 04 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 11:44:31 -0000 On 06/04/2015 12:26, Timo Sirainen wrote: > On 04 Mar 2015, at 10:32, Chris Newman wrote: >> Q for list: If the server has a message larger than UINT32_MAX in the store and >> a client tries to fetch it, should the server just go ahead and violate the >> base-spec's UINT32_MAX limit > Dovecot has already been doing this for the last 10 years or so. If it has been compiled with 64bit off_t support (default) it has allowed >32bit APPENDs and FETCHing will always return the full message. I doubt anybody has actually attempted using that, but if this becomes more commonly used there is already a large number of Dovecots happily serving such content without extra extensions.. I guess this isn't ideal from protocol purity point of view, but it's probably going to work fine in practise whenever such emails are actually becoming used. I still prefer if support for more than UINT32_MAX is advertised somehow. Maybe this can be folded into IMAP update. From nobody Mon Apr 13 08:16:15 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CB51ACD30 for ; Mon, 13 Apr 2015 08:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24HuyXkOz2V5 for ; Mon, 13 Apr 2015 08:16:08 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC2C1ACCEE for ; Mon, 13 Apr 2015 08:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1428938167; d=isode.com; s=selector; i=@isode.com; bh=EY6ulnH6OLEk+KeqP1WWg6rCThzVKI0y3UZQAE99xFc=; 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=Hg4fV3XJFhe8tnstmJbXkdUu0MLv9DnRZcgSUUvg2hoxatJn7SQp8DLD1l3xbkXPcYovuP TmDrfd+eBqCGkPM2W/VnbnpsxdVxLEEhIgei/51ejUC+gyOtO39AJUCYufOQ+IMGpzse/3 /H/vz6KCJuL7b/3HSUV/wLwNXhbUGfc=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Apr 2015 16:16:07 +0100 Message-ID: <552BDDB7.9080304@isode.com> Date: Mon, 13 Apr 2015 16:16:07 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Chris Newman , IMAPEXT References: <551A0193.5030104@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:16:13 -0000 Hi Chris, On 03/04/2015 07:33, Chris Newman wrote: > I've reviewed the append limit proposal already and will review a SNIPPET > proposal if one is written up. If someone else can commit to editing a SNIPPET > draft, I'll write charter text for it and review the draft. But no point > writing that text if there's no document editor. I can edit the SNIPPET draft, but I will not commit to doing the initial outline of it. So we still need for somebody to sketch out how this might look first. From nobody Mon Apr 13 08:27:45 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550431ACD88 for ; Mon, 13 Apr 2015 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.596 X-Spam-Level: *** X-Spam-Status: No, score=3.596 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlyVKb5zV6kq for ; Mon, 13 Apr 2015 08:27:42 -0700 (PDT) Received: from smg3.telecom.sna.samsung.com (unknown [63.166.115.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3ED1ACD2D for ; Mon, 13 Apr 2015 08:27:42 -0700 (PDT) X-AuditID: 41a9fa21-f79bf6d00000716e-bf-552be0621a55 Received: from exHub3.telecom.sna.samsung.com (Unknown_Domain [105.52.12.230]) by smg3.telecom.sna.samsung.com (SMGOUT STA) with SMTP id 18.0B.29038.260EB255; Mon, 13 Apr 2015 10:27:30 -0500 (CDT) Received: from EXMB5.telecom.sna.samsung.com ([169.254.1.80]) by exHub3.telecom.sna.samsung.com ([2002:6934:ce6::6934:ce6]) with mapi id 14.03.0210.002; Mon, 13 Apr 2015 10:27:41 -0500 From: Jayantheesh S B To: Alexey Melnikov , IMAPEXT Thread-Topic: [imapext] Charter Proposal for a new IMAP related Working Group Thread-Index: AQHQa+UDqDWa+Otx3UirURVLZqZ+o51LIf6g Date: Mon, 13 Apr 2015 15:27:40 +0000 Message-ID: <02454F842DD7B449B96715A2AD90C0365EBA2111@exMB5.telecom.sna.samsung.com> References: <551A0193.5030104@isode.com> In-Reply-To: <551A0193.5030104@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [105.52.12.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsWSacLzTDfpgXaowcbl+hYzVhdZPJ7F5cDk sWTJTyaPU82GAUxR3DZJiSVlwZnpefp2CdwZFzZMZyt4KFVxqeM4YwPjG9EuRk4OCQETicvd p5kgbDGJC/fWs3UxcnEICRxjlFjUu5MFwtnDKPGp5xGQw87BJqAj8SQYpF5EwFvic9N0dhBb WMBH4uWJ+awQcV+Jnp/bGCFsI4k/1+azgNgsAqoSy1t/MoPYvAIhElM//QSLCwloSHz/9AUs zimgKbHqwwmwmYxA93w/tQbsNmYBcYlbT+ZD3SkgsWTPeWYIW1Ti5eN/rBC2osTcXzeZIep1 JBbs/sQGYWtLLFv4GmqvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUaY4N91YryQ1JzU5 P1evOC9Rrzgxt7g0L10PyN/ECIwXx5W/FHcw7tpvf4iRiYPzEKMEB5eUSHFqXkpqUWJpSUY8 KErii4FxItXAyPV61o3Q9XPZVoVte79Fae208gW/Mt35Mk+tmMvQn+0dU/7z5onYBf8uOr00 LmG+FMSp69J0wER7tpBT8gwbSZb5+e2Ouqz/7vIUevizanzWuafHy/TrtY3t0qBf/1haI/Yn L17l2RVWunPXrd1/uzrufnquLqyyRCo/5sAKhwmJx4p7RPiTlViKMxINtZiLihMB5dU3rWIC AAA= Archived-At: Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:27:44 -0000 HI Alexey, Below Charter Proposal for The IMAP APPEND extension (imapappend) working g= roup, looks good. =20 I am Ok with the proposal text as is. Regards, Jay -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Monday, March 30, 2015 10:08 PM To: IMAPEXT Subject: [imapext] Charter Proposal for a new IMAP related Working Group Hi, I've asked Barry earlier what he would like to do about draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he ask= ed for a charter for a new short term IMAP related WG. Here is a proposal: The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies= a protocol for transferring email messages between a server that implement= s a message store, and a client. It also includes commands for manipulating= the message store -- creating, deleting, and renaming mailboxes, adding a = message to a mailbox, and copying messages from one mailbox to another. IMAP (RFC 3501) contains the "literal" syntactic construct for transferring= blocks of data. When sending a literal from a client to a server, RFC 3501= requires the client to wait for the server to send a command continuation = request between sending the octet count and the string data. This complicates client implementations and resulted in definition of LITER= AL+ IMAP extension (RFC 2088) which specifies an alternate form of literal = which does not require this network round trip. While this extension is qui= te commonly supported by servers, some implementations decided to disable i= t because it is frequently abused by naive clients that try to upload big m= essages without checking whether servers can accept big messages. The IMAP APPEND extension (imapappend) working group has two related delive= rables which are targeted at improving the current situation. One deliverab= le is based on draft-jayantheesh-imap-appendlimit-extension-03 and defines a way for servers to announce APPEND limit for a particular ser= ver or a particular mailbox. The second deliverable is based on draft-melni= kov-rfc2088bis-01. It describes implementation choices for server supportin= g LITERAL+ extension and also defines LITERAL- extension which have similar= properties, but is easier for servers to implement while preventing denial= of service attacks from malicious and naive IMAP clients. Both deliverable= s will be Standards Track documents. As part of the protocol development, implementation experience on both the = client and server side is highly desireable, so that the actual operational= value of this extension can be assessed. The working group will document t= he results of this experience on the working group wiki. No other IMAP extension work is in scope for this working group. ------ Comments: 1) I don't particularly care if LITERAL- is standardized or not, but I woul= d like the problem to be solved. If we can't agree on LITERAL-, then draft-= melnikov-rfc2088bis can just become a revision of LITERAL+. 2) I've also heard some interest in standardizing the SNAPSHOT facility.=20 I am ambivalent on whether it should be added to the above. (If you think i= t should, please suggest a new paragraph to add). I would like to keep the = charter to no more than 3 deliverables. Any opinions on the proposal? Best Regards, Alexey From nobody Mon Apr 13 09:21:25 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4CA1A024E for ; Mon, 13 Apr 2015 09:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWxch8Hm3awA for ; Mon, 13 Apr 2015 09:21:24 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B061A0211 for ; Mon, 13 Apr 2015 09:21:23 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-08v.sys.comcast.net with comcast id FUM61q0034zp9eg01UMPEf; Mon, 13 Apr 2015 16:21:23 +0000 Received: from bigworm.curecanti.org ([67.176.83.228]) by resomta-po-07v.sys.comcast.net with comcast id FUMN1q00l4vagWz01UMPTS; Mon, 13 Apr 2015 16:21:23 +0000 Received: from localhost (localhost.localdomain [IPv6:::1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id CD44368068 for ; Mon, 13 Apr 2015 10:21:22 -0600 (MDT) Received: from dangerzone.curecanti.org (dangerzone.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Mon, 13 Apr 2015 10:21:22 -0600 Date: Mon, 13 Apr 2015 10:21:22 -0600 Message-ID: <20150413102122.Horde.f6fd7WsdcM19S6mhkNze2un@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <551A0193.5030104@isode.com> <552BDDB7.9080304@isode.com> In-Reply-To: <552BDDB7.9080304@isode.com> User-Agent: Internet Messaging Program (IMP) H6 (7.0.0-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1428942083; bh=4yENWF//yIyRRtVzuhGYTF5KT3/qS91NBf1DnaM05ys=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=WyDlZivV5z0uGGPDox7gHPaD5Shan31xxMp8fDvGfU52sjDPnx42LXeil/T88C1uX H5RU1I5M0qoM6BMOmPk5kUO4MX3riZHQkmWPUX8s6DNRDU0wHjTz2iXnNuDPxBQOE6 THivevfigkvn6n/0Np69eWHrGKktPLmnH62ds2WmHyOPd/Fac3YjPRL4/P1B3Be9s7 rQmPdZQC2/mWkrWrcXYai4SX925QS570C4ZT0wnz9Gas67P0bnZy1id8nE4Hvop4dB rsohGB5NOvVEnf9wYGI4jS0ufNfWXNl8Eq8luJeA2kiRoP+AW/210yl5yLhdLKaa5e hrHC38ifbLZbw== Archived-At: Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 16:21:25 -0000 Quoting Alexey Melnikov : > Hi Chris, > > On 03/04/2015 07:33, Chris Newman wrote: >> I've reviewed the append limit proposal already and will review a SNIPPET >> proposal if one is written up. If someone else can commit to >> editing a SNIPPET >> draft, I'll write charter text for it and review the draft. But no point >> writing that text if there's no document editor. > I can edit the SNIPPET draft, but I will not commit to doing the > initial outline of it. So we still need for somebody to sketch out > how this might look first. Hi Alexey, I talked with Timo regarding SNIPPET, which has been internally implemented in Dovecot, although not yet with an IMAP protocol API. I would be willing to draft what is necessary in order to add to the group scope and begin a discussion on how to implement at the IMAP level. Let me know if interested and what needs to be done. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From nobody Mon Apr 13 15:39:03 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5771B2AB3 for ; Mon, 13 Apr 2015 15:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFE5mh4xVaMd for ; Mon, 13 Apr 2015 15:39:00 -0700 (PDT) Received: from omr-m5.mx.aol.com (omr-m5.mx.aol.com [64.12.232.237]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F0A1B2AAE for ; Mon, 13 Apr 2015 15:38:59 -0700 (PDT) Received: from mtaout-mcb02.mx.aol.com (mtaout-mcb02.mx.aol.com [172.26.50.174]) by omr-m5.mx.aol.com (Outbound Mail Relay) with ESMTP id 01EA33800005B; Mon, 13 Apr 2015 18:38:59 -0400 (EDT) Received: from [10.172.0.72] (unknown [10.172.0.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mcb02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id CB20E38000090; Mon, 13 Apr 2015 18:38:58 -0400 (EDT) Message-ID: <552C457A.50700@aol.com> Date: Mon, 13 Apr 2015 18:38:50 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: imapext@ietf.org References: <551A0193.5030104@isode.com> In-Reply-To: <551A0193.5030104@isode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1428964738; bh=hteHML0j6RG3Zm+XeNzkWvoUiOoaGJ25Zv8w6TVECz4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=nVPtzoPUbrupGL8lFPFW0FfNdGjmv3/hBbzA2SVBUy2hiaW5zjw5t0oiV7uKof2mC r66zYK3zfXCweFFo21m+nVDwqWVboHbJZV1BHBJ1B1o2XkSEMTimYJxK+VmIJSWkQG kQ5xFAGOGGrA136NOsZjILXNu5eBZA7N0s4vcvOk= x-aol-sid: 3039ac1a32ae552c45825798 X-AOL-IP: 10.172.0.72 Archived-At: Cc: 'Alexey Melnikov' Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 22:39:01 -0000 Is there any interest in an additional APPEND related extension to support replacement of stored messages (e.g. Drafts, Notes). In the past year or so we've seen: a) a significant increase in the number of sessions doing automatic saving of drafts, some of which don't have much error handling for mobile network flakiness and end up orphaning the original copy. b) more sessions interacting with a "Notes" folder in same manner. c) some cloud based apps replacing messages as soon as they're discovered after delivery (presumably to add their own "metadata" in the form of client-specific headers) For all the reasons that MOVE (RFC 6851) made sense, I think a REPLACE extension would make sense for providing an atomic alternative to the current APPEND/STORE/EXPUNGE trio required to replace messages. I have the beginnings of a draft written up, but given the creation of this working group would be willing to accelerate getting it out there. Any interest? - Stuart On 3/30/15 10:08 PM, Alexey Melnikov wrote: > Hi, > > I've asked Barry earlier what he would like to do about > draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he > asked for a charter for a new short term IMAP related WG. Here is a > proposal: > > > The Internet Message Access Protocol (IMAP), defined in RFC 3501, > specifies a protocol for transferring email messages between a server > that implements a message store, and a client. It also includes commands > for manipulating the message store -- creating, deleting, and renaming > mailboxes, adding a message to a mailbox, and copying messages from one > mailbox to another. > > IMAP (RFC 3501) contains the "literal" syntactic construct for > transferring blocks of data. When sending a literal from a client to a > server, > RFC 3501 requires the client to wait for the server to send a command > continuation request between sending the octet count and the string data. > This complicates client implementations and resulted in definition > of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form > of literal which does not require this network round trip. While this > extension is quite commonly supported by servers, some implementations > decided to disable it because it is frequently abused by naive clients > that try to upload big messages without checking whether servers can > accept big messages. > > The IMAP APPEND extension (imapappend) working group has two related > deliverables which are targeted at improving the current situation. One > deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03 > and defines a way for servers to announce APPEND limit for a particular > server or a particular mailbox. The second deliverable is based on > draft-melnikov-rfc2088bis-01. It describes implementation choices for > server supporting LITERAL+ extension and also defines LITERAL- extension > which have similar properties, but is easier for servers to implement > while preventing denial of service attacks from malicious and naive IMAP > clients. Both deliverables will be Standards Track documents. > > As part of the protocol development, implementation experience on both > the client and server side is highly desireable, so that the actual > operational value of this extension can be assessed. The working group > will document the results of this experience on the working group wiki. > > No other IMAP extension work is in scope for this working group. > > ------ > Comments: > > > 1) I don't particularly care if LITERAL- is standardized or not, but I > would like the problem to be solved. If we can't agree on LITERAL-, then > draft-melnikov-rfc2088bis can just become a revision of LITERAL+. > > 2) I've also heard some interest in standardizing the SNAPSHOT facility. > I am ambivalent on whether it should be added to the above. (If you > think it should, please suggest a new paragraph to add). I would like to > keep the charter to no more than 3 deliverables. > > Any opinions on the proposal? > > Best Regards, > Alexey > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From nobody Tue Apr 14 01:48:20 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16FC1A0145 for ; Tue, 14 Apr 2015 01:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixqe6LLJQUo4 for ; Tue, 14 Apr 2015 01:48:17 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571D41A0113 for ; Tue, 14 Apr 2015 01:48:17 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id A30D6FA0069; Tue, 14 Apr 2015 08:48:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1429001294; bh=qvgaGGIV77OXrZbhlLpc973Fm8xsfuSBT+Jl66TQcsM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rmE/5oiCYfTBS1YbVW/UNyiI/YBO/6M3T4n26chkOB23mO9b+qezerRcHl4ijSm59 Bef1oLr67WofdUjiQXw3CS5xpS7qy/9V84K/HQwAEpgfmKAsPu5AQOmEgy6wXjN1F5 QA+34GIrdet3qsnzGD6c3oYSPq6FW3AIAuGWL20w= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1429001292-31136-31135/11/14; Tue, 14 Apr 2015 08:48:12 +0000 From: Arnt Gulbrandsen To: Stuart Brandt Date: Tue, 14 Apr 2015 10:48:12 +0200 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Ubuntu 14.04.2 LTS Mime-Version: 1.0 Message-Id: <0c4cfb3b-d4b3-42ed-9727-dd41d3c8a903@gulbrandsen.priv.no> In-Reply-To: <552C457A.50700@aol.com> References: <551A0193.5030104@isode.com> <552C457A.50700@aol.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Cc: Alexey Melnikov , imapext@ietf.org Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 08:48:18 -0000 Stuart Brandt writes: > I have the beginnings of a draft written up, but given the > creation of this working group would be willing to accelerate > getting it out there. I have a perfectly formed draft, the result of considerable off-line discussion last year, but no real interest in taking it further. You can have it if you want it. Arnt From nobody Tue Apr 14 05:07:48 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB13C1A8F4B for ; Tue, 14 Apr 2015 05:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCYhb8pSV8VB for ; Tue, 14 Apr 2015 05:07:45 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 89EBA1A8F3C for ; Tue, 14 Apr 2015 05:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1429013263; d=isode.com; s=selector; i=@isode.com; bh=kbJ6aQWzGhuaY9Yl0PxzveRIcJH4GDtiY5AIOmOZujw=; 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=RU1bahWZ4AtgBRXJoSRQyYYSWJASjeXUD50dbdru282h87/Ft1LRPp2RJv737BwIdIx2sF wjBJWNQCffJYb7ySMpf6GFNPlMgAha93n4a7i0mWzFAWTVSZzj4Yumb68n4/xPI2E1JZK5 pCteaBF0FVXzV5mtnkmdlyu+NENR6q0=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 14 Apr 2015 13:07:43 +0100 Message-ID: <552D0309.7080903@isode.com> Date: Tue, 14 Apr 2015 13:07:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Stuart Brandt , imapext@ietf.org References: <551A0193.5030104@isode.com> <552C457A.50700@aol.com> In-Reply-To: <552C457A.50700@aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 12:07:47 -0000 Hi Stuart, On 13/04/2015 23:38, Stuart Brandt wrote: > Is there any interest in an additional APPEND related extension to > support replacement of stored messages (e.g. Drafts, Notes). In the > past year or so we've seen: > a) a significant increase in the number of sessions doing automatic > saving of drafts, some of which don't have much error handling for > mobile network flakiness and end up orphaning the original copy. > b) more sessions interacting with a "Notes" folder in same manner. > c) some cloud based apps replacing messages as soon as they're > discovered after delivery (presumably to add their own "metadata" in > the form of client-specific headers) > > For all the reasons that MOVE (RFC 6851) made sense, I think a REPLACE > extension would make sense for providing an atomic alternative to the > current APPEND/STORE/EXPUNGE trio required to replace messages. > > I have the beginnings of a draft written up, but given the creation of > this working group would be willing to accelerate getting it out there. I think you should post the draft regardless of whether or not it is included in the charter. Personally I would like to see something before saying "yes I am interested" or "no". > Any interest? > > - Stuart > > > On 3/30/15 10:08 PM, Alexey Melnikov wrote: >> Hi, >> >> I've asked Barry earlier what he would like to do about >> draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he >> asked for a charter for a new short term IMAP related WG. Here is a >> proposal: >> >> >> The Internet Message Access Protocol (IMAP), defined in RFC 3501, >> specifies a protocol for transferring email messages between a server >> that implements a message store, and a client. It also includes commands >> for manipulating the message store -- creating, deleting, and renaming >> mailboxes, adding a message to a mailbox, and copying messages from one >> mailbox to another. >> >> IMAP (RFC 3501) contains the "literal" syntactic construct for >> transferring blocks of data. When sending a literal from a client to a >> server, >> RFC 3501 requires the client to wait for the server to send a command >> continuation request between sending the octet count and the string >> data. >> This complicates client implementations and resulted in definition >> of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form >> of literal which does not require this network round trip. While this >> extension is quite commonly supported by servers, some implementations >> decided to disable it because it is frequently abused by naive clients >> that try to upload big messages without checking whether servers can >> accept big messages. >> >> The IMAP APPEND extension (imapappend) working group has two related >> deliverables which are targeted at improving the current situation. One >> deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03 >> and defines a way for servers to announce APPEND limit for a particular >> server or a particular mailbox. The second deliverable is based on >> draft-melnikov-rfc2088bis-01. It describes implementation choices for >> server supporting LITERAL+ extension and also defines LITERAL- extension >> which have similar properties, but is easier for servers to implement >> while preventing denial of service attacks from malicious and naive IMAP >> clients. Both deliverables will be Standards Track documents. >> >> As part of the protocol development, implementation experience on both >> the client and server side is highly desireable, so that the actual >> operational value of this extension can be assessed. The working group >> will document the results of this experience on the working group wiki. >> >> No other IMAP extension work is in scope for this working group. >> >> ------ >> Comments: >> >> >> 1) I don't particularly care if LITERAL- is standardized or not, but I >> would like the problem to be solved. If we can't agree on LITERAL-, then >> draft-melnikov-rfc2088bis can just become a revision of LITERAL+. >> >> 2) I've also heard some interest in standardizing the SNAPSHOT facility. >> I am ambivalent on whether it should be added to the above. (If you >> think it should, please suggest a new paragraph to add). I would like to >> keep the charter to no more than 3 deliverables. >> >> Any opinions on the proposal? >> >> Best Regards, >> Alexey >> >> _______________________________________________ >> 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 nobody Tue Apr 14 08:13:32 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE821B2CB1 for ; Tue, 14 Apr 2015 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD8p0k_lSQWI for ; Tue, 14 Apr 2015 08:13:27 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87521B2CBD for ; Tue, 14 Apr 2015 08:12:06 -0700 (PDT) Received: by qkx62 with SMTP id 62so23378563qkx.0 for ; Tue, 14 Apr 2015 08:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Axr9i1YEV9vTO8W6HQd19ph4qaELVdirzSTu8AgADb8=; b=sa68yXPZyAYEPuE8BR64qRuroZf6n4PRoUCj0E9P2wVlj/vDhKD9sOxGQmrKvlRmNB 7JvIUedvT7c7hPzQCCssZS729z9dinWYUNFtcJnACiia6u7Wf5VaF4hU6MsvxvIe1ThO EBzxrjcRbMMPF/6sQnibWunnqXhYED7Tn1a04xKPv85Qp0mQyq6aUMGEExAtIoKVk19h Q7iYWJFRru5ncJ795drEcXa+crKDMxwA5J7mXbs31GT/dXk1Q32oPXO47gKcjXRu6ZX0 dxYcHJuyE+wk3MqDgI3Chg/S51lj1OQgZbYl42bk7BH1fo8TvnqekvWAPb2WjeqZ6dVQ oBJw== X-Received: by 10.55.20.30 with SMTP id e30mr31525939qkh.45.1429024311343; Tue, 14 Apr 2015 08:11:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.38 with HTTP; Tue, 14 Apr 2015 08:11:30 -0700 (PDT) In-Reply-To: References: From: Naren Date: Tue, 14 Apr 2015 11:11:30 -0400 Message-ID: To: imapext@ietf.org Content-Type: multipart/alternative; boundary=001a1140559474000c0513b0a665 Archived-At: Subject: Re: [imapext] imapext Digest, Vol 32, Issue 14 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 15:13:29 -0000 --001a1140559474000c0513b0a665 Content-Type: text/plain; charset=UTF-8 The charter text looks ok. Both the deliverable are related to each other. Thanks -Naren On Tue, Mar 31, 2015 at 3:00 PM, wrote: > Send imapext mailing list submissions to > imapext@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/imapext > or, via email, send a message with subject or body 'help' to > imapext-request@ietf.org > > You can reach the person managing the list at > imapext-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of imapext digest..." > > Today's Topics: > > 1. Charter Proposal for a new IMAP related Working Group > (Alexey Melnikov) > > > ---------- Forwarded message ---------- > From: Alexey Melnikov > To: IMAPEXT > Cc: > Date: Tue, 31 Mar 2015 03:08:19 +0100 > Subject: [imapext] Charter Proposal for a new IMAP related Working Group > Hi, > > I've asked Barry earlier what he would like to do about > draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he > asked for a charter for a new short term IMAP related WG. Here is a > proposal: > > > The Internet Message Access Protocol (IMAP), defined in RFC 3501, > specifies a protocol for transferring email messages between a server > that implements a message store, and a client. It also includes commands > for manipulating the message store -- creating, deleting, and renaming > mailboxes, adding a message to a mailbox, and copying messages from one > mailbox to another. > > IMAP (RFC 3501) contains the "literal" syntactic construct for > transferring blocks of data. When sending a literal from a client to a > server, > RFC 3501 requires the client to wait for the server to send a command > continuation request between sending the octet count and the string data. > This complicates client implementations and resulted in definition > of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form > of literal which does not require this network round trip. While this > extension is quite commonly supported by servers, some implementations > decided to disable it because it is frequently abused by naive clients > that try to upload big messages without checking whether servers can > accept big messages. > > The IMAP APPEND extension (imapappend) working group has two related > deliverables which are targeted at improving the current situation. One > deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03 > and defines a way for servers to announce APPEND limit for a particular > server or a particular mailbox. The second deliverable is based on > draft-melnikov-rfc2088bis-01. It describes implementation choices for > server supporting LITERAL+ extension and also defines LITERAL- extension > which have similar properties, but is easier for servers to implement > while preventing denial of service attacks from malicious and naive IMAP > clients. Both deliverables will be Standards Track documents. > > As part of the protocol development, implementation experience on both > the client and server side is highly desireable, so that the actual > operational value of this extension can be assessed. The working group > will document the results of this experience on the working group wiki. > > No other IMAP extension work is in scope for this working group. > > ------ > Comments: > > > 1) I don't particularly care if LITERAL- is standardized or not, but I > would like the problem to be solved. If we can't agree on LITERAL-, then > draft-melnikov-rfc2088bis can just become a revision of LITERAL+. > > 2) I've also heard some interest in standardizing the SNAPSHOT facility. I > am ambivalent on whether it should be added to the above. (If you think it > should, please suggest a new paragraph to add). I would like to keep the > charter to no more than 3 deliverables. > > Any opinions on the proposal? > > Best Regards, > Alexey > > > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > > --001a1140559474000c0513b0a665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The charter text looks ok.

Both the deliverable are re= lated to each other.

Thanks

-Naren

On Tue, Mar 31, 2= 015 at 3:00 PM, <imapext-request@ietf.org> wrote:

Send imapext mailing list submissions to =C2=A0 =C2=A0 =C2=A0 =C2=A0 imapext@iet= f.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/imapext<= /a>
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ima= pext-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 imape= xt-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of imapext digest..."

Today's Topics:

=C2=A0 =C2=A01. Charter Proposal for a new IMAP related Working Group
=C2=A0 =C2=A0 =C2=A0 (Alexey Melnikov)

---------- Forwarded message ----------
From:=C2=A0Alexey Melnik= ov <alexey.melnikov@isode.c= om>
To:=C2=A0IMAPEXT <imap= ext@ietf.org>
Cc:=C2=A0
Date:=C2=A0Tue, 31 Mar 2015 03:08:19 += 0100
Subject:=C2=A0[imapext] Charter Proposal for a new IMAP related Wor= king Group
Hi,

I've asked Barry earlier what he would like to do about
draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and= he
asked for a charter for a new short term IMAP related WG. Here is a
proposal:

The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for transferring blocks of data. When sending a literal from a client to a serv= er,
RFC 3501 requires the client to wait for the server to send a command
continuation request between sending the octet count and the string data. This complicates client implementations and resulted in definition
of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form
of literal which does not require this network round trip. While this
extension is quite commonly supported by servers, some implementations
decided to disable it because it is frequently abused by naive clients
that try to upload big messages without checking whether servers can
accept big messages.

The IMAP APPEND extension (imapappend) working group has two related
deliverables which are targeted at improving the current situation. One
deliverable is based on draft-jayantheesh-imap-appendlimit-extension= -03
and defines a way for servers to announce APPEND limit for a particular
server or a particular mailbox. The second deliverable is based on
draft-melnikov-rfc2088bis-01. It describes implementation choices for
server supporting LITERAL+ extension and also defines LITERAL- extension which have similar properties, but is easier for servers to implement
while preventing denial of service attacks from malicious and naive IMAP clients. Both deliverables will be Standards Track documents.

As part of the protocol development, implementation experience on both
the client and server side is highly desireable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

------
Comments:

1) I don't particularly care if LITERAL- is standardized or not, but I = would like the problem to be solved. If we can't agree on LITERAL-, the= n draft-melnikov-rfc2088bis can just become a revision of LITERAL+.

2) I've also heard some interest in standardizing the SNAPSHOT facility= . I am ambivalent on whether it should be added to the above. (If you think= it should, please suggest a new paragraph to add). I would like to keep th= e charter to no more than 3 deliverables.

Any opinions on the proposal?

Best Regards,
Alexey

_______________________________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext

--001a1140559474000c0513b0a665-- From nobody Mon Apr 20 08:06:22 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AED1B2E74 for ; Mon, 20 Apr 2015 08:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7yFZ2lZsLn4 for ; Mon, 20 Apr 2015 08:06:20 -0700 (PDT) Received: from smg3.telecom.sna.samsung.com (unknown [63.166.115.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8B61B2E7B for ; Mon, 20 Apr 2015 08:06:09 -0700 (PDT) X-AuditID: 41a9fa21-f79bf6d00000716e-ab-553515d43bf7 Received: from exHub1.telecom.sna.samsung.com (Unknown_Domain [105.52.12.248]) by smg3.telecom.sna.samsung.com (SMGOUT STA) with SMTP id 6B.93.29038.4D515355; Mon, 20 Apr 2015 10:05:56 -0500 (CDT) Received: from EXMB5.telecom.sna.samsung.com ([169.254.1.80]) by exHub1.telecom.sna.samsung.com ([2002:6934:cf8::6934:cf8]) with mapi id 14.03.0210.002; Mon, 20 Apr 2015 10:06:07 -0500 From: Jayantheesh S B To: IMAPEXT Thread-Topic: [imapext] Charter Proposal for a new IMAP related Working Group Thread-Index: AQHQa+UDZiL8XmTViku59iF0qxiGO51WHuRA Date: Mon, 20 Apr 2015 15:06:07 +0000 Message-ID: <02454F842DD7B449B96715A2AD90C0365EBAB229@exMB5.telecom.sna.samsung.com> References: <551A0193.5030104@isode.com> In-Reply-To: <551A0193.5030104@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [105.52.12.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsWSacLzQ/eKqGmowZSbFhYzVhdZPJ7F5cDk sWTJTyaPU82GAUxR3DZJiSVlwZnpefp2CdwZ/45NZi2YI1WxcdME1gbGXaJdjJwcEgImEp83 HGKFsMUkLtxbz9bFyMUhJHCMUeLPm/VMIAkhgT2MEhOXh3UxsnOwCehIPAkGiYoIyEnMX3QY rIJZQF/iz8ZLzCC2sICPxMsT81khanwlen5uY4SwjSRONR9hA7FZBFQl5s09wA5i8wqESFy4 MpsZYpOGxPdPX8BsTgFNiVUfToDVMAKd9v3UGqhd4hK3nsxngjhZQGLJnvPMELaoxMvH/6Be UZSY++smM0S9jsSC3Z/YIGxtiWULXzND7BWUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjHK FOemG+uVpOakJufn6hXnJeoVJ+YWl+al6wH5mxiBUeS48pfiDsZd++0PMTJxcB5ilODgkhIp Ts1LSS1KLC3JiAfFTnwxMHqkGhhZp7ybGxirxlOxTTaR/dfbutfiJYZRJbcCH0ir/reIUDHb ZB+xNfGQ7W0/n3W37GY/ODh3+h5OIcUQ45t2fguj7Ga/eNO92/bWmfctCu02EqfLd6U4T62X zfswe/Hbw5rKv49zV/7mSzQ0K3+tcPujBduVic4rtrbPDihNcLI2t1m7MeGsvYcSS3FGoqEW c1FxIgD9vFxHbQIAAA== Archived-At: Cc: Alexey Melnikov Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 15:06:21 -0000 Hi All, Kindly share your comments regarding the Charter text proposed by Alexey.=20 Regards, Jay -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Monday, March 30, 2015 10:08 PM To: IMAPEXT Subject: [imapext] Charter Proposal for a new IMAP related Working Group Hi, I've asked Barry earlier what he would like to do about draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he ask= ed for a charter for a new short term IMAP related WG. Here is a proposal: The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies= a protocol for transferring email messages between a server that implement= s a message store, and a client. It also includes commands for manipulating= the message store -- creating, deleting, and renaming mailboxes, adding a = message to a mailbox, and copying messages from one mailbox to another. IMAP (RFC 3501) contains the "literal" syntactic construct for transferring= blocks of data. When sending a literal from a client to a server, RFC 3501= requires the client to wait for the server to send a command continuation = request between sending the octet count and the string data. This complicates client implementations and resulted in definition of LITER= AL+ IMAP extension (RFC 2088) which specifies an alternate form of literal = which does not require this network round trip. While this extension is qui= te commonly supported by servers, some implementations decided to disable i= t because it is frequently abused by naive clients that try to upload big m= essages without checking whether servers can accept big messages. The IMAP APPEND extension (imapappend) working group has two related delive= rables which are targeted at improving the current situation. One deliverab= le is based on draft-jayantheesh-imap-appendlimit-extension-03 and defines a way for servers to announce APPEND limit for a particular ser= ver or a particular mailbox. The second deliverable is based on draft-melni= kov-rfc2088bis-01. It describes implementation choices for server supportin= g LITERAL+ extension and also defines LITERAL- extension which have similar= properties, but is easier for servers to implement while preventing denial= of service attacks from malicious and naive IMAP clients. Both deliverable= s will be Standards Track documents. As part of the protocol development, implementation experience on both the = client and server side is highly desireable, so that the actual operational= value of this extension can be assessed. The working group will document t= he results of this experience on the working group wiki. No other IMAP extension work is in scope for this working group. ------ Comments: 1) I don't particularly care if LITERAL- is standardized or not, but I woul= d like the problem to be solved. If we can't agree on LITERAL-, then draft-= melnikov-rfc2088bis can just become a revision of LITERAL+. 2) I've also heard some interest in standardizing the SNAPSHOT facility.=20 I am ambivalent on whether it should be added to the above. (If you think i= t should, please suggest a new paragraph to add). I would like to keep the = charter to no more than 3 deliverables. Any opinions on the proposal? Best Regards, Alexey From nobody Mon Apr 20 15:44:22 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666C01B33AE for ; Mon, 20 Apr 2015 15:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD4FjECUJR0s for ; Mon, 20 Apr 2015 15:44:19 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE4F1B33AF for ; Mon, 20 Apr 2015 15:44:19 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so1155656ied.1 for ; Mon, 20 Apr 2015 15:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=toZOIP50dWrtrT+49G47zqfEXz8wlqexTD79ANHa7wY=; b=NSvcdOLzAVTQp4hc0hp5TIxfhAU0I/8taT5u8Uz+2WvmXG7+62coZIyAjmJi/S5B8B 3zuvYIpUvF7JU/UViwWZZim3cG1JuVt9n+i+O6Np3hQ4TlkimPg38Be3RQHhDehMucrZ h/GBM5dEmUe1sWwdpDLeUmgqpgfyPNsAglrbeHMefluk5wSGh5NMAAlHvl8kI+g1TuQ3 sKWnGbog1KuyjAx2SS8CbtmftrhMEj6erLF3DmN/7pM9lbMrMCvipr5Hk85CsoVI1aFn t7EPRaC8vZSsrKN2/tOJQFatYl5dJSCsswDAxjt3oO7CeHghAZxfZnKaemN52KJYRZvV Vkvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=toZOIP50dWrtrT+49G47zqfEXz8wlqexTD79ANHa7wY=; b=MoCWBKHTrHWBi3YdaByYcvR93WfDnFrJ28jO0fEYW7CreN5GHSsvLnuIXysEW+i7Ba K3OgeHBgIx19hVCx5fwHLWt4zkAZ/Yozry3UaG+OPBcVxkWnVZv1kCgMMKpMAsmr4Nci Wkj8FlBJW+A2V9KUPX/wCCXDVyn7De++Kb0XJMKmtf2cQpOUOtIg8HRN3SgNgqWgEyM4 qnzv5E0LNHxBN6v2KMIRIl+QR/LRcWbsqWBlFmh8UJr4jLvlteY/1SNdgaqfG4cVmUub ya29uA79HZrDq/+ZqW0DhxQSIvZMdGDyF9fXEJPBBN7CiJABtbA3SUGeAGHJ83XpmrpO DdkA== X-Gm-Message-State: ALoCoQk5HComUQHOyfY7c5b+OLYhnObaFcBykgOmTELvSDeKx+fyoCJBgZXgH6gEf46zT0mLzg1U X-Received: by 10.107.138.130 with SMTP id c2mr24695608ioj.74.1429569859077; Mon, 20 Apr 2015 15:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.103.101 with HTTP; Mon, 20 Apr 2015 15:43:48 -0700 (PDT) In-Reply-To: <551A0193.5030104@isode.com> References: <551A0193.5030104@isode.com> From: Jamie Nicolson Date: Mon, 20 Apr 2015 15:43:48 -0700 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a113f284ea1e5e905142fab57 Archived-At: Cc: IMAPEXT Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 22:44:21 -0000 --001a113f284ea1e5e905142fab57 Content-Type: text/plain; charset=UTF-8 Thanks, I think this is a valuable area to address in a WG. We're interested in both of these extensions for Gmail. On Mon, Mar 30, 2015 at 7:08 PM, Alexey Melnikov wrote: > Hi, > > I've asked Barry earlier what he would like to do about > draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he > asked for a charter for a new short term IMAP related WG. Here is a > proposal: > > > The Internet Message Access Protocol (IMAP), defined in RFC 3501, > specifies a protocol for transferring email messages between a server > that implements a message store, and a client. It also includes commands > for manipulating the message store -- creating, deleting, and renaming > mailboxes, adding a message to a mailbox, and copying messages from one > mailbox to another. > > IMAP (RFC 3501) contains the "literal" syntactic construct for > transferring blocks of data. When sending a literal from a client to a > server, > RFC 3501 requires the client to wait for the server to send a command > continuation request between sending the octet count and the string data. > This complicates client implementations and resulted in definition > of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form > of literal which does not require this network round trip. While this > extension is quite commonly supported by servers, some implementations > decided to disable it because it is frequently abused by naive clients > that try to upload big messages without checking whether servers can > accept big messages. > > The IMAP APPEND extension (imapappend) working group has two related > deliverables which are targeted at improving the current situation. One > deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03 > and defines a way for servers to announce APPEND limit for a particular > server or a particular mailbox. The second deliverable is based on > draft-melnikov-rfc2088bis-01. It describes implementation choices for > server supporting LITERAL+ extension and also defines LITERAL- extension > which have similar properties, but is easier for servers to implement > while preventing denial of service attacks from malicious and naive IMAP > clients. Both deliverables will be Standards Track documents. > > As part of the protocol development, implementation experience on both > the client and server side is highly desireable, so that the actual > operational value of this extension can be assessed. The working group > will document the results of this experience on the working group wiki. > > No other IMAP extension work is in scope for this working group. > > ------ > Comments: > > > 1) I don't particularly care if LITERAL- is standardized or not, but I > would like the problem to be solved. If we can't agree on LITERAL-, then > draft-melnikov-rfc2088bis can just become a revision of LITERAL+. > > 2) I've also heard some interest in standardizing the SNAPSHOT facility. I > am ambivalent on whether it should be added to the above. (If you think it > should, please suggest a new paragraph to add). I would like to keep the > charter to no more than 3 deliverables. > > Any opinions on the proposal? > > Best Regards, > Alexey > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > --001a113f284ea1e5e905142fab57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks, I think this is a valuable area to address in a WG= . We're interested in both of these extensions for Gmail.

On Mon, Mar 30, 2015 at 7= :08 PM, Alexey Melnikov <alexey.melnikov@isode.com> = wrote:

Hi,

I've asked Barry earlier what he would like to do about
draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he
asked for a charter for a new short term IMAP related WG. Here is a
proposal:

The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for transferring blocks of data. When sending a literal from a client to a serv= er,
RFC 3501 requires the client to wait for the server to send a command
continuation request between sending the octet count and the string data. This complicates client implementations and resulted in definition
of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form
of literal which does not require this network round trip. While this
extension is quite commonly supported by servers, some implementations
decided to disable it because it is frequently abused by naive clients
that try to upload big messages without checking whether servers can
accept big messages.

The IMAP APPEND extension (imapappend) working group has two related
deliverables which are targeted at improving the current situation. One
deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03
and defines a way for servers to announce APPEND limit for a particular
server or a particular mailbox. The second deliverable is based on
draft-melnikov-rfc2088bis-01. It describes implementation choices for
server supporting LITERAL+ extension and also defines LITERAL- extension which have similar properties, but is easier for servers to implement
while preventing denial of service attacks from malicious and naive IMAP clients. Both deliverables will be Standards Track documents.

As part of the protocol development, implementation experience on both
the client and server side is highly desireable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

------
Comments:

1) I don't particularly care if LITERAL- is standardized or not, but I = would like the problem to be solved. If we can't agree on LITERAL-, the= n draft-melnikov-rfc2088bis can just become a revision of LITERAL+.

2) I've also heard some interest in standardizing the SNAPSHOT facility= . I am ambivalent on whether it should be added to the above. (If you think= it should, please suggest a new paragraph to add). I would like to keep th= e charter to no more than 3 deliverables.

Any opinions on the proposal?

Best Regards,
Alexey

_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext

--001a113f284ea1e5e905142fab57-- From nobody Mon Apr 20 15:46:29 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5341B32E6 for ; Mon, 20 Apr 2015 15:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITPvuIRbW7D8 for ; Mon, 20 Apr 2015 15:46:26 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453CC1B32E3 for ; Mon, 20 Apr 2015 15:46:26 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so1192572ied.1 for ; Mon, 20 Apr 2015 15:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wklHRQq/0KVumY9Yx3IxS/eLDTukBcKnOjUY/ZHkbMw=; b=gFRNZxHUFtG3Asyt4MEl29P+NVm3XaCoXwtxYfFtXLuTxoSC5hb7hGC+fngR+dOSeI N6W/En3+mo47Ap9nmucU3HWaZEXzekCOcgWxwVqLbNkQYMVVMA+9IgB71hhcI+F6xgAo qyRKBC9PKYBhcnGIiUVYN2XRh6u7PReRuM8w33ZF8kfasjo1NxJw9EuNZ7/N20ngeDpA TtxHfP3Leeho0ujucz5ZVUfVjMFdNWXKtyDBj50whVBT5FARtzDlHRevotJqPKiwzosB nzH/gmzb3XjzG6lnxfPA+2Z8uq/qE2i+ae6rv7+EjvwipeTjoMNTl0oDx69SNLZ5vfvi gCIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wklHRQq/0KVumY9Yx3IxS/eLDTukBcKnOjUY/ZHkbMw=; b=ev2v47RAhcfihFd+J0w7yOWEewFqNl1qRIamFGlj+UKBhocfWgJXHrBvg74FAzk2qC ozQ9TX8koBJ0nTuLWkKFDsq82+hI5yeQvbrTtZzjRWH1hCVCnaG66q5JI8LWHvwck5QM 5f9ZxKWNRcSldKdDTuvhQ715HhSIPMrbnRHBZEKJpDInLJFocmEwfaRY808EA7HMdrvI 0A/PgOOzm8TLso9gS0x+Ix/ixx+1js647njxmbJ48QqPuZj5usWdlcWvANEGzYIRwJlF G4mkCnAKTZT4xSAY6+LgAsrGT13TB+YR5nOMvl/dUNRJ7oQOfTJZQYneLmcUdliJ8CfM uD6w== X-Gm-Message-State: ALoCoQlOSD7l8CcDjSUQuhvfa16LuWc3Qwig+Zh7/2OszNCyF83sURn6J2p3eh6gbIDIA28u6oZS X-Received: by 10.107.167.73 with SMTP id q70mr24818572ioe.82.1429569985709; Mon, 20 Apr 2015 15:46:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.103.101 with HTTP; Mon, 20 Apr 2015 15:45:52 -0700 (PDT) In-Reply-To: <552D0309.7080903@isode.com> References: <551A0193.5030104@isode.com> <552C457A.50700@aol.com> <552D0309.7080903@isode.com> From: Jamie Nicolson Date: Mon, 20 Apr 2015 15:45:52 -0700 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a1142a4802e3e5c05142fb3ed Archived-At: Cc: "imapext@ietf.org" , Stuart Brandt Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 22:46:29 -0000 --001a1142a4802e3e5c05142fb3ed Content-Type: text/plain; charset=UTF-8 Yes, please post. REPLACE sounds very useful for drafts. On Tue, Apr 14, 2015 at 5:07 AM, Alexey Melnikov wrote: > Hi Stuart, > > On 13/04/2015 23:38, Stuart Brandt wrote: > >> Is there any interest in an additional APPEND related extension to >> support replacement of stored messages (e.g. Drafts, Notes). In the past >> year or so we've seen: >> a) a significant increase in the number of sessions doing automatic >> saving of drafts, some of which don't have much error handling for mobile >> network flakiness and end up orphaning the original copy. >> b) more sessions interacting with a "Notes" folder in same manner. >> c) some cloud based apps replacing messages as soon as they're discovered >> after delivery (presumably to add their own "metadata" in the form of >> client-specific headers) >> >> For all the reasons that MOVE (RFC 6851) made sense, I think a REPLACE >> extension would make sense for providing an atomic alternative to the >> current APPEND/STORE/EXPUNGE trio required to replace messages. >> >> I have the beginnings of a draft written up, but given the creation of >> this working group would be willing to accelerate getting it out there. >> > I think you should post the draft regardless of whether or not it is > included in the charter. Personally I would like to see something before > saying "yes I am interested" or "no". > > Any interest? >> >> - Stuart >> >> >> On 3/30/15 10:08 PM, Alexey Melnikov wrote: >> >>> Hi, >>> >>> I've asked Barry earlier what he would like to do about >>> draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he >>> asked for a charter for a new short term IMAP related WG. Here is a >>> proposal: >>> >>> >>> The Internet Message Access Protocol (IMAP), defined in RFC 3501, >>> specifies a protocol for transferring email messages between a server >>> that implements a message store, and a client. It also includes commands >>> for manipulating the message store -- creating, deleting, and renaming >>> mailboxes, adding a message to a mailbox, and copying messages from one >>> mailbox to another. >>> >>> IMAP (RFC 3501) contains the "literal" syntactic construct for >>> transferring blocks of data. When sending a literal from a client to a >>> server, >>> RFC 3501 requires the client to wait for the server to send a command >>> continuation request between sending the octet count and the string data. >>> This complicates client implementations and resulted in definition >>> of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form >>> of literal which does not require this network round trip. While this >>> extension is quite commonly supported by servers, some implementations >>> decided to disable it because it is frequently abused by naive clients >>> that try to upload big messages without checking whether servers can >>> accept big messages. >>> >>> The IMAP APPEND extension (imapappend) working group has two related >>> deliverables which are targeted at improving the current situation. One >>> deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03 >>> and defines a way for servers to announce APPEND limit for a particular >>> server or a particular mailbox. The second deliverable is based on >>> draft-melnikov-rfc2088bis-01. It describes implementation choices for >>> server supporting LITERAL+ extension and also defines LITERAL- extension >>> which have similar properties, but is easier for servers to implement >>> while preventing denial of service attacks from malicious and naive IMAP >>> clients. Both deliverables will be Standards Track documents. >>> >>> As part of the protocol development, implementation experience on both >>> the client and server side is highly desireable, so that the actual >>> operational value of this extension can be assessed. The working group >>> will document the results of this experience on the working group wiki. >>> >>> No other IMAP extension work is in scope for this working group. >>> >>> ------ >>> Comments: >>> >>> >>> 1) I don't particularly care if LITERAL- is standardized or not, but I >>> would like the problem to be solved. If we can't agree on LITERAL-, then >>> draft-melnikov-rfc2088bis can just become a revision of LITERAL+. >>> >>> 2) I've also heard some interest in standardizing the SNAPSHOT facility. >>> I am ambivalent on whether it should be added to the above. (If you >>> think it should, please suggest a new paragraph to add). I would like to >>> keep the charter to no more than 3 deliverables. >>> >>> Any opinions on the proposal? >>> >>> Best Regards, >>> Alexey >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > --001a1142a4802e3e5c05142fb3ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, please post. REPLACE sounds very useful for drafts.

On Tue, Apr 1= 4, 2015 at 5:07 AM, Alexey Melnikov <alexey.melnikov@isode.com= > wrote:

Hi Stuart,

On 13/04/2015 23:38, Stuart Brandt wrote:

Is there any interest in an additional APPEND related extension to support = replacement of stored messages (e.g. Drafts, Notes). In the past year or so= we've seen:
a) a significant increase in the number of sessions doing automatic saving = of drafts, some of which don't have much error handling for mobile netw= ork flakiness and end up orphaning the original copy.
b) more sessions interacting with a "Notes" folder in same manner= .
c) some cloud based apps replacing messages as soon as they're discover= ed after delivery (presumably to add their own "metadata" in the = form of client-specific headers)

For all the reasons that MOVE (RFC 6851) made sense, I think a REPLACE exte= nsion would make sense for providing an atomic alternative to the current A= PPEND/STORE/EXPUNGE trio required to replace messages.

I have the beginnings of a draft written up, but given the creation of this= working group would be willing to accelerate getting it out there.

I think you should post the draft regardless of whether or not it is includ= ed in the charter. Personally I would like to see something before saying &= quot;yes I am interested" or "no".

Any interest?

- Stuart

On 3/30/15 10:08 PM, Alexey Melnikov wrote:

Hi,

I've asked Barry earlier what he would like to do about
draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he
asked for a charter for a new short term IMAP related WG. Here is a
proposal:

The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for transferring blocks of data. When sending a literal from a client to a
server,
RFC 3501 requires the client to wait for the server to send a command
continuation request between sending the octet count and the string data. This complicates client implementations and resulted in definition
of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form
of literal which does not require this network round trip. While this
extension is quite commonly supported by servers, some implementations
decided to disable it because it is frequently abused by naive clients
that try to upload big messages without checking whether servers can
accept big messages.

The IMAP APPEND extension (imapappend) working group has two related
deliverables which are targeted at improving the current situation. One
deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03
and defines a way for servers to announce APPEND limit for a particular
server or a particular mailbox. The second deliverable is based on
draft-melnikov-rfc2088bis-01. It describes implementation choices for
server supporting LITERAL+ extension and also defines LITERAL- extension which have similar properties, but is easier for servers to implement
while preventing denial of service attacks from malicious and naive IMAP clients. Both deliverables will be Standards Track documents.

As part of the protocol development, implementation experience on both
the client and server side is highly desireable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

------
Comments:

1) I don't particularly care if LITERAL- is standardized or not, but I<= br> would like the problem to be solved. If we can't agree on LITERAL-, the= n
draft-melnikov-rfc2088bis can just become a revision of LITERAL+.

2) I've also heard some interest in standardizing the SNAPSHOT facility= .
I am ambivalent on whether it should be added to the above. (If you
think it should, please suggest a new paragraph to add). I would like to keep the charter to no more than 3 deliverables.

Any opinions on the proposal?

Best Regards,
Alexey

_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext

--001a1142a4802e3e5c05142fb3ed-- From nobody Wed Apr 29 06:45:19 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B691A9241 for ; Wed, 29 Apr 2015 06:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTZAwutkWByf for ; Wed, 29 Apr 2015 06:45:14 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61E51A9240 for ; Wed, 29 Apr 2015 06:45:13 -0700 (PDT) Received: by qgfi89 with SMTP id i89so11317489qgf.1 for ; Wed, 29 Apr 2015 06:45:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=3zEgtfM8n39rvPHwNiKKbocSG+qkTKQXqi0yA6RLvJM=; b=KLeNI4itQSGgHML0F+558GecpiPMwcpNsikm8WLeqftUpqjneBw+zkC8FIKGO1dDq7 mkO0mW5sDsHS1T6yIfN2XKE1iVdEbe2ELs4uQNzFrSCTtLzdQEjFVMBMpPBJLKnI6vid HUWlxbrVWLXQlgIQqCL0qQYtjUNSy1I3HYVwUJon6kybNfhiEddTN3lcyG0rKqb+0T3L rl/f4oqYOyCWaak1106ULvdmqfZFOl8hH0xVpGgZqS8BKRgn7E2s6VEASupiKV55RWpr sZQ39O6Mlo+T5uuAwmdNOlZriTRHPkujw3loiQFW25rt0tga0+t6nilKqeElOeqqxWxP TBQQ== X-Gm-Message-State: ALoCoQmjbye7A43tdoUKx14Q5/I05qaO9gC8kqWEIcifx37V/bGbZX5fTubV+U0DpwnPeTDJQUPN X-Received: by 10.140.231.210 with SMTP id b201mr17435427qhc.82.1430315113001; Wed, 29 Apr 2015 06:45:13 -0700 (PDT) Received: from [10.172.125.106] (h-64-236-208-27.nat.aol.com. [64.236.208.27]) by mx.google.com with ESMTPSA id a6sm14786575qgf.17.2015.04.29.06.45.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 06:45:12 -0700 (PDT) Message-ID: <5540E067.1050609@teamaol.com> Date: Wed, 29 Apr 2015 09:45:11 -0400 From: Stu Brandt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "'imapext@ietf.org'" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [imapext] IMAP REPLACE extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 13:45:18 -0000 As promised, here's a draft of a REPLACE extension. Since the most obvious question is going to be "Why REPLACE and not an option on APPEND?", I'll answer it straight away... First, APPEND is valid in the authenticated state. REPLACE requires the selected state. I chose not to generate a mixed state scenario for APPEND. Secondly, REPLACE is similar to MOVE in that it avoids a number of issues that come with a serialized non-atomic sequence attempting to perform a single operation. MOVE is not an option on COPY, so I chose to follow the same precedent. Here's the writeup. ------------------------------------------------------------------------ Network Working Group S. Brandt Internet-Draft AOL Intended status: Standards Track April 29, 2015 Expires: October 31, 2015 IMAP REPLACE Extension draft-brandt-imap-replace-00 Abstract This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacment is a common operation for clients that automatically save drafts or notes as a user composes them. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 31, 2015. Copyright Notice Copyright (c) 2015 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. Brandt Expires October 31, 2015 [Page 1] Internet-Draft IMAP REPLACE Extension April 2015 Table of Contents 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . . 3 3.1. Advertising Support for REPLACE . . . . . . . . . . . . . 3 3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3 3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4 3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 4 3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 5 4. Interaction with other extensions . . . . . . . . . . . . . . 5 4.1. RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . . 6 4.2. RFC 4469, CATENATE . . . . . . . . . . . . . . . . . . . 6 4.3. RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . . 6 4.4. RFC 6785, IMAP Events in Sieve . . . . . . . . . . . . . 6 4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 6 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 [RFC3501] extension to facilitate replacing an existing message with a new one. This is accomplished by defining a new REPLACE command and extending the UID command to allow UID REPLACE. Using commands from the base IMAP specification, replacement of a message involves three separate commands issued in serial fashion; APPEND, STORE, EXPUNGE. Pipelining of these three commands is not recommended since failure of any individual command should prevent subsequent commands from being executed lest the original message Brandt Expires October 31, 2015 [Page 2] Internet-Draft IMAP REPLACE Extension April 2015 version be lost. The REPLACE command is intended to provide an atomic alternative to the existing non-atomic sequence. Because of the non-atomic nature of the existing sequence, interruptions can leave messages in intermediate states which can be seen and acted upon by other clients. Such interruptions can also strand older revisions of messages, thereby forcing the user to manually clean up multiple revisions of the same message in order to avoid wasteful quota consumption. Additionally, the existing sequence can fail on APPEND due to an over-quota condition even though the subsequent STORE/EXPUNGE would free up enough space for the newly revised message. And finally, server efficiencies may be possible with a single logical message replacement operation as compared to the existing APPEND/STORE/EXPUNGE sequence. In its simplest form, the REPLACE command is an atomic encapsulation of STORE + UID EXPUNGE + APPEND. Servers that support the REPLACE command MUST guarantee atomicity; either the specified message is completely replaced by the supplied message, or the specified message is left unmodified and no part of the supplied message data is stored. Servers supporting REPLACE also MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced. 3. REPLACE and UID REPLACE 3.1. Advertising Support for REPLACE Servers that implement the REPLACE extension will return "REPLACE" as one of the supported capabilities in the CAPABILITY command response. 3.2. REPLACE Command Arguments: message sequence number mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal Responses: no specific responses for this command Result: OK - replace completed NO - replace error; can't remove specified message or can't add new message content BAD - command unknown or arguments invalid Brandt Expires October 31, 2015 [Page 3] Internet-Draft IMAP REPLACE Extension April 2015 Example: C: A003 REPLACE 4 Drafts (\Seen \Draft) {312} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) C: From: Fritz Schmidt C: Subject: happy new year !! C: To: miss.mitzy@example.org C: Message-Id: C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Just saw the best fireworks show. Wish you were here. C: S: * 4 EXPUNGE S: A003 OK [APPENDUID 1 2000] Replace completed 3.3. UID REPLACE Command This extends the first form of the UID command (see [RFC3501] Section 6.4.8) to add the REPLACE command defined above as a valid argument. This form of REPLACE uses a UID rather than sequence number as its first parameter. Example: C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST) C: From: Fritz Schmidt C: Subject: happy new year !! C: To: miss.mitzy@example.org C: Message-Id: C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Just saw the best fireworks show. Wish you were here. C: Hopefully next year you can join us. C: S: * 4 EXPUNGE S: A004 OK [APPENDUID 1 2001] Replace completed 3.4. Semantics of REPLACE and UID REPLACE The REPLACE and UID REPLACE commands take five arguments: a message identifier, a named mailbox, an optional parenthesized flag list, an optional message date/time string, and a message literal. The message literal will be appended to the named mailbox, and the message specified by the message identifier will be removed from the Brandt Expires October 31, 2015 [Page 4] Internet-Draft IMAP REPLACE Extension April 2015 selected mailbox. These operations will appear to the client as a single action. This has the same effect as the following sequence: 1. [UID] STORE +FLAGS.SILENT \DELETED 2. UID EXPUNGE 3. APPEND In the cited sequence, the original message is removed first to avoid possible quota implications of APPENDing new data first. Additionally, the EXPUNGE portion of the sequence only applies to the specified message, not all messages flagged as \Deleted. Although the effect of REPLACE is identical to the steps above, the semantics are not identical; similar to MOVE [RFC6851], the intermediate states produced do not occur, and the response codes are different. In particular, the response codes for EXPUNGE and APPEND will be returned while those for the STORE operation MUST NOT be generated. When an error occurs while processing REPLACE or UID REPLACE, the server MUST NOT leave the selected mailbox in an inconsistent or modified state; any untagged EXPUNGE response MUST NOT be sent until all actions are successfully completed. Additionally, the target mailbox MUST NOT be modified until all actions are successfully completed. Because of the similarity of REPLACE to APPEND, extensions that affect APPEND affect REPLACE in the same way. Response codes such TRYCREATE (see [RFC3501] Section 6.3.11), as well as those defined by extensions, are sent as appropriate. See Section 4 for more information about how REPLACE interacts with other IMAP extensions. 3.5. IMAP State Diagram Impacts Unlike the APPEND command which is valid in the authenticated state, the REPLACE command MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. 4. Interaction with other extensions This section describes how REPLACE interacts with some other IMAP extensions. Brandt Expires October 31, 2015 [Page 5] Internet-Draft IMAP REPLACE Extension April 2015 4.1. RFC 4314, ACL The ACL rights [RFC4314] required for UID REPLACE are the union of the ACL rights required for UID STORE, UID EXPUNGE, and APPEND. 4.2. RFC 4469, CATENATE Servers supporting both REPLACE and CATENATE [RFC4469] MUST support the addtional append-data and resp-text-code elements defined the Formal Syntax section of RFC4469 in conjunction with the REPLACE command. 4.3. RFC 4315, UIDPLUS Servers supporting both REPLACE and UIDPLUS [RFC4315] MUST send APPENDUID in response to a UID REPLACE command. The only exceptions to this are the ones outlined for APPEND in RFC4315 section 3. 4.4. RFC 6785, IMAP Events in Sieve REPLACE applies to IMAP events in Sieve [RFC6785] in the same way that APPEND does. Therefore, REPLACE can cause a Sieve script to be invoked with the imap.cause set to "APPEND". Because the intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by REPLACE, no action will be taken that results in a imap.cause of FLAG. 4.5. RFC 7162, CONDSTORE/QRESYNC Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] MUST treat the message being replaced as if it were being removed with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of RFC 7162 are particularly relevant for this condition. 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-select", "mailbox", and "seq- number". [RFC4466] defines the non-terminal "append-message". 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. Brandt Expires October 31, 2015 [Page 6] Internet-Draft IMAP REPLACE Extension April 2015 capability =/ "REPLACE" command-select =/ replace replace = "REPLACE" SP seq-number SP mailbox append-message uid = "UID" SP (copy / fetch/ search / store / move / replace) 6. Security Considerations This document is believed to add no security problems beyond those that may already exist with the base IMAP specificaiton. 7. IANA Considerations The IANA is requested to add REPLACE to the "IMAP 4 Capabilities" registry, http://www.iana.org/assignments/imap4-capabilities. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005. [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005. [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006. [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC6785] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, November 2012. Brandt Expires October 31, 2015 [Page 7] Internet-Draft IMAP REPLACE Extension April 2015 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", RFC 7162, May 2014. 9.2. Informative References [RFC6851] Gulbrandsen, A. and N. Freed, "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, January 2013. Author's Address Stuart Brandt AOL 43623 Preddy Ct Ashburn, VA 20147 USA Email: stujenerin@aol.com Brandt Expires October 31, 2015 [Page 8] From nobody Wed Apr 29 09:09:31 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC891A6FCB for ; Wed, 29 Apr 2015 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHUWo4qweJwl for ; Wed, 29 Apr 2015 09:09:29 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id AFB4F1A1B0E for ; Wed, 29 Apr 2015 09:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1430323767; d=isode.com; s=selector; i=@isode.com; bh=E+L4BKaxDtIb+feC2G6BvfTKMu5aO5dZhfYC14UJpdo=; 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=aWJvWzqXNPKLbriCd+WOtwAvPTtGawk1vd36y8xcSTfvguMZ9nBAz8q+6ELp+Wmo9Be1OI mewuQ82Th12OeX2iaYe4eAbCcUKpfR1MexL5pjoc2F/esOWxNySAkHrW8iooxbhEcfNlGS bPe2jmg7aSCj4Mkos/eMdWcV7Kfcd7Q=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 29 Apr 2015 17:09:27 +0100 Message-ID: <55410226.4090709@isode.com> Date: Wed, 29 Apr 2015 17:09:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Stu Brandt , "'imapext@ietf.org'" References: <5540E067.1050609@teamaol.com> In-Reply-To: <5540E067.1050609@teamaol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [imapext] IMAP REPLACE extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 16:09:30 -0000 Hi Stu, This is a very good start, thank you for doing this! On 29/04/2015 14:45, Stu Brandt wrote: > As promised, here's a draft of a REPLACE extension. > > Since the most obvious question is going to be "Why REPLACE and not an > option on APPEND?", I'll answer it straight away... > > First, APPEND is valid in the authenticated state. REPLACE requires > the selected state. I chose not to generate a mixed state scenario for > APPEND. Secondly, REPLACE is similar to MOVE in that it avoids a > number of issues that come with a serialized non-atomic sequence > attempting to perform a single operation. MOVE is not an option on > COPY, so I chose to follow the same precedent. > > Here's the writeup. [snip] > 3.2. REPLACE Command [snip] > Example: > C: A003 REPLACE 4 Drafts (\Seen \Draft) {312} > S: + Ready for literal data > C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) > C: From: Fritz Schmidt > C: Subject: happy new year !! > C: To: miss.mitzy@example.org > C: Message-Id: > C: MIME-Version: 1.0 > C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > C: > C: Just saw the best fireworks show. Wish you were here. > C: > S: * 4 EXPUNGE > S: A003 OK [APPENDUID 1 2000] Replace completed I think an untagged APPENDUID should be issued before expunge, so that the client can safely correlate the old and the new message, without > > 3.3. UID REPLACE Command > > This extends the first form of the UID command (see [RFC3501] > Section 6.4.8) to add the REPLACE command defined above as a valid > argument. This form of REPLACE uses a UID rather than sequence > number as its first parameter. > > Example: > C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350} > S: + Ready for literal data > C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST) > C: From: Fritz Schmidt > C: Subject: happy new year !! > C: To: miss.mitzy@example.org > C: Message-Id: > C: MIME-Version: 1.0 > C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > C: > C: Just saw the best fireworks show. Wish you were here. > C: Hopefully next year you can join us. > C: > S: * 4 EXPUNGE > S: A004 OK [APPENDUID 1 2001] Replace completed As above. > 4. Interaction with other extensions > > This section describes how REPLACE interacts with some other IMAP > extensions. > > Brandt Expires October 31, 2015 [Page 5] > Internet-Draft IMAP REPLACE Extension April 2015 > > 4.1. RFC 4314, ACL > > The ACL rights [RFC4314] required for UID REPLACE are the union of > the ACL rights required for UID STORE, UID EXPUNGE, Just to make this clearer, I would add "in the current mailbox" > and APPEND. "In the target mailbox". Best Regards, Alexey