From nobody Tue Jan 5 12:05:15 2016 Return-Path: X-Original-To: imapext@ietf.org Delivered-To: imapext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C87F1A026F; Tue, 5 Jan 2016 11:10:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105191025.31613.33420.idtracker@ietfa.amsl.com> Date: Tue, 05 Jan 2016 11:10:25 -0800 Archived-At: X-Mailman-Approved-At: Tue, 05 Jan 2016 12:05:12 -0800 Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, sm+ietf@elandsys.com, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: [imapext] Alissa Cooper's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 19:10:25 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-imapapnd-appendlimit-extension-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It's unusual to see author names without first initials in the document header. Not sure if that was intentional but seems like it should be fixed (assuming the authors have both first names and surnames). = Section 2 = "In this case the client SHOULD get an APPENDLIMIT value by issuing a STATUS or LIST command. An IMAP client SHOULD be able to parse both formats. By looking at the upload size advertised by the IMAP server, a client MUST NOT try to APPEND mail more than the advertised limit." The first and last normative requirements here seem too strict considering that this extension basically allows an optimization. That is, if a client decides not to find out the append limit for a particular mailbox using STATUS or LIST, that doesn't seem to create any particular problem. Likewise, it seems better for a client to avoid sending an attachment larger than a known limit, but doing so doesn't seem so problematic as to warrant a MUST NOT. From nobody Tue Jan 5 14:35:24 2016 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 20AA01B2D96; Tue, 5 Jan 2016 14:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 9dyFE2wE8Lm5; Tue, 5 Jan 2016 14:35:18 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4BE1AC3E9; Tue, 5 Jan 2016 14:35:17 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.227.85.115]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u05MYiC8024551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2016 14:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452033297; x=1452119697; bh=wxbYVeEHnx17y/6mqZMaJVn6/VLcG437/a4jW1jWF/w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QzDlnEfnyZitZ00mI+DMBIpijpPLKt5C5ivSi5OYWMAd5myTJskLM/HxAJ0tDz/Zd mcMeOKUJTSsLTP0f317429u5CJnorln1L3go6IfrOwiTsXWcb78C1XhD050Gpdmg7Z F/2jzATuUWrUSB/v5s0+knTgZrje+SycwYVNVWlE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452033297; x=1452119697; i=@elandsys.com; bh=wxbYVeEHnx17y/6mqZMaJVn6/VLcG437/a4jW1jWF/w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vFWxpBj1kUWmjS1AGTMX+brej3UTtS39/TueqwOZ2Qx7D9crkPiKWV5pIf3IYfjas pjHiyrKkjL0MQeSQuWb6/tpfpXftStwvzdebr3Z2SlBqFNg8VHhSZX/9tFPYY2LvLm o9IgOZ778vUNQj1axNrOHk0nfImrKZ5QFs3KNeHA= Message-Id: <6.2.5.6.2.20160105142257.0d8dfce0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Jan 2016 14:33:16 -0800 To: Sarah Banks , ops-dir@ietf.org, draft-ietf-imapapnd-appendlimit-extension.all@ietf.org From: S Moonesamy In-Reply-To: <437CE97B-E4A2-4AB6-A340-2DD21733809D@encrypted.net> References: <437CE97B-E4A2-4AB6-A340-2DD21733809D@encrypted.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: imapext@ietf.org Subject: Re: [imapext] OPS-DIR review of draft-ietf-imapapnd-appendlimit-extension-08 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, 05 Jan 2016 22:35:20 -0000 Hi Sarah, At 10:58 04-01-2016, Sarah Banks wrote: >The document is ready with a minor nit/comment. Thanks for the review. >This draft discusses an extension to IMAP, where a server can use >APPENDLIMIT to communicate to the client the maximum mail upload >size, via several commands (status, list, capability). The document >cites a particularly useful use case, of mobile devices and resource >contention. I found the document fairly well written, and I have a >single comment: > >Section 3.1 - is the should in "should issue a STATUS >command" normative? It reads as if it could be... The "should" in the above is not normative. The usage of a RFC 2119 "SHOULD" in the sentence would be incorrect as there isn't any other way to get the desired Section 3.1 "STATUS response". >Authors, thanks for making me research "hone in" versus "home in" >(ala section 6). :) I'll credit Barry for that. :-) Regards, S. Moonesamy (as document shepherd) From nobody Tue Jan 5 15:51:16 2016 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 11A281ACE23; Tue, 5 Jan 2016 15:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 erJwboIjBmWz; Tue, 5 Jan 2016 15:51:15 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD81ACD3F; Tue, 5 Jan 2016 15:51:15 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.227.85.115]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u05Notq5011223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2016 15:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452037870; x=1452124270; bh=0Adoozebtqnf7YwX5SEaeP5qVhyutDfPbz2/Q3LKdNo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4HLnwNWCt92riEw4lD/yTrteTHznPXflJxiXzOuPCQBs421fSGxwoBTWVhCzNhoju FDcZ7JHnR3V2/K0K4egk/WPeiqjjIphMjQB0n9Lxngl4dWQE8RN9JZFpIWK2ojR33H RdcBCTXoCHdRQAOmTEEwcAYjnuRIJG4XQER74atI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452037870; x=1452124270; i=@elandsys.com; bh=0Adoozebtqnf7YwX5SEaeP5qVhyutDfPbz2/Q3LKdNo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bVcPlymEDTflKOdQ8nq/30+9XNGu5Abm/Y7JdFU5kRgRLPxc4xZ6k2t+6J+Mie95M O0UNKNKbwUgdwECX8o65fTiJx+8kcWirElCW7MlAO/P9mFUOo6FLHadCQ89HI5y+/9 d9IS4LPz5NjzmCWwnA4+6iYPe4V/8VC+Pq1v4v/I= Message-Id: <6.2.5.6.2.20160105153055.0f34f228@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Jan 2016 15:50:46 -0800 To: imapext@ietf.org From: S Moonesamy In-Reply-To: <20160105191025.31613.33420.idtracker@ietfa.amsl.com> References: <20160105191025.31613.33420.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, Alissa Cooper , mapapnd-chairs@ietf.org, iesg@ietf.org Subject: Re: [imapext] Alissa Cooper's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 05 Jan 2016 23:51:16 -0000 Hello, At 11:10 05-01-2016, Alissa Cooper wrote: >= Section 2 = > >"In this case the client SHOULD get an APPENDLIMIT value by issuing a > STATUS or LIST command. > > An IMAP client SHOULD be able to parse both formats. By looking at > the upload size advertised by the IMAP server, a client MUST NOT try > to APPEND mail more than the advertised limit." > >The first and last normative requirements here seem too strict >considering that this extension basically allows an optimization. That >is, if a client decides not to find out the append limit for a particular >mailbox using STATUS or LIST, that doesn't seem to create any particular >problem. Likewise, it seems better for a client to avoid sending an >attachment larger than a known limit, but doing so doesn't seem so >problematic as to warrant a MUST NOT. I'll suggest writing the first sentence as follows: In this case the client can get an APPENDLIMIT value by either issuing a STATUS or a LIST command. I avoided including a normative recommendation to keep it simple. There is the following in Section 6: "because the client knows the limit and should not even be trying to send such commands, a server might consider even a single attempt to be abusive, and terminate the IMAP connection straight away." I'll suggest some text: By looking at the upload size advertised by the IMAP server a client can avoid trying to APPEND mail more than the advertised limit." Regards, S. Moonesamy (as document shepherd) From nobody Tue Jan 5 18:37:29 2016 Return-Path: X-Original-To: imapext@ietf.org Delivered-To: imapext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 462051A036B; Tue, 5 Jan 2016 17:28:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Tue, 05 Jan 2016 17:28:03 -0800 Archived-At: X-Mailman-Approved-At: Tue, 05 Jan 2016 18:37:28 -0800 Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, sm+ietf@elandsys.com, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 01:28:03 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-imapapnd-appendlimit-extension-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this extension, it seems useful, I just have a few comments that can be left to the editors and AD to handle if I disappear for maternity leave. I think the security considerations section could be a bit more clear on the actual risks with this extension. I think the flow of the section can be improved to make these risks a bit more clear. First, this extension lets you find out the limit for either the server or individual mailboxes, so shouldn't the first part of the description focus on a possible DoS filling up those resources? I'm not sure why there is a focus on "without this extension". Then, it's a common security programming practice to enforce size limitations in code. Why is there a focus on an attacker sending append content that exceeds the allowable size rather than just saying that such append content should be rejected? From nobody Tue Jan 5 19:55:06 2016 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 056031A9009; Tue, 5 Jan 2016 19:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 j5Y0gin8HZqZ; Tue, 5 Jan 2016 19:55:01 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 E80431A900A; Tue, 5 Jan 2016 19:55:00 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id z14so3388309igp.1; Tue, 05 Jan 2016 19:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=L7ylqDdYtYkK3tTI8eZZ9ySvHTVrcIErbaIQmjZq1t0=; b=H9mwV4OxR3M4viYc52Y0ZzPO/Da20XW+PpXo6oG3uucZo5vlHXYaXsCpnx7JHz8EBB nFzk/kL4X8QGWqW0tNMk7f3iS+PX2L8GlnoK7DEhthFzt+ib0BBGx8gbf+/gw8Cg4rlp fnufqr6cgixKDU/uAYYNnQ26kBVGoQXkI8mSPIHQhWQ5xq/v0FFF+t5RDIb+ThcBYyov 2A41xGLv3PSdmHmt2tViAQeWAMmOr5yLJpZiIXhIA4V3OuDdCGWCzOvi9mcLFYbNkHiZ MCB5ZQS4oBqBiz6x6WWU2eYM7Ces8zX+Z2ys7AlvfKASfXk9WvFKuV+rsTXRacVrezg6 WBgA== MIME-Version: 1.0 X-Received: by 10.50.183.11 with SMTP id ei11mr7032845igc.81.1452052500249; Tue, 05 Jan 2016 19:55:00 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.83 with HTTP; Tue, 5 Jan 2016 19:55:00 -0800 (PST) In-Reply-To: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Wed, 6 Jan 2016 11:55:00 +0800 X-Google-Sender-Auth: iBk-DgcWi-gxHm_tHa9rQY3OLmA Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapapnd-chairs@ietf.org, The IESG , "imapext@ietf.org" , SM Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 03:55:02 -0000 > First, this extension lets you find out the limit for either the server > or individual mailboxes, so shouldn't the first part of the description > focus on a possible DoS filling up those resources? I don't understand where you're going with this. This has nothing to do with a storage limit -- that's handled by the QUOTA extension that's a separate thing, and any client can already fill up the quota of the user it's logged in as. This extension is about limiting the size of a single message, because servers have such limitations and currently have no way to tell the client about them. The only purpose of this extension is to let a client discover a server's size limit for a single message. The security considerations need to be about how that knowledge can be used to breach security. The answer to that is "it can't, really", but the one issue we came up with is documented there. Do you have any specific security considerations to suggest that are specific to this extension: the ability for a client to discover what a server's policy limit is on the size of a single message? > Then, it's a common security programming practice to enforce size > limitations in code. Why is there a focus on an attacker sending append > content that exceeds the allowable size rather than just saying that such > append content should be rejected? A server will always have to be able to deal (in code) with messages greater than the maximum size they allow, because IMAP syntactically allows them to be transmitted. The server can only say "NO" to appending the message after it receives it. The security considerations are talking about whether the server might do something harsher to a client that appears to be abusive -- kicking it off and disabling the account, for example. Barry From nobody Tue Jan 5 20:06:24 2016 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 D77581A9036; Tue, 5 Jan 2016 20:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 7SMHDNgU4O-k; Tue, 5 Jan 2016 20:06:19 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 1EF0F1A9030; Tue, 5 Jan 2016 20:06:19 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id b14so58085257wmb.1; Tue, 05 Jan 2016 20:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/fI5+Pi6ouxpihWwS8ktjhIZmKZz2oWFtYSq5H5dI2I=; b=TrDJNQMf/PY+HN4Qm/xD5RZuBxtPAxfSPVhFjLvV95/eqoHunrT9ZVLDYmopVBThef wkRqtg7VroUwiktfQRi2d/kFZtHjmiXb87TXuP44/IyoDMtWqo2R4ZAbVfbaUh46Umww jJodhP0lMms/GoQu5OiSYl16b4hYfXA0QoeIoNHGYulrahl/yVcdLu8HCtt650zbL0yG 8MpV3AWFrc/KFfquyAcfWaRyZIVEmm3ZOQ/piU6G2J8fkQBp+bq2sQumvvEMwAxD5bzC p3Y8GT5ARICont2VBXw8aMU8UUUe5Fn4h9vamR0eY5HK630e3BwMjmBx5kGDEqgMrCd6 INGA== MIME-Version: 1.0 X-Received: by 10.28.111.194 with SMTP id c63mr7764228wmi.90.1452053177732; Tue, 05 Jan 2016 20:06:17 -0800 (PST) Received: by 10.28.52.65 with HTTP; Tue, 5 Jan 2016 20:06:17 -0800 (PST) In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Tue, 5 Jan 2016 23:06:17 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapapnd-chairs@ietf.org, The IESG , "imapext@ietf.org" , SM Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 04:06:21 -0000 Hi Barry, On Tue, Jan 5, 2016 at 10:55 PM, Barry Leiba wrote: >> First, this extension lets you find out the limit for either the server >> or individual mailboxes, so shouldn't the first part of the description >> focus on a possible DoS filling up those resources? > > I don't understand where you're going with this. This has nothing to > do with a storage limit -- that's handled by the QUOTA extension > that's a separate thing, and any client can already fill up the quota > of the user it's logged in as. Yes, I understand that. > > This extension is about limiting the size of a single message, because > servers have such limitations and currently have no way to tell the > client about them. The only purpose of this extension is to let a > client discover a server's size limit for a single message. In section 3, it also discusses per mailbox limitations. The draft covers both the option for this extension being used for the server and on a per mailbox basis. This also comes up in the security considerations section. > > The security considerations need to be about how that knowledge can be > used to breach security. The answer to that is "it can't, really", > but the one issue we came up with is documented there. > > Do you have any specific security considerations to suggest that are > specific to this extension: the ability for a client to discover what > a server's policy limit is on the size of a single message? The security considerations section doesn't read well IMO. When it gets to the following sentence: "But with this extension, the attacker can immediately choose a value that's a little too large," It doesn't read well to me. Why would they chose a value that's a little too large? Too large for what? They already have the size limit per server or per mailbox. Does this mean they will send a bunch of messages with the append size maxed out for the mailbox or the server to fill the quota? Then with the sentence: "To mitigate this extension's input to such an attack, a server might take a harder line on message sizes that are above the APPENDLIMIT value " Why isn't it explicit in that such messages should/MUST be rejected? For the security consideration, this seems like an expected response to prevent additional problems (checking that size limitations are met to avoid buffer overrun scenarios in code). Thanks, Kathleen > >> Then, it's a common security programming practice to enforce size >> limitations in code. Why is there a focus on an attacker sending append >> content that exceeds the allowable size rather than just saying that such >> append content should be rejected? > > A server will always have to be able to deal (in code) with messages > greater than the maximum size they allow, because IMAP syntactically > allows them to be transmitted. The server can only say "NO" to > appending the message after it receives it. The security > considerations are talking about whether the server might do something > harsher to a client that appears to be abusive -- kicking it off and > disabling the account, for example. > > Barry -- Best regards, Kathleen From nobody Tue Jan 5 21:08:37 2016 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 B9A721A9130; Tue, 5 Jan 2016 21:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 5sLJ5qiXGuQp; Tue, 5 Jan 2016 21:08:31 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 72B5B1A9129; Tue, 5 Jan 2016 21:08:31 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id ik10so25575467igb.1; Tue, 05 Jan 2016 21:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hbLaF9xgtepjMdu0qM9TQmAPXs4mjOQ9IC0EGKgzFVs=; b=QP+6wuSjQElapLPy/Upm2qCA1H2kzomVOcGMxYl63H33NGAPf2i9qwT8ZEGV8ubTNu V+q0gz7GRag56DZZOCtxEAQ1fnGe6Mt3n5WIkhejP0IZE6VJEfjruNDokidABxdfEcQC 6k104MZ2mLzc6KmciuKBkrOmTuWabVm32LKcq2k09sRvhz1oM+rHSjfnxBoCpuX5209L UewO8qAD76mKCREnF3n3TIJeF8nev35SUPHZZANj+6+pbsukz0SJCKS3/rS45bRErL/K eHNebtVwv1zfffWot3EaCafAF3Lb31ne5mP4K5SKJXWV8rH7yBXCsS5USOfZ9vFU/wvQ Yzgg== MIME-Version: 1.0 X-Received: by 10.51.17.39 with SMTP id gb7mr7954595igd.54.1452056910741; Tue, 05 Jan 2016 21:08:30 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.83 with HTTP; Tue, 5 Jan 2016 21:08:30 -0800 (PST) In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Wed, 6 Jan 2016 13:08:30 +0800 X-Google-Sender-Auth: sP0prs2qD0kt03TqMzxjs08V8Vk Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, SM , The IESG , "imapext@ietf.org" , imapapnd-chairs@ietf.org Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 05:08:32 -0000 >> This extension is about limiting the size of a single message, because >> servers have such limitations and currently have no way to tell the >> client about them. The only purpose of this extension is to let a >> client discover a server's size limit for a single message. > > In section 3, it also discusses per mailbox limitations. The draft > covers both the option for this extension being used for the server > and on a per mailbox basis. This also comes up in the security > considerations section. Server-wide limits and per-mailbox limits are no different with regard to any security considerations. I don't see where the Security Considerations section says that they are. Can you point to specific text? >> The security considerations need to be about how that knowledge can be >> used to breach security. The answer to that is "it can't, really", >> but the one issue we came up with is documented there. >> >> Do you have any specific security considerations to suggest that are >> specific to this extension: the ability for a client to discover what >> a server's policy limit is on the size of a single message? > > The security considerations section doesn't read well IMO. That's entirely possible. > When it gets to the following sentence: > > "But with this extension, the attacker can immediately choose a value > that's a little too large," > > It doesn't read well to me. Why would they chose a value that's a > little too large? Too large for what? They already have the size > limit per server or per mailbox. Does this mean they will send a > bunch of messages with the append size maxed out for the mailbox or > the server to fill the quota? The point of the attack isn't filling a mailbox; it's sending boatloads of data to the server. Suppose there's a limit of 2 MB. If the client sends 2 MB messages repeatedly, those messages will eventually cause the mailbox to hit the quota, and further attempts to bombard the server will be rejected. But messages that are, say, 2.1MB will fail to append (the server will respond "NO" to them), and the client can keep bombarding the server with such messages. The text is trying to warn about that, suggesting that the server might "take a hard line" -- that is, take more serious action than just saying "NO" to the append attempts, but perhaps actually lock out the account until someone checks out the situation. > Why isn't it explicit in that such messages should/MUST be rejected? The messages themselves will be rejected (they APPEND command will get "NO" for a response), but the damage -- the sending of a lot of data unnecessarily -- will have already been done. > For the security consideration, this seems like an expected response > to prevent additional problems (checking that size limitations are met > to avoid buffer overrun scenarios in code). This has nothing to do with buffer overruns. Servers already have to deal with arbitrary sizes for literals, and they will already allocate buffers based on the literal size that the client sends. Buffer overruns are not an issue here, and this extension does nothing that changes that. Barry From nobody Wed Jan 6 04:57:54 2016 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 CC4D21B2B46; Wed, 6 Jan 2016 04:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 psn1Q1yDPOWT; Wed, 6 Jan 2016 04:57:49 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 F2C521B2B47; Wed, 6 Jan 2016 04:57:48 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id p186so71560741qke.0; Wed, 06 Jan 2016 04:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H8nxsWN87QrrvyE8598OitxXJlrWK+1zHpN7+bIkkCw=; b=KoY5QGTYxsL8uYMShTzL9aCdBkkMIY9Vc5OOqH7dz2hvN3b58CWFdWOQwNe0n7vO7m mHsE6MVG/5m2erjGGtnxwNjoLaC5SEeifLZE2rXuHPwszoArkLMsgO8nubSBa65JX1PW hlzRoZnKNFiYto+bWND1OjJ6ZKbBoQjGvbSFXjlwDyE2CgXjFcmSsy8GDEOI/B4cWbnm FpJeY2DIbM8xj3fNie3TZGdY9hBk+eNXhizaJqvAuF7RThYkqrk6zqzZv8x2V8JEasru 0OR4hYxMhmxShy4UifdrJzW5Lqc3gUuKof4TvIqEmgZdVS6uv3A37PHQDFZaJPuiRpS+ LqqA== X-Received: by 10.55.75.203 with SMTP id y194mr107252927qka.2.1452085068153; Wed, 06 Jan 2016 04:57:48 -0800 (PST) Received: from [10.0.0.215] ([76.19.40.209]) by smtp.gmail.com with ESMTPSA id t47sm44121376qgt.28.2016.01.06.04.57.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jan 2016 04:57:46 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Wed, 6 Jan 2016 07:57:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> To: Barry Leiba Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , SM , The IESG , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 12:57:51 -0000 Sent from my iPhone On Jan 6, 2016, at 12:08 AM, Barry Leiba wrote: >>> This extension is about limiting the size of a single message, because >>> servers have such limitations and currently have no way to tell the >>> client about them. The only purpose of this extension is to let a >>> client discover a server's size limit for a single message. >>=20 >> In section 3, it also discusses per mailbox limitations. The draft >> covers both the option for this extension being used for the server >> and on a per mailbox basis. This also comes up in the security >> considerations section. >=20 > Server-wide limits and per-mailbox limits are no different with regard > to any security considerations. I don't see where the Security > Considerations section says that they are. Can you point to specific > text? >=20 >>> The security considerations need to be about how that knowledge can be >>> used to breach security. The answer to that is "it can't, really", >>> but the one issue we came up with is documented there. >>>=20 >>> Do you have any specific security considerations to suggest that are >>> specific to this extension: the ability for a client to discover what >>> a server's policy limit is on the size of a single message? >>=20 >> The security considerations section doesn't read well IMO. >=20 > That's entirely possible. >=20 >> When it gets to the following sentence: >>=20 >> "But with this extension, the attacker can immediately choose a value >> that's a little too large," >>=20 >> It doesn't read well to me. Why would they chose a value that's a >> little too large? Too large for what? They already have the size >> limit per server or per mailbox. Does this mean they will send a >> bunch of messages with the append size maxed out for the mailbox or >> the server to fill the quota? >=20 > The point of the attack isn't filling a mailbox; it's sending > boatloads of data to the server. Suppose there's a limit of 2 MB. If > the client sends 2 MB messages repeatedly, those messages will > eventually cause the mailbox to hit the quota, and further attempts to > bombard the server will be rejected. But messages that are, say, > 2.1MB will fail to append (the server will respond "NO" to them), and > the client can keep bombarding the server with such messages. The > text is trying to warn about that, suggesting that the server might > "take a hard line" -- that is, take more serious action than just > saying "NO" to the append attempts, but perhaps actually lock out the > account until someone checks out the situation. This point wasn't clear to me from the current text. I'd suggest updating i= t to make it more clear. >=20 >> Why isn't it explicit in that such messages should/MUST be rejected? >=20 > The messages themselves will be rejected (they APPEND command will get > "NO" for a response), but the damage -- the sending of a lot of data > unnecessarily -- will have already been done. Can this be made more clear as well? It's not in the current text. >=20 >> For the security consideration, this seems like an expected response >> to prevent additional problems (checking that size limitations are met >> to avoid buffer overrun scenarios in code). >=20 > This has nothing to do with buffer overruns. Servers already have to > deal with arbitrary sizes for literals, and they will already allocate > buffers based on the literal size that the client sends. Buffer > overruns are not an issue here, and this extension does nothing that > changes that. Ok, thanks. I think of the other text is clear, then this concern won't com= e up as it would be understood as not being an issue. Thanks, Kathleen=20 >=20 > Barry From nobody Wed Jan 6 12:22:08 2016 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 830FC1A0252; Wed, 6 Jan 2016 12:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 gmcykGuiKqyF; Wed, 6 Jan 2016 12:22:01 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA5A1A00FA; Wed, 6 Jan 2016 12:22:01 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.208.165]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u06KLhnJ000353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2016 12:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452111717; x=1452198117; bh=IrJjyK/ys6XhymXQumPPll0IW3e7q1T6y3ohqKsrrSs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kmimVrTShoRcMwW/I/+9xsoVCO99rutY3svAr6DWk58G9pRdW7isa1Du8MCc4RjD2 GHv5CPGXLJTEaR+V+ow/SXt0QST45zWdjBYlrSOO6ncPMtRV7ptfCCTT0Tr4KzbTWj g7i2F28VNhJ9WCYQGebiGqBV+0MWP9A3XLA1QDjY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452111717; x=1452198117; i=@elandsys.com; bh=IrJjyK/ys6XhymXQumPPll0IW3e7q1T6y3ohqKsrrSs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GZ9T/a1m5XHTG0R+78llDCqthNvovL7tl1HGhLNTnuPUC/6PkTyHVcHyEOOwDvMH5 //LfkD5ljV/x69ltqvkUYMqGmdCsCX6fjI1Uh9XS5bloMf1qq57Uv2OH0LaHl34c1/ LDMk0/6v9E/WINPFtuOCXUGG16oa/7zLG1+XWntk= Message-Id: <6.2.5.6.2.20160106121402.0d584cd0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Jan 2016 12:21:27 -0800 To: Alissa Cooper , The IESG From: S Moonesamy In-Reply-To: <20160105191025.31613.33420.idtracker@ietfa.amsl.com> References: <20160105191025.31613.33420.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Alissa Cooper's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 20:22:07 -0000 Hi Alissa, At 11:10 05-01-2016, Alissa Cooper wrote: >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >It's unusual to see author names without first initials in the document >header. Not sure if that was intentional but seems like it should be >fixed (assuming the authors have both first names and surnames). It is a mistake. It will be fixed in the next revision of the draft. >= Section 2 = > >"In this case the client SHOULD get an APPENDLIMIT value by issuing a > STATUS or LIST command. > > An IMAP client SHOULD be able to parse both formats. By looking at > the upload size advertised by the IMAP server, a client MUST NOT try > to APPEND mail more than the advertised limit." > >The first and last normative requirements here seem too strict >considering that this extension basically allows an optimization. That >is, if a client decides not to find out the append limit for a particular >mailbox using STATUS or LIST, that doesn't seem to create any particular >problem. Likewise, it seems better for a client to avoid sending an >attachment larger than a known limit, but doing so doesn't seem so >problematic as to warrant a MUST NOT. NEW In this case the client can get an APPENDLIMIT value by either issuing a STATUS or a LIST command. By looking at the upload size advertised by the IMAP server a client can avoid trying to APPEND mail more than the advertised limit. END Regards, S. Moonesamy (as document shepherd) From nobody Wed Jan 6 12:31:27 2016 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 B234A1A0379; Wed, 6 Jan 2016 12:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 2IVCfNHimzKT; Wed, 6 Jan 2016 12:31:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E681A0377; Wed, 6 Jan 2016 12:31:22 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.208.165]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u06KUs8F018964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2016 12:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452112270; x=1452198670; bh=anGxHC5I2C2Z9lm2+y00M4I9FCw3BwzHjjK8z2lVIMI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zs5MZgm/IMAm4MYwF1DkIKgjR8CUF+5J8dSRO4M/nu/OOSWYx2u9QKbJsDuksj0XC cGWIjgEcN5se6U/Rb01Q3IUh3iQF1ltZ6cDYXoMx8YsSgEc/09rhvSVSetW40k/5NM 8Rith2xZyF9NHtl/VrD5GMTj/tXTnwNf7leDIQ0A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452112270; x=1452198670; i=@elandsys.com; bh=anGxHC5I2C2Z9lm2+y00M4I9FCw3BwzHjjK8z2lVIMI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HMgDoKAeMcj5nOaWE2n2tg4KO9+e7Pq+KKsQ4V9pavULfAK3vAl91P9e6mDbOyOLF Q/S+Up6f0h9cwazyIJpggkOfAjBKh5Wq/FawHsGAJSC0balmvaJYk69ItE+8buXl/p WvhjPgqXnjcsNa0IZKjaFqkP7+5NfwWaImq/WVTk= Message-Id: <6.2.5.6.2.20160106122818.0d566218@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Jan 2016 12:30:43 -0800 To: Jayantheesh S B , Narendra Singh Bisht From: S Moonesamy In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: imapapnd-chairs@ietf.org, draft-ietf-imapapnd-appendlimit-extension@ietf.org, Kathleen Moriarty , The IESG , imapext@ietf.org, Barry Leiba Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 20:31:23 -0000 Hi Jay, Naren, At 04:57 06-01-2016, Kathleen Moriarty wrote: > >> The security considerations section doesn't read well IMO. > > > > That's entirely possible. > > > >> When it gets to the following sentence: > >> > >> "But with this extension, the attacker can immediately choose a value > >> that's a little too large," > >> > >> It doesn't read well to me. Why would they chose a value that's a > >> little too large? Too large for what? They already have the size > >> limit per server or per mailbox. Does this mean they will send a > >> bunch of messages with the append size maxed out for the mailbox or > >> the server to fill the quota? > > > > The point of the attack isn't filling a mailbox; it's sending > > boatloads of data to the server. Suppose there's a limit of 2 MB. If > > the client sends 2 MB messages repeatedly, those messages will > > eventually cause the mailbox to hit the quota, and further attempts to > > bombard the server will be rejected. But messages that are, say, > > 2.1MB will fail to append (the server will respond "NO" to them), and > > the client can keep bombarding the server with such messages. The > > text is trying to warn about that, suggesting that the server might > > "take a hard line" -- that is, take more serious action than just > > saying "NO" to the append attempts, but perhaps actually lock out the > > account until someone checks out the situation. > >This point wasn't clear to me from the current text. I'd suggest >updating it to make it more clear. > > > > >> Why isn't it explicit in that such messages should/MUST be rejected? > > > > The messages themselves will be rejected (they APPEND command will get > > "NO" for a response), but the damage -- the sending of a lot of data > > unnecessarily -- will have already been done. > >Can this be made more clear as well? It's not in the current text. Could you please suggest some text to address the above? Regards, S. Moonesamy (as document shepherd) From nobody Wed Jan 6 14:39:22 2016 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 A8D5B1A1B2C; Wed, 6 Jan 2016 14:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 LhkuzJ4PQG_p; Wed, 6 Jan 2016 14:39:19 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 2A4B31A1B2B; Wed, 6 Jan 2016 14:39:19 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id mw1so42308906igb.1; Wed, 06 Jan 2016 14:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=caHIueDtcigkWDwUORcsMSjungipke3mr5U+qRLtwbc=; b=N1az4f6QA8Ip8lACwADR0XuH/mIkZIToWBr92ZOTkhzHqp9wAeg6tyW2BQqrFAm6tb rI4kME/iAmJUCGjTtug+VnGq5kJoww5w8GHDlgsJwmvBhocXlBebUvAWeIQU0jFQ7iYx U+VIBRS/GjUDx8g6GH0bnJtmXE9qPNt73QhmInFMKAeyZgLjdxPGGKRpzPDTsKJRxeFe wiOvdDMeBcqTXXtV3CEv3FykXR7FleM3FduHfXgcOnZKiyyba1vH7pSynxNrCXaS4NaO b9psscUWaM9fWNqOWC091/2Gwu0oZzR7loHOIjZ7SAT6BA4fj7DbCvi/aTdHcOBvjC14 Yuug== MIME-Version: 1.0 X-Received: by 10.50.32.9 with SMTP id e9mr12508653igi.53.1452119958491; Wed, 06 Jan 2016 14:39:18 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.83 with HTTP; Wed, 6 Jan 2016 14:39:18 -0800 (PST) In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Thu, 7 Jan 2016 06:39:18 +0800 X-Google-Sender-Auth: P3lW5DmUmzsWlfLyFSYUiT7h27w Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapapnd-chairs@ietf.org" , SM , "imapext@ietf.org" , The IESG Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 22:39:20 -0000 >>> "But with this extension, the attacker can immediately choose a value >>> that's a little too large," >>> >>> It doesn't read well to me. Why would they chose a value that's a >>> little too large? Too large for what? They already have the size >>> limit per server or per mailbox. Does this mean they will send a >>> bunch of messages with the append size maxed out for the mailbox or >>> the server to fill the quota? >> >> The point of the attack isn't filling a mailbox; it's sending >> boatloads of data to the server. Suppose there's a limit of 2 MB. If >> the client sends 2 MB messages repeatedly, those messages will >> eventually cause the mailbox to hit the quota, and further attempts to >> bombard the server will be rejected. But messages that are, say, >> 2.1MB will fail to append (the server will respond "NO" to them), and >> the client can keep bombarding the server with such messages. The >> text is trying to warn about that, suggesting that the server might >> "take a hard line" -- that is, take more serious action than just >> saying "NO" to the append attempts, but perhaps actually lock out the >> account until someone checks out the situation. > > This point wasn't clear to me from the current text. I'd suggest updating it to make it more clear. I think it is, so please suggest specific text that you think will help clarify it for you. >>> Why isn't it explicit in that such messages should/MUST be rejected? >> >> The messages themselves will be rejected (they APPEND command will get >> "NO" for a response), but the damage -- the sending of a lot of data >> unnecessarily -- will have already been done. > > Can this be made more clear as well? It's not in the current text. No, it's not, because it's how IMAP works. This really isn't something we need to make clear here: anyone implementing this already knows this and will already be doing it. This is only about advertising an APPEND limit, not about how APPEND works and how you say "NO" to an APPEND command. Barry From nobody Wed Jan 6 15:40:52 2016 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 6EFAF1A1BF5; Wed, 6 Jan 2016 15:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 QcUqXBd6RA2n; Wed, 6 Jan 2016 15:40:50 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F571A1BE6; Wed, 6 Jan 2016 15:40:50 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.208.165]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u06NeVee007423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2016 15:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452123645; x=1452210045; bh=p6O6CtyY74l6nCZ+e7GL+RicttMDF1Kiv6zXCwo2ceI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=H98oVZPrE7KiKKoN+Ghm0l/B9e90Y0Et7EsRMy99OpfmlG3F0HUjf0iNenSEEXxN8 pA614m89c4J93n8mGjE2wCEO7lcqPWT08ubmvbivlqHXDtl9QTHuy40XqNBz+sXHUs fOVvUokbmKtb1+Fe0aDyyI7GE52WdpKZMRK0/hJ4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452123645; x=1452210045; i=@elandsys.com; bh=p6O6CtyY74l6nCZ+e7GL+RicttMDF1Kiv6zXCwo2ceI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HWEIuiAWW3f8MJj3LW+FUn37FXAFNrx/0MLUkHB0pNjyF6Zx1sDbW2GtRQVxHqtiD TcLY6UEDH6COivoFYXkRqx/lDHOpQE+84ZYYRTqYYEl6HOXFD/o5CLbA48RWOGlDHc 12300Mxyol9aE42/35QL0gvioc5M5WeNVeLPy6EY= Message-Id: <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Jan 2016 15:40:19 -0800 To: Narendra Singh Bisht , Jayantheesh S B From: S Moonesamy In-Reply-To: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 23:40:51 -0000 Hi Naren, Jay, At 15:15 06-01-2016, Ben Campbell wrote: >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >- section 2, last paragraph: > >It was not obvious to me if "An IMAP client SHOULD be able to parse both >formats. " meant both STATUS and LIST, or both global and per-mailbox. I >assume the former. In the first paragraph of Section 2 there is the following: "An IMAP server can publish the APPENDLIMIT capability in two formats." There are then two examples of the formats. In the last paragraph of Section 2 there is: "An IMAP client SHOULD be able to parse both formats." Does that refer to the two examples in Section 2? Regards, S. Moonesamy (as document shepherd) From nobody Wed Jan 6 15:47:21 2016 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 DCB371A1BEE; Wed, 6 Jan 2016 15:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 VNRX3mHVEAVw; Wed, 6 Jan 2016 15:47:16 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 D0A6F1A1B61; Wed, 6 Jan 2016 15:47:15 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id u188so78627019wmu.1; Wed, 06 Jan 2016 15:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rb3oVHtFmNTAqfFtTKLl8gAnEmOrmpYeXa1d8Rn2XNU=; b=q4BjP7zfk5qKxyW8liBa9SPgfJholL4LHL1qx5SyjZaf+p6wGlnamCl6o99cgbgP44 INpbMeco6yVZwiEL7QRXfAxuUdroTz2gH+09Db2YB1RtvBknQb57lc4F6za2lvJ3aES3 0DYZMErrY3IxFih84VjMLDW2QzOQRNLr2mt5I24CUGznM2edZ48f8lD3QkACo5LSbh2f Oxkh2IWBspvCbMiBU1ScH4ir2A0F3fEHtZ4PRepe+7Bt9TYJdOPlXv31RXeWHOm9ElAk 369moRJI0nmZSOLHbBqt7r3BNySoEmiIzfu+UC3Q+Wb3z36IBVLyA662GaP+581rVhWM F5sQ== MIME-Version: 1.0 X-Received: by 10.194.222.195 with SMTP id qo3mr109307554wjc.51.1452124034457; Wed, 06 Jan 2016 15:47:14 -0800 (PST) Received: by 10.28.52.65 with HTTP; Wed, 6 Jan 2016 15:47:14 -0800 (PST) In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Wed, 6 Jan 2016 18:47:14 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapapnd-chairs@ietf.org" , SM , "imapext@ietf.org" , The IESG Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 06 Jan 2016 23:47:18 -0000 On Wed, Jan 6, 2016 at 5:39 PM, Barry Leiba wrote: >>>> "But with this extension, the attacker can immediately choose a value >>>> that's a little too large," >>>> >>>> It doesn't read well to me. Why would they chose a value that's a >>>> little too large? Too large for what? They already have the size >>>> limit per server or per mailbox. Does this mean they will send a >>>> bunch of messages with the append size maxed out for the mailbox or >>>> the server to fill the quota? >>> >>> The point of the attack isn't filling a mailbox; it's sending >>> boatloads of data to the server. Suppose there's a limit of 2 MB. If >>> the client sends 2 MB messages repeatedly, those messages will >>> eventually cause the mailbox to hit the quota, and further attempts to >>> bombard the server will be rejected. But messages that are, say, >>> 2.1MB will fail to append (the server will respond "NO" to them), and >>> the client can keep bombarding the server with such messages. The >>> text is trying to warn about that, suggesting that the server might >>> "take a hard line" -- that is, take more serious action than just >>> saying "NO" to the append attempts, but perhaps actually lock out the >>> account until someone checks out the situation. >> >> This point wasn't clear to me from the current text. I'd suggest updating it to make it more clear. > > I think it is, so please suggest specific text that you think will > help clarify it for you. If we go back to my original comment, the last one: "Then, it's a common security programming practice to enforce size limitations in code. Why is there a focus on an attacker sending append content that exceeds the allowable size rather than just saying that such append content should be rejected?" This gets at the crux of the text in the security considerations section. This is essentially what's recommended, but take a round about way to get to this recommendation. Exceeding the allowed sizes is not permitted to prevent this 'attack'. You can leave it as-is, but I think the text can be more clear by eliminating most of the introduction to the actual recommendation. > >>>> Why isn't it explicit in that such messages should/MUST be rejected? >>> >>> The messages themselves will be rejected (they APPEND command will get >>> "NO" for a response), but the damage -- the sending of a lot of data >>> unnecessarily -- will have already been done. >> >> Can this be made more clear as well? It's not in the current text. > > No, it's not, because it's how IMAP works. This really isn't > something we need to make clear here: anyone implementing this already > knows this and will already be doing it. This is only about > advertising an APPEND limit, not about how APPEND works and how you > say "NO" to an APPEND command. Barry, my comments are about that limit and I think drafts should be readable by more than just those who implement mail (in this case). The last sentences of the security considerations section contains the same point I am making, but it takes a while to get to that recommendation, so I'm not really sure why you are arguing this point and thinking I am talking about anything other than the APPEND limit. It says: " To mitigate this extension's input to such an attack, a server might take a harder line on message sizes that are above the APPENDLIMIT value -- because the client knows the limit and should not even be trying to send such commands, a server might consider even a single attempt to be abusive, and terminate the IMAP connection straight away." The whole section could be reduced by starting with this recommendation and just stating that it prevents attacks on resources by rejecting messages with sizes above the append limit. There may be other attacks that are guarded against with this recommendation as well, so why limit it to this specific example and why lead with the example. I think it's more straightforward to just have the recommendation and that it is to prevent attacks on resources. If you don't want to fix it, that's fine. It's just a comment. Kathleen > > Barry -- Best regards, Kathleen From nobody Wed Jan 6 16:49:08 2016 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 4D9B91A21AE; Wed, 6 Jan 2016 16:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 DbctVLUUE7aF; Wed, 6 Jan 2016 16:49:04 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::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 835271A21A6; Wed, 6 Jan 2016 16:49:04 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id ik10so44269184igb.1; Wed, 06 Jan 2016 16:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a+U/483GhZJNbBq6BmGbPUpyTWhqlK9MOg3jIyi2bMs=; b=TI0R/jXVZtb+YijEt9Q/GDpFw2Bzyj/LjSmBibZK7fZk8z2CSEPvjmQgyPAICzAbEo 0CCTwJfd30040QAsfZLrK8vfXEyJDizQxNwEudvyjLDjcQZGIQkGMlt27Ao5fipB287p L0ia9/IRA/3it5cZWz9G3rXXnMHlLYXtvg6kuOcXiu5n3RvQLfSmYO8A4qmdamr3zRwg hxvGLWtlQ7EYTips/e7o2MaV8plvbnkQTh7PvuaSR/N2O+aUatZJ5gsUKVUNZfm+AbTn MsDnjmHA/M2fTx79VrWUpI/EiDb3CMwKbE8I/6fZoxcMpkgxNYimFTgtfsZ7vSzWmS0Q eTvQ== MIME-Version: 1.0 X-Received: by 10.50.183.11 with SMTP id ei11mr12149187igc.81.1452127743895; Wed, 06 Jan 2016 16:49:03 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.83 with HTTP; Wed, 6 Jan 2016 16:49:03 -0800 (PST) In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Thu, 7 Jan 2016 08:49:03 +0800 X-Google-Sender-Auth: RLdqPdtrs-Sm4dgrRkt79pditRg Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: The IESG , "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , SM , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 00:49:06 -0000 Hm. From your response, I'm still not sure you understand the issue we're bringing up in the Security Considerations, so I'd still like to push on the discussion a bit (even though it's "only" a comment) to make sure we do get the point across properly. The Security Considerations text is not talking about rejecting APPEND commands. For servers that have limits, there are already limits, and they already reject APPENDs that are above their limits. That's not an issue. The resource consumption issue has to do with the way the IMAP APPEND command works. What I'm going to say here is part of IMAP, and doesn't belong in this document, but the background might help you for this discussion. For a normal IMAP APPEND, the client sends "APPEND MailboxName {27183}" to say that it wants to append a message to MailboxName and that the message is 27,183 bytes long. It waits for a server response. If the server responds "OK", the client then sends the 27,183 bytes and processing continues. The server will respond "OK" again when everything's done. If the server responds "NO" after the length is sent, the client knows that it should not send the message data because the append has already been denied. There's an extension called non-synchronizing literals (LITERAL+), which allows the client to instead send "APPEND MailboxName {+27183}This is the message data[...]End of message data." (where that's actually 27,183 bytes of message data). The server will then process the APPEND command and can still respond OK or NO... but the data has been sent already, taking up resources, even though it might not have been needed (the server would have responded "NO" to the initial synchronizing literal if it had been given the chance). So the resource consumption problem has to do with non-synchronizing literals. This extension is meant to help with that problem by allowing servers to advertise append limits so that cooperative clients can avoid sending message data that will only get a NO response in the end. The issue that's being brought up in the Security Considerations is a possible (albeit far fetched) situation wherein a rogue client uses this new information to tune its attack by making appends that it knows will fail, and it knows that because of the advertised limit. And it's specifically intended to send useless data to the server. It knows the APPEND commands will ultimately be rejected, and it wants them to be -- the point is simply to send useless data. So no text that explains about rejecting (responding "NO" to) APPEND commands will help here. What we're trying to say is that servers should watch for behaviour they consider abusive and "take a harder line" with respect to clients that appear abusive, in order to try to avoid these sorts of attacks. Given that explanation, do you have a suggestion for re-wording things to make it clearer (without including explanations of how IMAP APPEND commands, IMAP responses, and IMAP literals work)? Barry On Thu, Jan 7, 2016 at 7:47 AM, Kathleen Moriarty wrote: > On Wed, Jan 6, 2016 at 5:39 PM, Barry Leiba wrote: >>>>> "But with this extension, the attacker can immediately choose a value >>>>> that's a little too large," >>>>> >>>>> It doesn't read well to me. Why would they chose a value that's a >>>>> little too large? Too large for what? They already have the size >>>>> limit per server or per mailbox. Does this mean they will send a >>>>> bunch of messages with the append size maxed out for the mailbox or >>>>> the server to fill the quota? >>>> >>>> The point of the attack isn't filling a mailbox; it's sending >>>> boatloads of data to the server. Suppose there's a limit of 2 MB. If >>>> the client sends 2 MB messages repeatedly, those messages will >>>> eventually cause the mailbox to hit the quota, and further attempts to >>>> bombard the server will be rejected. But messages that are, say, >>>> 2.1MB will fail to append (the server will respond "NO" to them), and >>>> the client can keep bombarding the server with such messages. The >>>> text is trying to warn about that, suggesting that the server might >>>> "take a hard line" -- that is, take more serious action than just >>>> saying "NO" to the append attempts, but perhaps actually lock out the >>>> account until someone checks out the situation. >>> >>> This point wasn't clear to me from the current text. I'd suggest updating it to make it more clear. >> >> I think it is, so please suggest specific text that you think will >> help clarify it for you. > > If we go back to my original comment, the last one: > > "Then, it's a common security programming practice to enforce size > limitations in code. Why is there a focus on an attacker sending > append content that exceeds the allowable size rather than just saying > that such append content should be rejected?" > > This gets at the crux of the text in the security considerations > section. This is essentially what's recommended, but take a round > about way to get to this recommendation. Exceeding the allowed sizes > is not permitted to prevent this 'attack'. > > You can leave it as-is, but I think the text can be more clear by > eliminating most of the introduction to the actual recommendation. > > >> >>>>> Why isn't it explicit in that such messages should/MUST be rejected? >>>> >>>> The messages themselves will be rejected (they APPEND command will get >>>> "NO" for a response), but the damage -- the sending of a lot of data >>>> unnecessarily -- will have already been done. >>> >>> Can this be made more clear as well? It's not in the current text. >> >> No, it's not, because it's how IMAP works. This really isn't >> something we need to make clear here: anyone implementing this already >> knows this and will already be doing it. This is only about >> advertising an APPEND limit, not about how APPEND works and how you >> say "NO" to an APPEND command. > > Barry, my comments are about that limit and I think drafts should be > readable by more than just those who implement mail (in this case). > The last sentences of the security considerations section contains the > same point I am making, but it takes a while to get to that > recommendation, so I'm not really sure why you are arguing this point > and thinking I am talking about anything other than the APPEND limit. > > It says: > > " To mitigate this > extension's input to such an attack, a server might take a harder > line on message sizes that are above the APPENDLIMIT value -- because > the client knows the limit and should not even be trying to send such > commands, a server might consider even a single attempt to be > abusive, and terminate the IMAP connection straight away." > > The whole section could be reduced by starting with this > recommendation and just stating that it prevents attacks on resources > by rejecting messages with sizes above the append limit. There may be > other attacks that are guarded against with this recommendation as > well, so why limit it to this specific example and why lead with the > example. I think it's more straightforward to just have the > recommendation and that it is to prevent attacks on resources. > > If you don't want to fix it, that's fine. It's just a comment. > > Kathleen > >> >> Barry > > > > -- > > Best regards, > Kathleen > From nobody Wed Jan 6 17:33:01 2016 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 15FFE1A3BA6; Wed, 6 Jan 2016 17:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 IUiP2stTqu44; Wed, 6 Jan 2016 17:32:54 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 76F211A3BA2; Wed, 6 Jan 2016 17:32:54 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id u188so80487113wmu.1; Wed, 06 Jan 2016 17:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6C+6s2MzuM/lCjrvvNSJJNCuaOEfDGrVLL+QKU7lRAo=; b=bX35lRe9br5CC6lP1LdMrodRwYIBiSGjWYS8xDbK2HxRbJENDi9q9ZrQRXPnfaBC63 k51D7NKhoma57mMV852mN4j2mMcwqsWiCB0kUOrRbarxHaKM3KEM3dA8fj0bKhn5pDvC +hkTe2fxYC1MVc63B3GNzqjTQncZgVEByH77+IF1a3pnOdHMR77IqYOD6gaJG5nzeYDX Fdbu3eb9HyOB66EZdDOO+YH+SBosCQbTn3oXvlYn5E31g34mBnvB8QLlTs7FnGm7e/in nXDTEVt4Cbl0MGNEOFs/T/5gTFyPU6UqdqO6+b2jVNEFxXah3/if0QqH2LlW6XJdJd4l NAUA== MIME-Version: 1.0 X-Received: by 10.194.222.195 with SMTP id qo3mr109691786wjc.51.1452130372920; Wed, 06 Jan 2016 17:32:52 -0800 (PST) Received: by 10.28.52.65 with HTTP; Wed, 6 Jan 2016 17:32:52 -0800 (PST) In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Wed, 6 Jan 2016 20:32:52 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: The IESG , "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , SM , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 01:32:57 -0000 On Wed, Jan 6, 2016 at 7:49 PM, Barry Leiba wrote: > Hm. From your response, I'm still not sure you understand the issue > we're bringing up in the Security Considerations, so I'd still like to > push on the discussion a bit (even though it's "only" a comment) to > make sure we do get the point across properly. > > The Security Considerations text is not talking about rejecting APPEND > commands. For servers that have limits, there are already limits, and > they already reject APPENDs that are above their limits. That's not > an issue. > > The resource consumption issue has to do with the way the IMAP APPEND > command works. What I'm going to say here is part of IMAP, and > doesn't belong in this document, but the background might help you for > this discussion. For a normal IMAP APPEND, the client sends "APPEND > MailboxName {27183}" to say that it wants to append a message to > MailboxName and that the message is 27,183 bytes long. It waits for a > server response. If the server responds "OK", the client then sends > the 27,183 bytes and processing continues. The server will respond > "OK" again when everything's done. If the server responds "NO" after > the length is sent, the client knows that it should not send the > message data because the append has already been denied. > > There's an extension called non-synchronizing literals (LITERAL+), > which allows the client to instead send "APPEND MailboxName > {+27183}This is the message data[...]End of message data." (where > that's actually 27,183 bytes of message data). The server will then > process the APPEND command and can still respond OK or NO... but the > data has been sent already, taking up resources, even though it might > not have been needed (the server would have responded "NO" to the > initial synchronizing literal if it had been given the chance). > > So the resource consumption problem has to do with non-synchronizing > literals. This extension is meant to help with that problem by > allowing servers to advertise append limits so that cooperative > clients can avoid sending message data that will only get a NO > response in the end. > > The issue that's being brought up in the Security Considerations is a > possible (albeit far fetched) situation wherein a rogue client uses > this new information to tune its attack by making appends that it > knows will fail, and it knows that because of the advertised limit. > And it's specifically intended to send useless data to the server. It > knows the APPEND commands will ultimately be rejected, and it wants > them to be -- the point is simply to send useless data. > > So no text that explains about rejecting (responding "NO" to) APPEND > commands will help here. What we're trying to say is that servers > should watch for behaviour they consider abusive and "take a harder > line" with respect to clients that appear abusive, in order to try to > avoid these sorts of attacks. > > Given that explanation, do you have a suggestion for re-wording things > to make it clearer (without including explanations of how IMAP APPEND > commands, IMAP responses, and IMAP literals work)? I was just suggesting that you could cut out the scenario, leave the last sentence and say it's because of a possible attack on resources, 'resources' being a short way of describing the scenario laid out. If some other attack comes out that is mitigated in a similar way that uses 'resources' in another way, you are covered. It also gets rid of the extra text that I don't see as necessary. But leave it if you think it's fine. Thanks, Kathleen > > Barry > > > > On Thu, Jan 7, 2016 at 7:47 AM, Kathleen Moriarty > wrote: >> On Wed, Jan 6, 2016 at 5:39 PM, Barry Leiba wrote: >>>>>> "But with this extension, the attacker can immediately choose a value >>>>>> that's a little too large," >>>>>> >>>>>> It doesn't read well to me. Why would they chose a value that's a >>>>>> little too large? Too large for what? They already have the size >>>>>> limit per server or per mailbox. Does this mean they will send a >>>>>> bunch of messages with the append size maxed out for the mailbox or >>>>>> the server to fill the quota? >>>>> >>>>> The point of the attack isn't filling a mailbox; it's sending >>>>> boatloads of data to the server. Suppose there's a limit of 2 MB. If >>>>> the client sends 2 MB messages repeatedly, those messages will >>>>> eventually cause the mailbox to hit the quota, and further attempts to >>>>> bombard the server will be rejected. But messages that are, say, >>>>> 2.1MB will fail to append (the server will respond "NO" to them), and >>>>> the client can keep bombarding the server with such messages. The >>>>> text is trying to warn about that, suggesting that the server might >>>>> "take a hard line" -- that is, take more serious action than just >>>>> saying "NO" to the append attempts, but perhaps actually lock out the >>>>> account until someone checks out the situation. >>>> >>>> This point wasn't clear to me from the current text. I'd suggest updating it to make it more clear. >>> >>> I think it is, so please suggest specific text that you think will >>> help clarify it for you. >> >> If we go back to my original comment, the last one: >> >> "Then, it's a common security programming practice to enforce size >> limitations in code. Why is there a focus on an attacker sending >> append content that exceeds the allowable size rather than just saying >> that such append content should be rejected?" >> >> This gets at the crux of the text in the security considerations >> section. This is essentially what's recommended, but take a round >> about way to get to this recommendation. Exceeding the allowed sizes >> is not permitted to prevent this 'attack'. >> >> You can leave it as-is, but I think the text can be more clear by >> eliminating most of the introduction to the actual recommendation. >> >> >>> >>>>>> Why isn't it explicit in that such messages should/MUST be rejected? >>>>> >>>>> The messages themselves will be rejected (they APPEND command will get >>>>> "NO" for a response), but the damage -- the sending of a lot of data >>>>> unnecessarily -- will have already been done. >>>> >>>> Can this be made more clear as well? It's not in the current text. >>> >>> No, it's not, because it's how IMAP works. This really isn't >>> something we need to make clear here: anyone implementing this already >>> knows this and will already be doing it. This is only about >>> advertising an APPEND limit, not about how APPEND works and how you >>> say "NO" to an APPEND command. >> >> Barry, my comments are about that limit and I think drafts should be >> readable by more than just those who implement mail (in this case). >> The last sentences of the security considerations section contains the >> same point I am making, but it takes a while to get to that >> recommendation, so I'm not really sure why you are arguing this point >> and thinking I am talking about anything other than the APPEND limit. >> >> It says: >> >> " To mitigate this >> extension's input to such an attack, a server might take a harder >> line on message sizes that are above the APPENDLIMIT value -- because >> the client knows the limit and should not even be trying to send such >> commands, a server might consider even a single attempt to be >> abusive, and terminate the IMAP connection straight away." >> >> The whole section could be reduced by starting with this >> recommendation and just stating that it prevents attacks on resources >> by rejecting messages with sizes above the append limit. There may be >> other attacks that are guarded against with this recommendation as >> well, so why limit it to this specific example and why lead with the >> example. I think it's more straightforward to just have the >> recommendation and that it is to prevent attacks on resources. >> >> If you don't want to fix it, that's fine. It's just a comment. >> >> Kathleen >> >>> >>> Barry >> >> >> >> -- >> >> Best regards, >> Kathleen >> -- Best regards, Kathleen From nobody Thu Jan 7 07:47:25 2016 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 CAF921A901E; Thu, 7 Jan 2016 07:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 F72Hu7lHuauB; Thu, 7 Jan 2016 07:47:20 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BED91A9009; Thu, 7 Jan 2016 07:47:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.208.165]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u07Fl4Vu027490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 07:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452181639; x=1452268039; bh=NTDlRwfTbjeNnjSgihithAI575TzJwCiof9hz6QYWjM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tJ5P+xspGW1725zmvgfAWPvfTI8v0Hbm+YRRdp3pVpNEBEmV+8HCz1o3u4T1/2CAT aUIN8mTVPpk9ZsGlI7hAb2BjHQfqWl/aGNYrR2rgilYR4GY0Cgaoxj5CD4TVuvaf6f 1AiCA1IcMXm7gEmIAL/XA3BPV9HiJF5h79rCPmwY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452181639; x=1452268039; i=@elandsys.com; bh=NTDlRwfTbjeNnjSgihithAI575TzJwCiof9hz6QYWjM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fJI4sHjiiJcG9la3MPqzBENCZ5cTzOcqdjhoK56AcUubScK3ru6u4QaWJ7NMcLruZ UlaCwF5PLBpuRWlRxZGsv6uN2GxKoLpw3gVdB6oHm9AIgsy1BkdeEJDQrq0uuFxktQ D7K4oOt2YAPUVY88gAzVggQzFociWfxyEagEVpgY= Message-Id: <6.2.5.6.2.20160107073744.0dc4b108@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Jan 2016 07:46:50 -0800 To: Ben Campbell , The IESG From: S Moonesamy In-Reply-To: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 15:47:22 -0000 Hi Ben, At 15:15 06-01-2016, Ben Campbell wrote: >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >- section 2, last paragraph: > >It was not obvious to me if "An IMAP client SHOULD be able to parse both >formats. " meant both STATUS and LIST, or both global and per-mailbox. I >assume the former. Thanks for the review. I am waiting for a reply from the authors. I previously commented that the "both formats" would be covered by the ABNF (Section 5). The normative language in that sentence is incorrect though [1]. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/imapext/current/msg05633.html From nobody Thu Jan 7 08:04:25 2016 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 3B3841A9045; Thu, 7 Jan 2016 08:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 1N1CNUkFPJVh; Thu, 7 Jan 2016 08:04:21 -0800 (PST) Received: from wguard02.sdsamerica.net (wguard02.sdsamerica.net [206.67.236.192]) by ietfa.amsl.com (Postfix) with ESMTP id 357801A904F; Thu, 7 Jan 2016 08:04:21 -0800 (PST) From: Jayantheesh S B To: S Moonesamy , Narendra Singh Bisht Thread-Topic: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) Thread-Index: AQHRSNuvPm5kd8JPBUCDmoH1NkyLjp7wOAAQ Date: Thu, 7 Jan 2016 16:04:19 +0000 Message-ID: References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> In-Reply-To: <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 16:04:23 -0000 Dear SM, Yes, both text refers to the same examples in Section 2. Regards, Jay -----Original Message----- From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of S Moonesamy Sent: Wednesday, January 06, 2016 6:40 PM To: Narendra Singh Bisht; Jayantheesh S B Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org; i= mapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-a= ppendlimit-extension-08: (with COMMENT) Hi Naren, Jay, At 15:15 06-01-2016, Ben Campbell wrote: >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extens >ion/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >- section 2, last paragraph: > >It was not obvious to me if "An IMAP client SHOULD be able to parse=20 >both formats. " meant both STATUS and LIST, or both global and=20 >per-mailbox. I assume the former. In the first paragraph of Section 2 there is the following: "An IMAP server can publish the APPENDLIMIT capability in two formats." There are then two examples of the formats. In the last paragraph of Secti= on 2 there is: "An IMAP client SHOULD be able to parse both formats." Does that refer to the two examples in Section 2? Regards, S. Moonesamy (as document shepherd)=20 _______________________________________________ imapext mailing list imapext@ietf.org https://www.ietf.org/mailman/listinfo/imapext From nobody Thu Jan 7 08:15:29 2016 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 C1AB21A908B; Thu, 7 Jan 2016 08:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 x-31xUumqvJ0; Thu, 7 Jan 2016 08:15:24 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE47C1A906D; Thu, 7 Jan 2016 08:15:22 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.208.165]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u07GF4lU025184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 08:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452183317; x=1452269717; bh=HM5DmWvaaO2ZWMT8hrsWeEvghkmSSvfs+VDUFVA+bHQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XIbCjtQnsZc2qPCkX2cmvaMAmOZlVpFvzspJyNXnd6GLEOyNuCBZZoq+dfRKyQV6G 2lNv7tWq/bGfrxBgt5ab5g+pKvYBBuTzSNeKJ084xOGZPwvuX66sUxF1hWqacT2f3I p/dTT3xfy2UKkOEBjp4ZsRYLCm2fE759DqOOfz0M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452183317; x=1452269717; i=@elandsys.com; bh=HM5DmWvaaO2ZWMT8hrsWeEvghkmSSvfs+VDUFVA+bHQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AX3k0wTeZHhF2haJ2u+KoJKmWCmccEHZnPmFRnqz7w/VTJ6ZoUqwwnQixaA6p5cTz nJbmZ8EwMph9hu13VwFE1dErkNvK4ibu4hR61IMF0FWDkkP4Uh/avN+xdRtt8j9LOf kBHQLHbpUuiQdzYYWWBGBBs9R/AXMUDZQv2o2lQE= Message-Id: <6.2.5.6.2.20160107081246.0dc27430@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Jan 2016 08:14:51 -0800 To: Jayantheesh S B , Narendra Singh Bisht From: S Moonesamy In-Reply-To: References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 16:15:28 -0000 Hi Jay, At 08:04 07-01-2016, Jayantheesh S B wrote: >Yes, both text refers to the same examples in Section 2. Thanks for confirming that. Why is there a RFC 2119 "SHOULD" in the first sentence of the last paragraph of Section 2? Regards, S. Moonesamy From nobody Thu Jan 7 08:28:21 2016 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 A84061A9035; Thu, 7 Jan 2016 08:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 KUjT7OuteewQ; Thu, 7 Jan 2016 08:28:18 -0800 (PST) Received: from wguard02.sdsamerica.net (wguard02.sdsamerica.net [206.67.236.192]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF041A8A93; Thu, 7 Jan 2016 08:28:18 -0800 (PST) From: Jayantheesh S B To: S Moonesamy , Narendra Singh Bisht Thread-Topic: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) Thread-Index: AQHRSWads96EBf5KXU6pGwRSssXWZJ7wO/hQ Date: Thu, 7 Jan 2016 16:28:16 +0000 Message-ID: <32e9302978e64b1b84ed10dbe68a68d4@SEAMBX01.sea.samsung.com> References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> <6.2.5.6.2.20160107081246.0dc27430@elandnews.com> In-Reply-To: <6.2.5.6.2.20160107081246.0dc27430@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 16:28:19 -0000 Dear SM, IMAP client implementing this extension, should be capable to parse both Ma= ilbox-specific and Global APPENDLIMIT response. IMAP client ignoring one format may result in non-compliance to this extens= ion. To stress that point we have added RFC 2119 "SHOULD" in that sentence.= =20 Regards, Jay -----Original Message----- From: S Moonesamy [mailto:sm+ietf@elandsys.com]=20 Sent: Thursday, January 07, 2016 11:15 AM To: Jayantheesh S B; Narendra Singh Bisht Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org; i= mapapnd-chairs@ietf.org Subject: RE: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-a= ppendlimit-extension-08: (with COMMENT) Hi Jay, At 08:04 07-01-2016, Jayantheesh S B wrote: >Yes, both text refers to the same examples in Section 2. Thanks for confirming that. Why is there a RFC 2119 "SHOULD" in the first sentence of the last paragrap= h of Section 2? Regards, S. Moonesamy=20 From nobody Thu Jan 7 08:41:34 2016 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 B93311A90AA; Thu, 7 Jan 2016 08:41:33 -0800 (PST) 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 lAGHw33Tygeb; Thu, 7 Jan 2016 08:41:32 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 502DB1A90AC; Thu, 7 Jan 2016 08:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1452184891; d=isode.com; s=selector; i=@isode.com; bh=VyUBwcPk1UZQVYRHH/ta7gmRJk34Rnhhrm+yUemHdf8=; 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=DlnQLEQ4g6hZ4EdTd0JJh1+S1oY8hdTPs+yfQmeWDI9/pUaHFX81beKb11Bqqa8R+MXRwl WH2we1bcB3KMKCC7m8dEYiotj9j+s02mPVuYLHs7OYW5YnFSXSngI7DOohPhFuugtIqqOS 7y5ywZ5BcQAVf2icA+xqakjqhp4CODk=; 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 ; Thu, 7 Jan 2016 16:41:31 +0000 To: Jayantheesh S B , S Moonesamy , Narendra Singh Bisht References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> <6.2.5.6.2.20160107081246.0dc27430@elandnews.com> <32e9302978e64b1b84ed10dbe68a68d4@SEAMBX01.sea.samsung.com> From: Alexey Melnikov Message-ID: <568E9521.60403@isode.com> Date: Thu, 7 Jan 2016 16:41:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <32e9302978e64b1b84ed10dbe68a68d4@SEAMBX01.sea.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 16:41:33 -0000 On 07/01/2016 16:28, Jayantheesh S B wrote: > Dear SM, > > IMAP client implementing this extension, should be capable to parse both Mailbox-specific and Global APPENDLIMIT response. > > IMAP client ignoring one format may result in non-compliance to this extension. To stress that point we have added RFC 2119 "SHOULD" in that sentence. SHOULD implies that it is possible for the client not to parse one of the variants in some circumstances. I think not using normative language is better here (or switch to MUST). > Regards, > Jay > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Thursday, January 07, 2016 11:15 AM > To: Jayantheesh S B; Narendra Singh Bisht > Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org; imapapnd-chairs@ietf.org > Subject: RE: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) > > Hi Jay, > At 08:04 07-01-2016, Jayantheesh S B wrote: >> Yes, both text refers to the same examples in Section 2. > Thanks for confirming that. > > Why is there a RFC 2119 "SHOULD" in the first sentence of the last paragraph of Section 2? > > Regards, > S. Moonesamy > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From nobody Thu Jan 7 08:48:39 2016 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 35EFA1A9047; Thu, 7 Jan 2016 08:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 vSwX5VYyEUdh; Thu, 7 Jan 2016 08:48:36 -0800 (PST) Received: from wguard02.sdsamerica.net (wguard02.sdsamerica.net [206.67.236.192]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9681A90B4; Thu, 7 Jan 2016 08:48:36 -0800 (PST) From: Jayantheesh S B To: Alexey Melnikov , S Moonesamy , Narendra Singh Bisht Thread-Topic: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) Thread-Index: AQHRSWpEiqLoMgOjyUOC1z2U9DWaQ57wQsbg Date: Thu, 7 Jan 2016 16:48:34 +0000 Message-ID: <91c4aa2bf57d4e76a924d2a7280489e7@SEAMBX01.sea.samsung.com> References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> <6.2.5.6.2.20160107081246.0dc27430@elandnews.com> <32e9302978e64b1b84ed10dbe68a68d4@SEAMBX01.sea.samsung.com> <568E9521.60403@isode.com> In-Reply-To: <568E9521.60403@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 16:48:38 -0000 Alexey, Ok, We will remove the normative language here. Regards, Jay -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Thursday, January 07, 2016 11:41 AM To: Jayantheesh S B; S Moonesamy; Narendra Singh Bisht Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org; i= mapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-a= ppendlimit-extension-08: (with COMMENT) On 07/01/2016 16:28, Jayantheesh S B wrote: > Dear SM, > > IMAP client implementing this extension, should be capable to parse both = Mailbox-specific and Global APPENDLIMIT response. > > IMAP client ignoring one format may result in non-compliance to this exte= nsion. To stress that point we have added RFC 2119 "SHOULD" in that sentenc= e. SHOULD implies that it is possible for the client not to parse one of the v= ariants in some circumstances. I think not using normative language is bett= er here (or switch to MUST). > Regards, > Jay > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Thursday, January 07, 2016 11:15 AM > To: Jayantheesh S B; Narendra Singh Bisht > Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org;=20 > imapext@ietf.org; imapapnd-chairs@ietf.org > Subject: RE: [imapext] Ben Campbell's No Objection on=20 > draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) > > Hi Jay, > At 08:04 07-01-2016, Jayantheesh S B wrote: >> Yes, both text refers to the same examples in Section 2. > Thanks for confirming that. > > Why is there a RFC 2119 "SHOULD" in the first sentence of the last paragr= aph of Section 2? > > Regards, > S. Moonesamy > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From nobody Thu Jan 7 08:50:34 2016 Return-Path: X-Original-To: imapext@ietf.org Delivered-To: imapext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1401A1BBC; Wed, 6 Jan 2016 15:15:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> Date: Wed, 06 Jan 2016 15:15:43 -0800 Archived-At: X-Mailman-Approved-At: Thu, 07 Jan 2016 08:50:32 -0800 Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, sm+ietf@elandsys.com, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 23:15:43 -0000 Ben Campbell has entered the following ballot position for draft-ietf-imapapnd-appendlimit-extension-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 2, last paragraph: It was not obvious to me if "An IMAP client SHOULD be able to parse both formats. " meant both STATUS and LIST, or both global and per-mailbox. I assume the former. From nobody Thu Jan 7 09:10:39 2016 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 2136E1A90EE; Thu, 7 Jan 2016 09:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 s1b6l8fHp3-t; Thu, 7 Jan 2016 09:10:37 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 306C01A90ED; Thu, 7 Jan 2016 09:10:37 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.208.165]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u07HAIXq025650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 09:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452186632; x=1452273032; bh=Ef4amfKp5pRh4EXmPGR7N+DicUx0BVDKovS/EPJEr3g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=26pHlxCzy5A/qjCwDDf/Nv8NZCKHnyi+Xz2DLwVn0fGusrJ5UVG1hDGpDxYEr8uC9 BechRk+YR7hPnZyzo0WmF9hhGmvTkqLUESTrIkQBhy/aRsn13lLHP6KNhiWAPjQ7O9 YMd+EtMJee+7RaMmt8eqX3N6OT4VnOqSgubfp9p4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452186632; x=1452273032; i=@elandsys.com; bh=Ef4amfKp5pRh4EXmPGR7N+DicUx0BVDKovS/EPJEr3g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=d6S2tSmAjqmthPmJF7j/8K+3wd5VcsNzBQAjLyeM60I2XmzdQUVM3cMDni1f9k4Nd jujsgdZs1CDdhBNMX6E6QpcXC5OojiRuc4hPOsu4LUTSnpEkkIks09N9EKx0uYrY/k D8uVi41Y+YYLFcbKmzSrHbCdvuFHmS4Lk1wAYJo4= Message-Id: <6.2.5.6.2.20160107083115.0e98f568@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Jan 2016 09:09:06 -0800 To: Jayantheesh S B , Narendra Singh Bisht , Alexey Melnikov From: S Moonesamy In-Reply-To: <32e9302978e64b1b84ed10dbe68a68d4@SEAMBX01.sea.samsung.com> References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> <6.2.5.6.2.20160107081246.0dc27430@elandnews.com> <32e9302978e64b1b84ed10dbe68a68d4@SEAMBX01.sea.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 17:10:38 -0000 Hi Jay, Alexey, At 08:41 07-01-2016, Alexey Melnikov wrote: >SHOULD implies that it is possible for the client not to parse one >of the variants in some circumstances. I think not using normative >language is better here (or switch to MUST). Yes. I don't think that using normative language is appropriate in that sentence. At 08:28 07-01-2016, Jayantheesh S B wrote: >IMAP client implementing this extension, should be capable to parse >both Mailbox-specific and Global APPENDLIMIT response. > >IMAP client ignoring one format may result in non-compliance to this >extension. To stress that point we have added RFC 2119 "SHOULD" in >that sentence. I'll suggest the following text: An IMAP client implementing this extension should be able to parse both mailbox-specific and global APPENDLIMIT responses. Regards, S. Moonesamy (as document shepherd) From nobody Thu Jan 7 09:12:40 2016 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 08E1D1A90D7; Thu, 7 Jan 2016 09:12:39 -0800 (PST) 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 8R8Z5fbrHPMe; Thu, 7 Jan 2016 09:12:38 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8D1A90CE; Thu, 7 Jan 2016 09:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1452186757; d=isode.com; s=selector; i=@isode.com; bh=lkGwBYapO4GJUODHowrnYcOWulU8sI5r4SZwMGedsE0=; 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=hDFSVw8dDIEy90jJi/n8ygdOlNjpGAWg4KKvCwvIn2en37zAAmEULCntwJx3vVkKKfG17i guvF1x+PBm8mIpiEpY/CoY7BRXcZlkuWPR4GfLB1mpSl7SDSBlXWl12xuCztkn9rVyzmNT j+jTz8G1Uqze0ZxAIUcCwcXjRFTFvx0=; 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 ; Thu, 7 Jan 2016 17:12:37 +0000 To: S Moonesamy , Jayantheesh S B , Narendra Singh Bisht References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> <6.2.5.6.2.20160107081246.0dc27430@elandnews.com> <32e9302978e64b1b84ed10dbe68a68d4@SEAMBX01.sea.samsung.com> <6.2.5.6.2.20160107083115.0e98f568@elandnews.com> From: Alexey Melnikov Message-ID: <568E9C6B.8060003@isode.com> Date: Thu, 7 Jan 2016 17:12:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <6.2.5.6.2.20160107083115.0e98f568@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 17:12:39 -0000 Hi SM, On 07/01/2016 17:09, S Moonesamy wrote: > Hi Jay, Alexey, > > At 08:41 07-01-2016, Alexey Melnikov wrote: >> SHOULD implies that it is possible for the client not to parse one of >> the variants in some circumstances. I think not using normative >> language is better here (or switch to MUST). > > Yes. I don't think that using normative language is appropriate in > that sentence. > > At 08:28 07-01-2016, Jayantheesh S B wrote: >> IMAP client implementing this extension, should be capable to parse >> both Mailbox-specific and Global APPENDLIMIT response. >> >> IMAP client ignoring one format may result in non-compliance to this >> extension. To stress that point we have added RFC 2119 "SHOULD" in >> that sentence. > > I'll suggest the following text: > > An IMAP client implementing this extension should be able to parse both > mailbox-specific and global APPENDLIMIT responses. +1. From nobody Thu Jan 7 09:16:02 2016 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 9EB351A90F1; Thu, 7 Jan 2016 09:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 7J3tsKku_hRh; Thu, 7 Jan 2016 09:16:00 -0800 (PST) Received: from wguard01.sdsamerica.net (wguard01.sdsamerica.net [206.67.236.191]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCBD1A90C3; Thu, 7 Jan 2016 09:16:00 -0800 (PST) From: Jayantheesh S B To: S Moonesamy , Narendra Singh Bisht , Alexey Melnikov Thread-Topic: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) Thread-Index: AQHRSWads96EBf5KXU6pGwRSssXWZJ7wO/hQgABhRwD//63MgA== Date: Thu, 7 Jan 2016 17:15:58 +0000 Message-ID: References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106152957.0d8df630@elandnews.com> <6.2.5.6.2.20160107081246.0dc27430@elandnews.com> <32e9302978e64b1b84ed10dbe68a68d4@SEAMBX01.sea.samsung.com> <6.2.5.6.2.20160107083115.0e98f568@elandnews.com> In-Reply-To: <6.2.5.6.2.20160107083115.0e98f568@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 17:16:01 -0000 Thanks SM. It's fine for me. If everybody is OK, I will update the proposed text.=20 Regards, Jay -----Original Message----- From: S Moonesamy [mailto:sm+ietf@elandsys.com]=20 Sent: Thursday, January 07, 2016 12:09 PM To: Jayantheesh S B; Narendra Singh Bisht; Alexey Melnikov Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org; i= mapapnd-chairs@ietf.org Subject: RE: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-a= ppendlimit-extension-08: (with COMMENT) Hi Jay, Alexey, At 08:41 07-01-2016, Alexey Melnikov wrote: >SHOULD implies that it is possible for the client not to parse one of=20 >the variants in some circumstances. I think not using normative=20 >language is better here (or switch to MUST). Yes. I don't think that using normative language is appropriate in that se= ntence. At 08:28 07-01-2016, Jayantheesh S B wrote: >IMAP client implementing this extension, should be capable to parse=20 >both Mailbox-specific and Global APPENDLIMIT response. > >IMAP client ignoring one format may result in non-compliance to this=20 >extension. To stress that point we have added RFC 2119 "SHOULD" in that=20 >sentence. I'll suggest the following text: An IMAP client implementing this extension should be able to parse both mailbox-specific and global APPENDLIMIT responses. Regards, S. Moonesamy (as document shepherd)=20 From nobody Thu Jan 7 09:19:09 2016 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 45EE61A9101; Thu, 7 Jan 2016 09:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 blUx-p0dcdc4; Thu, 7 Jan 2016 09:19:07 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0627C1A9102; Thu, 7 Jan 2016 09:19:06 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.208.165]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u07HIqfd014864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 09:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452187146; x=1452273546; bh=Ha9UYLrvVPMrSiH0S6sov5d/L0qgpCiS4CGPrLyk5LM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=G5ivtQaEHJ7hpDAQXjmYiDft5pBcJpZHbpep6vlDkYRJmvJUu3sobJsPRzopdu/B/ xfTsQtzxFdotaYg1h9fzit/9ZdKvFwTtpFi6QZcLFuskg+L+Xcmv5ynZUFFII0P3bO fHQbwAm0o456iS3imyBiQRK3xv1m8adpNvxTH4BI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452187146; x=1452273546; i=@elandsys.com; bh=Ha9UYLrvVPMrSiH0S6sov5d/L0qgpCiS4CGPrLyk5LM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WyoOmQIReScsdnryTBkLQgReC3Y1q9DpRrmKligAmR02HJ7EoK72WmJ20NpMlB5fi IpduvgIb4gBGxiN2Vv7m1OiXeQYG17RL8lcC3puZeST/WDPG9CxmQ5mTLf7MAZEgEN 0bcj1P66wJDybvBiZ+kusiyRjqviSF8rBaZVRU64= Message-Id: <6.2.5.6.2.20160107091507.0e9b10d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Jan 2016 09:18:38 -0800 To: Ben Campbell , The IESG From: S Moonesamy In-Reply-To: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 17:19:08 -0000 Hi Ben, At 15:15 06-01-2016, Ben Campbell wrote: >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >- section 2, last paragraph: > >It was not obvious to me if "An IMAP client SHOULD be able to parse both >formats. " meant both STATUS and LIST, or both global and per-mailbox. I >assume the former. OLD An IMAP client SHOULD be able to parse both formats. END NEW An IMAP client implementing this extension should be able to parse both mailbox-specific and global APPENDLIMIT responses. END Regards, S. Moonesamy (as document shepherd) From nobody Thu Jan 7 09:23:11 2016 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 D044F1A9104; Thu, 7 Jan 2016 09:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 uxgBKd-nKU-Z; Thu, 7 Jan 2016 09:23:05 -0800 (PST) Received: from wguard01.sdsamerica.net (wguard01.sdsamerica.net [206.67.236.191]) by ietfa.amsl.com (Postfix) with ESMTP id 714F41A90E0; Thu, 7 Jan 2016 09:23:05 -0800 (PST) From: Jayantheesh S B To: S Moonesamy , Alissa Cooper , "The IESG" Thread-Topic: [imapext] Alissa Cooper's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) Thread-Index: AQHRR/RlWF+Av3cVr0WWi4uFPEm6WJ7vQ4yAgAEMadA= Date: Thu, 7 Jan 2016 17:23:03 +0000 Message-ID: <13d76c6a27ff4d05a48d1cf39e978d27@SEAMBX01.sea.samsung.com> References: <20160105191025.31613.33420.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160106121402.0d584cd0@elandnews.com> In-Reply-To: <6.2.5.6.2.20160106121402.0d584cd0@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Alissa Cooper's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 17:23:07 -0000 Dear All, Updated the document with the below text proposed by SM. NEW In this case the client can get an APPENDLIMIT value by either issuing a STATUS or a LIST command. By looking at the upload size advertised by the IMAP server a client can avoid trying to APPEND mail more than the advertised limit. END Regards, Jay -----Original Message----- From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of S Moonesamy Sent: Wednesday, January 06, 2016 3:21 PM To: Alissa Cooper; The IESG Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org; i= mapapnd-chairs@ietf.org Subject: Re: [imapext] Alissa Cooper's No Objection on draft-ietf-imapapnd-= appendlimit-extension-08: (with COMMENT) Hi Alissa, At 11:10 05-01-2016, Alissa Cooper wrote: >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extens >ion/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >It's unusual to see author names without first initials in the document=20 >header. Not sure if that was intentional but seems like it should be=20 >fixed (assuming the authors have both first names and surnames). It is a mistake. It will be fixed in the next revision of the draft. >=3D Section 2 =3D > >"In this case the client SHOULD get an APPENDLIMIT value by issuing a > STATUS or LIST command. > > An IMAP client SHOULD be able to parse both formats. By looking at > the upload size advertised by the IMAP server, a client MUST NOT try > to APPEND mail more than the advertised limit." > >The first and last normative requirements here seem too strict=20 >considering that this extension basically allows an optimization. That=20 >is, if a client decides not to find out the append limit for a=20 >particular mailbox using STATUS or LIST, that doesn't seem to create=20 >any particular problem. Likewise, it seems better for a client to avoid=20 >sending an attachment larger than a known limit, but doing so doesn't=20 >seem so problematic as to warrant a MUST NOT. NEW In this case the client can get an APPENDLIMIT value by either issuing a STATUS or a LIST command. By looking at the upload size advertised by the IMAP server a client can avoid trying to APPEND mail more than the advertised limit. END Regards, S. Moonesamy (as document shepherd)=20 _______________________________________________ imapext mailing list imapext@ietf.org https://www.ietf.org/mailman/listinfo/imapext From nobody Thu Jan 7 09:57:36 2016 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 BE2BB1A9126; Thu, 7 Jan 2016 09:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dLjUlMNMcort; Thu, 7 Jan 2016 09:49:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 DD19B1A9125; Thu, 7 Jan 2016 09:49:45 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u07HnZvg031121 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2016 11:49:36 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "S Moonesamy" Date: Thu, 07 Jan 2016 11:49:36 -0600 Message-ID: In-Reply-To: <6.2.5.6.2.20160107091507.0e9b10d0@elandnews.com> References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160107091507.0e9b10d0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: X-Mailman-Approved-At: Thu, 07 Jan 2016 09:57:35 -0800 Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, The IESG , imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 07 Jan 2016 17:49:47 -0000 On 7 Jan 2016, at 11:18, S Moonesamy wrote: > Hi Ben, > At 15:15 06-01-2016, Ben Campbell wrote: >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - section 2, last paragraph: >> >> It was not obvious to me if "An IMAP client SHOULD be able to parse >> both >> formats. " meant both STATUS and LIST, or both global and >> per-mailbox. I >> assume the former. > > OLD > An IMAP client SHOULD be able to parse both formats. > END > > NEW > An IMAP client implementing this extension should be able to parse > both > mailbox-specific and global APPENDLIMIT responses. > END Works for me. (And shows I assumed wrong.) > > Regards, > S. Moonesamy (as document shepherd) From nobody Thu Jan 7 11:45:24 2016 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 B92E41AC3D0; Thu, 7 Jan 2016 11:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 G0cANMv-6QDE; Thu, 7 Jan 2016 11:45:19 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 292F01A00FD; Thu, 7 Jan 2016 11:45:19 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.208.165]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u07Jj5vV003806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 11:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452195917; x=1452282317; bh=ljEfo9HMKzJ83Xmx3pU26kRGp3tcFJi0iUEN1IxEo0A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OW6zZl0tEKXLhk4wPmsXSzjtqmIRVYHSBf3OysPbDb+tDcM8PLt0kNg0YCnW9QApl X0w4KRtQylScUyLYNhmbu/8doKiW9e8WU6mklyL/Nd3nnK1s9nj2Nrjf5cEWyilfHU zouowe2KudMiuDdxCJdRbFEtC0RgyfvrpNUfdkeo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452195917; x=1452282317; i=@elandsys.com; bh=ljEfo9HMKzJ83Xmx3pU26kRGp3tcFJi0iUEN1IxEo0A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IebCsOe5fJBDXYizMfKC4oe/QxTCj6Zi8+mItsuBhONAimTgCDefsuRn6rFJxT8Vn lUWUObfYvPmJ1UbM0ZsHqh9eBc2Q0EELYs5kvNewh0tOpT3GByds6AW5NsVUWFTUC6 vbfYqfRsxI9xyg1B/8eZQeiQStPx26TXti08kR2A= Message-Id: <6.2.5.6.2.20160107113945.0e12b348@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Jan 2016 11:44:36 -0800 To: Ben Campbell From: S Moonesamy In-Reply-To: References: <20160106231543.12304.75202.idtracker@ietfa.amsl.com> <6.2.5.6.2.20160107091507.0e9b10d0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: iesg@ietf.org, imapext@ietf.org Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (off-topic) 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, 07 Jan 2016 19:45:19 -0000 Hi Ben, At 09:49 07-01-2016, Ben Campbell wrote: >Works for me. (And shows I assumed wrong.) It shows that you did a good review. :-) It is a positive contribution to the draft. Regards, S. Moonesamy From nobody Thu Jan 7 12:53:09 2016 Return-Path: X-Original-To: imapext@ietf.org Delivered-To: imapext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 679591A00BE; Thu, 7 Jan 2016 12:53:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107205306.727.47959.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 12:53:06 -0800 Archived-At: Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-imapapnd-appendlimit-extension-09.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 20:53:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IMAP APPEND Extensions Working Group of the IETF. Title : The IMAP APPENDLIMIT Extension Authors : Jayantheesh SrimushnamBoovaraghamoorthy Narendra Singh Bisht Filename : draft-ietf-imapapnd-appendlimit-extension-09.txt Pages : 7 Date : 2016-01-07 Abstract: This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-imapapnd-appendlimit-extension-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 7 16:30:50 2016 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 545C01A8A98; Thu, 7 Jan 2016 16:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 gLBKbZcRBgAz; Thu, 7 Jan 2016 16:30:45 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 4693C1A8A71; Thu, 7 Jan 2016 16:30:45 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id z14so64758142igp.0; Thu, 07 Jan 2016 16:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gmP/x2XZggz2vEpiIXRWZqRHRtdWmepC9WxhOHMXcBE=; b=T6hc67h371yC+b7F+mhW823/iIKQ1f4Iml0/55WAdUoSJIh6DU6vcFAUzov3jRv1UL jVbXR13+OTMbtFuX5b9K9ITtjW8pRhq6ze8C2zG7Uuf30DRM1NKd1iJ8RZd0Jvdd8Djm usmay0CmnbJXpyeMkioZbTdbNxpX447r9zKVisRf6BVW+4ypUdScK0E0FjTdEgEyH4jc ab8JYquR41XeCs/JUDE2RRchipVjBvHZsYwtZnApi4Eq8ddiKvxDM0RYkf+QLOZV02aN q5Xfr3fsrQ4XPLsDXFzTS6h5jk8PZuC28ovSL/oEO80VkQTE/t7f1ORtDOUcrjTJUULo 1xiw== MIME-Version: 1.0 X-Received: by 10.50.143.10 with SMTP id sa10mr5668399igb.54.1452213044668; Thu, 07 Jan 2016 16:30:44 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.83 with HTTP; Thu, 7 Jan 2016 16:30:44 -0800 (PST) In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> Date: Fri, 8 Jan 2016 08:30:44 +0800 X-Google-Sender-Auth: 0q6FbLEawHO4OCEirrGJs16PhL8 Message-ID: From: Barry Leiba To: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapext@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "imapapnd-chairs@ietf.org" , The IESG , SM Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 08 Jan 2016 00:30:46 -0000 Authors and working group: In light of this discussion, I suggest that we replace the content of the Security Considerations section with this: NEW This extension provides additional information that cooperative clients can use as an optimization, and does not introduce new security concerns. This extension does not address abusive clients that intend to consume server resources, and servers will still have to take action to disconnect and/or restrict access to clients that exhibit abusive behavior. END Please comment, and if there are no objections, please make the change in another revision. Thanks. Barry On Thu, Jan 7, 2016 at 9:32 AM, Kathleen Moriarty wrote: > I was just suggesting that you could cut out the scenario, leave the > last sentence and say it's because of a possible attack on resources, > 'resources' being a short way of describing the scenario laid out. If > some other attack comes out that is mitigated in a similar way that > uses 'resources' in another way, you are covered. It also gets rid of > the extra text that I don't see as necessary. But leave it if you > think it's fine. From nobody Fri Jan 8 08:05:55 2016 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 35B6E1B2A1C; Fri, 8 Jan 2016 08:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 ABNbi1EgK_c5; Fri, 8 Jan 2016 08:05:52 -0800 (PST) Received: from wguard02.sdsamerica.net (wguard02.sdsamerica.net [206.67.236.192]) by ietfa.amsl.com (Postfix) with ESMTP id 97D5E1B2A1B; Fri, 8 Jan 2016 08:05:52 -0800 (PST) From: Jayantheesh S B To: Barry Leiba , "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , "imapext@ietf.org" Thread-Topic: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) Thread-Index: AQHRSCsx3E1RF5wBK0anMv3nwSVPtZ7uL4IAgAADJ4CAABFjAIAAgxuAgACifACAABL7AIAAEUWAgAAMPgCAAYD5AIAAsMeg Date: Fri, 8 Jan 2016 16:05:51 +0000 Message-ID: <93bb56db92e5406c910d0e947b3cf97e@SEAMBX01.sea.samsung.com> References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Archived-At: Cc: "imapapnd-chairs@ietf.org" , The IESG , SM Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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, 08 Jan 2016 16:05:54 -0000 Hi Barry, We are fine with the proposed text. We will update the draft with this text= and release a new version (10).=20 Regards, Jay -----Original Message----- From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Thursday, January 07, 2016 7:31 PM To: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org Cc: imapapnd-chairs@ietf.org; The IESG; SM Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapa= pnd-appendlimit-extension-08: (with COMMENT) Authors and working group: In light of this discussion, I suggest that we replace the content of the S= ecurity Considerations section with this: NEW This extension provides additional information that cooperative clients can use as an optimization, and does not introduce new security concerns. This extension does not address abusive clients that intend to consume server resources, and servers will still have to take action to disconnect and/or restrict access to clients that exhibit abusive behavior. END Please comment, and if there are no objections, please make the change in a= nother revision. Thanks. Barry On Thu, Jan 7, 2016 at 9:32 AM, Kathleen Moriarty wrote: > I was just suggesting that you could cut out the scenario, leave the=20 > last sentence and say it's because of a possible attack on resources,=20 > 'resources' being a short way of describing the scenario laid out. If=20 > some other attack comes out that is mitigated in a similar way that=20 > uses 'resources' in another way, you are covered. It also gets rid of=20 > the extra text that I don't see as necessary. But leave it if you=20 > think it's fine. _______________________________________________ imapext mailing list imapext@ietf.org https://www.ietf.org/mailman/listinfo/imapext From nobody Fri Jan 8 11:19:36 2016 Return-Path: X-Original-To: imapext@ietf.org Delivered-To: imapext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 623371B2B1B; Fri, 8 Jan 2016 11:19:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160108191928.9196.69631.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 11:19:28 -0800 Archived-At: Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-imapapnd-appendlimit-extension-10.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 19:19:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IMAP APPEND Extensions Working Group of the IETF. Title : The IMAP APPENDLIMIT Extension Authors : Jayantheesh SrimushnamBoovaraghamoorthy Narendra Singh Bisht Filename : draft-ietf-imapapnd-appendlimit-extension-10.txt Pages : 7 Date : 2016-01-08 Abstract: This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-imapapnd-appendlimit-extension-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 9 14:27:08 2016 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 E243C1A90A4; Sat, 9 Jan 2016 14:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 1jjbSm4sZqdI; Sat, 9 Jan 2016 14:27:05 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 6DBF81A90A3; Sat, 9 Jan 2016 14:27:05 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id g73so120956726ioe.3; Sat, 09 Jan 2016 14:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+JOguvYgwkiBz2vGsw7J/Snujj8wG+Wle2A43FpnzeQ=; b=x4O46ljzyJ38ljeGJDHL439e2Q72cez0YDJOBvrg1cJRrPgmEG+/NUz2euHv0XkbcH Fd9/qp3ydlAid02GluApdUdQgkjDQt1rZoURxDlumaYp2MHJdUusm105qL5pvTgFMGWQ sEcr24c4cA/Hv6BmwdlIZh2O1dqinejB9VgHuz/+PNFKFNkCXN/wE+qTbHbuEY94UlAA v8MwNKbn2LoObY0NkFBeJ/w/ePXPnGMIX9ahCGXldKsx3pnuUiIJUK7IJe6IRzm8GwDG 7QC7QkOvRuU6ZgJ/XX0rdRaKwYrrjNGxBhjvqtbp8nf5HrVIpwWftfw50YBzCLkqS6QC d7Vg== MIME-Version: 1.0 X-Received: by 10.107.5.209 with SMTP id 200mr62587559iof.193.1452378424796; Sat, 09 Jan 2016 14:27:04 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.83 with HTTP; Sat, 9 Jan 2016 14:27:04 -0800 (PST) In-Reply-To: <93bb56db92e5406c910d0e947b3cf97e@SEAMBX01.sea.samsung.com> References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> <93bb56db92e5406c910d0e947b3cf97e@SEAMBX01.sea.samsung.com> Date: Sat, 9 Jan 2016 17:27:04 -0500 X-Google-Sender-Auth: i0GXUadYazkq5_VnfUQaT2SllW0 Message-ID: From: Barry Leiba To: Jayantheesh S B Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" , SM , "imapext@ietf.org" , "imapapnd-chairs@ietf.org" Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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: Sat, 09 Jan 2016 22:27:07 -0000 > We are fine with the proposed text. We will update the draft with this > text and release a new version (10). Great; thanks. I'd like to hear from a couple of others to make sure it's OK with a few more people. Alexey, SM, can the two of you weigh in? Barry > -----Original Message----- > From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Thursday, January 07, 2016 7:31 PM > To: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org > Cc: imapapnd-chairs@ietf.org; The IESG; SM > Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) > > Authors and working group: > In light of this discussion, I suggest that we replace the content of the Security Considerations section with this: > > NEW > This extension provides additional information that cooperative > clients can use as an optimization, and does not introduce new > security concerns. This extension does not address abusive clients > that intend to consume server resources, and servers will still have > to take action to disconnect and/or restrict access to clients that > exhibit abusive behavior. > END > > Please comment, and if there are no objections, please make the change in another revision. Thanks. > > Barry > > On Thu, Jan 7, 2016 at 9:32 AM, Kathleen Moriarty wrote: >> I was just suggesting that you could cut out the scenario, leave the >> last sentence and say it's because of a possible attack on resources, >> 'resources' being a short way of describing the scenario laid out. If >> some other attack comes out that is mitigated in a similar way that >> uses 'resources' in another way, you are covered. It also gets rid of >> the extra text that I don't see as necessary. But leave it if you >> think it's fine. > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > From nobody Sun Jan 10 04:56:53 2016 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 672771ACD08; Sun, 10 Jan 2016 04:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 czuyQFLraSv2; Sun, 10 Jan 2016 04:56:49 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A4A521ACD03; Sun, 10 Jan 2016 04:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1452430608; d=isode.com; s=selector; i=@isode.com; bh=YDFslV4T13CKTmuXuRt7FvP+Q0AObws7YZyJjS92o9k=; 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=YQphRi4oBdBCZRtsJtMWDMkVXFL1cZEOW+i8deht7inr1oQ/lnazZ04kpXVzvEkKoNDgr7 sAQZM/5M41FBgAQ5OICbsfchL0HF5MLRwxR9k5rmVzuU4bMFLCjJWWg7kxcAk/5yxSDAvP dVFHK8tlO+dbpXyz4Bc8rznmONPQdMQ=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 10 Jan 2016 12:56:48 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (13C75) In-Reply-To: Date: Sun, 10 Jan 2016 13:00:07 +0000 Message-Id: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> <93bb56db92e5406c910d0e947b3cf97e@SEAMBX01.sea.samsung.com> To: Barry Leiba MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jayantheesh S B , "imapapnd-chairs@ietf.org" , SM , "imapext@ietf.org" , "draft-ietf-imapapnd-appendlimit-extension@ietf.org" Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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: Sun, 10 Jan 2016 12:56:51 -0000 Hi Barry, On 9 Jan 2016, at 22:27, Barry Leiba wrote: >> We are fine with the proposed text. We will update the draft with this >> text and release a new version (10). >=20 > Great; thanks. I'd like to hear from a couple of others to make sure > it's OK with a few more people. Alexey, SM, can the two of you weigh > in? Changes in -09 and -10 look good to me. >=20 > Barry >=20 >> -----Original Message----- >> From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of Barry Leiba >> Sent: Thursday, January 07, 2016 7:31 PM >> To: draft-ietf-imapapnd-appendlimit-extension@ietf.org; imapext@ietf.org >> Cc: imapapnd-chairs@ietf.org; The IESG; SM >> Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-ima= papnd-appendlimit-extension-08: (with COMMENT) >>=20 >> Authors and working group: >> In light of this discussion, I suggest that we replace the content of the= Security Considerations section with this: >>=20 >> NEW >> This extension provides additional information that cooperative >> clients can use as an optimization, and does not introduce new >> security concerns. This extension does not address abusive clients >> that intend to consume server resources, and servers will still have >> to take action to disconnect and/or restrict access to clients that >> exhibit abusive behavior. >> END >>=20 >> Please comment, and if there are no objections, please make the change in= another revision. Thanks. >>=20 >> Barry >>=20 >>> On Thu, Jan 7, 2016 at 9:32 AM, Kathleen Moriarty wrote: >>> I was just suggesting that you could cut out the scenario, leave the >>> last sentence and say it's because of a possible attack on resources, >>> 'resources' being a short way of describing the scenario laid out. If >>> some other attack comes out that is mitigated in a similar way that >>> uses 'resources' in another way, you are covered. It also gets rid of >>> the extra text that I don't see as necessary. But leave it if you >>> think it's fine. >>=20 >> _______________________________________________ >> imapext mailing list >> imapext@ietf.org >> https://www.ietf.org/mailman/listinfo/imapext >>=20 >=20 > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From nobody Sun Jan 10 07:46:09 2016 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 39E4F1ACDE7; Sun, 10 Jan 2016 07:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=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 WU-qrOdJb51F; Sun, 10 Jan 2016 07:46:06 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 889E61ACDDF; Sun, 10 Jan 2016 07:46:05 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.227.83.74]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u0AFjcp7000632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jan 2016 07:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452440752; x=1452527152; bh=tp8fHwG8kmE3f9M1p5Qcr5JSoQca1RAzSqhY3t3WJng=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uXqkb6KYCft4QLxF4oqcZOfQS3aqTKQklaPPJ7lQGrn4f/pD8j5s2nlVZhfy4sVSs lkFHKnzklrJnSNS4zziaHQe6PwZ3xVo4TJzIYSHf5Z88kmMsw2s0Apbq1dKWFtvYao rcBapeXbt2qo3oxfCWyHDnxTCk6XTUFxUgv3lbYA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452440752; x=1452527152; i=@elandsys.com; bh=tp8fHwG8kmE3f9M1p5Qcr5JSoQca1RAzSqhY3t3WJng=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NiJ72rd9rLie25XoJUuvW728p+FXx7B0sBi1ygSxnF2y+2OySa3FORuqqT2j8cr2T oonK0GDkNXQw063BpLYy5hKKOmRUKkMfGT+2KM2YoOPeruqM0KOsAZVKOEudWaqhqr WmePkTqSJxZ+QgtSUis6GtZq+PBaoinc9asc03b4= Message-Id: <6.2.5.6.2.20160110073832.0e2917f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 10 Jan 2016 07:45:33 -0800 To: Barry Leiba , Jayantheesh S B From: S Moonesamy In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> <93bb56db92e5406c910d0e947b3cf97e@SEAMBX01.sea.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, imapapnd-chairs@ietf.org Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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: Sun, 10 Jan 2016 15:46:07 -0000 Hi Barry, At 14:27 09-01-2016, Barry Leiba wrote: >Great; thanks. I'd like to hear from a couple of others to make sure >it's OK with a few more people. Alexey, SM, can the two of you weigh >in? The first sentence in Section 6 (draft-ietf-imapapnd-appendlimit-extension-10) mentions that the extention does not introduce new security concerns. The second sentence is about clients which exhibit abusive behaviour. The text looks fine. Regards, S. Moonesamy From nobody Sun Jan 10 09:18:42 2016 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 5E63E1ACE49; Sun, 10 Jan 2016 09:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 5eUS1rmXzaLn; Sun, 10 Jan 2016 09:18:39 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 836021ACE0B; Sun, 10 Jan 2016 09:18:39 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id z14so87230279igp.1; Sun, 10 Jan 2016 09:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xjA2It15BMUyApG24qR2qqN3FLlanTZKu/I59R3MWVU=; b=Gws764njjODzhYUHWR9qaK8tBmm/lW3KKNlz3PHyWCvTy2lxyyfnx90iofDpztlF5L tQVuhLvSxPrcifS3/MNl4yv0Mizrl5T7HQ6NLep4+RLJUQWUei6pmVOJeiH40oJztFbw L2cvY+iXZXEtHrHtRT7uOoNkrEU+x8ybWtSBgG3KSrA9jjL/59n+uUdXkOU7BnUasBeC Fq0NycaFHz5s06zLTgSfR8oQ6U9ASQ921k5BTySk1KEnBqRnPqAxh+FfVdybay6y+g3M 9HcNNgBv24QeL5n6/cTv3XzK3ezUFvWzHe5TaKgggNJb2rEyLX2K3WHeXkjYK7XlWuo+ KifQ== MIME-Version: 1.0 X-Received: by 10.50.138.11 with SMTP id qm11mr8908010igb.53.1452446318905; Sun, 10 Jan 2016 09:18:38 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.83 with HTTP; Sun, 10 Jan 2016 09:18:38 -0800 (PST) In-Reply-To: <6.2.5.6.2.20160110073832.0e2917f0@elandnews.com> References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> <93bb56db92e5406c910d0e947b3cf97e@SEAMBX01.sea.samsung.com> <6.2.5.6.2.20160110073832.0e2917f0@elandnews.com> Date: Sun, 10 Jan 2016 12:18:38 -0500 X-Google-Sender-Auth: syEJwoPiWeoyt3_I6R5KeYRGtuE Message-ID: From: Barry Leiba To: S Moonesamy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jayantheesh S B , imapapnd-chairs@ietf.org, "imapext@ietf.org" , draft-ietf-imapapnd-appendlimit-extension@ietf.org Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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: Sun, 10 Jan 2016 17:18:40 -0000 > The first sentence in Section 6 > (draft-ietf-imapapnd-appendlimit-extension-10) mentions that the extention > does not introduce new security concerns. The second sentence is about > clients which exhibit abusive behaviour. Yes: the first sentence says that this extension is about cooperative clients. The second sentence says that it does nothing with respect to abusive clients, and that servers still have to deal with that. Are you saying that you think that's unclear and needs a few more words? > The text looks fine. Kewl. b From nobody Sun Jan 10 09:26:56 2016 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 B67441ACE12; Sun, 10 Jan 2016 09:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=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 FP5moNPRxQZh; Sun, 10 Jan 2016 09:26:52 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7E41ACE3D; Sun, 10 Jan 2016 09:26:51 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.227.83.74]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u0AHQG21005109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jan 2016 09:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452446800; x=1452533200; bh=JbN+o2ijKYd+uVyBjv67Ff9d59UgLGRPLAbj2W1B+og=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TxBY9plWd1xp3byFjvymlCDaslMZTdL3Dxx7XnspbE403Lya5vvBXkZP9uwZeYk6u KAsRCMtr35reElP65pGsA760CKeXCQNToU+oC517A2qfLIhK2lf3X5opg3wTzsnccW 0MiSFHI3+pwMhDmo3QZ6EE89LfGVI2qQS0LD67Eo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452446800; x=1452533200; i=@elandsys.com; bh=JbN+o2ijKYd+uVyBjv67Ff9d59UgLGRPLAbj2W1B+og=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yu8YOnXHsiQiGkKSb7BruR2yntgJno4B9sznUTJ8c4Dpt3XR0+k0zF20A3NyMy6Ni cY+IwHqcXdyWqfl1C50ZDkW99PLhnv7Kl5N0N/STsEkk6o4yGw2zvnE6d0cM/h3geq gaRr806lgMdQPsAjR890O4kilLTxNmlmnZIKJdWw= Message-Id: <6.2.5.6.2.20160110092036.0ccb9008@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 10 Jan 2016 09:23:48 -0800 To: Barry Leiba From: S Moonesamy In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> <93bb56db92e5406c910d0e947b3cf97e@SEAMBX01.sea.samsung.com> <6.2.5.6.2.20160110073832.0e2917f0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: Jayantheesh S B , imapapnd-chairs@ietf.org, imapext@ietf.org, draft-ietf-imapapnd-appendlimit-extension@ietf.org Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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: Sun, 10 Jan 2016 17:26:54 -0000 Hi Barry, At 09:18 10-01-2016, Barry Leiba wrote: >Yes: the first sentence says that this extension is about cooperative >clients. The second sentence says that it does nothing with respect >to abusive clients, and that servers still have to deal with that. >Are you saying that you think that's unclear and needs a few more >words? Sorry, I should have been clear. I explained what I understood on reading the text and concluded that it is fine. I don't think that more words are needed. Regards, S. Moonesamy From nobody Sun Jan 10 09:28:51 2016 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 3EF641ACE3D; Sun, 10 Jan 2016 09:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=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 fQfoT0xSDQi6; Sun, 10 Jan 2016 09:28:49 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 815241ACE12; Sun, 10 Jan 2016 09:28:49 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.227.83.74]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u0AHO9LE004417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jan 2016 09:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452446926; x=1452533326; bh=JbN+o2ijKYd+uVyBjv67Ff9d59UgLGRPLAbj2W1B+og=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OyfB0zQSH29h26dmHNyHfIt/dBGCeQ1dI2isbt+ANlJTapqVn4jvhbokG5GrRGzuy vMeFFIbQzLd3kQq7/w9939VEcVL28h1t6zYdH+2hQOsdpDee9/SO3IN9kBhvMatHp1 3RgzfDvF2K37mqcrQT276yeabkTENXAfZNdeuKuQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452446926; x=1452533326; i=@elandsys.com; bh=JbN+o2ijKYd+uVyBjv67Ff9d59UgLGRPLAbj2W1B+og=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Gq3QhWZShh4GAca6Lwvu6CjTZe3dEspBgd+7Pbsfl8vuUZ6xeQIKVqlm6lEx8g/4R AFge68jOlPNlAyfJ8BKa6dbWYfKddyW78Vt+RItETk9k8DC8lJWbmvkOJ7yAeaRFfw j8REWx1dwZD/0oXDlUk/hByHGiFGsfBvfSwKT+6c= Message-Id: <6.2.5.6.2.20160110092036.0ccb9008@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 10 Jan 2016 09:23:48 -0800 To: Barry Leiba From: S Moonesamy In-Reply-To: References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> <93bb56db92e5406c910d0e947b3cf97e@SEAMBX01.sea.samsung.com> <6.2.5.6.2.20160110073832.0e2917f0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: Jayantheesh S B , imapapnd-chairs@ietf.org, imapext@ietf.org, draft-ietf-imapapnd-appendlimit-extension@ietf.org Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT) 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: Sun, 10 Jan 2016 17:28:50 -0000 Hi Barry, At 09:18 10-01-2016, Barry Leiba wrote: >Yes: the first sentence says that this extension is about cooperative >clients. The second sentence says that it does nothing with respect >to abusive clients, and that servers still have to deal with that. >Are you saying that you think that's unclear and needs a few more >words? Sorry, I should have been clear. I explained what I understood on reading the text and concluded that it is fine. I don't think that more words are needed. Regards, S. Moonesamy From nobody Tue Jan 19 08:05:30 2016 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 240811B312B for ; Tue, 19 Jan 2016 08:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_45=0.6, 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 FpOZwZvESShI for ; Tue, 19 Jan 2016 08:05:26 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 6D3B81B3122 for ; Tue, 19 Jan 2016 08:05:26 -0800 (PST) Received: by mail-pa0-x22f.google.com with SMTP id yy13so360808897pab.3 for ; Tue, 19 Jan 2016 08:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=we8hCY2NI5MCwNmUYE+nVvTtLhK/3MZtN3ZvBP2/Vog=; b=YFEqdjA24KNxR68YDjqHJVMrmMOKTsU9DG0jo0YU728inxpazLGsfHNS17v+mZFDKY ohAF9V3/j5xet1rinin3EnJkVhdDy5IMpC+HLU6USPYD5zgeKiPTC1rD/TMvKfSs5lad Uza9LGYhfGMt/zidWA5rkiybnw6PyNzqdRWPUwnFWcyWt6TRj2k1EzBQxD2xktNdOOFf JEPQgBnN1jB8t/FoF8sT8WydrvYU2I61ditfjNRk8TswE3pZRTtd9E2xycL3j88ZIImZ ebt+2ysSRRlZYG/G1bBtTVjj5bDIAt4vqAIMZL3ZkG1qZAi2FDhGnm8MC4G2kF8UNz5V 2Xvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=we8hCY2NI5MCwNmUYE+nVvTtLhK/3MZtN3ZvBP2/Vog=; b=Gws8rCNQWhyTnKRtnB1HxkEVAwb733z0tAubJfh6Kc5fSjKcylqwo9xL9pzhJIbpeq MPFIGVCfNfSjEjVmF2AWyw4jOpaEF7VwsAblj9VpXsBQN8avIL7/7Hf0+EsRS61DWX/j rJTiPYujuzINHTvhBuC4dP8+F3iYLTW4t5BFy0qvennb5FcKFMWC5p9EluozmzrRHZSH RMfzMGg+tWgnM26wmmID1rhKV1Pojz1C6x5Z8RN8YZ6x+0HrPO2jJVfOsxuvDUgcGFkr TzfMmZZt3+jBd7imvhvbi1PAN5L/pcfWqFe4JmjSK3l2Myo6Osky+md7DtPP9sxEWVm3 dzAA== X-Gm-Message-State: ALoCoQm9G2W5iUOeX7grm9c2x9TqTccYlcgxI81tDV0nP7oxEQ6996icDC7x9qDaNmbRgNsycDoJ+njNzY8ELqJfht1DaiTJZR59sXBnon0zdT1N+Ud6ZJeColR+60b9DMfKn8K7BNPYOCn/FyRhQs9L9dpeWH1N9MuzGHs6wW5keIWqqKOKEjodELM3Rn0T8TCKzH8IGW0E X-Received: by 10.67.1.102 with SMTP id bf6mr45576536pad.103.1453219526069; Tue, 19 Jan 2016 08:05:26 -0800 (PST) Received: from [10.172.161.177] ([64.236.138.3]) by smtp.gmail.com with ESMTPSA id sv8sm42832978pab.13.2016.01.19.08.05.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jan 2016 08:05:25 -0800 (PST) To: "'imapext@ietf.org'" From: Stu Brandt Message-ID: <569E5EC3.3070500@teamaol.com> Date: Tue, 19 Jan 2016 11:05:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [imapext] IMAP Replace update (02) 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, 19 Jan 2016 16:05:30 -0000 Based on some discussion off list, draft-brandt-imap-replace-02 has been submitted. It attempts to add clarity around use cases where the selected mailbox and the mailbox specified as command argument could vary. Here it is: ------------------------------------------------------------------------ Network Working Group S. Brandt Internet-Draft AOL Intended status: Standards Track January 19, 2016 Expires: July 22, 2016 IMAP REPLACE Extension draft-brandt-imap-replace-02 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 replacement 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 July 22, 2016. Copyright Notice Copyright (c) 2016 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 July 22, 2016 [Page 1] Internet-Draft IMAP REPLACE Extension January 2016 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 . . . . . . . . . . . . . . 6 4.1. RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . . 6 4.2. RFC 4469, CATENATE . . . . . . . . . . . . . . . . . . . 6 4.3. RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . . 8 4.4. RFC 6785, IMAP Events in Sieve . . . . . . . . . . . . . 8 4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 8 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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. Since there is no replace function in the base IMAP specification, clients have instead had to use a combination of three separate commands issued in serial fashion; APPEND, STORE, EXPUNGE. Pipelining of these three commands is not recommended since failure Brandt Expires July 22, 2016 [Page 2] Internet-Draft IMAP REPLACE Extension January 2016 of any individual command should prevent subsequent commands from being executed lest the original message version be lost. 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 a single-command encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a message, except that it avoids any of the quota implications or intermediate states associated with the 3 command sequence. In handling a REPLACE command, a server MUST NOT generate a response code for the STORE +flags \DELETED portion of the sequence. Additionally, servers supporting the REPLACE command MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced. Finally, the replaced and replacing messages SHOULD NOT be present in the mailbox at the same time. 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 July 22, 2016 [Page 3] Internet-Draft IMAP REPLACE Extension January 2016 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 July 22, 2016 [Page 4] Internet-Draft IMAP REPLACE Extension January 2016 selected mailbox. These operations will appear to the client as a single action. This has the same effect as the following sequence: 1. APPEND 2. [UID] STORE +FLAGS.SILENT \DELETED 3. UID EXPUNGE In the cited sequence, the quota implications of the APPEND are evaluated within the context of the pending EXPUNGE so that only the net quota consumption is considered. 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 state; any untagged EXPUNGE response MUST NOT be sent until all actions are successfully completed. While it may be common for the named mailbox argument to match the selected mailbox for the common use case of replacing a draft, the REPLACE extension intentionally does not require the two to be the same. As an example, it's possible to use the REPLACE command to replace a message in the \Drafts special-use mailbox with a message in the \Sent special-use mailbox following message submission. 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 and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. Brandt Expires July 22, 2016 [Page 5] Internet-Draft IMAP REPLACE Extension January 2016 4. Interaction with other extensions This section describes how REPLACE interacts with some other IMAP extensions. 4.1. RFC 4314, ACL The ACL rights [RFC4314] required for UID REPLACE are the union of the ACL rights required for UID STORE and UID EXPUNGE in the current mailbox, and APPEND in the target mailbox. 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. When combined with CATENATE, REPLACE can become a quite efficient way for message manipulation. Brandt Expires July 22, 2016 [Page 6] Internet-Draft IMAP REPLACE Extension January 2016 Example: User composes message and attaches photo ---------------------------------------- C: A010 APPEND Drafts (\Seen \Draft) {1201534} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST) C: From: Fritz Schmidt C: Message-ID: C: MIME-Version: 1.0 C: Content-Type: multipart/mixed; C: boundary="------------030305060306060609050804" C: C: --------------030305060306060609050804 C: Content-Type: text/plain; charset=utf-8; format=flowed C: Content-Transfer-Encoding: 7bit C: C: Here is picture from the fireworks C: C: Yours... C: Fritz C: C: --------------030305060306060609050804 C: Content-Type: image/jpeg; C: name="Fireworks.jpg" C: Content-Transfer-Encoding: base64 C: Content-Disposition: attachment; C: filename="Fireworks.jpg" C: C: C: --------------030305060306060609050804-- S: A010 OK [APPENDUID 1 3002] APPEND complete User completes message with To: and Subject: fields --------------------------------------------------- C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71} S: + Ready for literal data C: To: Mitzy C: Subject: My view of the fireworks C: URL "/Drafts/;UID=3002") S: * 5 EXISTS S: * 4 EXPUNGE S: A011 OK [APPENDUID 1 3003] REPLACE completed Brandt Expires July 22, 2016 [Page 7] Internet-Draft IMAP REPLACE Extension January 2016 4.3. RFC 4315, UIDPLUS Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send APPENDUID in response to a UID REPLACE command. For additional information see section 3 of RFC4315. Servers implementing REPLACE and UIDPLUS are also advised to send the APPENDUID response code in an untagged OK before sending the EXPUNGE or replaced responses. (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS specification means that the client first receives an EXPUNGE for a message and afterwards APPENDUID for the new message. It can be unnecessarily difficult to process that sequence usefully.) 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. capability =/ "REPLACE" command-select =/ replace replace = "REPLACE" SP seq-number SP mailbox append-message uid = "UID" SP (copy / fetch/ search / store / move / replace) Brandt Expires July 22, 2016 [Page 8] Internet-Draft IMAP REPLACE Extension January 2016 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 The author would like to thank the participants of IMAPEXT with particular thanks to Arnt Gulbrandsen, Alexey Melkinov, and Chris Newman for their specific contributions. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005, . [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, December 2005, . [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, . [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 2006, . Brandt Expires July 22, 2016 [Page 9] Internet-Draft IMAP REPLACE Extension January 2016 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6785] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, November 2012, . [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", RFC 7162, DOI 10.17487/RFC7162, May 2014, . 9.2. Informative References [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, . Author's Address Stuart Brandt AOL 43623 Preddy Ct Ashburn, VA 20147 USA Email: stujenerin@aol.com Brandt Expires July 22, 2016 [Page 10] From nobody Mon Jan 25 09:31:51 2016 Return-Path: X-Original-To: imapext@ietf.org Delivered-To: imapext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 597A91B3780; Mon, 25 Jan 2016 09:31:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160125173146.19747.76574.idtracker@ietfa.amsl.com> Date: Mon, 25 Jan 2016 09:31:46 -0800 Archived-At: Cc: imapapnd-chairs@ietf.org, barryleiba@gmail.com, S Moonesamy , draft-ietf-imapapnd-appendlimit-extension@ietf.org, The IESG , imapext@ietf.org, rfc-editor@rfc-editor.org Subject: [imapext] Protocol Action: 'The IMAP APPENDLIMIT Extension' to Proposed Standard (draft-ietf-imapapnd-appendlimit-extension-10.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 17:31:46 -0000 The IESG has approved the following document: - 'The IMAP APPENDLIMIT Extension' (draft-ietf-imapapnd-appendlimit-extension-10.txt) as Proposed Standard This document is the product of the IMAP APPEND Extensions Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ Technical Summary The document defines an extension to the IMAP service whereby a server can advertise its capability to support maximum mail upload size using CAPABILITY, STATUS, and LIST commands. The type of RFC being requested is Proposed Standard as the draft defines a protocol that will have to be supported on by an IMAP client and an IMAP server. Review and Consensus The document was reviewed by the Imapapnd Working Group. There was a small number of participants interested in the draft. There is at least one implementation of this, but some participants are skeptical about broad acceptance, as this extension addresses an issue that is not commonly much of a problem. Although the document addresses that in Section 1, it did not convince part of the working group. The WG consensus on this extension can be described as rough, even though there wasn't any noteworthy controversy. Personnel S. Moonesamy is the Document Shepherd for this document. Barry Leiba is the Responsible Area Director. From nobody Thu Jan 28 13:03:06 2016 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 0FF411AD2F6 for ; Thu, 28 Jan 2016 13:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 D9muGLpV0E2N for ; Thu, 28 Jan 2016 13:03:02 -0800 (PST) Received: from wguard01.sdsamerica.net (mx1.sdsamerica.net [206.67.236.191]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9051AD0CF for ; Thu, 28 Jan 2016 13:03:02 -0800 (PST) From: Jayantheesh S B To: "imapext@ietf.org" , "alexey.melnikov@isode.com" Thread-Topic: [imapext] IMAP4 non-synchronizing literals - draft-ietf-imapapnd-rfc2088bis-01 Thread-Index: AQHRLsKj0Pxv6ogMSk2DrJiIfWLUUZ7BlBAAgAA67ICAT/B+UA== Date: Thu, 28 Jan 2016 21:02:58 +0000 Message-ID: <32632fae99ba42028794d611b8e31b41@SEAMBX01.sea.samsung.com> References: <6.2.5.6.2.20151204031930.103a4fd0@elandnews.com> <5666FA20.3060308@isode.com> <56672B8D.5010609@teamaol.com> In-Reply-To: <56672B8D.5010609@teamaol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_32632fae99ba42028794d611b8e31b41SEAMBX01seasamsungcom_" MIME-Version: 1.0 Received-SPF: none Archived-At: Cc: "S Moonesamy \(sm+ietf@elandsys.com\)" Subject: Re: [imapext] IMAP4 non-synchronizing literals - draft-ietf-imapapnd-rfc2088bis-01 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, 28 Jan 2016 21:03:05 -0000 --_000_32632fae99ba42028794d611b8e31b41SEAMBX01seasamsungcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alexey, I agree with not to restrict this with only APPEND command. All, Kindly share your review comments for this draft-ietf-imapapnd-rfc2088bis-0= 1. Regards, Jay From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of Stu Brandt Sent: Tuesday, December 08, 2015 2:12 PM To: imapext@ietf.org Subject: Re: [imapext] IMAP4 non-synchronizing literals - draft-ietf-imapap= nd-rfc2088bis-01 Alexey - I agree with Jamie...restricting to just APPEND (and MULTIAPPEND, and CATEN= ATE) seems unnecessary. Thinking of potential new extensions (e.g. REPLAC= E), there could likely be additional cases where the motivation for LITERAL= - applies. - Stu On 12/8/15 10:41 AM, Alexey Melnikov wrote: On 04/12/2015 18:35, Jamie Nicolson wrote: Apologies if this was discussed before, but why limit the LITERAL- size res= triction to APPEND? Why not just make it apply to all commands: any literal= > 4KB must be sent as a synchronizing literal. This might be easier for cl= ients and servers to implement, so that the code for processing literals do= esn't need to know which command it belongs to. The impact on other command= s would be very limited, since they will almost never need to send a litera= l that large. I personally don't mind if it applies to all commands. Other thoughts? On Fri, Dec 4, 2015 at 3:25 AM, S Moonesamy > wrote: Hello, The second draft on our charter about "IMAP4 non-synchronizing literals" [1= ]. Could the working group please review draft-ietf-imapapnd-rfc2088bis-01= and send comments to the mailing list? Regards, S. Moonesamy (as imapapdb WG Chair) 1. https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-01 _______________________________________________ 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 --_000_32632fae99ba42028794d611b8e31b41SEAMBX01seasamsungcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alexey,

 <= /p>

I agree with not to restr= ict this with only APPEND command.

 <= /p>

All,

 <= /p>

Kindly share your review = comments for this draft-ietf-imapapnd-rfc2088bis-01.

 <= /p>

Regards,

Jay

From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of Stu Brandt
Sent: Tuesday, December 08, 2015 2:12 PM
To: imapext@ietf.org
Subject: Re: [imapext] IMAP4 non-synchronizing literals - draft-ietf= -imapapnd-rfc2088bis-01

 

Alexey -

I agree with Jamie...restricting to just APPEND (and MULTIAPPEND, and CATEN= ATE) seems unnecessary.   Thinking of potential new extensions (e= .g. REPLACE), there could likely be additional cases where the motivation f= or LITERAL- applies.

- Stu

On 12/8/15 10:41 AM, Alexey Melnikov wrote:

On 04/12/2015 18:35, Jamie Nicolson wrote:

Apologies if this was discussed before, but why limi= t the LITERAL- size restriction to APPEND? Why not just make it apply to al= l commands: any literal > 4KB must be sent as a synchronizing literal. T= his might be easier for clients and servers to implement, so that the code for processing literals doesn't need to kno= w which command it belongs to. The impact on other commands would be very l= imited, since they will almost never need to send a literal that large.

I personally don't mind if it applies to all command= s. Other thoughts?

 

On Fri, Dec 4, 2015 at 3:25 AM, S Moonesamy <sm+ietf@eland= sys.com> wrote:

Hello,

The second draft on our charter about "IMAP4 non-synchronizing literal= s" [1].  Could the working group please review draft-ietf-imapapn= d-rfc2088bis-01 and send comments to the mailing list?

Regards,
S. Moonesamy (as imapapdb WG Chair)

1. https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-01

_______________________________________________
imapext mailing list
imapext@ietf.org<= br> 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

 

--_000_32632fae99ba42028794d611b8e31b41SEAMBX01seasamsungcom_--