From nobody Thu Jan 3 19:37:58 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF6E130F06; Thu, 3 Jan 2019 19:37:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bron Gondwana To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Cc: extra@ietf.org, brong@fastmailteam.com, Bron Gondwana , iesg-secretary@ietf.org, extra-chairs@ietf.org Message-ID: <154657307701.29566.11297110328897092709.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2019 19:37:57 -0800 Archived-At: Subject: [Extra] Publication has been requested for draft-ietf-extra-imap-fetch-preview-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 03:37:57 -0000 Bron Gondwana has requested publication of draft-ietf-extra-imap-fetch-preview-00 as Proposed Standard on behalf of the EXTRA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ From nobody Fri Jan 4 11:58:44 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5945D130E85; Fri, 4 Jan 2019 11:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GiyUurza4Q2r; Fri, 4 Jan 2019 11:58:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7004F130E8E; Fri, 4 Jan 2019 11:58:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7C933B81AAE; Fri, 4 Jan 2019 11:58:30 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, extra@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190104195830.7C933B81AAE@rfc-editor.org> Date: Fri, 4 Jan 2019 11:58:30 -0800 (PST) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8508_on_IMAP_REPLACE_Extension?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 19:58:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8508 Title: IMAP REPLACE Extension Author: S. Brandt Status: Standards Track Stream: IETF Date: January 2019 Mailbox: stujenerin@aol.com Pages: 11 Characters: 21984 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-extra-imap-replace-03.txt URL: https://www.rfc-editor.org/info/rfc8508 DOI: 10.17487/RFC8508 This document defines an IMAP extension that 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. This document is a product of the Email mailstore and eXtensions To Revise or Amend Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jan 4 11:59:15 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8CD130EAF; Fri, 4 Jan 2019 11:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0LY3udcFK42H; Fri, 4 Jan 2019 11:58:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98FA130EC2; Fri, 4 Jan 2019 11:58:57 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8FB62B81ABA; Fri, 4 Jan 2019 11:58:48 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, extra@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190104195848.8FB62B81ABA@rfc-editor.org> Date: Fri, 4 Jan 2019 11:58:48 -0800 (PST) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8514_on_Internet_Message_Access_Protocol_?= =?utf-8?q?=28IMAP=29_-_SAVEDATE_Extension?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 19:59:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8514 Title: Internet Message Access Protocol (IMAP) - SAVEDATE Extension Author: S. Bosch Status: Standards Track Stream: IETF Date: January 2019 Mailbox: stephan.bosch@open-xchange.com Pages: 7 Characters: 13176 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-extra-imap-savedate-01.txt URL: https://www.rfc-editor.org/info/rfc8514 DOI: 10.17487/RFC8514 This document adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP). It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends the FETCH command with the means to retrieve the save date attribute and extends the SEARCH command to allow using the save date attribute in searching criteria. This document is a product of the Email mailstore and eXtensions To Revise or Amend Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jan 4 14:08:33 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2283B126BED for ; Fri, 4 Jan 2019 14:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=rMYxvl6U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eFYIlVRr 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 HrDLeHCWk6DU for ; Fri, 4 Jan 2019 14:08:31 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CC81271FF for ; Fri, 4 Jan 2019 14:08:30 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B5A5420F20 for ; Fri, 4 Jan 2019 17:08:29 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 04 Jan 2019 17:08:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=/1Q/ZrsWSbN7lbWWIm7vpAn6lJSaBubDbOTcw+h Nt0Y=; b=rMYxvl6Ukor3oDvR18Asugd29dKObdLktf6+bK4bzbzSdTGrhXluSh7 372GdJq9ulw1UuI2tggCZvdW0+9q2YnrX1/nfsbVTOqRYBaaMmIQjnaGm1xH5d0Z 2EdDNgmgBq8ScNU2HoPFJgOpHFazDypvkZ0LDgOjBPzIRTrStrJ+gWlezl8SKraN aiqZ0P/TL1N0xGXtYVQINcxFkOyQHwo7uiT5Jc+K9Sa22yffuasC3h6/I5OpFK+r NyVHMKvG6auxVtDu8BJhUluKy8MJQDm+DbaJAwS8vo8p7LE+7AOvEN7d7s4/ouls AFj5kmNMrgd0o/FZq6FuLdUMcPHZ2Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=/1Q/ZrsWSbN7lbWWIm7vpAn6lJSaBubDbOTcw+hNt0Y=; b=eFYIlVRr yA831zOCDduf63eDz+WRwUdGgk/BLaG++ClPrgoAOSjtJZm3FMFRcVKc+eLUST34 70y9kpnwVebIns71pbCBxhOukPXEVsfN4XQYqBTUPYaB54lzhqAsCqOd1bI8qYzZ fHQTJ3hXFnULeuYxXUMeznuzBR4H5eY1+LvgdhUzGgOaj9y39F5tDF/dSSwTgkpK 0KchuMO6/HWWYRwLT8tKVGdzQgqU8a0Ixr/KU+f1q6PqfsyH+iTM2MXUWxHwWua4 H0MH1a6g33skb2BUHxV8aUXc3q04Cs4TqUOcDmoPqw8LlRMBOFg9zylEuVkrYEfK pfsfPQBQD1AgNA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvddugdduiedtucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsghroh hnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6F277203BE; Fri, 4 Jan 2019 17:08:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: <30fe2af6-6c17-4d96-9714-337123bd35ee@www.fastmail.com> Date: Fri, 04 Jan 2019 17:08:27 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=ddb15ee601794c639346e295ae6603fa Archived-At: Subject: [Extra] Two RFCs on the same day! X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 22:08:32 -0000 --ddb15ee601794c639346e295ae6603fa Content-Type: text/plain Congratulations Stuart and Stephan on publication! I've submitted fetch-preview for publication as well, so we're down to just IMAP4rev2 left to work on right now :) (I may also round out the message actions RFCs by writing up a DESTROY draft at some point. It's basically just a REPLACE with no new message!) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --ddb15ee601794c639346e295ae6603fa Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Congratulations Stuart and Stephan on publication!

I've submitted fetch-preview for publication as well, so we're d= own to just IMAP4rev2 left to work on right now :)

(I may = also round out the message actions RFCs by writing up a DESTROY draft at= some point.  It's basically just a REPLACE with no new message!)

Cheers,

Bro= n.

--
&n= bsp; Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

=

--ddb15ee601794c639346e295ae6603fa-- From nobody Sun Jan 6 14:13:00 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF5712D4ED; Sun, 6 Jan 2019 14:12:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154681277828.16929.18247897769470424327.idtracker@ietfa.amsl.com> Date: Sun, 06 Jan 2019 14:12:58 -0800 Archived-At: Subject: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 22:12:58 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-extra-sieve-fcc-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-extra-sieve-fcc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3898 IMPORTANT S 3. > copy of the generated message into the mailbox provided in the > subsequent argument. The syntax and semantics of the mailbox > argument MUST match those of the mailbox argument to the "fileinto" > action specified in Section 4.1 of [RFC5228]. If the specified > mailbox doesn't exist, the implementation MUST file the message into > the user's main mailbox (e.g. IMAP "INBOX"). This seems to sort of conflict with S 3.1.1. I assume that the logic is: if (!exists && :create) { try_to_create() }; if (!exists) { file_in_inbox()} else { file_in_fcc_mailbox()}, but this text isn't celar. COMMENTS S 1. > > The capability string associated with this extension is "fcc". > > Each action that generates additional messages will need to specify > how it interfacts with :fcc. This document specifies the interaction > of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions. Are these the only such actions? From nobody Mon Jan 7 05:15:39 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A51E6130E0A; Mon, 7 Jan 2019 05:15:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154686693163.23232.15216204981970430299.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2019 05:15:31 -0800 Archived-At: Subject: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-sieve-fcc-08=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 13:15:32 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-extra-sieve-fcc-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-extra-sieve-fcc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also have a minor comment on this sentence: "If the specified mailbox doesn't exist, the implementation MUST file the message into the user's main mailbox (e.g. IMAP "INBOX")." Beside the conflict Ekr mentioned, I'm wondering why this is a MUST. I guess the other option would be to not copy it anywhere (and file an error message to the user). I'm not an expert on mail at all but as a user I would find it confusing to find such messages in my INBOX. However, if there is a good reason that it must be ensured that such a message is stored, I guess that's the only viable default option. From nobody Mon Jan 7 10:27:07 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BE412785F; Mon, 7 Jan 2019 10:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 WgmmRlpeNk96; Mon, 7 Jan 2019 10:27:04 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3841112426E; Mon, 7 Jan 2019 10:27:04 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1Q6T4PHGW00DH2Z@mauve.mrochek.com>; Mon, 7 Jan 2019 10:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546885319; bh=iS9Z5TbpEkWfqy61iT1oZ4t/ys8hpD7E9pNDwkQuCjQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=R4wCYFpLzE/JguUCNO+aA+DoMYqXJvVU1GKwm0sm6FSSRThZZNHbr7msjrvVsB6ag zVBZssZpkmSvwvhxJRLxsHZ64X93/0LAxJZRMwc32lwKZAWU5wv9WxkUXyTCuimKnn Gh/8LaM4Y3hDbJH/bvuHgC8T1zptWjmEBrjYqoRo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Mon, 7 Jan 2019 10:21:54 -0800 (PST) Cc: The IESG , extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, extra-chairs@ietf.org Message-id: <01R1Q6T33BRA00004L@mauve.mrochek.com> Date: Mon, 07 Jan 2019 09:08:11 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 07 Jan 2019 05:15:31 -0800" <154686693163.23232.15216204981970430299.idtracker@ietfa.amsl.com> References: <154686693163.23232.15216204981970430299.idtracker@ietfa.amsl.com> To: =?utf-8?q?Mirja_K=C3=BChlewind?= Archived-At: Subject: Re: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-sieve-fcc-08=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 18:27:06 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I also have a minor comment on this sentence: > "If the specified > mailbox doesn't exist, the implementation MUST file the message into > the user's main mailbox (e.g. IMAP "INBOX")." > Beside the conflict Ekr mentioned, I'm wondering why this is a MUST. An argument can be made for a SHOULD. But some compliance language is in order here. > I guess > the other option would be to not copy it anywhere (and file an error message to > the user). First, let's be clear on who the "user" is here. The entities involved are (a) the original message sender, (b) the original message recipient/sieve owner, and (c) the recipient of the newly generated message we're making a copy of. (a) and (c) may be the same (in the case of vacation) or different (in the case of notify). Reporting this sort of problem to the original message sender in all cases is not only nonsensical, it's a privacy violation - the original sender has no business seeing the notifications their message caused to be sent. So (a) is out. (c) is also nonsensical - the person receiving the notification neither knows nor should be aware of additional copies made by the notification sender. That leaves (b) - and given this is an :fcc the only place we are sure to have for this error message to go is the sieve owner's mailbox. That means an error report is going to take the form of another email message. So we're talking about someone receiving a message (in their INBOX) reporting a problem delivering a notification message regarding yet another message to some folder. Dunno about you, but that certainly confuses me. And not to seem immodest, but if it confuses me, I think it will confuse most people a lot more than simply recieving the notification in the wrong place. This is actually just a specific case of the more general rule that it's a bad idea to have notifications generate notifications. We require the messages generated by vacation and notify to have an empty MAIL FROM, meaning failure to deliver those messages will not generate an error. I don't see a good argument for deviating from this practive in this case. > I'm not an expert on mail at all but as a user I would find it > confusing to find such messages in my INBOX. However, if there is a good reason > that it must be ensured that such a message is stored, I guess that's the only > viable default option. Since the only other option is for this notification copy to silently disappear, and presumably the person who wrote the Sieve clearly wants to keep a record of the notifications they have sent, I think this needs to at least be a SHOULD. Beyond that, we require the same fallback to INBOX behavior for Sieve fileinto, and IME it hasn't been confusing. (And yes, it does happen.) So there is precedent for this being a MUST. OTOH, we're talking about notifications, and there is also precedent for dropping them on the floor. Bottom line is I prefer a MUST but a SHOULD would be acceptable. Ned From nobody Tue Jan 8 07:59:40 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7590F130EA4; Tue, 8 Jan 2019 07:59:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-extra-sieve-special-use@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154696317840.25571.13000547897657048147.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2019 07:59:38 -0800 Archived-At: Subject: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 15:59:39 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-extra-sieve-special-use-04: 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-extra-sieve-special-use/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please use the RFC 8174 boilerplate in Section 2. From nobody Tue Jan 8 14:15:57 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D55F12D7F8; Tue, 8 Jan 2019 14:15:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-extra-sieve-special-use@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org, shwethab@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154698574945.25563.16303327118011706457.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2019 14:15:49 -0800 Archived-At: Subject: [Extra] Warren Kumari's No Objection on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 22:15:50 -0000 Warren Kumari has entered the following ballot position for draft-ietf-extra-sieve-special-use-04: 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-extra-sieve-special-use/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to shwethab@cisco.com for the OpsDir review. From nobody Wed Jan 9 01:30:42 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BF5130DED; Wed, 9 Jan 2019 01:30:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-sieve-fcc.all@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154702622280.7446.9285138848727921959@ietfa.amsl.com> Date: Wed, 09 Jan 2019 01:30:22 -0800 Archived-At: Subject: [Extra] Opsdir last call review of draft-ietf-extra-sieve-fcc-08 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 09:30:30 -0000 Reviewer: Dan Romascanu Review result: Has Issues The document extends the Sieve Email Filtering Language [RFC5228] by providing a number of action commands, some of which can generate additional messages of behalf of the user. It is a clear document, its target being developers and users of the protocol. I liked the fact that the authors included a 'Compatibility with Other Actions' section that describes the interoperability with existing deployed versions of the protocol, as well as the inclusion of a temporary section about Implementation Status. I am missing however some information about possible impact of the new action commands on deployment and operations on servers already in operation. I assume that scalability and compatibility between older and newer versions (including or not the new defined commands) were assessed, but this is not documented. Some confirmation, warnings (if any) and useful information that operators should know at deployment would be useful. I suggest that you consider adding such a paragraph or short section. From nobody Wed Jan 9 03:05:27 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD3112F1A6; Wed, 9 Jan 2019 03:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=D/OGt9hp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yarV84FO 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 f-5vz2u98nMf; Wed, 9 Jan 2019 03:05:18 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3A6130DCA; Wed, 9 Jan 2019 03:05:14 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AC2D623695; Wed, 9 Jan 2019 06:05:13 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 09 Jan 2019 06:05:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:date:references:subject; s=fm2; bh=08M v18ihZyA5kbfEz020TEC6DGWYakUuKcxFaZ2+3so=; b=D/OGt9hpEN+n2In1UR6 vv2EMz5Mh1jiJ1xXrDnIq3Q1cSDAeNcrYWrBFEFd9RgbVMF3mYtlWKRgc4CbEOQI RMXr4wE2hO73BjuFiFuzeE3PebW5Gd2WdB5w5s94vuQadpI1ljcIodlBTJVNs2xe 44pDGuBAltgyW2nKjpdbhio6QUJ1KBXWRB9P4RLnS6WaMr1z2bw7TDQdSt+zWr1h gGNvlT7tEHXXFLhixy1NHDptOor7R2mgQ6dJtme7qkgkM2CbQpUSdxjqbrtYYUqF 2AXHGYy0oGNYSX97BO4ive4IAI1Vx22hzLmgba9HFZ9EczA7byppFdFLlnLuScDm Q/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=08Mv18ihZyA5kbfEz020TEC6DGWYakUuKcxFaZ2+3 so=; b=yarV84FOhb8ylnir/FMAjH5RFdaX4waDgGs1qoPvF9oUzLanJxC/x+V0+ hFi2rVOQUJDUjMpSIRQmFaQUYW+qf3TnGH5Ce4K3ML8o5zyVkZoRVmS+gLLdPQQj SlKi5LIsYM5JGz84CJlbT6xa9xL3ECbeM2na0k54wMyuT+j/3xpwIGfMDRbSXHZK NaMUEFN1Ba1mmY7oVuvKnP0Gq7OOsVien52TWiXVoDnH4ctTSnJMvCpWvsG1dA7z euIAIFLbOpsW1SJTER5z1YS6WkrEdr0t9vmliU1ng7ooqGLFp1Y+6E85/le9qkQU wcksDqMam7DMOWcD0lZjyoy8iHEVw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedugddvfeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffhvfgggfgtofgjffhfufesthejredtredtjeenucfhrhhomheptehlvgig vgihucfovghlnhhikhhovhcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgr ihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 75A1E9E15D; Wed, 9 Jan 2019 06:05:13 -0500 (EST) Message-Id: <1547031913.1905154.1629702968.4FBE79B8@webmail.messagingengine.com> From: Alexey Melnikov To: Dan Romascanu , ops-dir@ietf.org Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-sieve-fcc.all@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 In-Reply-To: <154702622280.7446.9285138848727921959@ietfa.amsl.com> Date: Wed, 09 Jan 2019 11:05:13 +0000 References: <154702622280.7446.9285138848727921959@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-sieve-fcc-08 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 11:05:20 -0000 Hi Dan, Thank you for your review. On Wed, Jan 9, 2019, at 9:30 AM, Dan Romascanu wrote: > Reviewer: Dan Romascanu > Review result: Has Issues > > The document extends the Sieve Email Filtering Language [RFC5228] by providing > a number of action commands, some of which can generate additional messages of > behalf of the user. It is a clear document, its target being developers and > users of the protocol. I liked the fact that the authors included a > 'Compatibility with Other Actions' section that describes the interoperability > with existing deployed versions of the protocol, as well as the inclusion of a > temporary section about Implementation Status. I am missing however some > information about possible impact of the new action commands on deployment and > operations on servers already in operation. I assume that scalability and > compatibility between older and newer versions (including or not the new > defined commands) were assessed, but this is not documented. As :fcc is controlled by Sieve extension mechanism, Sieve scripts need to be updated before :fcc can be used. This means that either users need to manually update scripts and/or implementations that would use :fcc automatically need to be updated. So older (nonextended) implementations are not affected by this extension. Does this help or did I miss the point you are trying to convey? Thank you, Alexey > Some confirmation, > warnings (if any) and useful information that operators should know at > deployment would be useful. I suggest that you consider adding such a paragraph > or short section. > From nobody Wed Jan 9 03:27:50 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3B8130DC7; Wed, 9 Jan 2019 03:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OWOpgMqNIvC8; Wed, 9 Jan 2019 03:27:47 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 688D012950A; Wed, 9 Jan 2019 03:27:47 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id l14so5735368ioj.5; Wed, 09 Jan 2019 03:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nGkJwsxahYr36CQ3Hk4La6rPDjDcKzuqLgMQG7w9iuo=; b=EAAZzWG7ZYx+xUc3cgtRprf34Ht7sEw3x/aD/bRfE3V1OIIoxOow1nqhlQBnJoqLVI RsXZA0Ek0vJwunUd91RC1pRhod+1ebxV9Uy+La+bstiwZzqMAQulKe8rNAZhedNTL7QT dxyr0Rd0VQTvHT7ypUxvA8fCYtF2NsNTp2URd6kZmANJJXyOVQQXar4/mVVvRWMDkrhV RZZI0q9JgvvPzNWiWzEZmGGfZkW+DffhuY980caqko1nOHP8zkZyYU/4S2Pq5vujAObX 0p9a/Tnj/q19M/zbXxg/t2xXHJhxd8HahJfkf45oDf1P9vLPEBMZyolVmfgPgGPlYOgx uX9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nGkJwsxahYr36CQ3Hk4La6rPDjDcKzuqLgMQG7w9iuo=; b=DnMIeGULJtX5nwnYv7QLWr9T40e3rJBhhFTZF4HFss++unHTqRZZasexjwKlQe25UZ XMhXk5CjZKqpoe4vOGiz647iBJcMKL5PF5xGkjDlppo7gv7KMKI3cPT2sMEt8udwe7p+ ABBGgYJ3DBMKWShWGHdqUcHefuOE67vECMjWlZ9dX3S4QH5IGLSxyed7LbgGxPv4VQ48 bjCAXY1VGUDeBkrsR0FYtvK8UkGUQ88z+POSl7DXyTx9KEQrvHFIWOufmeL2qfHY6eyX HbaxZEUk0D69YOUxg89MHEWq0icW3R93U+1qEMlp3s0F9bHBhzHi74cNZGmg3+soETIP 9WhA== X-Gm-Message-State: AJcUukfK771UifWeEQvxx7x2aIJ9yhLQusvQQiDhwqktfJHMATZmeagD hgymLEXp8F6I65k45J0XmFX6BOXPXCNUDYs9omU= X-Google-Smtp-Source: ALg8bN6QruySPV3PZF5lPQZnL9/owzDCXPhAC7gF7H8kdi7WXW4E7gbRCnzjQ3vszW9dNr1L9VVvgkFeE2rh/4U+z0k= X-Received: by 2002:a5d:9a84:: with SMTP id c4mr3604661iom.123.1547033266617; Wed, 09 Jan 2019 03:27:46 -0800 (PST) MIME-Version: 1.0 References: <154702622280.7446.9285138848727921959@ietfa.amsl.com> <1547031913.1905154.1629702968.4FBE79B8@webmail.messagingengine.com> In-Reply-To: <1547031913.1905154.1629702968.4FBE79B8@webmail.messagingengine.com> From: Dan Romascanu Date: Wed, 9 Jan 2019 13:27:34 +0200 Message-ID: To: Alexey Melnikov Cc: ops-dir@ietf.org, extra@ietf.org, ietf , draft-ietf-extra-sieve-fcc.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000005004c3057f04c072" Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-sieve-fcc-08 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 11:27:49 -0000 --0000000000005004c3057f04c072 Content-Type: text/plain; charset="UTF-8" Hi Alexey, Thanks for the answer. It helps indeed. It would help better if this is documented with one paragraph in the text of the document. While developers know well the details, users and operators may be less familiar with these. Regards, Dan On Wed, Jan 9, 2019 at 1:05 PM Alexey Melnikov wrote: > Hi Dan, > Thank you for your review. > > On Wed, Jan 9, 2019, at 9:30 AM, Dan Romascanu wrote: > > Reviewer: Dan Romascanu > > Review result: Has Issues > > > > The document extends the Sieve Email Filtering Language [RFC5228] by > providing > > a number of action commands, some of which can generate additional > messages of > > behalf of the user. It is a clear document, its target being developers > and > > users of the protocol. I liked the fact that the authors included a > > 'Compatibility with Other Actions' section that describes the > interoperability > > with existing deployed versions of the protocol, as well as the > inclusion of a > > temporary section about Implementation Status. I am missing however some > > information about possible impact of the new action commands on > deployment and > > operations on servers already in operation. I assume that scalability and > > compatibility between older and newer versions (including or not the new > > defined commands) were assessed, but this is not documented. > > As :fcc is controlled by Sieve extension mechanism, Sieve scripts need to > be updated before :fcc can be used. This means that either users need to > manually update scripts and/or implementations that would use :fcc > automatically need to be updated. > So older (nonextended) implementations are not affected by this extension. > > Does this help or did I miss the point you are trying to convey? > > Thank you, > Alexey > > > Some confirmation, > > warnings (if any) and useful information that operators should know at > > deployment would be useful. I suggest that you consider adding such a > paragraph > > or short section. > > > --0000000000005004c3057f04c072 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexey,

Thanks for t= he answer. It helps indeed. It would help better if this is documented with= one paragraph in the text of the document. While developers know well the = details, users and operators may be less familiar with these.

Regards,

Dan

=

On Wed, Jan 9, 2019 a= t 1:05 PM Alexey Melnikov <aam= elnikov@fastmail.fm> wrote:
Hi Dan,
Thank you for your review.

On Wed, Jan 9, 2019, at 9:30 AM, Dan Romascanu wrote:
> Reviewer: Dan Romascanu
> Review result: Has Issues
>
> The document extends the Sieve Email Filtering Language [RFC5228] by p= roviding
> a number of action commands, some of which can generate additional mes= sages of
> behalf of the user. It is a clear document, its target being developer= s and
> users of the protocol. I liked the fact that the authors included a > 'Compatibility with Other Actions' section that describes the = interoperability
> with existing deployed versions of the protocol, as well as the inclus= ion of a
> temporary section about Implementation Status. I am missing however so= me
> information about possible impact of the new action commands on deploy= ment and
> operations on servers already in operation. I assume that scalability = and
> compatibility between older and newer versions (including or not the n= ew
> defined commands) were assessed, but this is not documented.

As :fcc is controlled by Sieve extension mechanism, Sieve scripts need to b= e updated before :fcc can be used. This means that either users need to man= ually update scripts and/or implementations that would use :fcc automatical= ly need to be updated.
So older (nonextended) implementations are not affected by this extension.<= br>
Does this help or did I miss the point you are trying to convey?

Thank you,
Alexey

> Some confirmation,
> warnings (if any) and useful information that operators should know at=
> deployment would be useful. I suggest that you consider adding such a = paragraph
> or short section.
>
--0000000000005004c3057f04c072-- From nobody Wed Jan 9 08:01:06 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E26128CF2; Wed, 9 Jan 2019 08:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 05duxunc0Ifu; Wed, 9 Jan 2019 08:00:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3151130E95; Wed, 9 Jan 2019 08:00:56 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1SUAKH3R400DVRD@mauve.mrochek.com>; Wed, 9 Jan 2019 07:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547049348; bh=hpeh2FO9GleYzHvckC41IG9o3RznHqmF4LOvhByvfkM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=hiSpObGUkxFbhoM9Db1RyGx7l8zSZ6euVesJhKJ9RJfoI035bLHZU2lIWBFBPFIqH ifwfUnlsMHCmqx4iSm/zq/2P7qHACyTnqS3CiheFDBtm6SC28CZA3iQfw74NoHqVpF 2Nav15lPwRfXppIqUEuWDD1iMxPjjlFrbcS/Y7PQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Wed, 9 Jan 2019 07:55:42 -0800 (PST) Cc: The IESG , extra@ietf.org, Jiankang Yao , draft-ietf-extra-sieve-fcc@ietf.org, extra-chairs@ietf.org Message-id: <01R1SUAHNJJC00004L@mauve.mrochek.com> Date: Wed, 09 Jan 2019 07:21:53 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 06 Jan 2019 14:12:58 -0800" <154681277828.16929.18247897769470424327.idtracker@ietfa.amsl.com> References: <154681277828.16929.18247897769470424327.idtracker@ietfa.amsl.com> To: Eric Rescorla Archived-At: Subject: Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 16:00:59 -0000 > Eric Rescorla has entered the following ballot position for > draft-ietf-extra-sieve-fcc-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-extra-sieve-fcc/ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3898 > IMPORTANT > S 3. > > copy of the generated message into the mailbox provided in the > > subsequent argument. The syntax and semantics of the mailbox > > argument MUST match those of the mailbox argument to the "fileinto" > > action specified in Section 4.1 of [RFC5228]. If the specified > > mailbox doesn't exist, the implementation MUST file the message into > > the user's main mailbox (e.g. IMAP "INBOX"). > This seems to sort of conflict with S 3.1.1. I think you meant 3.1.2 (mailbox extension), not 3.1.1 (imap4flags). > I assume that the logic > is: if (!exists && :create) { try_to_create() }; if (!exists) { > file_in_inbox()} else { file_in_fcc_mailbox()}, but this text isn't > celar. Actually, there's a more serious conflict here. RFC 5228 section 4.1 has this to say in regards to the semantics of the mailbox argument to fileinto: If the specified mailbox doesn't exist, the implementation MAY treat it as an error, create the mailbox, or deliver the message to an implementation-defined mailbox. If the implementation uses a different encoding scheme than UTF-8 for mailbox names, it SHOULD reencode the mailbox name from UTF-8 to its encoding scheme. For example, the Internet Message Access Protocol [IMAP] uses modified UTF-7, such that a mailbox argument of "odds & ends" would appear in IMAP as "odds &- ends". If the semantics MUST match this, as the document currently says, then you can't then require fallback to INBOX if the specified mailbox doesn't already exist, since only one of several possible behaviors. Nor does :create in RFC 5490 actually change this. All the mailbox extension does is provide a means to say "create the mailbox". It doesn't change the behavior when :create isn't specified, meaning implementations are allowed to treat :create as a no-op. (The reason for this, incidentally, is that requiring :create for a create operation would potentially invalidate existing sieves.) Or, to put this another way, RFC 5228 says this is also valid: if (!exists) { try_to_create() }; if (!exists) { file_in_inbox()} else { file_in_fcc_mailbox()} as well as several other possibilities. I think the correct way to resolve this is to make the text match RFC 5228 semantics. The alternative is to note that the semantics here aren't those of fileinto, which I see as a least astonishment principle violation. > COMMENTS > S 1. > > > > The capability string associated with this extension is "fcc". > > > > Each action that generates additional messages will need to specify > > how it interfacts with :fcc. This document specifies the interaction > > of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions. > Are these the only such actions? They are the only standardized ones. There are probably implementations of the old notify draft out there: https://datatracker.ietf.org/doc/html/draft-martin-sieve-notify and there may be other stuff as well. Ned From nobody Wed Jan 9 08:13:55 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B019E130EC9; Wed, 9 Jan 2019 08:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 8voAo6CaUNlm; Wed, 9 Jan 2019 08:13:45 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48AF128D0C; Wed, 9 Jan 2019 08:13:45 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1SUQJKQWG00DK9V@mauve.mrochek.com>; Wed, 9 Jan 2019 08:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547050120; bh=dFH+A+ReB1lcuoaF4R5k/+8fo+4SAWeoSBm8wmufHWk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=HmEtT5qmV4YuGAv44ytab9edVWNHI3kJ2GMz2+KJIeoFrTLdWU1IJ7WZLn91AylT8 K7FuZhiBxeGsd4dpB84tTBMXBMnCZZWojTdD/I56xy0UBr1IWOlS4+vId76PpuTvsj 3blWJyc00f6qgytKHiZgE4WWB9B+vczJUdDvhR0E= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Wed, 9 Jan 2019 08:08:32 -0800 (PST) Cc: Alexey Melnikov , extra@ietf.org, ops-dir@ietf.org, ietf , draft-ietf-extra-sieve-fcc.all@ietf.org Message-id: <01R1SUQEDQD200004L@mauve.mrochek.com> Date: Wed, 09 Jan 2019 07:58:32 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 09 Jan 2019 13:27:34 +0200" References: <154702622280.7446.9285138848727921959@ietfa.amsl.com> <1547031913.1905154.1629702968.4FBE79B8@webmail.messagingengine.com> To: Dan Romascanu Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-sieve-fcc-08 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 16:13:47 -0000 > Thanks for the answer. It helps indeed. It would help better if this is > documented with one paragraph in the text of the document. While developers > know well the details, users and operators may be less familiar with these. I'm going to push back on this a bit. It's effectively axiomatic that in order to understand a protocol extension you first need to understand the protocol and it's extension mechanism. Having every extension reiterate a subset of how the extension mechanism works seems pointless at best and more likely counterproductive - covering only a subset of the mechanism, which is all you're be able to do without repeating a significant amount of RFC 5228 will give the (incorrect) impression that it's all you need to know. Now, it would be one thing if there was a section in RFC 5228 that describes the extension mechanism - if that were the case we could just reference it. But for better or worse RFC 5228 isn't constructed that way. Perhaps more than any other protocol, Sieve is designed to be extended easily, and the discussion of how that works appears throughout the document. Finally, if we're going to talk about implementation and use issues in regards to this extension - and I'm not saying we should - such text would be better spent on discussing the interplay between this extension and where sieves are evaluated. Ned From nobody Wed Jan 9 08:19:31 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C87130E6C; Wed, 9 Jan 2019 08:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=H5XI/Ukp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E5Xip+ph 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 fYHGcrO-Qv3R; Wed, 9 Jan 2019 08:19:27 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539B6127B4C; Wed, 9 Jan 2019 08:19:27 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 79EB92208B; Wed, 9 Jan 2019 11:19:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 09 Jan 2019 11:19:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=34r0g8S2xPLxS6Vxh65FnW6/+ku qz4tk3K1DTRERVfs=; b=H5XI/UkpMwUZ02SRFZ2h3qg524UppwRju9i21p5+Od0 HIgR2Quj2ahkiR50B/u/KAfkw73AAVPDmKtfpUoImgXvW22x+6MH2h1ufak3b7vc uvhfcbA67vC9lWc0bvrjxPhafgf2COriABakWkp5x/bh2wcjgJU9JDMQsX6OaqSW PcVZtD7h2D6EwNxXqREjsb4QLDU2zUTmaOIYVF1ENOYA3xW8jty3gpe0J/4+5UyM 8mat+B2yaf9L/tLxVJKZaGp58M2ryfTAp2gW9vh4CDoW2ZnaPGTCATf9a3B/Igwn fGSS9+lB8U83rnflsRwH2QdRO7cPS9n/I31nU/3Q7EA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=34r0g8 S2xPLxS6Vxh65FnW6/+kuqz4tk3K1DTRERVfs=; b=E5Xip+phTMv9dMTwcHPYF7 zEafqQUSbIulHG+7A7Cq43Er9C2nwZ1/eA2s7kwliZ6+EQcCewdMUlxdTWWWgZEI mG14WFpB1dokH8fBZmOVwghFp8MoElugYbCtThKeyHD2YQRMW8Zl0v63r2nlVaVh HVzwujVxY0prBlKmIfFubDO7alhFLtUe3o9ncii9mwwlz/VIZSUHtgtVCeHqI86r wCohoCJYt8EtF4N3h3bweZsVKMFecbqyste+mzERseQ8Q2HyaCnE2brvRgeSSj8X xpHO212HgdepPk5MAjjMO7agPwO3K8SHBvwm/9KVMKaCS6AVx1xMjiZXrdVQIreg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedugdekjeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcu ofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepjeegrdejjedrkeehrddvhedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 3E3A11026D; Wed, 9 Jan 2019 11:19:23 -0500 (EST) To: Ned Freed , Eric Rescorla Cc: extra@ietf.org, Jiankang Yao , draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org References: <154681277828.16929.18247897769470424327.idtracker@ietfa.amsl.com> <01R1SUAHNJJC00004L@mauve.mrochek.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Wed, 9 Jan 2019 11:19:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <01R1SUAHNJJC00004L@mauve.mrochek.com> Content-Type: multipart/mixed; boundary="------------360E7096423F7000CB742021" Content-Language: en-US Archived-At: Subject: Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 16:19:29 -0000 This is a multi-part message in MIME format. --------------360E7096423F7000CB742021 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ned, On 1/9/19 10:21 AM, Ned Freed wrote: >> Eric Rescorla has entered the following ballot position for >> draft-ietf-extra-sieve-fcc-08: No Objection >> IMPORTANT >> S 3. >>> copy of the generated message into the mailbox provided in the >>> subsequent argument. The syntax and semantics of the mailbox >>> argument MUST match those of the mailbox argument to the "fileinto" >>> action specified in Section 4.1 of [RFC5228]. If the specified >>> mailbox doesn't exist, the implementation MUST file the message into >>> the user's main mailbox (e.g. IMAP "INBOX"). >> This seems to sort of conflict with S 3.1.1. > I think you meant 3.1.2 (mailbox extension), not 3.1.1 (imap4flags). > >> I assume that the logic >> is: if (!exists && :create) { try_to_create() }; if (!exists) { >> file_in_inbox()} else { file_in_fcc_mailbox()}, but this text isn't >> celar. > Actually, there's a more serious conflict here. RFC 5228 section 4.1 has this > to say in regards to the semantics of the mailbox argument to fileinto: > > If the specified mailbox doesn't exist, the > implementation MAY treat it as an error, create the mailbox, or > deliver the message to an implementation-defined mailbox. If the > implementation uses a different encoding scheme than UTF-8 for > mailbox names, it SHOULD reencode the mailbox name from UTF-8 to its > encoding scheme. For example, the Internet Message Access Protocol > [IMAP] uses modified UTF-7, such that a mailbox argument of "odds & > ends" would appear in IMAP as "odds &- ends". > > If the semantics MUST match this, as the document currently says, then you > can't then require fallback to INBOX if the specified mailbox doesn't already > exist, since only one of several possible behaviors. > > Nor does :create in RFC 5490 actually change this. All the mailbox > extension does is provide a means to say "create the mailbox". It doesn't > change the behavior when :create isn't specified, meaning implementations > are allowed to treat :create as a no-op. (The reason for this, incidentally, > is that requiring :create for a create operation would potentially invalidate > existing sieves.) > > Or, to put this another way, RFC 5228 says this is also valid: > > if (!exists) { try_to_create() }; > if (!exists) { file_in_inbox()} else { file_in_fcc_mailbox()} > > as well as several other possibilities. > > I think the correct way to resolve this is to make the text match RFC 5228 > semantics. The alternative is to note that the semantics here aren't > those of fileinto, which I see as a least astonishment principle violation. I agree, and I had originally used the RFC 5228 text.  The current text was a result of a comment during AD review, which I have asked him to review/reconsider.  My intent is to revert to the 5228 text unless there is pushback, in which case I will have to note the semantic difference as you suggest. >> COMMENTS >> S 1. >>> The capability string associated with this extension is "fcc". >>> >>> Each action that generates additional messages will need to specify >>> how it interfacts with :fcc. This document specifies the interaction >>> of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions. >> Are these the only such actions? > They are the only standardized ones. There are probably implementations > of the old notify draft out there: > > https://datatracker.ietf.org/doc/html/draft-martin-sieve-notify > > and there may be other stuff as well. Well, there is [e]reject, but we decided to remove the section stating that :fcc is incompatible.  We can certainly add it back in. -- Ken Murchison Cyrus Development Team FastMail US LLC --------------360E7096423F7000CB742021 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------360E7096423F7000CB742021-- From nobody Wed Jan 9 08:56:29 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D80130ED9; Wed, 9 Jan 2019 08:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 P3g7YW3QbGgT; Wed, 9 Jan 2019 08:56:12 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 E399A130F01; Wed, 9 Jan 2019 08:56:11 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id v10so6525303ios.13; Wed, 09 Jan 2019 08:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gr2XKXkknDL+UML382xKsKvsLPO13UikIVXGKG2NO5s=; b=ZjM+pjwOONTwrFj1jhnfkyd7btiuXzj9I0Gdz8gDHtRgPEpq3n53iSF1mczanLtqma mgR0Zlhm0syj+EZEJEkHq/NpZLGixdqFl0ip9VmDdHXAOBfefJnBSxX02QCVlBhRbQgy VsEXzcBLgIYW2PYh8a5R0h1yuUZND4AYOs7eqBUanBrUOgqfr7dSVTjQFHD9blc9eivT nO4cSwaFAQmp6HKOJLOs0vYvhi5WtF8wjIseYODAstm4lK7zXgSvsAdkR2uZjeKDXl+T qOeOYoFJSPBy6m0Dvz8acui+/4VKUUVBmqu6lEdHDsqh+E7WxbDWIVwsBV2jE/4tksF6 5p1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gr2XKXkknDL+UML382xKsKvsLPO13UikIVXGKG2NO5s=; b=KSe1ly4eBUdWBR5dCOdUgjr5P9g11/x3u8O9N+TSVvRkV3d2+syLUBLi4XMrLOppDY qjWzHoYF9HK4SxezKCItUE/c8nJLJJicDTPkOAt6mJ3SJE7xZDaIEvVAmqzM/tmpnmRg nc+B+BvC2TXrPSHpGlHucQ8bLyaudo0zB6ki3Gsoppj/2BX4524QVR8Z+ekhoyMgKXKH ijELYrYVmsH46ltmtK+nt+xC7eVjNnAUKhLD5i0wuauOuK2sLkdu4TBq0kFXxqPAz/Vz hyAHqVuLRUvFjGmtW/YSUB+mpwA6FrdTJkgWN6SSz8Ma23JbJR1j2y7vX8v5GJCLXZMD MlkQ== X-Gm-Message-State: AJcUuke6d/MOrfgwUubWpCqg+TGRBkgAWvtZj+r75qyGM6oGrqdE0eDv 9E0MX5uB4f3ISGG6HQxvVuBvw3Mhh4MwOXYz1oeM5g== X-Google-Smtp-Source: ALg8bN5FK107p8hwgmA7L0piUUp3mnvCr2pdBI3sighxOY207rHhN9cA1m8bhc8zZg1MtcwGT9Gqd+rL9FvMKqum9s8= X-Received: by 2002:a6b:e514:: with SMTP id y20mr4321782ioc.105.1547052971148; Wed, 09 Jan 2019 08:56:11 -0800 (PST) MIME-Version: 1.0 References: <154702622280.7446.9285138848727921959@ietfa.amsl.com> <1547031913.1905154.1629702968.4FBE79B8@webmail.messagingengine.com> <01R1SUQEDQD200004L@mauve.mrochek.com> In-Reply-To: <01R1SUQEDQD200004L@mauve.mrochek.com> From: Dan Romascanu Date: Wed, 9 Jan 2019 18:55:58 +0200 Message-ID: To: Ned Freed Cc: Alexey Melnikov , extra@ietf.org, ops-dir@ietf.org, ietf , draft-ietf-extra-sieve-fcc.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000cb49f4057f095682" Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-sieve-fcc-08 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 16:56:15 -0000 --000000000000cb49f4057f095682 Content-Type: text/plain; charset="UTF-8" Hi Ned, Thanks for your answer. I am leaving to the OPS ADs the judgment about how important the clarification text would be. The OPS-DIR reviews are written to help them in their evaluaton tasks. Regards, Dan On Wed, Jan 9, 2019 at 6:13 PM Ned Freed wrote: > > Thanks for the answer. It helps indeed. It would help better if this is > > documented with one paragraph in the text of the document. While > developers > > know well the details, users and operators may be less familiar with > these. > > I'm going to push back on this a bit. It's effectively axiomatic that in > order > to understand a protocol extension you first need to understand the > protocol > and it's extension mechanism. Having every extension reiterate a subset of > how > the extension mechanism works seems pointless at best and more likely > counterproductive - covering only a subset of the mechanism, which is > all you're be able to do without repeating a significant amount of > RFC 5228 will give the (incorrect) impression that it's all you need to > know. > > Now, it would be one thing if there was a section in RFC 5228 that > describes the extension mechanism - if that were the case we could > just reference it. But for better or worse RFC 5228 isn't constructed that > way. Perhaps more than any other protocol, Sieve is designed to be extended > easily, and the discussion of how that works appears throughout the > document. > > Finally, if we're going to talk about implementation and use issues in > regards > to this extension - and I'm not saying we should - such text would be > better > spent on discussing the interplay between this extension and where sieves > are > evaluated. > > Ned > --000000000000cb49f4057f095682 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ned,

Thanks for your answ= er. I am leaving to the OPS ADs the judgment about how important the clarif= ication text would be. The OPS-DIR reviews are written to help them in thei= r evaluaton tasks.

Regards,

Dan


On Wed, Jan 9, 2019 at 6:13 PM Ned Freed <ned.freed@mrochek.com> wrote:
> Thanks for the answer. It h= elps indeed. It would help better if this is
> documented with one paragraph in the text of the document. While devel= opers
> know well the details, users and operators may be less familiar with t= hese.

I'm going to push back on this a bit. It's effectively axiomatic th= at in order
to understand a protocol extension you first need to understand the protoco= l
and it's extension mechanism. Having every extension reiterate a subset= of how
the extension mechanism works seems pointless at best and more likely
counterproductive - covering only a subset of the mechanism, which is
all you're be able to do without repeating a significant amount of
RFC 5228 will give the (incorrect) impression that it's all you need to= know.

Now, it would be one thing if there was a section in RFC 5228 that
describes the extension mechanism - if that were the case we could
just reference it. But for better or worse RFC 5228 isn't constructed t= hat
way. Perhaps more than any other protocol, Sieve is designed to be extended=
easily, and the discussion of how that works appears throughout the
document.

Finally, if we're going to talk about implementation and use issues in = regards
to this extension - and I'm not saying we should - such text would be b= etter
spent on discussing the interplay between this extension and where sieves a= re
evaluated.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned
--000000000000cb49f4057f095682-- From nobody Wed Jan 9 11:43:56 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F720130F94; Wed, 9 Jan 2019 11:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=LARfn5RE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BBRYw82y 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 PqiIpu3r0IKn; Wed, 9 Jan 2019 11:43:47 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFD512DF72; Wed, 9 Jan 2019 11:43:47 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 6C8A413D6; Wed, 9 Jan 2019 14:43:46 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 09 Jan 2019 14:43:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=t wvVMXpPzWzFlYQevlmA5+TxokSdFmfiSivZZBYBDdo=; b=LARfn5RERqFHzHgUg PEUwxcCMOq9E7oqeAUKSvaZtm4zZhf/6Bp2exQAc6dgBJ4seiMYUJWdCnK/lNuuC gtU3SNxdNPS1xNI1MYTl8EkhEwxqqod4Otrx1jh5sAO/XajijjbXusJa3Gj58JeR QFFDZX+DLnviltkyVKCkDDwyVs1ePyCeA/BEbHqn94TpGBAZpd13iGOpcmDC5L5U 7XDfNaZb75nEajdiZhYkQ6YZcB4WRiLG/pmnXmv2Yocb/2OVjHu6ZFpbPLqbcZyB JzmG5lmrf6AApVgqAyjYvin8SL+NpQK5F/Q4nl3dRTXKraDKNgk0MVXLwqV07avD tFhbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=twvVMXpPzWzFlYQevlmA5+TxokSdFmfiSivZZBYBD do=; b=BBRYw82y1KdIQ6RzntNvbKdDys5HlN6mZhKkuud+CXPZDbx61HNxEYxw/ JY8vIz3RLLAES3Oybg+WijtDIaaFHtY4tpkyEshOS5DqYEWCPR1U7fdsf/ZnCk5V vpB9zeMhU5E2TJyGuLxOv4Xt/qN+kb0yHU33Z7N0ERIRxdJQos4Z8t7YnpQj3M3v pwdOlgzxRjT6L5okHZPAnOsvrQZC08/utAzO3fP4xSaM78YVhFTO5y/YKbfgF82T 8OD3UfpUeyCYDmVarLVEh8QXU3+0BAVC2xwToxNG8Yq7Sec5PSPkJiemjRov2GfA KdVaF/1clHEmrvVVItKZHFn+/06Qw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedugddufedtucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekgeenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.84]) by mail.messagingengine.com (Postfix) with ESMTPA id DF60DE43A6; Wed, 9 Jan 2019 14:43:44 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <154508476504.4235.1662228852126189639@ietfa.amsl.com> Date: Wed, 9 Jan 2019 14:43:43 -0500 Cc: IETF Gen-ART , extra@ietf.org, draft-ietf-extra-sieve-fcc.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154508476504.4235.1662228852126189639@ietfa.amsl.com> To: Ines Robles X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Extra] [Gen-art] Genart last call review of draft-ietf-extra-sieve-fcc-08 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 19:43:50 -0000 Ines, thanks for your review. I entered a No Objection ballot. Alissa > On Dec 17, 2018, at 5:12 PM, Ines Robles = wrote: >=20 > Reviewer: Ines Robles > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-extra-sieve-fcc-08 > Reviewer: Ines Robles > Review Date: 2018-12-17 > IETF LC End Date: 2018-12-18 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > I believe the draft is technically good. This document is well written = and > clear to understand. >=20 > This document defines an extension to Sieve Email Filtering Language = commands > to allow a copy of any generated message to be filed into a target = mailbox. > This document updates RFC5230 and RFC5435 by adding a new tagged = argument to > the "vacation" and "enotify" actions respectively. >=20 > Major issues: Not found. >=20 > Minor issues: Not found. >=20 > Nits/editorial comments: Page 3. "how it interfacts with :fcc." =3D> = how it > interacts with :fcc.? >=20 > Summary: 0 errors (**), 0 flaws (~~), 2 warnings (=3D=3D), 6 comments = (--). >=20 > Thanks for this document, >=20 > Ines. >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jan 9 13:51:38 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5277A12DD85; Wed, 9 Jan 2019 13:51:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 13:51:29 -0800 Archived-At: Subject: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 21:51:29 -0000 Ben Campbell has entered the following ballot position for draft-ietf-extra-sieve-fcc-08: Discuss 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-extra-sieve-fcc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work on this. I plan to ballot "yes", but have one item I think needs to be discussed first: The security considerations say that this extension adds no new considerations not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not sure that that is true. It seems like the ability to insert a copy of message into a mailbox might have security and/or privacy considerations. This seems analogous to the "fileinto" action. I looked for security considerations for that in RFC 5228. All I found was a statement that "fileinfo" can be dangerous, but no elaboration on the nature of the danger or how it might be mitigated. So while I agree that fcc would have similar considerations as "fileinfo", I'm not sure those considerations have been adequately documented. (I expect people will point me to something I missed, or where some other analogous feature is documented, in which case I will clear.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §1, last paragraph (nit): Should "each action" be "each new action"? §3.2, construction for FCC-OPTS: There is no extension point among the options, which would seem to require any new options update this RFC. Would it be reasonable to add one? From nobody Wed Jan 9 15:17:47 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79301131181; Wed, 9 Jan 2019 15:17:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154707584442.5000.13501401246628029757.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 15:17:24 -0800 Archived-At: Subject: [Extra] Adam Roach's Yes on draft-ietf-extra-sieve-fcc-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 23:17:27 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-sieve-fcc-08: Yes 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-extra-sieve-fcc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work everyone did on this document. The mechanism seems quite useful. I have some minor suggestions that you may want to consider incorporating. I support Ben's discuss. --------------------------------------------------------------------------- §1: > This extension defines a new optional tagged argument ":fcc" to > action commands which generate additional messages to allow a copy of Nit: "...commands that generate..." --------------------------------------------------------------------------- §3: > alters the behavior of action commands which generate additional Nit: "...commands that generate..." --------------------------------------------------------------------------- §3.2: > FCC = ":fcc" string *FCC-OPTS > ; per Section 2.6.2 of RFC5228, > ; the tagged arguments in FCC may appear in any order This threw me for a bit of a loop when I got to the example in section 5, and I had to go carefully read RFC 5228 to figure out what was going on. I think this would be much clearer and more accurate if the rule were described as: > FCC = *FCC-OPTS ":fcc" string *FCC-OPTS --------------------------------------------------------------------------- General: I'm a little concerned about the fact that this extension is generating a new message and attempting to store it into a potentially quota-controlled user folder. This would seem to be a run-time error, about which RFC 5228 says: > When an error happens, implementations MUST notify the user that an > error occurred and which actions (if any) were taken, and do an > implicit keep. This probably isn't the right behavior for FCC. I think a sentence or two of guidance about what happens when an FCC action would put the destination mailbox over quota are in order, particularly since they'll be different than the guidance in the base SIEVE spec. I might just be confused here -- corrections to any incorrect notions I've expressed would be appreciated. From nobody Wed Jan 9 16:04:26 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B53B12DF71; Wed, 9 Jan 2019 16:04:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154707865829.4946.2773236088316133086.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 16:04:18 -0800 Archived-At: Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 00:04:19 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-sieve-fcc-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-extra-sieve-fcc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ben's Discuss. I also have some other comments. Section 1 Each action that generates additional messages will need to specify how it interfacts with :fcc. [...] Do we need to Update: 5228 so that authors of such future actions are aware of this requirement? The syntax and semantics of the mailbox argument MUST match those of the mailbox argument to the "fileinto" action specified in Section 4.1 of [RFC5228]. If the specified mailbox doesn't exist, the implementation MUST file the message into the user's main mailbox (e.g. IMAP "INBOX"). It's unclear that the "syntax and semantics MUST match" needs the 2119 MUST; it could just be "are defined to match". (Except they don't, since we add on the extra condition that a nonexistant mailbox name be delivered to the no-longer-implementation-defined INBOX folder instead of the other MAY options for fileinto.) Section 3.1 Tagged arguments in future extensions to the "fileinto" action should describe their interaction with ":fcc", if any. This is not a very strong statement. What would an implementor be expected to do upon encountering such future extensions that do not describe interaction with :fcc? (This requirement may also be a candidate for an Updates: relationship with 5228.) Section 3.1.2 Perhaps note that implementations are permitted but not required to create the mailbox (if needed) without this extension. Section 3.1.3 It's a bit odd to update the behavior of another document that's still an I-D (vs. specifying the behavior in question in that document). Section 5 Usage: vacation [FCC] [":days" number | ":seconds" number] [":subject" string] [":from" string] [":addresses" string-list] [":mime"] [":handle" string] This is presumably just my having skimmed RFC 5228 too quickly, but why is this [FCC] instead of [":fcc" string]" or similar? (Same for the notify action in Section 6.) Section 7 Do we want to have a list of currently defined actions that are not compatible with the "fcc" extension, to avoid any confusion by future readers as to what was defined at the time of this writing? From nobody Wed Jan 9 17:20:59 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A570A12DD85; Wed, 9 Jan 2019 17:20:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-extra-sieve-special-use@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154708325763.4990.14007827148353808097.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 17:20:57 -0800 Archived-At: Subject: [Extra] Benjamin Kaduk's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 01:20:58 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-sieve-special-use-04: Yes 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-extra-sieve-special-use/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting Yes because this document seems like it is going to do the right thing in helping to keep sieve up to date with IMAP. But I do still have a few comments. Section 1 Commonly, several mailboxes in an IMAP message store [IMAP] have a special use; e.g. it is where the user's draft messages are stored, where a copy of sent messages are kept, or it is where spam messages are filed automatically at delivery. [...] nits: there's a singular/plural mismatch between "several mailboxes" and "it"; there should also be a comma after "e.g.". Section 4 Implementations SHOULD handle an invalid special- use flag in the same way as an invalid mailbox name is handled. The (Does "invalid" mean "syntactically invalid" or "nonexistent" or something else? Presumably this is just a sieve convention that I've not been exposed to yet...) However, while the set of mailboxes to which the involved special-use flags are assigned remains unchanged, implementations SHOULD ensure that the mailbox choice is made consistently, so that the same mailbox is used every time. Conversely, the chosen mailbox MAY change once the special-use flag assignments that are relevant for the mailbox choice are changed (usually by user interaction). If delivery to the special-use mailbox fails for reasons not relating to its existence, the Sieve interpreter MUST NOT subsequently attempt delivery in the indicated default mailbox as a fall-back. Instead, it MUST proceed exactly as it does in case the ":specialuse" argument is absent and delivery to the mailbox named by its positional argument fails. This prevents the situation where messages are unexpectedly spread over two mailboxes in case transient or intermittent delivery failures occur. It seems a little inconsistent to only avoid spreading messages over two mailboxes as a SHOULD for when multiple options exist but a MUST for transient delivery failure. But presumably this has already been well-discussed in the WG and I shouldn't try to reopen it. Section 4.2 The IMAP example should probably use RFC 6761 domains. From nobody Wed Jan 9 18:49:36 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B78130F73; Wed, 9 Jan 2019 18:49:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-extra-sieve-special-use@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154708857484.5207.16946770094550744825.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 18:49:34 -0800 Archived-At: Subject: [Extra] Adam Roach's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 02:49:35 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-sieve-special-use-04: Yes 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-extra-sieve-special-use/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I have two minor suggestions for improvement. --------------------------------------------------------------------------- §1: > It also adds > the ability to file messages into an anonymous personal mailbox that > has a particular special-use attribute assigned using a ":specialuse" > argument for the "fileinto" command [SIEVE]. I was perplexed by the use of "anonymous" (here and elsewhere in the document), expecting it to be a term of art defined in some other RFC. I poked around at the plausible references and didn't find anything. After reading the rest of the document, I *think* the notion is that you're talking about a mailbox that is identified by its special-use attribute rather than its name. If that's the intention, it might be clearer to simply say "unnamed;" or, barring that, perhaps clarify in the Introduction what is meant by "anonymous." (Yes, I get that "unnamed" and "anonymous" are technically synonyms, but "anonymous" typically is used as a term of art corresponding to personal anonymity in the context of communications, making its use confusing in this context without any additional explanation) --------------------------------------------------------------------------- §2: > 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 [KEYWORDS]. Please use RFC 8174 boilerplate. From nobody Wed Jan 9 23:31:39 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD63913116E; Wed, 9 Jan 2019 23:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 MrtylfFsMDYn; Wed, 9 Jan 2019 23:31:30 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1980129A87; Wed, 9 Jan 2019 23:31:27 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1TQUYIBDS00E9C7@mauve.mrochek.com>; Wed, 9 Jan 2019 23:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547105310; bh=FWsuogUrDRLC6j1nO0zHtqWD5KvRYGfkEXkGOvpnUYk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=aEtyngNXODJT+qvpGw5OUWzUBK+BWxyPnGRIsdDagB5UJQ7+VBSnQiMHqmDxfmsFP Sekr0DGaMAsvCESr9NcBBrklb+vvrkRmOWNpUiIE5aP6eZHRJjNDWVyZv8iYTy29pa Ol2u2ISNb5pFdL6PcPgng8uVj1Yoyy3o8HMug+Hs= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Wed, 9 Jan 2019 23:28:25 -0800 (PST) Cc: The IESG , extra@ietf.org, draft-ietf-extra-sieve-special-use@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org Message-id: <01R1TQUWRF7800004L@mauve.mrochek.com> Date: Wed, 09 Jan 2019 23:23:29 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 09 Jan 2019 18:49:34 -0800" <154708857484.5207.16946770094550744825.idtracker@ietfa.amsl.com> References: <154708857484.5207.16946770094550744825.idtracker@ietfa.amsl.com> To: Adam Roach Archived-At: Subject: Re: [Extra] Adam Roach's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 07:31:32 -0000 > Adam Roach has entered the following ballot position for > draft-ietf-extra-sieve-special-use-04: Yes > 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-extra-sieve-special-use/ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Thanks to everyone who worked on this document. I have two minor suggestions for > improvement. > --------------------------------------------------------------------------- > §1: > > It also adds > > the ability to file messages into an anonymous personal mailbox that > > has a particular special-use attribute assigned using a ":specialuse" > > argument for the "fileinto" command [SIEVE]. > I was perplexed by the use of "anonymous" (here and elsewhere in the document), > expecting it to be a term of art defined in some other RFC. I poked around at > the plausible references and didn't find anything. > After reading the rest of the document, I *think* the notion is that you're > talking about a mailbox that is identified by its special-use attribute rather > than its name. Identified in the script. It does have a name. > If that's the intention, it might be clearer to simply say > "unnamed;" or, barring that, perhaps clarify in the Introduction what is meant > by "anonymous." I'm not wild about anonymous but unnamed doesn't seem like an improvement to me. The mailbox does have a name and this kind of makes it sound like it doesn't. Maybe something like "mailbox identified only by" or something similar? > (Yes, I get that "unnamed" and "anonymous" are technically synonyms, but > "anonymous" typically is used as a term of art corresponding to personal > anonymity in the context of communications, making its use confusing in this > context without any additional explanation) Also true. Ned From nobody Wed Jan 9 23:44:24 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB9A13118B; Wed, 9 Jan 2019 23:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 8hxGWDrtuyOH; Wed, 9 Jan 2019 23:44:21 -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 88A2C13118A; Wed, 9 Jan 2019 23:44:21 -0800 (PST) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0A7iClZ072714 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 01:44:13 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547106254; bh=t7WNpn1sfG+Fkj84YkT+p1DEk3UCUFztmuWS7BCL9z0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=utfuIviAYYqCcZ/WnCw/w5QfyuZTwuez4JJ4+hqfwIE1klesdBvU9M2EFE76tabwW GVMTBZc81Pm6DE0XSExc/S4DG6FloCorQMHEPNYc6b3JqMI44SczSxaPLXYkMEs3rY FZl0Zm7cPzfdFdF72tzytO+mldpKcp3u4mZq32XQ= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Ned Freed Cc: The IESG , extra@ietf.org, draft-ietf-extra-sieve-special-use@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org References: <154708857484.5207.16946770094550744825.idtracker@ietfa.amsl.com> <01R1TQUWRF7800004L@mauve.mrochek.com> From: Adam Roach Message-ID: <0d883bab-a1f2-d5b7-8586-3bc40603d6fa@nostrum.com> Date: Thu, 10 Jan 2019 01:44:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <01R1TQUWRF7800004L@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] Adam Roach's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 07:44:23 -0000 >> --------------------------------------------------------------------------- >> §1: >>> It also adds >>> the ability to file messages into an anonymous personal mailbox that >>> has a particular special-use attribute assigned using a ":specialuse" >>> argument for the "fileinto" command [SIEVE]. >> I was perplexed by the use of "anonymous" (here and elsewhere in the document), >> expecting it to be a term of art defined in some other RFC. I poked around at >> the plausible references and didn't find anything. >> After reading the rest of the document, I *think* the notion is that you're >> talking about a mailbox that is identified by its special-use attribute rather >> than its name. > Identified in the script. It does have a name. Right. Sorry, English is terribly imprecise for this kind of thing. I meant it in the sense of "he who shall not be named," rather than "thing without a name," but of course your interpretation is the obvious one. Now that you've pointed that out, I agree that this isn't a significant improvement. > >> If that's the intention, it might be clearer to simply say >> "unnamed;" or, barring that, perhaps clarify in the Introduction what is meant >> by "anonymous." > I'm not wild about anonymous but unnamed doesn't seem like an improvement to > me. The mailbox does have a name and this kind of makes it sound like it > doesn't. > > Maybe something like "mailbox identified only by" or something similar? That would certainly work, and it's much clearer. /a From nobody Wed Jan 9 23:45:26 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D20113118A; Wed, 9 Jan 2019 23:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 dLO39Gk1BPuE; Wed, 9 Jan 2019 23:45:23 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA51131188; Wed, 9 Jan 2019 23:45:23 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1TR9MUNGW00EL39@mauve.mrochek.com>; Wed, 9 Jan 2019 23:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547106018; bh=2ygrhQUg2RcyjtSn3oLICNzwpng5r5Z1YLbJgDimDcE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=lWFNUpSm7SPbwTxByOzVIGMKr5/9/Ro5u6lA1vnNXiVwpCX6YCoy+avpUv/A9QNRJ vbx35+WyWrF+EDHeQO1q+u0wHTP3/pPSKGKFwubxTQyvRVBznbsQHg/+Ma01Xb63xQ 8HFAYojL1Tt69llFGYpdxBh0kJa5MLGcxidX7ER4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Wed, 9 Jan 2019 23:40:15 -0800 (PST) Cc: The IESG , extra@ietf.org, draft-ietf-extra-sieve-special-use@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org Message-id: <01R1TR9L1OVU00004L@mauve.mrochek.com> Date: Wed, 09 Jan 2019 23:31:27 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 09 Jan 2019 17:20:57 -0800" <154708325763.4990.14007827148353808097.idtracker@ietfa.amsl.com> References: <154708325763.4990.14007827148353808097.idtracker@ietfa.amsl.com> To: Benjamin Kaduk Archived-At: Subject: Re: [Extra] Benjamin Kaduk's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 07:45:24 -0000 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-extra-sieve-special-use-04: Yes > 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-extra-sieve-special-use/ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I'm balloting Yes because this document seems like it is going to do the > right thing in helping to keep sieve up to date with IMAP. But I do still > have a few comments. > Section 4 > Implementations SHOULD handle an invalid special- > use flag in the same way as an invalid mailbox name is handled. The > (Does "invalid" mean "syntactically invalid" or "nonexistent" or something > else? Presumably this is just a sieve convention that I've not been > exposed to yet...) Given that the preceeding sentence in the paragraph is "The special-use flag specified with the ":specialuse" argument MUST conform to the "use-attr" syntax described in Section 6 of RFC6154 [SIEVE-MAILBOX]." I think it's actually pretty clear that this is talking about syntax and not something. I suppose changing it to say "syntactically invalid" would not hurt, but I don't really think it's necessary given the context. What actually concerns me more here is the MUST in the first sentence. This use of compliance language strikes me as misplaced. Sieve scripts are specified by users one way or another and say what they say; when we talk about compliance in these documents we're talking about what a Sieve implementation has to do, like the SHOULD in the second sentence, which is actually dealing with the case where the MUST is violated. > However, while the > set of mailboxes to which the involved special-use flags are assigned > remains unchanged, implementations SHOULD ensure that the mailbox > choice is made consistently, so that the same mailbox is used every > time. Conversely, the chosen mailbox MAY change once the special-use > flag assignments that are relevant for the mailbox choice are changed > (usually by user interaction). > If delivery to the special-use mailbox fails for reasons not relating > to its existence, the Sieve interpreter MUST NOT subsequently attempt > delivery in the indicated default mailbox as a fall-back. Instead, > it MUST proceed exactly as it does in case the ":specialuse" argument > is absent and delivery to the mailbox named by its positional > argument fails. This prevents the situation where messages are > unexpectedly spread over two mailboxes in case transient or > intermittent delivery failures occur. > It seems a little inconsistent to only avoid spreading messages over two > mailboxes as a SHOULD for when multiple options exist but a MUST for > transient delivery failure. But presumably this has already been > well-discussed in the WG and I shouldn't try to reopen it. Yes it has. I am not happy with it, but given the semantics of special-use in IMAP I don't see how it can be handled any other way. For example, if someone has the same special-use flag on two different mailboxes, then removes them both, then some time later puts them back, it's just not reasonable to expect an implementation to remember the original ordering and return to it. > Section 4.2 > The IMAP example should probably use RFC 6761 domains. Agreed. Ned From nobody Thu Jan 10 00:15:17 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E0B13118B; Thu, 10 Jan 2019 00:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 dpv-1eX9vXDW; Thu, 10 Jan 2019 00:15:12 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D58B13118A; Thu, 10 Jan 2019 00:15:12 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1TSBKVI3K00E89M@mauve.mrochek.com>; Thu, 10 Jan 2019 00:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547107807; bh=wLtIZLbFBkkT+qHa4aPV+KK0JI6ZU8nN6xK9IqQ7LUo=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ZUYSYszTJgc1na//8FgGYGQ39vDzKtX+nHw7ykGwjHY8GE8hCC7of3cdfOIj2FJe9 mFFhIJo2klmGhdTSrg9q2eAW5fQBF8EU/WKeQvxVVaKUzx6soEPkAuKAmHXrdtPiss +ZNq7DFxvIodJj29ZqvhXV2Z4CLeeCmEKDgKfmyU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Thu, 10 Jan 2019 00:10:03 -0800 (PST) Cc: The IESG , extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, extra-chairs@ietf.org Message-id: <01R1TSBIF7DU00004L@mauve.mrochek.com> Date: Wed, 09 Jan 2019 23:42:01 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 09 Jan 2019 16:04:18 -0800" <154707865829.4946.2773236088316133086.idtracker@ietfa.amsl.com> References: <154707865829.4946.2773236088316133086.idtracker@ietfa.amsl.com> To: Benjamin Kaduk Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 08:15:15 -0000 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-extra-sieve-fcc-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-extra-sieve-fcc/ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I support Ben's Discuss. I also have some other comments. > Section 1 > Each action that generates additional messages will need to specify > how it interfacts with :fcc. [...] > Do we need to Update: 5228 so that authors of such future actions are aware > of this requirement? Unfortunately Sieve extensions have a tendency to create new requirements that subsequent extensions have to address. For example, the relational extension specified in RFC 5231 adds additional match types that subsequent extensions that specify new tests have to deal with. While I realize this is not ideal, I don't think it's reasonable to have to update the base specification every time this happens. Specking as an implementor the great thing about Sieve is that the syntax never changes so you never have to tweak your parser. This is a huge win. The less great thing is that any time something like this is added have to check every place the semantic comes up and make sure you've handled all the cases, meaning it's an O(N*M) sort of deal. The fact that N and M are small and will remain so is what makes it manageable. > The syntax and semantics of the mailbox > argument MUST match those of the mailbox argument to the "fileinto" > action specified in Section 4.1 of [RFC5228]. If the specified > mailbox doesn't exist, the implementation MUST file the message into > the user's main mailbox (e.g. IMAP "INBOX"). > It's unclear that the "syntax and semantics MUST match" needs the 2119 > MUST; it could just be "are defined to match". (Except they don't, since > we add on the extra condition that a nonexistant mailbox name be delivered > to the no-longer-implementation-defined INBOX folder instead of the other > MAY options for fileinto.) A previous response of mine mentioned a similar issue in the special use extension. On consideration, I think the use of compliance language here is incorrect in regards to syntax since the Sieve implementation has no control over what people put in their scripts, and until a script is evaluated there's no way to be sure the syntactic requirements of the underlying store (which may or may not be an IMAP store) are met. Semantics of a syntactically valid mailbox name are another matter. They really do need to match whatever it is that fileinto does or we have a mess on our hands. (FWIW, in our implementation there's no way it could work any other way since the use of :fcc results > Section 3.1 > Tagged arguments in future extensions to the > "fileinto" action should describe their interaction with ":fcc", if > any. > This is not a very strong statement. What would an implementor be expected > to do upon encountering such future extensions that do not describe > interaction with :fcc? Maybe "need to" rather than "should"? This isn't really a place where compliance language should be used either since we're talking about something future extension specifications need to do. > (This requirement may also be a candidate for an > Updates: relationship with 5228.) We didn't do that with RFC 5231. I'm not sure this is the time to start. > Section 3.1.2 > Perhaps note that implementations are permitted but not required to create > the mailbox (if needed) without this extension. As previously discussed in the EKR comment thread, this definitely needs to be sorted out. > Section 3.1.3 > It's a bit odd to update the behavior of another document that's still an > I-D (vs. specifying the behavior in question in that document). But the same could be said about that document updating the behavior of this one. > Section 5 > Usage: vacation [FCC] > [":days" number | ":seconds" number] > [":subject" string] > [":from" string] > [":addresses" string-list] > [":mime"] > [":handle" string] > > This is presumably just my having skimmed RFC 5228 too quickly, but why is > this [FCC] instead of [":fcc" string]" or similar? > (Same for the notify action in Section 6.) FCC is defined in section 3.2. > Section 7 > Do we want to have a list of currently defined actions that are not > compatible with the "fcc" extension, to avoid any confusion by future > readers as to what was defined at the time of this writing? As noted previously, we had it and took it out based on review comments. I don't especially care if we do or not, but we need to pick an approach and stick to it. Ned From nobody Thu Jan 10 00:36:46 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49AD131192; Thu, 10 Jan 2019 00:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=hCfQ+GAF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DYhKI/QF 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 5Ba7Pg31-zar; Thu, 10 Jan 2019 00:36:34 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EA0129C6A; Thu, 10 Jan 2019 00:36:33 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A9C6D22CFD; Thu, 10 Jan 2019 03:36:32 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 10 Jan 2019 03:36:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=i eK4N+xpo1iS5FEj/PXlSv8LcT8jL5IXToJluuF7PEA=; b=hCfQ+GAFVHjpY8CFW RKhL5lAAZORGLsqLnGUATPCaqbNy2Bc15X+q+36zdUoQP8zNGm1vRS8YAiH0O3+H kODG7AWjKVe8FhxG4LiS7ncVAhNbaXdfUx/xSdotInrsGWb0pRymuJBOde9Q4Phu nTt8rWywy5SUsK56wjUYlju9m9OgoDbTw2RSizXi/Fl23QPDt/H7mPmYV8lVxqB0 N0wp+xPe5JSfx5rRMKt13Sur5HJbcVjA/oIrdKotNv10QZZePCznZbTio2VW/8xi BvCbU/91m+yZ9KQLRFl4qNRk1Hs39JqiS3kA8w9haPVIaCqAPU60cvNcbivaxzQw cXU7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ieK4N+xpo1iS5FEj/PXlSv8LcT8jL5IXToJluuF7P EA=; b=DYhKI/QFLdluIVxp6WltIunyMucXkUkFQTvcKlXiN/jOKghi+Zbzr8A3l G8zZZYGbEZOTWM/+Fiqm/r6BeZFAI+TEo3bRIYgC9XYpQnB8Kk6GEupVS//emSPU IXyHBz9a+OaB7Eav4sbO3ZBrB9aEKQddQOkYLUXihBY1luRkfZ8dreqCW+PBgeM0 dOYJ1vr7alFULvLSVZuHPxw1isnq1Z2Jz8EGMiSYzxY9kvT5PYAJb4N8He9u2Pxy cbB8vrxUy+Upv6cqGSIEQy5WabIUBPtbKncuFgX60w50WotmdO5gZp2T4x5vIYpH fJHGRGdTt/qMW3vgrePWAm+cHX7/Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedvgdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhffojg ffgffkfhfvsehtqhhmtdhhtddvnecuhfhrohhmpeetlhgvgigvhicuofgvlhhnihhkohhv uceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucfkphepjeejrdelje drudeghedrheehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhes fhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.0.9] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id 24B25E4664; Thu, 10 Jan 2019 03:36:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2019 08:42:56 +0000 Cc: The IESG , extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, extra-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> To: Ben Campbell Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 08:36:37 -0000 Hi Ben, > On 9 Jan 2019, at 21:51, Ben Campbell wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for the work on this. I plan to ballot "yes", but have one item I t= hink > needs to be discussed first: >=20 > The security considerations say that this extension adds no new considerat= ions > not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm= not > sure that that is true. >=20 > It seems like the ability to insert a copy of message into a mailbox might= have > security and/or privacy considerations. Can you give me an idea of what you have in mind here, other than putting th= e user (Sieve script owner) over quota? In particular, what are the possible privacy implications? Thank you, Alexey > This seems analogous to the "fileinto" > action. I looked for security considerations for that in RFC 5228. All I f= ound > was a statement that "fileinfo" can be dangerous, but no elaboration on th= e > nature of the danger or how it might be mitigated. So while I agree that f= cc > would have similar considerations as "fileinfo", I'm not sure those > considerations have been adequately documented. (I expect people will poi= nt me > to something I missed, or where some other analogous feature is documented= , in > which case I will clear.) From nobody Thu Jan 10 06:56:56 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99654130EFE; Thu, 10 Jan 2019 06:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 LhoR9rnTzb6N; Thu, 10 Jan 2019 06:56:47 -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 047C3130ED9; Thu, 10 Jan 2019 06:56:46 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0AEuHj2043690 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 08:56:18 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547132179; bh=LwypdW+0t1i0EuD8AogPJBK7Zycc3idbnphESYkZMRE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=jblGQnGRzO+dhu17zJ0j5gCJIzio8mpIIeLbYsTviIaS6bwWK0bAYXbkp1/tSea4O KWvfVFW3K/8b9OFXOp1H5cwYfNzdPOU3MWky4Sp8I1fsbRjhGgyo8mHKx3FtRwHSbb DQ/yyIOLWxXCZF9yi6VeoSFIGR4lwxmBJf6eybss= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_84178FEF-D57A-43CF-BFAB-9FCAFC281495"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 10 Jan 2019 08:56:16 -0600 In-Reply-To: <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org To: Alexey Melnikov References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 14:56:49 -0000 --Apple-Mail=_84178FEF-D57A-43CF-BFAB-9FCAFC281495 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 10, 2019, at 2:42 AM, Alexey Melnikov = wrote: >=20 > Hi Ben, >=20 >> On 9 Jan 2019, at 21:51, Ben Campbell wrote: >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Thanks for the work on this. I plan to ballot "yes", but have one = item I think >> needs to be discussed first: >>=20 >> The security considerations say that this extension adds no new = considerations >> not already present in [RFC5228], [RFC5230], [RFC5435], and = [RFC6131]. I'm not >> sure that that is true. >>=20 >> It seems like the ability to insert a copy of message into a mailbox = might have >> security and/or privacy considerations. >=20 > Can you give me an idea of what you have in mind here, other than = putting the user (Sieve script owner) over quota? I can=E2=80=99t say that I know what the security considerations might = be; I=E2=80=99m just skeptical that the answer is =E2=80=9Cno new = considerations." The authors of 5228 thought =E2=80=9Cfileinto=E2=80=9D = could be dangerous. Do we know why? >=20 > In particular, what are the possible privacy implications? Could there be issues with, say, shared mailboxes? Or storing cleartext = for mail that would be sent encrypted? I suspect the answers may be more IMAP related than sieve related, but = even that might suggest citing something IMAP related. Ben. >=20 > Thank you, > Alexey >> This seems analogous to the "fileinto" >> action. I looked for security considerations for that in RFC 5228. = All I found >> was a statement that "fileinfo" can be dangerous, but no elaboration = on the >> nature of the danger or how it might be mitigated. So while I agree = that fcc >> would have similar considerations as "fileinfo", I'm not sure those >> considerations have been adequately documented. (I expect people = will point me >> to something I missed, or where some other analogous feature is = documented, in >> which case I will clear.) >=20 --Apple-Mail=_84178FEF-D57A-43CF-BFAB-9FCAFC281495 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw3XRAACgkQgFZKbJXz 1A0qfA/8Djx+T4CdztMcrXd162nDSg6sNe/RbHYbHn/SZppRgEVlOfI7v5M5Yqk1 W6pXd8b5cpynzSUyfcEL5HuN4tyVtIq/uaaMSghXIdUIKK715YrV/QNk+gmAPKC8 yb0/VrGqthhK+eggteEr+FhlJrMoIzVQOLNn6nFn72URnTVA0sFfWXGzU9dMTFt7 mdIvFKIQIUdUUm1ZkhhNoL5i0FtiQPKgmWKTe9EcXTBMjTj4tymAi3ncL8Nx0G1X c9PAfqTe4c+eEaku7pVIKdkq2DhKsDySO/8liGzd50KTCHmnQ25GAPRbymMPzGWP HLTDl0l+cur7TptKSqtP4TbSG/ozLp1JOah4ONr7jgqoEEct/jvU5/52MdEcOIQa b2kKjFhOutPLTdVWDECPL3OglFcVAFO3XnOnDAtmTuYXPkXULyLSAqJcXzBHR7ru 6e+hwKzpeetd6clP2qED6xu64T+dP0IFYPxNuhlovznpP1GBsNi77jGinTZ3z78b AXj4Z7gbmdVNvpKkgiT8K6UXtbbHMxYBzGnEtlF9PpGrtCR2qxE9+peWSYoc5dg6 OfliF2v2bPAVhSRqF/FDvwaAo6Ngyj5HGH2wbh3tLkqHeN8d49R8URD8h05LM6RA yJDpqVPsLNowpEhOgTQzsDKkS1Z/UYr+Tr7dvBF/pnSCsrbt4DY= =Rxf/ -----END PGP SIGNATURE----- --Apple-Mail=_84178FEF-D57A-43CF-BFAB-9FCAFC281495-- From nobody Thu Jan 10 07:15:11 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83E6130F15; Thu, 10 Jan 2019 07:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=kuiwvClb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NB2iEYKh 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 Xevstnwzxb_B; Thu, 10 Jan 2019 07:15:03 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7517130F1D; Thu, 10 Jan 2019 07:15:02 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C777921DE0; Thu, 10 Jan 2019 10:15:01 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 10 Jan 2019 10:15:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:date:in-reply-to; s=fm2; bh=p2i gAJr3CSqbUdxFlVxSPFasEdttFViZZh2hYMchBcM=; b=kuiwvClblRG009dqA8S RvrHMyjdeH5p6HBP2uC0MJJmKijgz0Y2BRPGINeIxyo+QviyxHZUu//oia2pjuXR qM63aC1KxZuSOVdrQ5RmjDgy504e5VRxuTQxzlNaYo6/BjTKjhrFHuIM+6FPSFoZ Egu1II3F27ZBXMv6uvw9ODjWRSdqP05Treh/oSHpqin/hlXjvD4laQkuNgtrGq5D pP3TOR/FOBvcw3qhH1RkP4fefqliNRDAnkKt51tcRkL13WCqCjenyeCfVSjhHnOp uPxB3+is1+STWZ1jkQhOjgzYmSeaj1G4DbftlHakCYBkk/oouVSHSvtC1pm6cQdK 0CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=p2igAJr3CSqbUdxFlVxSPFasEdttFViZZh2hYMchB cM=; b=NB2iEYKhioHasnTK1w8asKUb0u8SlJbyxnJM+dNyaMkpfC/edjVB1Hnrk 0h4x7KmI8PW17ZyrjClt170sRnser34mnDXL4hZ2/zHdYR/HH1ChY1dfCRWsfDLg q5ehUkvGWDCx/AzsfJFlspyAK3OgPjjX0y+R1pFFfR/7eKMlLff7og4q7aNJTej9 smTyV39tB4/QQ4JtPiL7UqVMykxx7YmXF4Qk3Jz3NsFtihKDAtNWfZSbDyR6+VGx x8G99bx1y9HdlOKocXDw/swGnd9vM/pMq2uzEBVtJGzWzfTALCMjA9RB00xz9VlY NyWeDy6OLVsdDwIWcnnfTDBFUc5WQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeefgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof hfufffjgesthhqredtredtjeenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcu oegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 21FA89E1EC; Thu, 10 Jan 2019 10:14:59 -0500 (EST) Message-Id: <1547133299.3806739.1630945640.44BE5606@webmail.messagingengine.com> From: Alexey Melnikov To: Ben Campbell Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> Date: Thu, 10 Jan 2019 15:14:59 +0000 In-Reply-To: <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 15:15:05 -0000 Hi Ben, On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell wrote: >=20 >=20 > > On Jan 10, 2019, at 2:42 AM, Alexey Melnikov w= rote: > >=20 > > Hi Ben, > >=20 > >> On 9 Jan 2019, at 21:51, Ben Campbell wrote: > >>=20 > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >>=20 > >> Thanks for the work on this. I plan to ballot "yes", but have one item= I think > >> needs to be discussed first: > >>=20 > >> The security considerations say that this extension adds no new consid= erations > >> not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131].= I'm not > >> sure that that is true. > >>=20 > >> It seems like the ability to insert a copy of message into a mailbox m= ight have > >> security and/or privacy considerations. > >=20 > > Can you give me an idea of what you have in mind here, other than putti= ng the user (Sieve script owner) over quota? >=20 > I can=E2=80=99t say that I know what the security considerations might be= ; I=E2=80=99m=20 > just skeptical that the answer is =E2=80=9Cno new considerations." The au= thors=20 > of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dangerous. Do we know= why? I don't remember now, even though I participated in the discussion. > > In particular, what are the possible privacy implications? >=20 > Could there be issues with, say, shared mailboxes? Possibly. I can write something about this. > Or storing cleartext for mail that would be sent encrypted? I can't think of how this is going to be possible. Sieve notifications/vaca= tion replies can disclose private information from Sieve script owner, but = storing such messages doesn't leak any more information (ignore shared fold= ers, I agree this might be an issue), because such messages will be stored = in one of owner's mailboxes . > I suspect the answers may be more IMAP related than sieve related, but=20 > even that might suggest citing something IMAP related. Best Regards, Alexey From nobody Thu Jan 10 07:29:34 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAF130EEA; Thu, 10 Jan 2019 07:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 xSW2qogPtQqs; Thu, 10 Jan 2019 07:29:16 -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 6378C130FFB; Thu, 10 Jan 2019 07:29:16 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0AFT3YK049062 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 09:29:04 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547134145; bh=fFa28l8duu9g/Z6u5nDDjbLekd9J5yzasVimXS3HjPw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=MWK45prBmWUCgQ6XmMA27WQIfqGsqFt1FcFlAj97exWwRBNyWSenHJNBdIKIlcpmU hTOLezOG5COthFYKL12MvdVb5ylATDkZ2+RXZyl4o3DNeSjtbtH5hHuQr+8C5yob9F pYBjhnNgO5ki1hhSeipCmANNuRPDkY0wg46DDe6s= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <1C3A8600-2EF7-4339-BD05-5C642476C0D7@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A0CB7605-0F2C-4340-84D2-F74F9334B292"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 10 Jan 2019 09:29:03 -0600 In-Reply-To: <1547133299.3806739.1630945640.44BE5606@webmail.messagingengine.com> Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org To: Alexey Melnikov References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <1547133299.3806739.1630945640.44BE5606@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 15:29:19 -0000 --Apple-Mail=_A0CB7605-0F2C-4340-84D2-F74F9334B292 Content-Type: multipart/alternative; boundary="Apple-Mail=_B4E60530-ECA5-431B-BEF2-E308677F53FC" --Apple-Mail=_B4E60530-ECA5-431B-BEF2-E308677F53FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 10, 2019, at 9:14 AM, Alexey Melnikov = wrote: >=20 > Hi Ben, >=20 > On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell wrote: >>=20 >>=20 >>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov = wrote: >>>=20 >>> Hi Ben, >>>=20 >>>> On 9 Jan 2019, at 21:51, Ben Campbell wrote: >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Thanks for the work on this. I plan to ballot "yes", but have one = item I think >>>> needs to be discussed first: >>>>=20 >>>> The security considerations say that this extension adds no new = considerations >>>> not already present in [RFC5228], [RFC5230], [RFC5435], and = [RFC6131]. I'm not >>>> sure that that is true. >>>>=20 >>>> It seems like the ability to insert a copy of message into a = mailbox might have >>>> security and/or privacy considerations. >>>=20 >>> Can you give me an idea of what you have in mind here, other than = putting the user (Sieve script owner) over quota? >>=20 >> I can=E2=80=99t say that I know what the security considerations = might be; I=E2=80=99m >> just skeptical that the answer is =E2=80=9Cno new considerations." = The authors >> of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dangerous. Do we = know why? >=20 > I don't remember now, even though I participated in the discussion. >=20 >>> In particular, what are the possible privacy implications? >>=20 >> Could there be issues with, say, shared mailboxes? >=20 > Possibly. I can write something about this. >=20 >> Or storing cleartext for mail that would be sent encrypted? >=20 > I can't think of how this is going to be possible. Sieve = notifications/vacation replies can disclose private information from = Sieve script owner, but storing such messages doesn't leak any more = information (ignore shared folders, I agree this might be an issue), = because such messages will be stored in one of owner's mailboxes . Doesn=E2=80=99t that make the safety of storing the message dependent on = having reasonable protections for the owner=E2=80=99s mailboxes? >=20 >> I suspect the answers may be more IMAP related than sieve related, = but >> even that might suggest citing something IMAP related. >=20 > Best Regards, > Alexey --Apple-Mail=_B4E60530-ECA5-431B-BEF2-E308677F53FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 10, 2019, at 9:14 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ben,

On Thu, Jan 10, 2019, at 2:56 = PM, Ben Campbell wrote:


On Jan 10, 2019, at 2:42 = AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ben,

On 9 Jan 2019, at 21:51, Ben Campbell <ben@nostrum.com> = wrote:

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks for the work on this. I plan = to ballot "yes", but have one item I think
needs to be = discussed first:

The security = considerations say that this extension adds no new considerations
not already present in [RFC5228], [RFC5230], [RFC5435], and = [RFC6131]. I'm not
sure that that is true.
It seems like the ability to insert a copy of message into a = mailbox might have
security and/or privacy = considerations.

Can you give = me an idea of what you have in mind here, other than putting the user = (Sieve script owner) over quota?

I can=E2=80=99t say that I know what the security = considerations might be; I=E2=80=99m 
just = skeptical that the answer is =E2=80=9Cno new considerations." The = authors 
of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be = dangerous. Do we know why?

I don't remember now, even = though I participated in the discussion.

In= particular, what are the possible privacy implications?

Could there be issues with, say, = shared mailboxes?

Possibly. I can write something about this.

Or = storing cleartext for mail that would be sent encrypted?

I can't think of how this is going to be possible. Sieve = notifications/vacation replies can disclose private information from = Sieve script owner, but storing such messages doesn't leak any more = information (ignore shared folders, I agree this might be an issue), = because such messages will be stored in one of owner's mailboxes = .

Doesn=E2=80=99t that make the safety of storing = the message dependent on having reasonable protections for the owner=E2=80= =99s mailboxes?


I suspect the answers may be more = IMAP related than sieve related, but 
even that = might suggest citing something IMAP related.

Best Regards,
Alexey

= --Apple-Mail=_B4E60530-ECA5-431B-BEF2-E308677F53FC-- --Apple-Mail=_A0CB7605-0F2C-4340-84D2-F74F9334B292 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw3ZL8ACgkQgFZKbJXz 1A2pFQ//XuKAekBP7ED8T89GXMgLdT0lKA48TdbbNBc4Sp5xuWy0IXpAH4diSNv1 OdNxX4lIXVeBmVObvbsZm3eBzxP60hHrV07FkE0irp3ojSxLoJVsUEQYoNdTaHJ4 7o9CBH42us0m/NDEQBGVJ7NKzPs23KhygdrXEDay0KXvJpRqtU2EAo829YMmGrbp yYdr4xXgJ7kSm3VDpbp4gm1UQgQ7Q8g41EaBKHJn4qpqaroboJ4YVriIdpOU7Zfm IweybzuIViA1eJcU3C0WN7bsJysMKorxtpnWSFfJoJpe4vpH19JlnM+RK912lH2s C/EMH+ICbK4O2qrPKXXLUCYEWnrAJZ+faI5dl4DkIG1zSML0xCdyxFH+Z/VQ5Bh+ pvgHNzmCREn8Qp1YA1LzbPVWxnpHDx815w1P3P9RuQLHKb/fYg1tPj9ZNgTDshGz HoiXklPk1NSbtntTPZLPo/JgeJ2UgCLf6T8CyuwfryaJkQ50KGl3H2uXKy7TENZv 06KuswhO9ptZASEePLDMQ4f0inRK1NZKEREhw2ryM87o1rqhi7APLxU4jhM/F/vV yaiZdkdCfDX+hdMsX+/D2TakNOl1UwzRbGzJJCyExkKNYCOmNCRO3h59aUrphqp2 7bKRb8f5DEfI+A3XyFs4/VqfjeSCLzgGYkG1RQeFEe/nruiAtlE= =pUWk -----END PGP SIGNATURE----- --Apple-Mail=_A0CB7605-0F2C-4340-84D2-F74F9334B292-- From nobody Thu Jan 10 08:23:23 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D7B130E73; Thu, 10 Jan 2019 08:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=BRaA9Dnd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LIKOECuy 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 hFJmsk2yTFYQ; Thu, 10 Jan 2019 08:23:18 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CFB130E71; Thu, 10 Jan 2019 08:23:17 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2DA42233AB; Thu, 10 Jan 2019 11:23:17 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 10 Jan 2019 11:23:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:date:in-reply-to; s=fm2; bh=Y1l rSgf4gOj6fsnnHjLdQf5wfJGI+NQ4Pht+WO1A5FQ=; b=BRaA9DndoNLqHLeYzZL iRVCI+wDyjIOObZpblaato9ppFBxbSkQ7jSlTwXM1zXd40q8rk65TAc3qOttlKZa sB6m55bnTDQ2Y47NHrOaFwKSvL5VidLttqjQLqJF+rgPTfWiLTSOzxBP7mXdgP4D PURJ63S+Q6vVljKNPsLrgiUfOiEpqM+uD5Sq1awTc6C3jJ5UIPewGp8vjYESumcu j6RlP4NAyOmhd98G9CBg6thu2AEy3lLoWK10Q5z96/J15yUBsDwKxe1aprmkKSCZ OXO+HiQZgllqO59C9Q/dd/2N8qicBfWbSdME2PRCm0Oa8d7TJIrAJsLv9jaREXi3 fqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Y1lrSgf4gOj6fsnnHjLdQf5wfJGI+NQ4Pht+WO1A5 FQ=; b=LIKOECuy4sE39YnsMsXqIKaWPwP5wl2Ahe05XxrYC5OSPXk4CN6hVeBGH /9CIwWxz+pQB1wNx0TkuTiQDE2QSrc1tAoRNZJH6MrJjpVFXYMxnVeZpar7CKmyt b73hm6mCtnRFsEn6jI7qeUWmdIYyN8g+WM6tF8TosIypngXEd9H7iHie85kMXahF TadD7VTxzm/4/gCdIZ9DpnS7bcnBTkrFIiHbl77u4dlVz4fbgikwSPkA3fo0CM7v NIPxAfhaqgoBiVfwVYfA3ZiHiqQISsQPcrkgmWmtqRTozEbGboYl5wikQft4GG46 hNYTZQEJGfMUQZYNGMEdIT2/hBmjg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeefgdekjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof hfufffjgesrgejreerredtjeenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcu oegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AB15C9E1EC; Thu, 10 Jan 2019 11:23:13 -0500 (EST) Message-Id: <1547137393.3825651.1631025328.2D213854@webmail.messagingengine.com> From: Alexey Melnikov To: Ben Campbell Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_154713739338256510" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <1547133299.3806739.1630945640.44BE5606@webmail.messagingengine.com> <1C3A8600-2EF7-4339-BD05-5C642476C0D7@nostrum.com> Date: Thu, 10 Jan 2019 16:23:13 +0000 In-Reply-To: <1C3A8600-2EF7-4339-BD05-5C642476C0D7@nostrum.com> Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:23:20 -0000 This is a multi-part message in MIME format. --_----------=_154713739338256510 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote: >> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov >> wrote:>>=20 >> Hi Ben, >>=20 >> On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell wrote: >>>=20 >>>=20 >>>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov >>>> wrote:>>>>=20 >>>> Hi Ben, >>>>=20 >>>>> On 9 Jan 2019, at 21:51, Ben Campbell wrote: >>>>>=20 >>>>> ------------------------------------------------------------------ >>>>> ---->>>>> DISCUSS: >>>>> ------------------------------------------------------------------ >>>>> ---->>>>>=20 >>>>> Thanks for the work on this. I plan to ballot "yes", but have one >>>>> item I think>>>>> needs to be discussed first: >>>>>=20 >>>>> The security considerations say that this extension adds no new >>>>> considerations>>>>> not already present in [RFC5228], [RFC5230], [RFC= 5435], and >>>>> [RFC6131]. I'm not>>>>> sure that that is true. >>>>>=20 >>>>> It seems like the ability to insert a copy of message into a >>>>> mailbox might have>>>>> security and/or privacy considerations. >>>>=20 >>>> Can you give me an idea of what you have in mind here, other than >>>> putting the user (Sieve script owner) over quota?>>>=20 >>> I can=E2=80=99t say that I know what the security considerations might >>> be; I=E2=80=99m>>> just skeptical that the answer is =E2=80=9Cno new co= nsiderations." The >>> authors>>> of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dangerou= s. Do we know why? >>=20 >> I don't remember now, even though I participated in the discussion. >>=20 >>>> In particular, what are the possible privacy implications? >>>=20 >>> Could there be issues with, say, shared mailboxes? >>=20 >> Possibly. I can write something about this. >>=20 >>> Or storing cleartext for mail that would be sent encrypted? >>=20 >> I can't think of how this is going to be possible. Sieve >> notifications/vacation replies can disclose private information from >> Sieve script owner, but storing such messages doesn't leak any more >> information (ignore shared folders, I agree this might be an issue), >> because such messages will be stored in one of owner's mailboxes .>=20 > Doesn=E2=80=99t that make the safety of storing the message dependent on > having reasonable protections for the owner=E2=80=99s mailboxes?IMAP acce= ss already requires TLS, so all message retrieval is already over encrypted channel. If you meant something else, can you please elaborate? >>=20 >>> I suspect the answers may be more IMAP related than sieve >>> related, but>>> even that might suggest citing something IMAP related. >>=20 >> Best Regards, >> Alexey >=20 --_----------=_154713739338256510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote:
On Jan 10, 20= 19, at 9:14 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ben,

On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell= wrote:


On Jan 10, 2019, at 2:42 AM, Alexey Melnikov= <aamelnikov@fastmail.fm&g= t; wrote:

Hi Ben,

On 9 Jan 2019, at 21:51, Ben Campbell <ben@nostrum.com> wrote:

----------------------------------------------------------------------=
DISCUSS:
----------------------------------------------------------------------=

Thanks for the work on this. I plan to ballot "yes", but have one item= I think
needs to be discussed first:

The security considerations say that this extension adds no new consid= erations
not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131].= I'm not
sure that that is true.

It seems like the ability to insert a copy of message into a mailbox m= ight have
security and/or privacy considerations.

Can you give me an idea of what you have in mind here, other than putt= ing the user (Sieve script owner) over quota?

I can=E2=80=99t say that I know what the security considerations might= be; I=E2=80=99m 
just skeptical that the answer is =E2=80=9Cno new considerations." The= authors 
of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dangerous. Do we k= now why?

I don't remember now, even though I participat= ed in the discussion.

In particular, what are the possible pr= ivacy implications?

Could there be issues with, say, shared mailboxes?

Possibly. I can write something about this.

Or storing cleartext for mail that would be sent encrypted?

I can't think of how this is going to be possi= ble. Sieve notifications/vacation replies can disclose private information = from Sieve script owner, but storing such messages doesn't leak any more in= formation (ignore shared folders, I agree this might be an issue), because = such messages will be stored in one of owner's mailboxes .

Doesn=E2=80=99t that make the safety of storing the message dependent = on having reasonable protections for the owner=E2=80=99s mailboxes?
IMAP access already requires TLS, so all message retrieva= l is already over encrypted channel.

If you meant something else, can you please elaborate?

I suspect the answers may be more IMAP related than sieve re= lated, but 
even that might suggest citing something IMAP related.

Best Regards,
Alexey


--_----------=_154713739338256510-- From nobody Thu Jan 10 08:27:55 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29356130E71; Thu, 10 Jan 2019 08:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 xnAPzCT6kIsm; Thu, 10 Jan 2019 08:27: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 78751127133; Thu, 10 Jan 2019 08:27:45 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0AGRUkA058633 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 10:27:32 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547137653; bh=uxnPX6iFDcBaKp4hne/kpxuCz1wAgZ8qWbnAJKzipF8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=BilJjv7VIzw2RAIejbmaZSUaGrzDyrzn7H0FfvxzzVXWz4dXGUDZa8xuL8zaA9yr/ xw+cVfNzffwQuTMuLA9YH0asQpGPb/QAwLeMMcvJdGwR0W6W/BgPW+1JBc3r14trw/ c9oyNEQ5m/CjBtCAjMKd8MV3exHya3pNmZhnoKG4= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <3CCF615E-6ABF-4681-BF75-A205B7B1B10E@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4F5586F1-0F4D-4809-88F3-177BEAD6C956"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 10 Jan 2019 10:27:29 -0600 In-Reply-To: <1547137393.3825651.1631025328.2D213854@webmail.messagingengine.com> Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org To: Alexey Melnikov References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <1547133299.3806739.1630945640.44BE5606@webmail.messagingengine.com> <1C3A8600-2EF7-4339-BD05-5C642476C0D7@nostrum.com> <1547137393.3825651.1631025328.2D213854@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:27:47 -0000 --Apple-Mail=_4F5586F1-0F4D-4809-88F3-177BEAD6C956 Content-Type: multipart/alternative; boundary="Apple-Mail=_7D343F0A-3869-47FD-898C-89B0F9ABF096" --Apple-Mail=_7D343F0A-3869-47FD-898C-89B0F9ABF096 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 10, 2019, at 10:23 AM, Alexey Melnikov = wrote: >=20 > On Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote: >>> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov > wrote: >>>=20 >>> Hi Ben, >>>=20 >>> On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell wrote: >>>>=20 >>>>=20 >>>>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov = > wrote: >>>>>=20 >>>>> Hi Ben, >>>>>=20 >>>>>> On 9 Jan 2019, at 21:51, Ben Campbell > wrote: >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> Thanks for the work on this. I plan to ballot "yes", but have one = item I think >>>>>> needs to be discussed first: >>>>>>=20 >>>>>> The security considerations say that this extension adds no new = considerations >>>>>> not already present in [RFC5228], [RFC5230], [RFC5435], and = [RFC6131]. I'm not >>>>>> sure that that is true. >>>>>>=20 >>>>>> It seems like the ability to insert a copy of message into a = mailbox might have >>>>>> security and/or privacy considerations. >>>>>=20 >>>>> Can you give me an idea of what you have in mind here, other than = putting the user (Sieve script owner) over quota? >>>>=20 >>>> I can=E2=80=99t say that I know what the security considerations = might be; I=E2=80=99m >>>> just skeptical that the answer is =E2=80=9Cno new considerations." = The authors >>>> of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dangerous. Do = we know why? >>>=20 >>> I don't remember now, even though I participated in the discussion. >>>=20 >>>>> In particular, what are the possible privacy implications? >>>>=20 >>>> Could there be issues with, say, shared mailboxes? >>>=20 >>> Possibly. I can write something about this. >>>=20 >>>> Or storing cleartext for mail that would be sent encrypted? >>>=20 >>> I can't think of how this is going to be possible. Sieve = notifications/vacation replies can disclose private information from = Sieve script owner, but storing such messages doesn't leak any more = information (ignore shared folders, I agree this might be an issue), = because such messages will be stored in one of owner's mailboxes . >>=20 >> Doesn=E2=80=99t that make the safety of storing the message dependent = on having reasonable protections for the owner=E2=80=99s mailboxes? > IMAP access already requires TLS, so all message retrieval is already = over encrypted channel. Is sieve limited to working only over IMAP? Even if =E2=80=9Cyes=E2=80=9D, that's a data-at-rest vs data-in-motion = question. >=20 > If you meant something else, can you please elaborate? >>>=20 >>>> I suspect the answers may be more IMAP related than sieve related, = but >>>> even that might suggest citing something IMAP related. >>>=20 >>> Best Regards, >>> Alexey --Apple-Mail=_7D343F0A-3869-47FD-898C-89B0F9ABF096 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 10, 2019, at 10:23 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

On = Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote:
On Jan = 10, 2019, at 9:14 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ben,

On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell = wrote:


On = Jan 10, 2019, at 2:42 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ben,

On 9 Jan 2019, at 21:51, Ben = Campbell <ben@nostrum.com> wrote:

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks for the work on this. I plan to ballot "yes", but have = one item I think
needs to be = discussed first:

The security considerations say that = this extension adds no new considerations
not already present in [RFC5228], [RFC5230], [RFC5435], and = [RFC6131]. I'm not
sure that that is = true.

It seems like the ability to insert a copy of message into a = mailbox might have
security and/or = privacy considerations.

Can you give me an idea = of what you have in mind here, other than putting the user (Sieve script = owner) over quota?

I can=E2=80=99t say that I know what = the security considerations might be; I=E2=80=99m 
just = skeptical that the answer is =E2=80=9Cno new considerations." The = authors 
of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be = dangerous. Do we know why?

I don't remember now, even though I participated in the = discussion.

In particular, what are the possible privacy = implications?

Could there be issues with, say, shared = mailboxes?

Possibly. I can write something about this.

Or storing cleartext for = mail that would be sent encrypted?

I can't think of how this is going to be possible. Sieve = notifications/vacation replies can disclose private information from = Sieve script owner, but storing such messages doesn't leak any more = information (ignore shared folders, I agree this might be an issue), = because such messages will be stored in one of owner's mailboxes = .
Doesn=E2=80=99t that make the safety = of storing the message dependent on having reasonable protections for = the owner=E2=80=99s mailboxes?
IMAP = access already requires TLS, so all message retrieval is already over = encrypted channel.

Is sieve limited to working only over = IMAP?

Even if =E2=80=9Cyes=E2=80=9D, = that's a data-at-rest vs data-in-motion question.


If you meant something else, can you please = elaborate?

I suspect the answers may be more IMAP related than sieve = related, but 
even that might suggest citing something IMAP related.

Best Regards,
Alexey

= --Apple-Mail=_7D343F0A-3869-47FD-898C-89B0F9ABF096-- --Apple-Mail=_4F5586F1-0F4D-4809-88F3-177BEAD6C956 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw3cnEACgkQgFZKbJXz 1A0JNw/9HvMLueGwAReyUiXhSa2rf6V69lHu775hdE736OJhLNwF7h1Owp0vIOsi 2Tm1YdTKRYcFXNLxhXAz6SMeuEy+938Oz/EggFDQRwAfQbWc4VoWHP5cIZB1fYi4 mWBk/F9I8RBbP9QxWagjyXhuYCYJ+r8FOYFdl25e1M5hvJ4doBhlt5GEJQrBCMb0 ET8k8X3MjiTTNI9II6Nyl7TTM5C6pivWNRWhvNvF3NEsvQLEFQ7VmTtYKgtEX7Yt LNwwbtmhACdd49LVZcjaqSKM74Oaqh5hFtO8u19384MYFEkISJShdgobjthrlq62 xkgTyHW0pv//WYs2XUKBrVf7VlH/RvRx6zPmY1GxPbeQfKQ4WLAQDPd+yV8yRmLc AlQ2mAEe/H1ihNX+kqWT+bXVTtNqbvlqeIltqSVLGQhoXKFQ7Vm8J9tnet3XS47y ueVZkSrBZiQ0zUZqot7Pd7S4qlcZXrwXMKfNwaS0+VmM2e5sbkwzD9jrrVAIzn0Z UqMwQNd2+LjZD15k043IpsWi+fkaPm91DidKTnxxJ9s/oC6F5KdyaYE5T8kfK3Dh +mLgC3wEMtpqbsUisyXw0YB8QconwkiYkCpXtawy+SUnLKrg/6h17bcyXr8/xVit q0EE7tzmblF1jogBR7RkV0ME9Ym4C0uS7NAPaA7PMw9Lr7pseMA= =z0tL -----END PGP SIGNATURE----- --Apple-Mail=_4F5586F1-0F4D-4809-88F3-177BEAD6C956-- From nobody Thu Jan 10 08:36:13 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E11130E82; Thu, 10 Jan 2019 08:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Pfz14clj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EQuSX4oF 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 9tjGovadLQK2; Thu, 10 Jan 2019 08:36:10 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3E0130E73; Thu, 10 Jan 2019 08:36:10 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3136F21F23; Thu, 10 Jan 2019 11:36:08 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 10 Jan 2019 11:36:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:in-reply-to:references:date; s=fm2; bh=xcS V1gY1dHHfK0BO8+K9IEzQDTdK/pPdH+a3k7c/Rk4=; b=Pfz14clj49M//dvogo7 GKkkqR91cm8J6PZq3hEX7LOZoEHOxEN8PDJH5cnigaAo/uT/TGv062ak0Ia58hrU rm3z+k33wUMEEyRCb2ByEhr72wMUKBZVdnkxMyYZ1Ayj1AUEQ+4pV46I1YPr96+n 1BCQssxdnStVHHNrbRW3yjWyFZ8iEqD3vQ5Hh8DgClgkvEuVxppA8Y3b1FUigqvB rV4RcT/wi0nRASqg911HoLcNKwxtrOKHYznOS1UtJj42QOQwOyeQcvXRjafbVDM5 FF/kw7ZFzW552wjWXm0rv44UQ2HOFws+LuVVJsiaAlVAt9F/H5HVqJYmfWqN8Itr 05Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=xcSV1gY1dHHfK0BO8+K9IEzQDTdK/pPdH+a3k7c/R k4=; b=EQuSX4oF+OwAGAWUkvl8IprWLiGRGDCD2O6UFFgAaNzD7vHOHJEdNRlG2 Yav6B5euAv2zgRUX4QK6A0VdbSCMcq84vpn3/i+VU8JA4J3R36ZPsaL5/o6ViL+u 7BP1vX35UzsIcSG+qkVv+Xy+Goln980kcdqfnKiwBzUi2rRiVA6KUKIzYydhP5Fd zfFS1iJzw7ETZyp4J27YQbmDq1HfxiCOQtiLJNKcJIDAZJ774HLrEe5KjzGSVHzO FRy2nVbzgr2tOsPLKK314njke8zZ2mCZvi5jO7R0RmuKx/umOvlGgm5QDLn29Z91 Q0UdtidJ0RInRTbnqfA0HKA6xfYzw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeefgdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof fujghfffesrgejreerredtjeenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcu oegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8CEA49E15D; Thu, 10 Jan 2019 11:36:06 -0500 (EST) Message-Id: <1547138166.3829145.1631037600.2E0CCD71@webmail.messagingengine.com> From: Alexey Melnikov To: Ben Campbell Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_154713816638291450" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 In-Reply-To: <3CCF615E-6ABF-4681-BF75-A205B7B1B10E@nostrum.com> References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <1547133299.3806739.1630945640.44BE5606@webmail.messagingengine.com> <1C3A8600-2EF7-4339-BD05-5C642476C0D7@nostrum.com> <1547137393.3825651.1631025328.2D213854@webmail.messagingengine.com> <3CCF615E-6ABF-4681-BF75-A205B7B1B10E@nostrum.com> Date: Thu, 10 Jan 2019 16:36:06 +0000 Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:36:12 -0000 This is a multi-part message in MIME format. --_----------=_154713816638291450 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Ben, On Thu, Jan 10, 2019, at 4:27 PM, Ben Campbell wrote: >> On Jan 10, 2019, at 10:23 AM, Alexey Melnikov >> wrote:>>=20 >> On Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote: >>>> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov >>>> wrote:>>>>=20 >>>> Hi Ben, >>>>=20 >>>> On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell wrote: >>>>>=20 >>>>>=20 >>>>>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov >>>>>> wrote:>>>>>>=20 >>>>>> Hi Ben, >>>>>>=20 >>>>>>> On 9 Jan 2019, at 21:51, Ben Campbell wrote: >>>>>>>=20 >>>>>>> ---------------------------------------------------------------- >>>>>>> ------>>>>>>> DISCUSS: >>>>>>> ---------------------------------------------------------------- >>>>>>> ------>>>>>>>=20 >>>>>>> Thanks for the work on this. I plan to ballot "yes", but have >>>>>>> one item I think>>>>>>> needs to be discussed first: >>>>>>>=20 >>>>>>> The security considerations say that this extension adds no new >>>>>>> considerations>>>>>>> not already present in [RFC5228], [RFC5230], = [RFC5435], and >>>>>>> [RFC6131]. I'm not>>>>>>> sure that that is true. >>>>>>>=20 >>>>>>> It seems like the ability to insert a copy of message into a >>>>>>> mailbox might have>>>>>>> security and/or privacy considerations. >>>>>>=20 >>>>>> Can you give me an idea of what you have in mind here, other than >>>>>> putting the user (Sieve script owner) over quota?>>>>>=20 >>>>> I can=E2=80=99t say that I know what the security considerations might >>>>> be; I=E2=80=99m>>>>> just skeptical that the answer is =E2=80=9Cno ne= w considerations." The >>>>> authors>>>>> of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dang= erous. Do we know why? >>>>=20 >>>> I don't remember now, even though I participated in the discussion.>>>> >>>>>> In particular, what are the possible privacy implications?>>>>>=20 >>>>> Could there be issues with, say, shared mailboxes? >>>>=20 >>>> Possibly. I can write something about this. >>>> >>>>> Or storing cleartext for mail that would be sent encrypted?>>>>=20 >>>> I can't think of how this is going to be possible. Sieve >>>> notifications/vacation replies can disclose private information >>>> from Sieve script owner, but storing such messages doesn't leak any >>>> more information (ignore shared folders, I agree this might be an >>>> issue), because such messages will be stored in one of owner's >>>> mailboxes .>>>=20 >>> Doesn=E2=80=99t that make the safety of storing the message dependent on >>> having reasonable protections for the owner=E2=80=99s mailboxes?>> IMAP= access already requires TLS, so all message retrieval is already >> over encrypted channel.>=20 > Is sieve limited to working only over IMAP? Sieve can talk directly to the mailstore over local API, IPC, some proprietary protocol, etc. This is not in scope for this document. >=20 > Even if =E2=80=9Cyes=E2=80=9D, that's a data-at-rest How messages are stored in any particular mailstore is outside the scope of both Sieve or IMAP. This was never specified in any RFC and this is not something unique to FCC anyway. But if you can suggest some specific text to add, the WG can discuss it. > vs data-in-motion question. >=20 >>=20 >> If you meant something else, can you please elaborate? >>>>=20 >>>>> I suspect the answers may be more IMAP related than sieve >>>>> related, but>>>>> even that might suggest citing something IMAP relat= ed. >>>>=20 >>>> Best Regards, >>>> Alexey Best Regards, Alexey --_----------=_154713816638291450 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Ben,

On Thu, Jan 10, 2019, at 4:27 PM, Ben Campbell wrote:
On Jan 10, 20= 19, at 10:23 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

On Thu, Jan 10, 2019, at 3:2= 9 PM, Ben Campbell wrote:
On Jan 10, 2019, at 9:14 AM, = Alexey Melnikov <aamelnikov@fa= stmail.fm> wrote:

Hi Ben,

On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell= wrote:


On Jan 10, 2019, at 2:42 AM, Alexey Melnikov= <aamelnikov@fastmail.fm&g= t; wrote:

Hi Ben,

On 9 Jan 2019, at 21:51, Ben Campbell <ben@nostrum.com> wrote:

----------------------------------------------------------------------=
DISCUSS:
----------------------------------------------------------------------=

Thanks for the work on this. I plan to ballot "yes", but have one item= I think
needs to be discussed first:

The security considerations say that this extension adds no new consid= erations
not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131].= I'm not
sure that that is true.

It seems like the ability to insert a copy of message into a mailbox m= ight have
security and/or privacy considerations.

Can you give me an idea of what you have in mind here, other than putt= ing the user (Sieve script owner) over quota?

I can=E2=80=99t say that I know what the security considerations might= be; I=E2=80=99m 
just skeptical that the answer is =E2=80=9Cno new considerations." The= authors 
of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dangerous. Do we k= now why?

I don't remember now, even though I participat= ed in the discussion.

In particular, what are the possible privacy implications?

Could there be issues with, say, shared mailboxes?

Possibly. I can write something about this.

Or storing cleartext fo= r mail that would be sent encrypted?

I can't think of how this is going to be possi= ble. Sieve notifications/vacation replies can disclose private information = from Sieve script owner, but storing such messages doesn't leak any more in= formation (ignore shared folders, I agree this might be an issue), because = such messages will be stored in one of owner's mailboxes .

Doesn=E2=80=99t that make the safety of storing the message dependent = on having reasonable protections for the owner=E2=80=99s mailboxes?
IMAP access already = requires TLS, so all message retrieval is already over encrypted channel.

Is sieve limited to working only over IMAP?
Sieve can talk directly to the mailstore over local API, = IPC, some proprietary protocol, etc. This is not in scope for this document= .


Even if =E2=80=9Cyes=E2=80=9D, that's a data-at-rest
How messages are stored in any particular mailstore is ou= tside the scope of both Sieve or IMAP. This was never specified in any RFC = and this is not something unique to FCC anyway. But if you can suggest some= specific text to add, the WG can discuss it.

vs data-in-motion question.

If you meant something else, can = you please elaborate?

I suspect the answ= ers may be more IMAP related than sieve related, but 
=
even that might suggest citing something IMAP related.

Best Regards,
Alexey
Best Regards,
Alexey

--_----------=_154713816638291450-- From nobody Thu Jan 10 08:40:45 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DB8130EC2 for ; Thu, 10 Jan 2019 08:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 8WveT7PEweVk for ; Thu, 10 Jan 2019 08:40:40 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id CDF5213106C for ; Thu, 10 Jan 2019 08:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547138439; d=isode.com; s=june2016; i=@isode.com; bh=+771bFwxYGTM32CxFLgNs5BQa1pk/rT1xmcapqSN+ik=; 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=VfNwVippD2LZDbWSdxbql7RVc9qFzhA2+3BDiRTt7hnFv0j5dGetQi1anif8Wff2xeOph/ rTc9NhKfZf1kp6wrTM1P8IOJfFr1PhO9BuT//7H88jUeNBbXMlyRbStg+8ZOiAG9I4WGM5 O413gcFHeKmL4I+F69LTdVtrskeIFUA=; 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, 10 Jan 2019 16:40:38 +0000 To: extra From: Alexey Melnikov Message-ID: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> Date: Thu, 10 Jan 2019 16:40:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Extra] Status of draft-ietf-extra-sieve-fcc X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:40:44 -0000 Hi, Based on IESG review, I think the document should have some text about the following security/privacy considerations: 1) Possible information disclosure from generated messages which are filed to shared folders (as opposed to private folders). I.e. non intended parties might discover that a Sieve script owner is on holidays, owner's location, etc. 2) FCC can put owner over quota, causing denial of service. I don't believe we need to come up with any novel solutions to these problems, but we should explain them. Best Regards, Alexey From nobody Thu Jan 10 08:43:13 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A58F130E86; Thu, 10 Jan 2019 08:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 FOZvWHdR4VbF; Thu, 10 Jan 2019 08:43:05 -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 2B5BC130E90; Thu, 10 Jan 2019 08:43:05 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0AGgfRS061068 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 10:42:42 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547138563; bh=mTO6bXVmr9yOdru7pQp0+f5Ehz1aYN2KRYNWCOi7boI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Xv1fixD0bDR9PCpY8uiWtrjKFCK45+v9BRIT6vDhqVYs9SA9b+1hY7Gi72gaejR8S 1y4FuQ268+n607AlhyMA/PTSxi2jEIn9c4FckW8LGAmEQgGcQZvFeng2xMBUABkjRv 2Q/E6WBp/GqkAMBP0iQfD1kRcyartup0TV7Z7cZo= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <931CF4CC-EE58-4B32-A877-0D58005FF29F@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0C4B27DA-0353-4BAA-A9B1-FBC717AA27D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 10 Jan 2019 10:42:40 -0600 In-Reply-To: <1547138166.3829145.1631037600.2E0CCD71@webmail.messagingengine.com> Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org To: Alexey Melnikov References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <1547133299.3806739.1630945640.44BE5606@webmail.messagingengine.com> <1C3A8600-2EF7-4339-BD05-5C642476C0D7@nostrum.com> <1547137393.3825651.1631025328.2D213854@webmail.messagingengine.com> <3CCF615E-6ABF-4681-BF75-A205B7B1B10E@nostrum.com> <1547138166.3829145.1631037600.2E0CCD71@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:43:07 -0000 --Apple-Mail=_0C4B27DA-0353-4BAA-A9B1-FBC717AA27D4 Content-Type: multipart/alternative; boundary="Apple-Mail=_CC00F4FA-9B48-4C82-B3D1-C20A97CE60C5" --Apple-Mail=_CC00F4FA-9B48-4C82-B3D1-C20A97CE60C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 10, 2019, at 10:36 AM, Alexey Melnikov = wrote: >=20 > Hi Ben, >=20 > On Thu, Jan 10, 2019, at 4:27 PM, Ben Campbell wrote: >>> On Jan 10, 2019, at 10:23 AM, Alexey Melnikov = > wrote: >>>=20 >>> On Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote: >>>>> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov = > wrote: >>>>>=20 >>>>> Hi Ben, >>>>>=20 >>>>> On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov = > wrote: >>>>>>>=20 >>>>>>> Hi Ben, >>>>>>>=20 >>>>>>>> On 9 Jan 2019, at 21:51, Ben Campbell > wrote: >>>>>>>>=20 >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>> DISCUSS: >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>=20 >>>>>>>> Thanks for the work on this. I plan to ballot "yes", but have = one item I think >>>>>>>> needs to be discussed first: >>>>>>>>=20 >>>>>>>> The security considerations say that this extension adds no new = considerations >>>>>>>> not already present in [RFC5228], [RFC5230], [RFC5435], and = [RFC6131]. I'm not >>>>>>>> sure that that is true. >>>>>>>>=20 >>>>>>>> It seems like the ability to insert a copy of message into a = mailbox might have >>>>>>>> security and/or privacy considerations. >>>>>>>=20 >>>>>>> Can you give me an idea of what you have in mind here, other = than putting the user (Sieve script owner) over quota? >>>>>>=20 >>>>>> I can=E2=80=99t say that I know what the security considerations = might be; I=E2=80=99m >>>>>> just skeptical that the answer is =E2=80=9Cno new = considerations." The authors >>>>>> of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dangerous. Do = we know why? >>>>>=20 >>>>> I don't remember now, even though I participated in the = discussion. >>>>>=20 >>>>>>> In particular, what are the possible privacy implications? >>>>>>=20 >>>>>> Could there be issues with, say, shared mailboxes? >>>>>=20 >>>>> Possibly. I can write something about this. >>>>>=20 >>>>>> Or storing cleartext for mail that would be sent encrypted? >>>>>=20 >>>>> I can't think of how this is going to be possible. Sieve = notifications/vacation replies can disclose private information from = Sieve script owner, but storing such messages doesn't leak any more = information (ignore shared folders, I agree this might be an issue), = because such messages will be stored in one of owner's mailboxes . >>>>=20 >>>> Doesn=E2=80=99t that make the safety of storing the message = dependent on having reasonable protections for the owner=E2=80=99s = mailboxes? >>> IMAP access already requires TLS, so all message retrieval is = already over encrypted channel. >>=20 >> Is sieve limited to working only over IMAP? > Sieve can talk directly to the mailstore over local API, IPC, some = proprietary protocol, etc. This is not in scope for this document. I=E2=80=99m not saying it should be in scope, but if the security = properties depend on a particular protocol being used it=E2=80=99s worth = mentioning that. >=20 >>=20 >> Even if =E2=80=9Cyes=E2=80=9D, that's a data-at-rest > How messages are stored in any particular mailstore is outside the = scope of both Sieve or IMAP. This was never specified in any RFC and = this is not something unique to FCC anyway. But if you can suggest some = specific text to add, the WG can discuss it. I was thinking something as simple as =E2=80=9CThe privacy properties = for data stored in any given mailbox depends on the access protocol used = and the underlying protections for the mailbox itself=E2=80=9D. That may = seem obvious, but sometimes we need to state the obvious. >=20 >> vs data-in-motion question. >>=20 >>>=20 >>> If you meant something else, can you please elaborate? >>>>>=20 >>>>>> I suspect the answers may be more IMAP related than sieve = related, but >>>>>> even that might suggest citing something IMAP related. >>>>>=20 >>>>> Best Regards, >>>>> Alexey > Best Regards, > Alexey --Apple-Mail=_CC00F4FA-9B48-4C82-B3D1-C20A97CE60C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 10, 2019, at 10:36 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi = Ben,

On = Thu, Jan 10, 2019, at 4:27 PM, Ben Campbell wrote:
On Jan = 10, 2019, at 10:23 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

On Thu, = Jan 10, 2019, at 3:29 PM, Ben Campbell wrote:
On Jan = 10, 2019, at 9:14 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ben,

On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell = wrote:


On = Jan 10, 2019, at 2:42 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ben,

On 9 Jan 2019, at 21:51, Ben = Campbell <ben@nostrum.com> wrote:

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks for the work on this. I plan to ballot "yes", but have = one item I think
needs to be = discussed first:

The security considerations say that = this extension adds no new considerations
not already present in [RFC5228], [RFC5230], [RFC5435], and = [RFC6131]. I'm not
sure that that is = true.

It seems like the ability to insert a copy of message into a = mailbox might have
security and/or = privacy considerations.

Can you give me an idea = of what you have in mind here, other than putting the user (Sieve script = owner) over quota?

I can=E2=80=99t say that I know what = the security considerations might be; I=E2=80=99m 
just = skeptical that the answer is =E2=80=9Cno new considerations." The = authors 
of 5228 thought =E2=80=9Cfileinto=E2=80=9D could be = dangerous. Do we know why?

I don't remember now, even though I participated in the = discussion.

In particular, what are the possible privacy = implications?

Could there be issues with, say, shared = mailboxes?

Possibly. I can write something about this.

Or storing cleartext for = mail that would be sent encrypted?

I can't think of how this is going to be possible. Sieve = notifications/vacation replies can disclose private information from = Sieve script owner, but storing such messages doesn't leak any more = information (ignore shared folders, I agree this might be an issue), = because such messages will be stored in one of owner's mailboxes = .
Doesn=E2=80=99t that make the safety = of storing the message dependent on having reasonable protections for = the owner=E2=80=99s mailboxes?
IMAP access already requires TLS, so all message retrieval is = already over encrypted channel.

Is sieve limited to working only over = IMAP?
Sieve can talk directly to the = mailstore over local API, IPC, some proprietary protocol, etc. This is = not in scope for this document.

I=E2=80=99m not saying it should be in scope, but = if the security properties depend on a particular protocol being used = it=E2=80=99s worth mentioning that.



Even if = =E2=80=9Cyes=E2=80=9D, that's a data-at-rest
How messages are stored in any = particular mailstore is outside the scope of both Sieve or IMAP. This = was never specified in any RFC and this is not something unique to FCC = anyway. But if you can suggest some specific text to add, the WG can = discuss it.

I was thinking something as simple as =E2=80=9CThe = privacy properties for data stored in any given mailbox depends on the = access protocol used and the underlying protections for the mailbox = itself=E2=80=9D. That may seem obvious, but sometimes we need to state = the obvious.


vs = data-in-motion question.

If you meant something else, = can you please elaborate?

I suspect the answers may be more IMAP = related than sieve related, but 
even that might suggest citing = something IMAP related.

Best Regards,
Alexey
=
Best Regards,
Alexey

= --Apple-Mail=_CC00F4FA-9B48-4C82-B3D1-C20A97CE60C5-- --Apple-Mail=_0C4B27DA-0353-4BAA-A9B1-FBC717AA27D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw3dgAACgkQgFZKbJXz 1A254BAAsHPw+7X623T2A+UMx2JIorkeP+nIjJomUk5Dcn2c8foA/Gp/BEQgzNr6 gCYm9A4uMJphp+ypSo1GvP/yEdEZh9QxegVYBMFYWt0+0BK6KFS2TDtp4BdcvrJO IVNMfzXwgnLxBkbhQBQTtQgXHHsYtQYwlWg7JZlz/S06o183izHHaJv5epkpPHLc 5ugoGiH86Yj6MejX23vWykaLTBvmXUQsFSMhV99XDvr4Tc7exBkaoyoLAN8m5dNV oU2a8BDSqz7UBHbS3O2kI5ZIddbuc66rzmTD8N9cLLKSv3A51rEBcFYI+Z0+K0cO nEEl/VF6TYhjmyncnsJ1fOFNUYqQuUsQAqzcg8H4ewIJb7qP//owUjEJCJfGOeY4 aHT9tHLHGyPSd7cgEtU94tXNF27EkFHSiYyzKq8Ns7UNmb7QlsQ39uhxyWzBkbvx uTtMVOCvRsfrnc5Z70nDlhrCBmSRZqww+ct6Fc0014xQvYxeb8Cg3f8MjK6OIM0z vLNTtBHVoHkJ/wggGFBTK+3GAv7M5t86r+Tsm+D0gQbu7kiIamLOapUZBhVj8c1P d/FpRS2+pBSzdMEqE4a++JgyTOE0+vSjj7h+ogw7kD6cUUh120yOZ8V+m6VYqJNP YkJdUHQmHHO9xGGMJfPZan9LPLcGamwHg5fEfNQf1ZI3KSpzKg8= =1IiF -----END PGP SIGNATURE----- --Apple-Mail=_0C4B27DA-0353-4BAA-A9B1-FBC717AA27D4-- From nobody Thu Jan 10 08:44:39 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B74128BCC for ; Thu, 10 Jan 2019 08:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=gUJ44Awz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=asVyMRcr 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 4C_io4ukhhSp for ; Thu, 10 Jan 2019 08:44:36 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D673126BED for ; Thu, 10 Jan 2019 08:44:36 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 00581243F3; Thu, 10 Jan 2019 11:44:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 10 Jan 2019 11:44:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=NMufXgyWcIw4BKxQR5tONaNULZf TK/nn7Nb8u/Xpo6M=; b=gUJ44AwzDu8dk/X901lRRtmuse4Xr/nAZpC52sPUFoj VeB2Tv+eSdv9SyqX29QAgx+L4Rni07r/jeAdc3qGR108D2lhrsdWizLkVa5Zoe7B EW5DT22P3eNFehWFSUrFbpQpHT0n4OkFv5Pr5qEtHxR3YeMxTQyn0PCelKg106gL rkq7mQzkDTu94TKkeYMSd4u7QVraTmoZyxrIthtVFR1XlTNF9cqF+F50wn8C3fwN 2gNhlTDl9kaCOAA0tAnsrHbhTN/VvU/yqZBY+/dNAAcFRDWBm86Z6jtTYe6IiPE7 3pGjUJNWKwgNJrX/NIcYjovwF3Ysn4BQgzQxEIusoAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=NMufXg yWcIw4BKxQR5tONaNULZfTK/nn7Nb8u/Xpo6M=; b=asVyMRcrmtn2w1GfsUnJx4 aUAla4JjhurizmwwTYCDe3M72vjXQRXQfpN7JKK2HPBzjK8/Cmtz7Hx2kaij4XXa MWTX+PU6feEH6YfUQSHvmFWeSdE7Lr6jSX77sX/wfjh2KGIOLL6qGO4IbF6UqBMw jDfLy1R2lsQ7MEl2Lg18t60NnP+o0QGIiyxjWNYk7326cLOrMBJ9psLlxW1cmq/T CShwBdJp4rye55l0FcnMUfkQm5QFrUYvJR3hMG84TkhyJ5GsB3i2A/q4mtoB1Qby jAM4l4UQGOgY5qWGvDTL4GUGb8dnYLmXmmIeOWPvH1Jbs5+RYGVGjGbNf3u3jcKQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeefgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhohfkff gfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehm uhhrtghhsehfrghsthhmrghilhdrtghomheqnecukfhppeejgedrjeejrdekhedrvdehtd enucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 707CF100BA; Thu, 10 Jan 2019 11:44:34 -0500 (EST) To: extra@ietf.org, Alexey Melnikov References: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <0f2de9ce-ae9e-5dfb-6212-9af8e7a181b2@fastmail.com> Date: Thu, 10 Jan 2019 11:44:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> Content-Type: multipart/mixed; boundary="------------C2EB129D83DB977B5B7ECA61" Content-Language: en-US Archived-At: Subject: Re: [Extra] Status of draft-ietf-extra-sieve-fcc X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:44:38 -0000 This is a multi-part message in MIME format. --------------C2EB129D83DB977B5B7ECA61 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/10/19 11:40 AM, Alexey Melnikov wrote: > Hi, > > Based on IESG review, I think the document should have some text about > the following security/privacy considerations: > > 1) Possible information disclosure from generated messages which are > filed to shared folders (as opposed to private folders). I.e. non > intended parties might discover that a Sieve script owner is on > holidays, owner's location, etc. > > 2) FCC can put owner over quota, causing denial of service. > > I don't believe we need to come up with any novel solutions to these > problems, but we should explain them. 3) Should I revert back to the RFC 5228 "fileinto" text about handling non-existent ":fcc" mailbox? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------C2EB129D83DB977B5B7ECA61 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------C2EB129D83DB977B5B7ECA61-- From nobody Thu Jan 10 08:46:11 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6BC130E97 for ; Thu, 10 Jan 2019 08:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 ye2dc0xqi09i for ; Thu, 10 Jan 2019 08:46:08 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5C703130E94 for ; Thu, 10 Jan 2019 08:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547138767; d=isode.com; s=june2016; i=@isode.com; bh=0vNJ9XyiqDDlJVbERHJoTUBDJ5DftJBTLvWr6vK8apU=; 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=Hc4wdRZeOgrB3pGlIDEwg4wA1WG4nlXKhJ+RDC1kRy2So4XWd5KaehcWtv2xU5F+fOVIHX kKrkCMdv/dXSfn87mHpWoJKd2bnEtYX/Ima+NJ/FCtvMdoBra2y/IC5ExyrxcW4cgQs5T6 kE9wrR0l15Awm5tt1FPlyKkU6W+3GZw=; 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, 10 Jan 2019 16:46:07 +0000 To: Ken Murchison , extra@ietf.org References: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> <0f2de9ce-ae9e-5dfb-6212-9af8e7a181b2@fastmail.com> From: Alexey Melnikov Message-ID: Date: Thu, 10 Jan 2019 16:45:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <0f2de9ce-ae9e-5dfb-6212-9af8e7a181b2@fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] Status of draft-ietf-extra-sieve-fcc X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:46:10 -0000 On 10/01/2019 16:44, Ken Murchison wrote: > 3) Should I revert back to the RFC 5228 "fileinto" text about handling > non-existent ":fcc" mailbox? I was talking purely about security considerations. You should do other changes to the document as agreed with IESG/on the mailing list. From nobody Thu Jan 10 10:46:32 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05C5130FAB; Thu, 10 Jan 2019 10:46:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 vNqImP4gSKLq; Thu, 10 Jan 2019 10:46:28 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790098.outbound.protection.outlook.com [40.107.79.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE88E130FA9; Thu, 10 Jan 2019 10:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9OGkmvgcLwumCDnBua/gtFB2g/6geQVUqslFO8cHRQU=; b=U/yNc5o9QYw+Y6lPYUP6k83FGV4soZ7GoftW37ezVEFguFPDVXXrz+xg7saljaiOhWBPf3mpa7WXcgW0KQPY5DiEpsVk5XuSLNhgNIKKLqHcCummB2N8704WqnRNtCELsbQGqsc1QF+6+Ijt+o3ORJDF8T+8qWSzyn81mTHC+cM= Received: from BN6PR0101CA0032.prod.exchangelabs.com (2603:10b6:405:2a::45) by BN8PR01MB5521.prod.exchangelabs.com (2603:10b6:408:ba::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.13; Thu, 10 Jan 2019 18:46:26 +0000 Received: from DM3NAM03FT038.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::204) by BN6PR0101CA0032.outlook.office365.com (2603:10b6:405:2a::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.14 via Frontend Transport; Thu, 10 Jan 2019 18:46:26 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT038.mail.protection.outlook.com (10.152.83.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.13 via Frontend Transport; Thu, 10 Jan 2019 18:46:25 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0AIkM2s017055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 13:46:24 -0500 Date: Thu, 10 Jan 2019 12:46:21 -0600 From: Benjamin Kaduk To: Ned Freed CC: The IESG , , , , Message-ID: <20190110184621.GO28515@kduck.mit.edu> References: <154707865829.4946.2773236088316133086.idtracker@ietfa.amsl.com> <01R1TSBIF7DU00004L@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <01R1TSBIF7DU00004L@mauve.mrochek.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(2980300002)(199004)(189003)(33656002)(6916009)(26826003)(6306002)(11346002)(956004)(54906003)(106002)(476003)(229853002)(36906005)(86362001)(316002)(106466001)(26005)(966005)(336012)(16586007)(446003)(486006)(478600001)(88552002)(75432002)(76176011)(2906002)(53416004)(186003)(7696005)(786003)(58126008)(14444005)(104016004)(426003)(8936002)(4326008)(6246003)(356004)(47776003)(6666004)(5660300001)(8676002)(23726003)(126002)(1076003)(246002)(97756001)(55016002)(305945005)(50466002)(46406003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR01MB5521; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT038; 1:uzaJn2XtvscYiCA+oVW7RiQjkPwdLU6hAULc85IYeHPzg2tm8N1/mKD+4O3ZgItnrRlGR1VjSP9E/NXeMuBtPB7S3A6l8NyBTMoAvYMp/r1+bpw+JXKXx/qgf2CsNsRX X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 78d0d3f8-47cf-4791-8adb-08d6772bece7 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BN8PR01MB5521; X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5521; 3:uNp6z0hFU76CyjlzH2sP7kJHfA+Y+mR/QEfEPhSzxvpUVFX19praoz05h3Q4Wj21RalgxhUWnXEf6irbJYHJyrjtPPEeiJXqkAeR9HZssJh4o5JbX6HTf2xHGuj35qC97nWl4DYQqH+QqHaJHqcWsyu+oC4oWTOP358LMg7m+kd/b6PJGIFPGHV/sFuUbJpBXhKueRW/A7A/e1N/JsXJ8wg2EJ1d71jBwxbxylwEMdX4iSXJRIo5kWo6HnhFfubkKm2el8LsF9yYC3i+Jm7g/n8aW+YmOd7ZSwGgzyVGlZSlcKchUmVS7WIEzcTC8v5Tz5xN+kbGMqL+oVGo7+FEwL0mZUqt20au7Xgdz6uuor2C+5lszuqjjkBnRyXBh/B2; 25:d8vOQHnc81hnlIGI/7xFdcZwxVcqXa+UI9Z0AdDJYiYPEHQ99SVDEFg5owBBw5ZFPWh16FStDzIQCzN9QY8DoT4mZvhZQAZdMPx/QMAN6uukounwDBjvWzB9tYJEZVzoiCi21efQ3lv3klcEMImgOhDgHxgr+o7LdLtUhQukAZPequr5WqyVp94PZ+KN1KK7iP4S+WOxbEE7dqmNN8y5N/DktaIy9OncDA+7FYKDoQS62iyeHxrAgh8n96YpWYrgUlI8YTRmip25cFsZSqxAneHMQqKPjrYvfxSlNAuQ6NabS4g+XwpBcVsY9HVb70znfxRntqEXY9uaJaaH20EbAQ== X-MS-TrafficTypeDiagnostic: BN8PR01MB5521: X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5521; 31:9dDRNaFr+DkKFGf8gpJxtl433LhH0CQ/Woe/ylETwdmfL0rgFUXK+2+AtOmChGqNXXhj4ed9H6SEdoZE71H03uDeAolYUJOUUxKRdvOpAm5TAhcsmNpP6BsuNYy07MabdflAd0QE/hN/biYB/mzkUp//iDlvlwvH4qKwlUNOCJ5cgNBI0YbBNF1qXC7DJa4dNsCNR0B84P6oYLPcZ8+LVGqBl2V+Nsex2vkN3d+J1c0=; 20:0uRUcBxfo1afvgxRg51E1qSQOGA9mD62Ns4n9rkA61FcycZiFt9E6MH55QyzbXhpB8qAmlqcyLmwhbqFM1SUB9OAU6K6wNg2EuKmz81el8dhvpdWC+DkdAU3sDpD+mXt7A1069gZjKG35TTNaayIT2smQkUYrHpODNukEmuuRnp430vDW3Jcbevj9kheDDqP6+LygTc+x/OAoLh5vUgv7l4z35LtHDdnBuNb+64qii1mL9m99QloElCeyQZDsH0yC4/fZ+jVjiRFOFexh3GVmpL8QD2zzaSjX8ETHN9z4UBG+uk13eVS/TW45yUWKjhZWw+uk2IKkvur0GFaf5CCF2UaDbQsDFL78141mO4Y1PZJCXZTogJZWS7QrkNKzRk/5g2GsMgOr4aYV5Rc3w+Hx/t4jYDTZw3D/OmgNXYNupYhKOBVe/Bd6HtDn1jsYxdHCjnRf62C4xdFqPlRmViUzeYKJxqf5iT2sRaFTa7ZfXGCkWRJHE6k3VdZgv0X2rGO X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5521; 4:PyG1Cgd2QpkYlfNAI37xVYsVQaDByihvDyE5/O9CdO6P7aC5C5xA6K6DWMGqhMON+dNxyydi2JeLomdAwX6+ZgOrsa6D03uY4MYTKGo7BMfmnVmTuu2nZkp5PUO6Sob8wbjJ06zC83DuM9qExQvkXLJkudDYKsxa6zaV+b9dYyzmibSfq4IuUbBuzq21N/wWlndkiBgdBusHZCTwYELwVWvFJ4FZ7AhNLXu4WMjxkAHZqXIyHTGWYLTlEV2NWwNpdAgiC7enjxxLOuC1xtMNV2b0G/jxRnO8YSf8AeGeiiHt7/s693LtPma8IMFbi2nC X-Forefront-PRVS: 0913EA1D60 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN8PR01MB5521; 23:/MA4qZONMIQ7ecMw4jk7kk28ekTBBRwZs1dJ1yjhY?= =?us-ascii?Q?Tgg1pWHsNI52Av5WNBNRl4bC9UKDI51vuFSfsjZbepV5lDm0MyOHu+hapl2k?= =?us-ascii?Q?6vKgiGPyOxQWGKtUoflTEyaSK0PRXk8Yh70O+EGfk/WhTF3lLQloc4X+d/Q3?= =?us-ascii?Q?rR9bACjv1cTzu83LnZ3nYAhAKwkvaoAvWf/ro2xuo2TIYQzgQojLvjXAdp6j?= =?us-ascii?Q?p2MlSQpPhqteVbJAHLp2O35Js75xjzbK247lBXv4VbjSY8iMk/xyfNTORgcy?= =?us-ascii?Q?yCLqPs+mrTXyJB/ICt+gPfsnxWYiUs5ocXjC9q3hsU82VzWPh0/b4k+SkzKn?= =?us-ascii?Q?QVClWKIiGBAay4Zxe2Mfp2uurEu7g+vQXO/mF2xop7VN64PCSRvBob7DrMfA?= =?us-ascii?Q?I2Ap5m43KfOscm+RJSyBJzf5JKrPxWrzHWHZ396KYx+MbHtjRiJ4hUBmvq2c?= =?us-ascii?Q?BeVyVfYIRHZHLiz7vJMLulkjg1OWr42uaqktDan2EaBzybG2ShMbKdGEZdQ8?= =?us-ascii?Q?c/ykaNH2SeRWk6ceJvWx+dJB1FUFT4QKMdwrGi3VQChjKe6XtrskfX7vN4lO?= =?us-ascii?Q?FcLbkN8fy/71QSgejUcIglArm3gEVr79TUpSfNuKFPCGJXyzxRY0V5khAR8u?= =?us-ascii?Q?qHf4ts5hwRUd+GrIToGPh69J5uJqEt9D6KakoK3HPit2CXtGGbzL/guQor0y?= =?us-ascii?Q?BnfIwqGOoXHlkAz/Zw9H0JHrSVr7i1R2dyI+TiX8BqcCt4ReXWNX9Xs4W7OW?= =?us-ascii?Q?Z4r490AIi6UY0vyu1mrtNl2KPQBd2iQ2CLsLc+FD0Sz7kJhgvE8xVQbkMmCB?= =?us-ascii?Q?f8wmmynvnth/pKEwwOXw9sTZIMS8gPGwXjdBIkhryT8/ULJqDrVGQLIVhswN?= =?us-ascii?Q?URTnDxTrazojPsZ0ucm8RH9brtBSp/QRyCi+juzuZlAQzq3aXpslBdSOgTol?= =?us-ascii?Q?qWMYVWISlje0Gz6uWjjJoEX+LJsugbCj4ksmD2i4lm8cSCnU8p0f6/30a9GM?= =?us-ascii?Q?P2OQNvnpAJgG9jNjTv6HVW1B/XOO+mxnh33+Ta5IZor5XsCiFSGPryjOb016?= =?us-ascii?Q?yvmGiF6S0pwE8IbLqFvPgn1HrIjuYDFCENqBylf3Mb+6at3zdnij+dpS4wge?= =?us-ascii?Q?6wqPsl9IxgQSHvdX+0oGviPvq0R37Zv2KxnS1Fe8L2s6I0l87q5Tl+n9huAR?= =?us-ascii?Q?OS0BtPPMiL5c14YahXFz1UwDITwl0ExWKv/4tJ3ljwfHbfcXZYISi0hXHLfA?= =?us-ascii?Q?WAnhhbk6WCTfYQbtI7kgr9CQVyPFP7uhx2AG3FC?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: VFER1OBGGACpk7dgq3+5MXROMc84/9zUBinY8/9Ez2THUnUieQqbpoImnAatp5WK21hCh6w6oYhQ6gtUNUb0OBNTCy+WZbH/UgYQ1AyAY10PDk6X+Mc7TAATviXYxnJ/Ummlh67tEO3HIdVSeJOlgfro5ygo9De6RuCHMB15cY/7VeT+gtMhyNmqSkXp6CaFPjjivMZ30lH+JkbjD+auhVK4ByVT1ZWq2D69Z4WY/GBep2tMXMwof4H66jAkv8pXGLrCcJWjwtuwXuW1AystTlKCNubN5ePBYqLhrEJsp+5unAJpg/z9DhHX8tOGf8u0 X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5521; 6:hlkIQiQ3NANdFFWlC2VnvMjeaBrELdTzendAee2t9Icw0TJFhWvCvIchUjay51iUMod9YgS0BUkqPyzYGs7qAbI0wYr2rivFOO03wNNA9R5fk/W8SjBqwXulBU3DEOnV9yvX3MrFPevIfDFM/9e93zAH+pMe1W2LOe6eN3w88I23MnwZtlJxT01oBqbim1KYx2k6ja6w8l9c357D5ahyy0n/eoixgEEumiljnqSCOQH0YNNrNU+7CecyujIhVRrm+Y42lI9tDjVYKZV2tJy6GV689uF+JnL6rY2gbnOCwJhJhgDAsm4bd/5IPt+KBJptfgqKIoMXH7/VwjhzmrJikZOI1ajQpm0hXhBM0nj9LgZpUfnVbo4+S8sOP62b2KgYFFGnZhW4V629kAk9FMYBt1vmg+aSLIv5kE+AM6VhxaIp7TgtBtNTEIgM6mskn88HzxjE1MgF0Qz6yFUFrxRdyw==; 5:ic3DtsC+/fC1HoVP5p/4P12574ADv6mxCwnx8aHfqeMGhq0qk7VqBkZ3tCP3YZJlRn9QUbjFZ6FqmPZnG3Iy4YvMYnVx1Fd/lS1n3pE55DyMV6IFYErgMP0iOvIpcpn/OC1qubn1K3wygrkdBw3wUP3cxSeYe99L32Gv+XiaqJxb5iyXvTmA/1A7PvTkI30GW7jmMlwiUTwomz1qQsk0IA==; 7:cf6kzUWprFIIEwWtYIJ9D+at4OpxTEGPsYvkFdI9PKaPm/a6hWHmdm5vToRFZdO6YLdsP5bQIhm11MGwLWlPOVrEtL9D1d8NHuSWg8Xw77FcLFP6483f6+7w9Q6J1zipENPnPjl8fq1dxMN298IfDA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2019 18:46:25.6400 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 78d0d3f8-47cf-4791-8adb-08d6772bece7 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR01MB5521 Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 18:46:31 -0000 On Wed, Jan 09, 2019 at 11:42:01PM -0800, Ned Freed wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-extra-sieve-fcc-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-extra-sieve-fcc/ > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > I support Ben's Discuss. I also have some other comments. > > > Section 1 > > > Each action that generates additional messages will need to specify > > how it interfacts with :fcc. [...] > > > Do we need to Update: 5228 so that authors of such future actions are aware > > of this requirement? > > Unfortunately Sieve extensions have a tendency to create new requirements > that subsequent extensions have to address. For example, the relational > extension specified in RFC 5231 adds additional match types that > subsequent extensions that specify new tests have to deal with. > > While I realize this is not ideal, I don't think it's reasonable to have to > update the base specification every time this happens. Okay. It sounds like there's a good culture already present here and not much to gain from an Updates relationship. > Specking as an implementor the great thing about Sieve is that the syntax never > changes so you never have to tweak your parser. This is a huge win. > > The less great thing is that any time something like this is added have to > check every place the semantic comes up and make sure you've handled all the > cases, meaning it's an O(N*M) sort of deal. The fact that N and M are small and > will remain so is what makes it manageable. > > > The syntax and semantics of the mailbox > > argument MUST match those of the mailbox argument to the "fileinto" > > action specified in Section 4.1 of [RFC5228]. If the specified > > mailbox doesn't exist, the implementation MUST file the message into > > the user's main mailbox (e.g. IMAP "INBOX"). > > > It's unclear that the "syntax and semantics MUST match" needs the 2119 > > MUST; it could just be "are defined to match". (Except they don't, since > > we add on the extra condition that a nonexistant mailbox name be delivered > > to the no-longer-implementation-defined INBOX folder instead of the other > > MAY options for fileinto.) > > A previous response of mine mentioned a similar issue in the special use > extension. On consideration, I think the use of compliance language here is > incorrect in regards to syntax since the Sieve implementation has no control I saw that other response, and agree that we should probably rethink our compliance language for these cases. > over what people put in their scripts, and until a script is evaluated there's > no way to be sure the syntactic requirements of the underlying store (which may > or may not be an IMAP store) are met. > > Semantics of a syntactically valid mailbox name are another matter. They really > do need to match whatever it is that fileinto does or we have a mess on our > hands. (FWIW, in our implementation there's no way it could work any other way > since the use of :fcc results (looks like this got cut off, but was just a side note anyway) > > Section 3.1 > > > Tagged arguments in future extensions to the > > "fileinto" action should describe their interaction with ":fcc", if > > any. > > > This is not a very strong statement. What would an implementor be expected > > to do upon encountering such future extensions that do not describe > > interaction with :fcc? > > Maybe "need to" rather than "should"? This isn't really a place where > compliance language should be used either since we're talking about > something future extension specifications need to do. I agree that we can't use compliance language here, and given the discussion above wouldn't make a big deal about this case either way (but "need to" is fine by me) > > (This requirement may also be a candidate for an > > Updates: relationship with 5228.) > > We didn't do that with RFC 5231. I'm not sure this is the time to start. > > > Section 3.1.2 > > > Perhaps note that implementations are permitted but not required to create > > the mailbox (if needed) without this extension. > > As previously discussed in the EKR comment thread, this definitely needs to be > sorted out. > > > Section 3.1.3 > > > It's a bit odd to update the behavior of another document that's still an > > I-D (vs. specifying the behavior in question in that document). > > But the same could be said about that document updating the behavior of this > one. I was thinking more that the two documents would advance together, with cyclical normative dependencies. So each just describes both the bits used from and used by the other, and presents it as "how things are". IIRC this is mostly up to the sponsoring AD, though. > > Section 5 > > > Usage: vacation [FCC] > > [":days" number | ":seconds" number] > > [":subject" string] > > [":from" string] > > [":addresses" string-list] > > [":mime"] > > [":handle" string] > > > > > This is presumably just my having skimmed RFC 5228 too quickly, but why is > > this [FCC] instead of [":fcc" string]" or similar? > > (Same for the notify action in Section 6.) > > FCC is defined in section 3.2. I think I wasn't sure how tightly bound the formal grammar and Usage statements were with each other -- the rest of the Usage statement didn't look like formal grammar on first glance. But there's plenty of ways I could have been wrong about that, so thanks for clarifying. > > Section 7 > > > Do we want to have a list of currently defined actions that are not > > compatible with the "fcc" extension, to avoid any confusion by future > > readers as to what was defined at the time of this writing? > > As noted previously, we had it and took it out based on review comments. I > don't especially care if we do or not, but we need to pick an approach and > stick to it. For my part, I'm happy just having heard that there was previous discussion, and won't pick a horse in the race. Thanks, Benjamin From nobody Thu Jan 10 12:57:06 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC29D12896A; Thu, 10 Jan 2019 12:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 nUIWC3VHH5vZ; Thu, 10 Jan 2019 12:57:02 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D846C130F3F; Thu, 10 Jan 2019 12:57:01 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1UIX4ZP1S00DTIY@mauve.mrochek.com>; Thu, 10 Jan 2019 12:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547153518; bh=rFOE7/017/zcFdz1RsDQmLfPZTZUMgDfFaESPrKrXJg=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=aqwR3E0lu3qsiaw1BR827z3UGVYD2ZEoM5FVGTtqV0ITCFcencUOpZBcdLpHjQBBA 9vSXnrui1nS2ui7rzj2nGv7JoxnxVTmGihZS3mkVqEIqGIq1vHuF+xbBE4YafuKHjL 5Os9C8ZJv8uyKFs5XVXpE3VUoccl1tXsl+kinbbI= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Thu, 10 Jan 2019 12:51:55 -0800 (PST) Cc: Alexey Melnikov , extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG , extra-chairs@ietf.org Message-id: <01R1UIX3NK2M00004L@mauve.mrochek.com> Date: Thu, 10 Jan 2019 09:53:12 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 10 Jan 2019 08:56:16 -0600" <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> To: Ben Campbell Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 20:57:04 -0000 > > On Jan 10, 2019, at 2:42 AM, Alexey Melnikov wrote: > > > > Hi Ben, > > > >> On 9 Jan 2019, at 21:51, Ben Campbell wrote: > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> Thanks for the work on this. I plan to ballot "yes", but have one item I think > >> needs to be discussed first: > >> > >> The security considerations say that this extension adds no new considerations > >> not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not > >> sure that that is true. > >> > >> It seems like the ability to insert a copy of message into a mailbox might have > >> security and/or privacy considerations. > > > > Can you give me an idea of what you have in mind here, other than putting the user (Sieve script owner) over quota? > I can’t say that I know what the security considerations might be; I’m > just skeptical that the answer is “no new considerations." I think this is demonstrably true. I'll first note that in terms of the sorts of messages it is capable of generating, the enotify extension with mailto: is effectively a superset of vacation. (Vacation is much more convenient to use and includes some additional builtin checks, but these aren't relevant here.) So it suffices to consider the notify :fcc case. Now compare the following sieves, each belonging to bob@example.com: [1] require ["enotify", "fcc"]; notify :fcc "INBOX.Sent" :message "Bob got mail!" "mailto:ken@example.com"; [2] require ["enotify", "fileinto"]; if header :is "subject" "Bob got mail!" { fileinto "INBOX.Sent"; } else { notify :message "Bob got mail!" "mailto:ken@example.com?to=bob@example.com"; } In case this isn't clear, the first script uses :fcc to make a copy of the notification and file it while the second uses a second notification recipient, test, and a fileinto to make the copy and file it. The results will likely differ in minor ways, e.g., Received: fields will probably be different, but since :fcc is constrained to have essentially the same semantics as fileinto, the security considerations aren't going to differ much if at all. The use of :fcc with actions defined in the future may result in additional security considerations, but we won't know what those are until it happens. Of course this also sidesteps the issue of whether or not the security considerations for fileinto are properly documented. > The authors of > 5228 thought “fileinto” could be dangerous. Do we know why? Yes, but I doubt you'll care for the answer much. (I certainly don't.) First, it's pretty obvious that there are risks with using fileinto. Off the top of my head: (1) Lost messages. An incorrectly set up fileinto, or a correct one that's set up and then forgotten can result in important messages being put in a place where nobody bothers to look. (2) Excessive disk usage. Lots of sites have automatic rules for cleaning out unread messages from commonly used mailboxes like INBOX or Junk. However, the assumption tends to be that since other folders have to be set up manually that they should have longer expiration times or not be subject to expiration policies at all. (3) Breaking non-idempotent workflows. Fileinto can be used to create additional copies of messages, and this can have bad effects on processors (including people) that fail to check for duplicates. (4) Creating large numbers of mailboxes. Combine fileinto and Sieve variables with a bit of carelessness, and you can achieve some spectacular results. Example: require ["fileinto", "variables"]; # File tagged list mail in an appropriate folder. if header :matches "subject" "*[*]*" { fileinto "List-${2}"; } (I note that this issue is described in more general terms in RFC 5229.) And so on. Similar lists can also be constructed for discard, redirect, ereject, etc. But here's the thing: Are these really the sorts of things that need to be listed in a security considerations section? Sure, they all have potential security ramifications, but the common factor in all of these is that somebody did something dumb. And the list of dumb things is effectively endless. Do we need to caution against having discard; or require "fileinto"; fileinto "Junk"; as your entire Sieve script? And if not, where do we draw the line? And perhaps more to the point, there's little if anything a Sieve implementer can do to prevent people from doing dumb things. In every case I've listed above - including the last two examples - there's a legitimate use-case that isn't dumb. Note: Speaking as someone who supports a Sieve implementation, users definitely do dumb things with sieves on a regular basis. In fact if I could add one recommendation to the base document, it would be that Sieve implementations running at or just before final delivery SHOULD log all actions the user' Sieve takes. Including explicit keep. Logging makes it possible to tell users what happened, and in most cases why. Of course the log then has privacy issues ... Even worse, we've now opened the door to a bunch of meta-issues that are well known to be ratholes: Exactly who is the target audience for security considerations? Where do we draw the line between "Obvious problem but sufficiently dangerous to be worth belaboring" and "Duh!!!"? Etc. And this brings us back to what's in RFC 5228. What's in there and what's not is a result of the fact that the process that produced that text in both RFC 3228 and 5228 was - and I'm being generous here - distinctly suboptimal. I don't think it's productive to get into the specifics of what went wrong, so let me just say that ratholes were involved, and by the time we extricated ourselves from those there was neither sufficient energy nor sufficient patience to try and flesh out what dangerous aspects of various actions needed to be discussed and which ones didn't. So we stuck in a dangerous bend sign and left it at that. In any case, while I acknowledge that the security considerations in RFC 5228 could and should be improved, I think doing so in a document that provides - let's face it - a power user feature and which is therefopre unlikely to be consulted by base specification implementors doesn't meet a cost-benefit analysis. I therefore support the text Alexey has suggested which I think goes just far enough. Ned From nobody Thu Jan 10 13:46:11 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37443131275; Thu, 10 Jan 2019 13:46:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 hKPY6-upnAFo; Thu, 10 Jan 2019 13:46:07 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680099.outbound.protection.outlook.com [40.107.68.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61F4131273; Thu, 10 Jan 2019 13:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ooeBRYJ1kzFI0nsDrIdrEDcbcYL37JJqTtA5ImIcW0g=; b=mRydXWKTI8iZHlpkSx4uLXSa8U2PR8S1q8mPHYUKF5rWlxuq8Ejy7Hqe/my+YVI7a/Tc/mgnGGd/VkTop6b9AYMPuRmY3y4KIN1F/WuCXeEcCGJsstHc+S0z5KwkL4pU4Lf1b7bZUzaLd/7vtzNoJ3tbaVlbg+Vvzd0NQa5mfuk= Received: from BN6PR0101CA0027.prod.exchangelabs.com (2603:10b6:405:2a::40) by CO2PR01MB2022.prod.exchangelabs.com (2603:10b6:102:6::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.9; Thu, 10 Jan 2019 21:46:03 +0000 Received: from DM3NAM03FT010.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by BN6PR0101CA0027.outlook.office365.com (2603:10b6:405:2a::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.13 via Frontend Transport; Thu, 10 Jan 2019 21:46:02 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT010.mail.protection.outlook.com (10.152.82.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Thu, 10 Jan 2019 21:46:02 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0ALjw1c016185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 16:46:00 -0500 Date: Thu, 10 Jan 2019 15:45:58 -0600 From: Benjamin Kaduk To: Ned Freed CC: The IESG , , , , Message-ID: <20190110214558.GQ28515@kduck.mit.edu> References: <154708325763.4990.14007827148353808097.idtracker@ietfa.amsl.com> <01R1TR9L1OVU00004L@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <01R1TR9L1OVU00004L@mauve.mrochek.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(396003)(39860400002)(2980300002)(199004)(189003)(106466001)(1076003)(7696005)(356004)(50466002)(47776003)(53416004)(16586007)(54906003)(76176011)(786003)(106002)(5660300001)(46406003)(316002)(186003)(26826003)(36906005)(86362001)(58126008)(478600001)(336012)(26005)(4326008)(6246003)(8676002)(2906002)(88552002)(8936002)(97756001)(104016004)(33656002)(305945005)(246002)(229853002)(55016002)(6306002)(6916009)(966005)(126002)(446003)(956004)(14444005)(486006)(11346002)(476003)(426003)(23726003)(75432002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB2022; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT010; 1:ROHM+OzAhFmwKnGSF6QpH612NIVjlQ1dD1zgmLffQv1P6wcIMUNMZ/QizCexbI2tZOoFTuJXC+HU5dFkuw8Z1yrwtaHir6q9ylEBWmST03CjzEQZRxOzF7hDCgWMoQza X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6fc35cc2-3dd7-4ecc-da5e-08d677450426 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:CO2PR01MB2022; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2022; 3:iw/F/FDYYUgfiGHdxMUUzHOttVJasB/g+7UrnvPoR+aZw0TzK9oUWQLX+zDB3rYmIlsWHxdcfwHfElgyyxSf9wPFJ+K/QXBsOBY1QtMt9CJav9UV85xcYNrbS5q+w0zlz0/IToKmCwnQv8jDOvIVcxuUE/VLqZz854qBcdwHrJtWnO2jj0Oxk6c5lpjRv6BMZQXKa3eneYERvtqkpAEOYu2lLfyTb0LNxZQh7PJ+4SSxbobdQlggz5j95YPN4A9DRQAaoLG4nTsimJEDQmTqGSTN2GX2WjWYw0aT3hfrH30Bn2YJYoRccF1wZZryZxx4o6p4JxG3QeLl8FNwyE0a7tRqp/hzlmRVp2sMhGNPI3WFY9SMtOhI9mQoYQkz0+fw; 25:xK1hFLURpJFw/st6wCLAgbZQ9lpS2d/73/KiKmTFxRTa+DPiMnE7lpV/PeIxKP8y7tqLwX3ZR7GbaMTVN2+3ZTI/q/5ES0x8UDjsUODzBdOXFbY1oqh3WBHDSTWX7h6gDISYzywkRpzJjIZdsxSXv1J9eOtvaU0Ba5bC9Rjexa12tpreepbY8ZOhhVkBq4507AV6uIRWM/6DXTIpZd93N5syuXAWMSkfXYKgjSwuZBk2bNCByimoRr2bUQdXjJJJGd/DsvREAEUwGqi44RcLeVx03n6HSex9CUPq0wVPjTJxQmJMGuksI18nVh5kyW1X3ubylCL0NwGc6zHk50kYPA== X-MS-TrafficTypeDiagnostic: CO2PR01MB2022: X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2022; 31:0Z9Aoq902VxlwTIiWwfWcT1X2DnpRbjN8C4PeCB39qsSlieaLn5lmmhkwjbMvepmsK8XQG1yPCEIuKqR/kihhmHmO/fdeUjO4aHQEE3RoOzBl/1BjT2ZIhVVlT6EIO/JbTa0FJkjVA5HBEYPBeeYYKxU7rrkAYatAl3tvLFgGo0fxt/HrcIpiukgXwNgeuWsywZWIwpasZYoO5Y4x+KjwRdVSCbTt8SemQVAFe3Qj5k=; 20:Xeoif5JLaAWGFTgrI7P966MKjdVtV1u30h1urcZP+1++vd3EmPYn1/7EEAYCp7RFCGBy3HxrHYRTne5hEobjjSGO96y18+9b3E2bseuHWeV7IzpVXhwxfNkkJeU7xPd9A9ycc4o1ND4CAJMJHWCLcvt7NWcDDmsg5x+4j/7hnMZI1vTEAoM037lBsES8r1JbjIlU54doa/cCpzK1wMpcaJi0559vx0KKkC/7gfXeW/+K7DjFbXzSh4kNoERImldfNq2nL7mN2wmpX21aO45gMrIMuzBPVpKfqLt81ZKmxtmpdMaLDa1i6Q6Vc/7c+HQDtfY1ap5IDzUXRsLb8TMpiI/0oaEQNlig+qhAnJEs6NKFFpfgME3kY4mYYHHqV3OOC+Xr9Nl4zY+qp6U6dtPUQOn1fttEA8hqZJG72kNLO2lxcirSfdM47oE0Nun85/STwxWnYoWnm7tf89+WCx5RSEH65iAj3H62BIgVLzv/L5wVKIKB9tuyHgCFt48+TQ2x X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2022; 4:AIDMpu/ZdN7LtboyWVAt5kaa3ZkpS8lGoTFP3R05fcE/GVXPyghkTI7epiYqeZHkWwUheJEgQZcDvwoxW3QSDO5FaR8L9K4JhBFo0AWSgOnxTCO8g2eumWRXQccNkbpUsF0KUIvgjNJOgNqJfGBEU6qof+0jx2mc/0lZfkamhx20+sPsHP3pM5xJD3ZprEu0zjhVi1VyP24FaNt3B4mQ0gpMj0KnwUer3E+6elxZ9yFE1BySHFZyt/nxByNenrMDywSrDR3gqwKV8ohNB6hxotus99Wj0iGuCHJ7DUUTaoxX1eokscoCg1HcqYrb/ZCs X-Forefront-PRVS: 0913EA1D60 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR01MB2022; 23:jaD3zCo/8iCmy+qMl9eYS6QgAo+zL1wD8UCVG3Ndd?= =?us-ascii?Q?t2Iy/hVF/WFC3Ges97QLl8tEUv5XJ89WEqb3bKWykUaOBJvYlInCwW8qGRCI?= =?us-ascii?Q?mDRi6oXOzCeQPLL5VoxGCqo/tcY6tmWYro50Q0N1ecnIBxG1f8hFSfzzrrvU?= =?us-ascii?Q?cTEkiN7y80PGI7OgYoT+vErOvYs3AU5rg1SUj7CY/asRH/zKLtQKE/5QSNDo?= =?us-ascii?Q?zXgIbpkg+CQCRVIm4ly+MLz0o6Es+4yGfwaqZpMCxbsQTBDxROH1t+1+nYOP?= =?us-ascii?Q?GdUHlw/mcH+GGR3Te9Lv7CBydt32EXVSVzqYfOWNzRcq97dk04DH6U+fIm3u?= =?us-ascii?Q?rVGivDvgKlNMewaR0R/IG08uC6QKo5QfMlg0nWPjCEa7hm65Fe4r3J/J+1C0?= =?us-ascii?Q?QW6wZzb2514XRA7R8N0gQemLP/cekOZLSqkyWuqgDlNRP2CGI2tNcM2d2gVX?= =?us-ascii?Q?qhZBkrRoCUqOX439bBpQRSWr4l+zNiCG/TZRHWc2XrvTsipyf6zHI9B/8khI?= =?us-ascii?Q?5/gWJ/nGRWF8w0hG6WsFdcoR1aLvyplq2QKoQ3A+9Bg7HPhdd73Eokr+2sT9?= =?us-ascii?Q?WEMDTQQEf6ALADKOsaqJFB5Q4UzUSEn28rm5aP1OZjhWUbWKMQ/kf19QQVxt?= =?us-ascii?Q?UX3902+DTxbyPf4gGnj3B1TzAuXaQXcdyVQQV+5dKmP9MIjKljQrXOWwmQeO?= =?us-ascii?Q?mVhYQNujhNIAHLplqBiB/wWXWozUyKxLwi1vdv/akh6Q7OvOeX8//JvJLnb6?= =?us-ascii?Q?/zCG6vf797uOK6pTpFdLT4I3lVjpmCeLrIuqSqk7r4B3M6MepUe8/Tzw0PjD?= =?us-ascii?Q?WocoxaekxH3UdoFWLRTmf2yfJkgT1zWJuoQ+uM/Qq0JWKFNdkax64VXLt2HI?= =?us-ascii?Q?+ljd0AYNg/tqMnzcMdDcQuH1wc3cim7al2JaK8ecti0qDqx8OEVK20md0Rh3?= =?us-ascii?Q?SUhUVR+l/4VkTul+UPOyUmqofDxODplsKoXhw6UNRdf+/dpiRBFPbbGMifXJ?= =?us-ascii?Q?5A4GClJC8G0DfZmebFnIavKnNZi+geWoy2euVKA9raINc4hsHAEAeSZgRhSl?= =?us-ascii?Q?6unKRiIZnm6DL0ktDQXMOpe7MfKrhob+m0Z6avjTzlCnljmYa0oBrfzLPPNT?= =?us-ascii?Q?Rp5p0eyn21+OYaRvTb4ZdWYK1lpfnt9J/VKxAZcc9Bvq4WV0oFQ+aqL4NM3q?= =?us-ascii?Q?Grq/dg3qlN7SQS+WYAZe0gRk+ppcZpH7kJcKpQ32wkApDJZ9ipvn2pB396aU?= =?us-ascii?Q?NdyfBebS3p+iki93R41uRl5OUDtBDYzs+238BVW?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: OXl5btDihH10SqhCrPMOuS+LU1Z1D7QGua0AZccjtUCaHW77HQPmJyP4CjlgjQO+fgAt2D7x96d1YQokO+lyJqSFAfOKIdHp36jOE/RBXldWXAhjBWB8VftkkE+UfaPXZ5bZMR1if4Z/2z7VqN2FPjc8gsKdXfVD7HtvmJlAa2qOGxDHXstDK3fC4uMWx4J2JX1O5eyOYYFcAJnQwlTBUCedR051+ns4Syuk5gp7EC+ZW6JtAsjtv8SMDHmiZQWt8VyqiYzhIYAXsh3pUCWafibRjZUuRglVGcI8VN+7Jl8WoHetIy7gUD/qzJx1uc9S X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2022; 6:RbnzPlbCs7sV4wg3ERP4l3w2wD3qTc0WPpx6GQSV1ihLBtf3Rjc3JQPvScQAyPyI/prBt3frmIX6d2ekrB0NCIaPl6M954l6P2x0JvQLTg51P13DKHNVMqlpQE2z5CW1POMybDq0SDTaMh2ilJTJvubnD5ChzgW4iSv0PyIs2Xj2exRzJ/fk0PPUARvIRlwB3509bhwyzKTLN4bFqE+3lYVwhDMAzido9royW5y/QkEicRZ02u5T7J5pAqazedOXzAu8J+dYXGxtcRnWXRtbry7cCIbfIcOLbnM7nFWul1V44BeWmVFT0tIv2l/m5ls/jkFouWJkwQaJ8Gi7BYRUNqiJMyfsxvSVAlhf8H4U1iq4VVJVjaAxHe+vXGeii2PFNr5jbKtILAPhxPkFSCNHR4jUVE/IsAy4K5zSWH1XWFySHBlYbNO8iZ63tyN+PyWEQNKhUFlb0rCzzPxG27IMOA==; 5:JRZ3bF8HMjLljiAp45qyKT+B17fBpji5lqXiOsYPCdXUtRCeuglrmECCXcIPLPR5nnNiMJpt/0WK46nJF2FH4tO7yWmCb5depJOaHJhvDT3+zbw2pn8bY/8uHoAzViqIBupeu5T/i7JTQakBEY2bgTVQt9S/8KfTT3h+yRAnQY0Jky/GFwyCvoAigC4M9ni/5ivA7IZSs+gHcu+gMlkoig==; 7:zA4A0G3MNwyr0be/mI4DDwy7cQxR7yc0PQP4WFV8QQEAsgC2sIjYT+rFUI1kMXVckDEysyFIZSdZAvi2Ibor/ULqAYpcVeFEv3L17HqUYMMVZmoqN+8JdiYwFNt7rdkdUMaukVTi3OpgPp4q7rFqRw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2019 21:46:02.1232 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6fc35cc2-3dd7-4ecc-da5e-08d677450426 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR01MB2022 Archived-At: Subject: Re: [Extra] Benjamin Kaduk's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 21:46:10 -0000 On Wed, Jan 09, 2019 at 11:31:27PM -0800, Ned Freed wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-extra-sieve-special-use-04: Yes > > > 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-extra-sieve-special-use/ > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > I'm balloting Yes because this document seems like it is going to do the > > right thing in helping to keep sieve up to date with IMAP. But I do still > > have a few comments. > > > Section 4 > > > Implementations SHOULD handle an invalid special- > > use flag in the same way as an invalid mailbox name is handled. The > > > (Does "invalid" mean "syntactically invalid" or "nonexistent" or something > > else? Presumably this is just a sieve convention that I've not been > > exposed to yet...) > > Given that the preceeding sentence in the paragraph is "The special-use flag > specified with the ":specialuse" argument MUST conform to the "use-attr" syntax > described in Section 6 of RFC6154 [SIEVE-MAILBOX]." I think it's actually > pretty clear that this is talking about syntax and not something. I suppose > changing it to say "syntactically invalid" would not hurt, but I don't really > think it's necessary given the context. Okay. > What actually concerns me more here is the MUST in the first sentence. This use > of compliance language strikes me as misplaced. Sieve scripts are specified by > users one way or another and say what they say; when we talk about compliance > in these documents we're talking about what a Sieve implementation has to do, > like the SHOULD in the second sentence, which is actually dealing with the > case where the MUST is violated. It's probably clearer to say something descriptive like "[...] flag specified with the ':specialuse' argument conforms to the 'use-attr' syntax described in [...]" -Benjamin > > However, while the > > set of mailboxes to which the involved special-use flags are assigned > > remains unchanged, implementations SHOULD ensure that the mailbox > > choice is made consistently, so that the same mailbox is used every > > time. Conversely, the chosen mailbox MAY change once the special-use > > flag assignments that are relevant for the mailbox choice are changed > > (usually by user interaction). > > > If delivery to the special-use mailbox fails for reasons not relating > > to its existence, the Sieve interpreter MUST NOT subsequently attempt > > delivery in the indicated default mailbox as a fall-back. Instead, > > it MUST proceed exactly as it does in case the ":specialuse" argument > > is absent and delivery to the mailbox named by its positional > > argument fails. This prevents the situation where messages are > > unexpectedly spread over two mailboxes in case transient or > > intermittent delivery failures occur. > > > It seems a little inconsistent to only avoid spreading messages over two > > mailboxes as a SHOULD for when multiple options exist but a MUST for > > transient delivery failure. But presumably this has already been > > well-discussed in the WG and I shouldn't try to reopen it. > > Yes it has. I am not happy with it, but given the semantics of special-use in > IMAP I don't see how it can be handled any other way. For example, if someone > has the same special-use flag on two different mailboxes, then removes them > both, then some time later puts them back, it's just not reasonable to expect > an implementation to remember the original ordering and return to it. > > > Section 4.2 > > > The IMAP example should probably use RFC 6761 domains. > > Agreed. > > Ned From nobody Thu Jan 10 14:16:39 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C71131285 for ; Thu, 10 Jan 2019 14:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 Tv2OhlrkKLcs for ; Thu, 10 Jan 2019 14:16:36 -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 5193313127E for ; Thu, 10 Jan 2019 14:16:36 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0AMGX2A015777 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 16:16:34 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547158595; bh=1/FAi1I6j2qFPBcfG1Oni1pZzQJUTCB84yyD5ZpPXPk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=kdLoJ3buK4EtuxM1/qwRuXE8lGOnP/3EdiyeV1EDqR+sj9PhukzTo9Nf+y9XwXP8F 1mBBAjMj7mjMjxfGSBFdBQ92Zj+Q9GR5B7zkWd0GiW+dv6dILYTbaIISXOUq0JNPRR KjjDAh0BL4MoNnn8ZqTvYr+tiuW2z8TeN6lUxinA= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <47A55584-25D5-409A-B5D0-884A9F8FAA30@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E61AA3E3-2C02-4FF3-A074-80DCA8C0578E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 10 Jan 2019 16:16:32 -0600 In-Reply-To: <01R1UIX3NK2M00004L@mauve.mrochek.com> Cc: draft-ietf-extra-sieve-fcc@ietf.org, Alexey Melnikov , extra@ietf.org, yaojk@cnnic.cn, The IESG , extra-chairs@ietf.org To: Ned Freed References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <01R1UIX3NK2M00004L@mauve.mrochek.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 22:16:38 -0000 --Apple-Mail=_E61AA3E3-2C02-4FF3-A074-80DCA8C0578E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 10, 2019, at 11:53 AM, Ned Freed wrote: >=20 >=20 >=20 >>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov = wrote: >>>=20 >>> Hi Ben, >>>=20 >>>> On 9 Jan 2019, at 21:51, Ben Campbell wrote: >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Thanks for the work on this. I plan to ballot "yes", but have one = item I think >>>> needs to be discussed first: >>>>=20 >>>> The security considerations say that this extension adds no new = considerations >>>> not already present in [RFC5228], [RFC5230], [RFC5435], and = [RFC6131]. I'm not >>>> sure that that is true. >>>>=20 >>>> It seems like the ability to insert a copy of message into a = mailbox might have >>>> security and/or privacy considerations. >>>=20 >>> Can you give me an idea of what you have in mind here, other than = putting the user (Sieve script owner) over quota? >=20 >> I can=E2=80=99t say that I know what the security considerations = might be; I=E2=80=99m >> just skeptical that the answer is =E2=80=9Cno new considerations." >=20 > I think this is demonstrably true. >=20 > I'll first note that in terms of the sorts of messages it is capable = of > generating, the enotify extension with mailto: is effectively a = superset of > vacation. (Vacation is much more convenient to use and includes some = additional > builtin checks, but these aren't relevant here.) >=20 > So it suffices to consider the notify :fcc case. >=20 > Now compare the following sieves, each belonging to bob@example.com: >=20 > [1] >=20 > require ["enotify", "fcc"]; > notify :fcc "INBOX.Sent" :message "Bob got mail!" = "mailto:ken@example.com"; >=20 > [2] >=20 > require ["enotify", "fileinto"]; > if header :is "subject" "Bob got mail!" { > fileinto "INBOX.Sent"; > } > else { > notify :message "Bob got mail!" = "mailto:ken@example.com?to=3Dbob@example.com"; > } >=20 > In case this isn't clear, the first script uses :fcc to make a copy of = the > notification and file it while the second uses a second notification = recipient, > test, and a fileinto to make the copy and file it. The results will = likely > differ in minor ways, e.g., Received: fields will probably be = different, but > since :fcc is constrained to have essentially the same semantics as = fileinto, > the security considerations aren't going to differ much if at all. >=20 > The use of :fcc with actions defined in the future may result in = additional > security considerations, but we won't know what those are until it = happens. >=20 I absolutely agree the security considerations for fcc are similar, = perhaps identical, to those for fileinto. > Of course this also sidesteps the issue of whether or not the security > considerations for fileinto are properly documented. That is my concern. >=20 >> The authors of >> 5228 thought =E2=80=9Cfileinto=E2=80=9D could be dangerous. Do we = know why? >=20 > Yes, but I doubt you'll care for the answer much. (I certainly don't.) = First, > it's pretty obvious that there are risks with using fileinto. Off the = top of my > head: >=20 > (1) Lost messages. An incorrectly set up fileinto, or a correct one = that's > set up and then forgotten can result in important messages being = put in a > place where nobody bothers to look. >=20 > (2) Excessive disk usage. Lots of sites have automatic rules for = cleaning out > unread messages from commonly used mailboxes like INBOX or Junk. = However, > the assumption tends to be that since other folders have to be set = up > manually that they should have longer expiration times or not be = subject > to expiration policies at all. >=20 > (3) Breaking non-idempotent workflows. Fileinto can be used to create > additional copies of messages, and this can have bad effects on > processors (including people) that fail to check for duplicates. >=20 > (4) Creating large numbers of mailboxes. Combine fileinto and Sieve > variables with a bit of carelessness, and you can achieve some > spectacular results. Example: >=20 > require ["fileinto", "variables"]; > # File tagged list mail in an appropriate folder. > if header :matches "subject" "*[*]*" { fileinto "List-${2}"; } >=20 > (I note that this issue is described in more general terms in RFC = 5229.) >=20 > And so on. Similar lists can also be constructed for discard, = redirect, > ereject, etc. >=20 > But here's the thing: Are these really the sorts of things that need = to be > listed in a security considerations section? I don=E2=80=99t think they all are. I=E2=80=99m primarily concerned = about things that could unintentionally expose information to third = parties. I guess data loss could be a secondary concern, but I=E2=80=99m = not as concerned about that. In email discussion so far, the only things that have come up that seem = to fit that is filing into a shared mailbox, or into a mailbox that is = otherwise not well protected. > Sure, they all have potential > security ramifications, but the common factor in all of these is that = somebody > did something dumb. And the list of dumb things is effectively = endless. Do we > need to caution against having >=20 > discard; >=20 > or >=20 > require "fileinto"; fileinto "Junk"; >=20 > as your entire Sieve script? And if not, where do we draw the line? >=20 > And perhaps more to the point, there's little if anything a Sieve = implementer > can do to prevent people from doing dumb things. In every case I've = listed > above - including the last two examples - there's a legitimate = use-case that > isn't dumb. >=20 > Note: Speaking as someone who supports a Sieve implementation, users = definitely > do dumb things with sieves on a regular basis. In fact if I could add = one > recommendation to the base document, it would be that Sieve = implementations > running at or just before final delivery SHOULD log all actions the = user' Sieve > takes. Including explicit keep. Logging makes it possible to tell = users what > happened, and in most cases why. Of course the log then has privacy = issues ... >=20 > Even worse, we've now opened the door to a bunch of meta-issues that = are well > known to be ratholes: Exactly who is the target audience for security > considerations? Where do we draw the line between "Obvious problem but > sufficiently dangerous to be worth belaboring" and "Duh!!!"? Etc. >=20 > And this brings us back to what's in RFC 5228. What's in there and = what's not > is a result of the fact that the process that produced that text in = both RFC > 3228 and 5228 was - and I'm being generous here - distinctly = suboptimal. >=20 > I don't think it's productive to get into the specifics of what went = wrong, so > let me just say that ratholes were involved, and by the time we = extricated > ourselves from those there was neither sufficient energy nor = sufficient > patience to try and flesh out what dangerous aspects of various = actions needed > to be discussed and which ones didn't. So we stuck in a dangerous bend = sign and > left it at that. >=20 My point was not to do a post-mortum on 5228, or to try to fix it. I=E2=80= =99m only concerned about any issue there to the extent that _this_ = draft relies on it. > In any case, while I acknowledge that the security considerations in = RFC 5228 > could and should be improved, I think doing so in a document that = provides - > let's face it - a power user feature and which is therefopre unlikely = to be > consulted by base specification implementors doesn't meet a = cost-benefit > analysis. I therefore support the text Alexey has suggested which I = think goes > just far enough. I think it=E2=80=99s likely that I agree; which text that Alexey = suggested do you refer to? If it=E2=80=99s down to mentioning shared = mailboxes and moving on, I=E2=80=99m fine with it at this point. Thanks! Ben. --Apple-Mail=_E61AA3E3-2C02-4FF3-A074-80DCA8C0578E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw3xEAACgkQgFZKbJXz 1A0v1RAAvWWaf4GYcgHs8Sk61qRCW9XvB3Cu8Vs4WOX0sacYuC3sw59+W0qfHjdL o5dffLD4dPFOB9msWiXtWAS7JExe+X0CIzcLimOrMRONbnUsxlMs7jvVU76Os+e4 7Lt900v18VLaU6kKGsvAvbPzE04V9VPyFNr6cOr2PHTf1nt+bRl4xiP0uCksSD8v urvPJvORL6z1siOeXHji8/oYGsU6zWCyBSyhoEpif2Pg4skxqofY+LlSIfUIZhdW OHhU4p5+3VovHBXg2Ht5/3IuywaWPHJQpwQAZuI6JEtgTRMFYTYOGDkJBWGYm3Tx 0aZD3/PX7TUGDL8drEy2N9Sm4oUO3oWQQ02tCYZCeUroIq/6oJtlspceSyh56PLP tvkyp3RPCyZ3xmJs4JCNaaltNY8UshNqG85or34vuqYlexmQReG2JDDFU82Jslet AMCcRWdU9LYi/1fDLpNqF18/ulRrttntgawiCY/hDWM/JqlY1LhbESsN3HJvXOS8 xQr0t69xFri9IMuvRDOi9OVWOR/VSkKf+Q2iyZYNf5/6ob8DPE6aw1UzDHI/Y4i8 livnaSyhQwdlajUU5DbKW1NA+qVkM0ejxjo+dsdNC8Yh57L0MhOO5FDrylKxtne5 Ld2wETCeCPVFHLfSbe6aWzKO0gMp9kRt9Qzig6ORTXt6Qy9XTkU= =+gf8 -----END PGP SIGNATURE----- --Apple-Mail=_E61AA3E3-2C02-4FF3-A074-80DCA8C0578E-- From nobody Fri Jan 11 07:48:38 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC70B124BF6; Fri, 11 Jan 2019 07:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 SgIypDQ9ZSEu; Fri, 11 Jan 2019 07:48:35 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DAE1228B7; Fri, 11 Jan 2019 07:48:35 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1VMG0L8SW00EYJ7@mauve.mrochek.com>; Fri, 11 Jan 2019 07:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547221410; bh=msVmzMYJRQuz8Va1MSkyt8OOzWokBSFMtQhMExOeAF0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=VWluXWKsZAYQcsdcoyJPWQ0bFC3OsFWsBlAjtzLSYw1zPesxVS3BLEc8qMczVwrFy mv7+gODCQC8JgKkcV/FX1OysMxs62VunCiQ8VG2cH+WvAtrwsl4wmXYO7XI3gVrURK EGhT+RRHJ+AUe/xZ58vdapTmgmCOEBlDxXnUP7es= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Fri, 11 Jan 2019 07:43:25 -0800 (PST) Cc: Ned Freed , draft-ietf-extra-sieve-fcc@ietf.org, Alexey Melnikov , extra@ietf.org, yaojk@cnnic.cn, The IESG , extra-chairs@ietf.org Message-id: <01R1VMFXYJC400004L@mauve.mrochek.com> Date: Fri, 11 Jan 2019 07:30:56 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 10 Jan 2019 16:16:32 -0600" <47A55584-25D5-409A-B5D0-884A9F8FAA30@nostrum.com> References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <01R1UIX3NK2M00004L@mauve.mrochek.com> <47A55584-25D5-409A-B5D0-884A9F8FAA30@nostrum.com> To: Ben Campbell Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 15:48:37 -0000 > I’m primarily concerned about things that could unintentionally expose > information to third parties. I guess data loss could be a secondary concern, > but I’m not as concerned about that. Since :fcc is handled locally the risk devolves down to whether or not the wrong someone can access the message after delivery. > In email discussion so far, the only things that have come up that seem to > fit that is filing into a shared mailbox, or into a mailbox that is otherwise > not well protected. Exactly. But this does gets back to what extent we want to warn people about doing dumb stuff. > ... > My point was not to do a post-mortum on 5228, or to try to fix it. I’m only > concerned about any issue there to the extent that _this_ draft relies on it. > > In any case, while I acknowledge that the security considerations in RFC 5228 > > could and should be improved, I think doing so in a document that provides - > > let's face it - a power user feature and which is therefopre unlikely to be > > consulted by base specification implementors doesn't meet a cost-benefit > > analysis. I therefore support the text Alexey has suggested which I think goes > > just far enough. > I think it’s likely that I agree; which text that Alexey suggested do you > refer to? If it’s down to mentioning shared mailboxes and moving on, I’m > fine with it at this point. See: https://mailarchive.ietf.org/arch/msg/extra/QcBHaAziCwHJJ4gvbO2XXB8IPB8 The proposal is to cover the shared folder issue as it relates to these sorts of messages as well as the possibility of quota issues. Ned From nobody Fri Jan 11 07:48:59 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025CF124BF6; Fri, 11 Jan 2019 07:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 DM8QZriSyztG; Fri, 11 Jan 2019 07:48:35 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C8812426E; Fri, 11 Jan 2019 07:48:35 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1VMIP5RBK00DNTO@mauve.mrochek.com>; Fri, 11 Jan 2019 07:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547221538; bh=ZAXhjALBq7FYkTJGv6cjCxyp9C7oP7FPx3k+gwK/dZc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=M5K+AkB7qPh87c7nscDTuwYPFO0GI82feeeWnln2Ps9VdtkHb26vGMBlCdCc6cZKb XsyhdZhdF4S0EmcGNyS6hwUhOLTy94RcCDfOh8U6D33kagrqE8TNk1tWxAyQBu7cMq Mu+cY1ZKW/pM2eeuDIEy8Q+OXZi9ia2iTPjCMmMs= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Fri, 11 Jan 2019 07:45:34 -0800 (PST) Cc: Ned Freed , The IESG , extra@ietf.org, draft-ietf-extra-sieve-special-use@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org Message-id: <01R1VMIMRH5A00004L@mauve.mrochek.com> Date: Fri, 11 Jan 2019 07:45:04 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 10 Jan 2019 15:45:58 -0600" <20190110214558.GQ28515@kduck.mit.edu> References: <154708325763.4990.14007827148353808097.idtracker@ietfa.amsl.com> <01R1TR9L1OVU00004L@mauve.mrochek.com> <20190110214558.GQ28515@kduck.mit.edu> To: Benjamin Kaduk Archived-At: Subject: Re: [Extra] Benjamin Kaduk's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 15:48:38 -0000 > On Wed, Jan 09, 2019 at 11:31:27PM -0800, Ned Freed wrote: > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-extra-sieve-special-use-04: Yes > > > > > 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-extra-sieve-special-use/ > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > I'm balloting Yes because this document seems like it is going to do the > > > right thing in helping to keep sieve up to date with IMAP. But I do still > > > have a few comments. > > > > > Section 4 > > > > > Implementations SHOULD handle an invalid special- > > > use flag in the same way as an invalid mailbox name is handled. The > > > > > (Does "invalid" mean "syntactically invalid" or "nonexistent" or something > > > else? Presumably this is just a sieve convention that I've not been > > > exposed to yet...) > > > > Given that the preceeding sentence in the paragraph is "The special-use flag > > specified with the ":specialuse" argument MUST conform to the "use-attr" syntax > > described in Section 6 of RFC6154 [SIEVE-MAILBOX]." I think it's actually > > pretty clear that this is talking about syntax and not something. I suppose > > changing it to say "syntactically invalid" would not hurt, but I don't really > > think it's necessary given the context. > Okay. > > What actually concerns me more here is the MUST in the first sentence. This use > > of compliance language strikes me as misplaced. Sieve scripts are specified by > > users one way or another and say what they say; when we talk about compliance > > in these documents we're talking about what a Sieve implementation has to do, > > like the SHOULD in the second sentence, which is actually dealing with the > > case where the MUST is violated. > It's probably clearer to say something descriptive like "[...] flag > specified with the ':specialuse' argument conforms to the 'use-attr' syntax > described in [...]" Works for me. Ned From nobody Fri Jan 11 10:08:02 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D900127AC2 for ; Fri, 11 Jan 2019 10:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 MSs3L_bqJJ73 for ; Fri, 11 Jan 2019 10:07:59 -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 87EDB1277CC for ; Fri, 11 Jan 2019 10:07:59 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0BI7urK007607 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 11 Jan 2019 12:07:57 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547230078; bh=Zt1+XbDqh9augCwECRinM4LP4fSXoXXaD9P38AHLV5U=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Z89lEHhZaxkz9O+X33pFQdviJWzH1A95v+n5LFLCcCshd1oEirq+j/oN39K5AWzcY lOvCcvMq5dIteKxq7DD+0bTx+qBwwwGJ6VOeGLaAG18vK5nplo5pvskTepz70zB2xp XqHsXy+VyhR+uXOVO009IuZf2C6VP2xVsf+fSOZ0= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <81499421-5F6D-4B2A-96EF-4352E1C6BC44@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AD3CFEA3-F119-49CB-A78B-6147489A5CC9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 11 Jan 2019 12:07:55 -0600 In-Reply-To: <01R1VMFXYJC400004L@mauve.mrochek.com> Cc: draft-ietf-extra-sieve-fcc@ietf.org, Alexey Melnikov , extra@ietf.org, yaojk@cnnic.cn, The IESG , extra-chairs@ietf.org To: Ned Freed References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <01R1UIX3NK2M00004L@mauve.mrochek.com> <47A55584-25D5-409A-B5D0-884A9F8FAA30@nostrum.com> <01R1VMFXYJC400004L@mauve.mrochek.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 18:08:00 -0000 --Apple-Mail=_AD3CFEA3-F119-49CB-A78B-6147489A5CC9 Content-Type: multipart/alternative; boundary="Apple-Mail=_8F8F1273-9364-4C90-BC8F-8E8ED58C3C36" --Apple-Mail=_8F8F1273-9364-4C90-BC8F-8E8ED58C3C36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 11, 2019, at 9:30 AM, Ned Freed wrote: >=20 >> I think it=E2=80=99s likely that I agree; which text that Alexey = suggested do you >> refer to? If it=E2=80=99s down to mentioning shared mailboxes and = moving on, I=E2=80=99m >> fine with it at this point. >=20 > See: >=20 > = https://mailarchive.ietf.org/arch/msg/extra/QcBHaAziCwHJJ4gvbO2XXB8IPB8 = >=20 > The proposal is to cover the shared folder issue as it relates to = these sorts > of messages as well as the possibility of quota issues. >=20 I am fine with that proposal. I will clear my DISCUSS. Ben. --Apple-Mail=_8F8F1273-9364-4C90-BC8F-8E8ED58C3C36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 11, 2019, at 9:30 AM, Ned Freed <ned.freed@mrochek.com> wrote:

I = think it=E2=80=99s likely that I agree; which text that Alexey suggested = do you
refer to? If it=E2=80=99s down to mentioning shared = mailboxes and moving on, I=E2=80=99m
fine with it at this = point.

See:

 https://mailarchive.ietf.org/arch/msg/extra/QcBHaAziCwHJJ4gvbO2= XXB8IPB8

The proposal = is to cover the shared folder issue as it relates to these = sorts
of messages = as well as the possibility of quota issues.


I= am fine with that proposal. I will clear my DISCUSS.

Ben.
= --Apple-Mail=_8F8F1273-9364-4C90-BC8F-8E8ED58C3C36-- --Apple-Mail=_AD3CFEA3-F119-49CB-A78B-6147489A5CC9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw423wACgkQgFZKbJXz 1A1HexAAzRfAVwCqorARTN4pVnThkgATS3Ko7LMR53mqe43px1QzbFh9EtH3I8Cx nK75Ckx+wfNx93ZvvNHa5lw9TCTsY51ZEml1ZNGWbynJHBlGNPYBVlXdSMmnh4NP hDUuoOxz/hgHJ/2uie1DKS5HweVM0jYcRDxu166zXxUVBDFrNOCt7BrR5OJGJ8uP fQhwLwlKbUkvdMClVAtTJbEazwcrXcGyyBEu3UL2yA3NIKkUEaMSi6r1rWNKNQo3 FAtu1XTS1lnKyWunK8IAwS8Av1G9MVwnhxv7gvF3hIlBx8Drok8hYgAI9QO//L7V w6SOSDnapkiNrQiDt46dLQB/MgRStwdBBaD5kNBwdAilSK7eCEvIW4lUxna+Rr9T lU6FU8s04TgTF4vTZIgeIz9E4Miaa0WAdeJfkIEKFaYABUynPz8V1dsM/4CCrcWI p8MrZBialZYIvu09jJRtm2jyQ4I/A5oIGkewW/Mm9pUozDrGXuRar/b5+lxGBA2J fJ0Hm1riuPvv2ReuwWBjesu5IPZCAcghPByba+bctzsuVQwBUofNT5hZWuVKbPUM 6rzY4Eno3GExuRE3cERyQjNpRvtWDXz7WThY1bcWDpzuOuf12lJ1UA6LCLZGg7Ca TgijzO6NVFmUFvH1oqhz1T6G5B4Q3HiTF1sJ59SPOTApX8Godsk= =PA3I -----END PGP SIGNATURE----- --Apple-Mail=_AD3CFEA3-F119-49CB-A78B-6147489A5CC9-- From nobody Fri Jan 11 10:10:10 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A601D1277CC; Fri, 11 Jan 2019 10:10:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154723020267.21974.8842298989488055017.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2019 10:10:02 -0800 Archived-At: Subject: [Extra] Ben Campbell's Yes on draft-ietf-extra-sieve-fcc-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 18:10:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-extra-sieve-fcc-08: Yes 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-extra-sieve-fcc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am clearing my DISCUSS, since conversation seems to be going in the right direction. I've included the DISCUSS text below for documentation purposes. The security considerations say that this extension adds no new considerations not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not sure that that is true. It seems like the ability to insert a copy of message into a mailbox might have security and/or privacy considerations. This seems analogous to the "fileinto" action. I looked for security considerations for that in RFC 5228. All I found was a statement that "fileinfo" can be dangerous, but no elaboration on the nature of the danger or how it might be mitigated. So while I agree that fcc would have similar considerations as "fileinfo", I'm not sure those considerations have been adequately documented. (I expect people will point me to something I missed, or where some other analogous feature is documented, in which case I will clear.) §1, last paragraph (nit): Should "each action" be "each new action"? §3.2, construction for FCC-OPTS: There is no extension point among the options, which would seem to require any new options update this RFC. Would it be reasonable to add one? From nobody Sat Jan 12 07:17:04 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E484F130E96; Sat, 12 Jan 2019 07:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=f0u+PYhY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bWWLTv68 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 QefAMohkePVX; Sat, 12 Jan 2019 07:17:01 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB45130E66; Sat, 12 Jan 2019 07:17:00 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B951321F4D; Sat, 12 Jan 2019 10:16:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 12 Jan 2019 10:16:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=3B3i5bgGpfPuiiNVnq8huq82Isl yPn1MJFbqfJYSAMU=; b=f0u+PYhY0FoEIS8WaVMt/WNP6BI0rLK4uMOSWFqvK+9 oOE0h0vh0bsw9Hd8YOh5V6swBZcxj79iJC+5Bsn/lo0e3NGxVYE3vVO9c0ngQ2/R 96M8ruuxp6YZ+Jf9w93c6mbuV01vpf3iItOF+n1WXs6aeIG6haBbo7bm1Ylk44R4 +DMNXyUjMIErB0n29Ky3VTEHeLTHaN21CgzmIRl5yyIdFhHc7cen0Yp3Yf/55v4t eKi+7/KxKUF9p0r77IkriX+IQoUNDT44FRRICFsRl6DEw7GUvPkcHK32n0HsbHC4 lNQqLN76L571/y4v0szMvlMUnqfuL91xTtETo1Z46vg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3B3i5b gGpfPuiiNVnq8huq82IslyPn1MJFbqfJYSAMU=; b=bWWLTv68DJ/CuY78cvHayP HWwn+YPe3dYbG97URqIN10tR6oi2nwacxY7o4VfQKUd1gP7Tfmx1+Cu6U1Pq4Vcy XYGtyxzBizrtpfsZ5TqqkIFwHRwehNtqjSsQd+EEefZfiADy6vUjEG64AfQfdm3d 7WP2rsWTOxq4MxlLh7EA424/pkNTpd38sQFoBbLpkYhOAySl2zhlmVx/GAz/YUG2 52VIJgtQ0xTcVuNILMTY+hv/FzUWf1LBmuC+ryJTFsg+VZMX6TejlB0xzfa7q9Pi PmpL62WsQ9ZEjAJ0Z1qqQFNo+Q8RtNC2QlbX/AM56ndjWceK4dOhposF6qbRdgFw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeejgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhohfkff gfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehm uhhrtghhsehfrghsthhmrghilhdrtghomheqnecukfhppeejgedrjeejrdekhedrvdehtd enucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 92765E44F4; Sat, 12 Jan 2019 10:16:55 -0500 (EST) To: Ben Campbell , The IESG Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, extra-chairs@ietf.org References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Sat, 12 Jan 2019 10:16:55 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------97936397C5C6C4129BD8563B" Content-Language: en-US Archived-At: Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 15:17:03 -0000 This is a multi-part message in MIME format. --------------97936397C5C6C4129BD8563B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ben, Thanks for the review. On 1/9/19 4:51 PM, Ben Campbell wrote: > COMMENT: > ---------------------------------------------------------------------- > > §1, last paragraph (nit): Should "each action" be "each new action"? > > §3.2, construction for FCC-OPTS: There is no extension point among the options, > which would seem to require any new options update this RFC. Would it be > reasonable to add one? The intention is that a new option could be added as such: FCC-OPTS /= ":foo" or FCC-OPTS /= BAR BAR = ":bar" string Is this insufficient or simply not clear from the text? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------97936397C5C6C4129BD8563B Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------97936397C5C6C4129BD8563B-- From nobody Sun Jan 13 07:02:56 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE28124BF6 for ; Sun, 13 Jan 2019 07:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=B/Zo7OME; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JfvSIkE2 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 0FeuGt8TrbHb for ; Sun, 13 Jan 2019 07:02:53 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808721228B7 for ; Sun, 13 Jan 2019 07:02:53 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 497952683A; Sun, 13 Jan 2019 10:02:52 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 13 Jan 2019 10:02:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=ygotJ8/qyErB13CdgcuO2PG1Azs KAlK0XhEpkMSPMIA=; b=B/Zo7OMEJb5N8LePURz1hLIwt+igg18wDEHa2uFPySr wevqp/Xf00mBRJCuu8a06Ax8Vqx9X7HI7G4hJkJWH5QM/fIx+U8cFA4B/O3ME6XI DZav41h9duzJyRL5+a0vGg5pexuNUQUBeCkmcxTE+BbXBTt4kZ7p5yJpdHltLRVw LZkFFdULPCYj7PmKWql/jb8XlT+I67i5Xb3m6kT3s7sXAz4EdKeZgSnHCcW9Jwbh nZTMX/xRaFlKqkj9TQtRRNB3Eq3iqDidAnEVrqonKWR2B7ijpv814brPkg5BPneP mpeP9qz3jEnLBGzZPpih4xpfBET1iSqphWehOEgvv5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ygotJ8 /qyErB13CdgcuO2PG1AzsKAlK0XhEpkMSPMIA=; b=JfvSIkE2QgC+K2Ij5UZp7u Zy713rGsMAbSkoaMq/WjiyvNzX8f41LAtjngIeZZVyLLgo6lGKeGMR0IAYLwjQgy krSARle+9y7ElfBOQ+6yJteRSZjVoxtFmsv4Ly32ifAvNfwoJYUClWXTAAjklS90 bF8TuxC/k1F4OEgkCqOwKWObsjULAOxqgjJCiMlLoDbH007vhQj1z4OxLLZUoqpr GrdTxPJxY18V0ufsUHFFw12ZdmwqON9g4/w/IiD6kfjegjGoJMMWiXYVsNiRAeJ/ KTig/1p4J64t1IEygJgefXbuN6N2OC/Hh17+mTruA7c3bJrsCAKbV1yMVduqb62w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeelgdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhohfkff gfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehm uhhrtghhsehfrghsthhmrghilhdrtghomheqnecukfhppeejgedrjeejrdekhedrvdehtd enucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 49D6FE407B; Sun, 13 Jan 2019 10:02:51 -0500 (EST) To: Alexey Melnikov , extra References: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <1f9e9303-6634-1e37-841f-f67d2d9c3a22@fastmail.com> Date: Sun, 13 Jan 2019 10:02:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> Content-Type: multipart/mixed; boundary="------------AD61CFDAD1E27AA950E69690" Content-Language: en-US Archived-At: Subject: Re: [Extra] Status of draft-ietf-extra-sieve-fcc X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 15:02:55 -0000 This is a multi-part message in MIME format. --------------AD61CFDAD1E27AA950E69690 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/10/19 11:40 AM, Alexey Melnikov wrote: > Hi, > > Based on IESG review, I think the document should have some text about > the following security/privacy considerations: > > 1) Possible information disclosure from generated messages which are > filed to shared folders (as opposed to private folders). I.e. non > intended parties might discover that a Sieve script owner is on > holidays, owner's location, etc. > > 2) FCC can put owner over quota, causing denial of service. How would this cause DoS?  If the FCC would put the user over quota, presumably this would be treated as a run-time error, and the incoming message would be be stored by an implicit keep.  Or are you just saying that the FCC itself is what would be denied? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------AD61CFDAD1E27AA950E69690 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------AD61CFDAD1E27AA950E69690-- From nobody Sun Jan 13 07:35:21 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9470312870E for ; Sun, 13 Jan 2019 07:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 9HvYo6vpD0lU for ; Sun, 13 Jan 2019 07:35:18 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5F2124BF6 for ; Sun, 13 Jan 2019 07:35:18 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1YEK9EV9S00F9MX@mauve.mrochek.com> for extra@ietf.org; Sun, 13 Jan 2019 07:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547393412; bh=eyLoIyrQSwsxAfB8a+/DWr0CfzD5S56Lfm62lufieC0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=EnQ2zLDaC4afzpYN47KGbre7sg4bwtp5X7rDbJ/Uf1AtrTNPmFI3rZH6Gu3kY6yrA ub9eJFH8Jxa89B22nY/j4YKgEnUq1OjKFBSFAaCgkERZAT2m03+hFzW2Ap3EqJEcNO 2q0iRjROOB5QFzzPc9ixBQiLfDPc3ZV9tKLNO9Rw= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Sun, 13 Jan 2019 07:30:09 -0800 (PST) Cc: Alexey Melnikov , extra Message-id: <01R1YEK77JMI00004L@mauve.mrochek.com> Date: Sun, 13 Jan 2019 07:22:49 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 13 Jan 2019 10:02:51 -0500" <1f9e9303-6634-1e37-841f-f67d2d9c3a22@fastmail.com> References: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> <1f9e9303-6634-1e37-841f-f67d2d9c3a22@fastmail.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] Status of draft-ietf-extra-sieve-fcc X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 15:35:20 -0000 > On 1/10/19 11:40 AM, Alexey Melnikov wrote: > > Hi, > > > > Based on IESG review, I think the document should have some text about > > the following security/privacy considerations: > > > > 1) Possible information disclosure from generated messages which are > > filed to shared folders (as opposed to private folders). I.e. non > > intended parties might discover that a Sieve script owner is on > > holidays, owner's location, etc. > > > > 2) FCC can put owner over quota, causing denial of service. > How would this cause DoS?  If the FCC would put the user over quota, > presumably this would be treated as a run-time error, and the incoming > message would be be stored by an implicit keep.  Or are you just saying > that the FCC itself is what would be denied? It's not the effect of a single fcc, but rather that fcc can be used to create an additional stream of messages, the cumulative effect of which would be to put the user at or over quota. As for the handling of situations where the fcc can't be delivered, we're talking about notifications here, and we've learned the hard way that generating more traffic as as result of a notification delivery failure is a REALLY bad idea. As such, I would expect an fcc delivery failure to be silently ignored. That's certainly how my implementation works. Ned From nobody Sun Jan 13 07:42:36 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A2D1288BD for ; Sun, 13 Jan 2019 07:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=Otn4nkLv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yHoQY1ok 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 L5RYknjrpZdy for ; Sun, 13 Jan 2019 07:42:32 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8B812870E for ; Sun, 13 Jan 2019 07:42:32 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B132621B74; Sun, 13 Jan 2019 10:42:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 13 Jan 2019 10:42:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=SFvmS/nZ01Ki49q8yR6qwYGavZp QSpStOMpa/jRQUp8=; b=Otn4nkLvWbCg/c9Zbj22aMUwNWY27o/4VaDb4iuNLAJ aO+PqNVt0s8KHphjqI5n8BamGQaP0OJTw0fnj2UEbBZ/0xtYsGAtQWJxx3hyORvB KgwtfcdXSp8gG3wVlyey77jIjb2YJtgsg/ygMX5M6gyGvddvbCbAfWhY12TE7b6T QlkbA1JksvAcjC11Bc8zDuxMLu3SpqQd9gCbMFlOceamzniSuIz2TGRP9dJObVd9 4A3o0avJexCkkx8xkFeRHfVbFeY3JqTe6TtL88Qp286Xj4iDF1Z+lghXwk4q7d+k +A74PylqcI+zGEGqNe6+bmukNGpGiXwo/khzNZAcROg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SFvmS/ nZ01Ki49q8yR6qwYGavZpQSpStOMpa/jRQUp8=; b=yHoQY1okWaJ9wWdajExTTV Tp5QfHtUqWqdMZJMyPEZzRwTbCkQRWQgcH+R9DdbABT+vk4sarJn/Z3rdGD/vBKe gs/YtVlIzZtWHDD06rio0ShSLXTWeJ1bGwRkl3nxDeD7m0iY5AC7Bpjo+R5vImrC 5AwHkNfatDC2toW32c3GvrOb1p+0pG1ZBSsRwUIQRbVjOcGQxDEeQGWIhi3jGFSB GsOLFYqTEKq5ySEK0E18Fg4okE5eOl2rvQjxXek/4dbPBoPO3Og32+SKyH4KC/G/ o0lx/VslINS7/mBqm6j/KL9LBUm4vqhN4WXKjqyWBGBW1U6vUIHSRhFWrGu4gjrg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeelgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhohfkff gfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehm uhhrtghhsehfrghsthhmrghilhdrtghomheqnecukfhppeejgedrjeejrdekhedrvdehtd enucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id D2536E407B; Sun, 13 Jan 2019 10:42:30 -0500 (EST) To: Ned Freed Cc: Alexey Melnikov , extra References: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> <1f9e9303-6634-1e37-841f-f67d2d9c3a22@fastmail.com> <01R1YEK77JMI00004L@mauve.mrochek.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Sun, 13 Jan 2019 10:42:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <01R1YEK77JMI00004L@mauve.mrochek.com> Content-Type: multipart/mixed; boundary="------------CA826A9F454300319ACF4911" Content-Language: en-US Archived-At: Subject: Re: [Extra] Status of draft-ietf-extra-sieve-fcc X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 15:42:34 -0000 This is a multi-part message in MIME format. --------------CA826A9F454300319ACF4911 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/13/19 10:22 AM, Ned Freed wrote: >> On 1/10/19 11:40 AM, Alexey Melnikov wrote: >> > Hi, >> > >> > Based on IESG review, I think the document should have some text about >> > the following security/privacy considerations: >> > >> > 1) Possible information disclosure from generated messages which are >> > filed to shared folders (as opposed to private folders). I.e. non >> > intended parties might discover that a Sieve script owner is on >> > holidays, owner's location, etc. >> > >> > 2) FCC can put owner over quota, causing denial of service. > > >> How would this cause DoS?  If the FCC would put the user over quota, >> presumably this would be treated as a run-time error, and the incoming >> message would be be stored by an implicit keep.  Or are you just saying >> that the FCC itself is what would be denied? > > It's not the effect of a single fcc, but rather that fcc can be used > to create > an additional stream of messages, the cumulative effect of which would > be to > put the user at or over quota. Ahh, yes!  I hadn't thought about that. > As for the handling of situations where the fcc can't be delivered, we're > talking about notifications here, and we've learned the hard way that > generating more traffic as as result of a notification delivery > failure is a > REALLY bad idea. As such, I would expect an fcc delivery failure to be > silently ignored. That's certainly how my implementation works. Should we add text to this effect? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------CA826A9F454300319ACF4911 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------CA826A9F454300319ACF4911-- From nobody Sun Jan 13 07:54:19 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C627112870E for ; Sun, 13 Jan 2019 07:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 vn9b8_SKIAYU for ; Sun, 13 Jan 2019 07:54:15 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4419F127B4C for ; Sun, 13 Jan 2019 07:54:15 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1YF7SA43K00FRLW@mauve.mrochek.com> for extra@ietf.org; Sun, 13 Jan 2019 07:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547394551; bh=wl6qqCTb4Bc10O7il4X5xlldoEVNqyJa3h9rdt0EuFQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=QVkKdmvDT5jX/YzUywqHFKDlJ7B5tq8UFnOzu5kE67t0eCrfXUMn4c5mG6kXeaOI5 ywEDi/BfJSKTzMnr3f2qEHy2y7LGO8QVpUp9WUGb3vjyre9bt3bSRLkMPSDxHFcDhO ol+ZoEKQtqTqloV/FXzhCum9DGFgr5AwyD7KpHC4= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Sun, 13 Jan 2019 07:49:03 -0800 (PST) Cc: Ned Freed , Alexey Melnikov , extra Message-id: <01R1YF7MV0SW00004L@mauve.mrochek.com> Date: Sun, 13 Jan 2019 07:48:26 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 13 Jan 2019 10:42:31 -0500" References: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> <1f9e9303-6634-1e37-841f-f67d2d9c3a22@fastmail.com> <01R1YEK77JMI00004L@mauve.mrochek.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] Status of draft-ietf-extra-sieve-fcc X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 15:54:17 -0000 > On 1/13/19 10:22 AM, Ned Freed wrote: > >> On 1/10/19 11:40 AM, Alexey Melnikov wrote: > >> > Hi, > >> > > >> > Based on IESG review, I think the document should have some text about > >> > the following security/privacy considerations: > >> > > >> > 1) Possible information disclosure from generated messages which are > >> > filed to shared folders (as opposed to private folders). I.e. non > >> > intended parties might discover that a Sieve script owner is on > >> > holidays, owner's location, etc. > >> > > >> > 2) FCC can put owner over quota, causing denial of service. > > > > > >> How would this cause DoS?  If the FCC would put the user over quota, > >> presumably this would be treated as a run-time error, and the incoming > >> message would be be stored by an implicit keep.  Or are you just saying > >> that the FCC itself is what would be denied? > > > > It's not the effect of a single fcc, but rather that fcc can be used > > to create > > an additional stream of messages, the cumulative effect of which would > > be to > > put the user at or over quota. > Ahh, yes!  I hadn't thought about that. > > As for the handling of situations where the fcc can't be delivered, we're > > talking about notifications here, and we've learned the hard way that > > generating more traffic as as result of a notification delivery > > failure is a > > REALLY bad idea. As such, I would expect an fcc delivery failure to be > > silently ignored. That's certainly how my implementation works. > Should we add text to this effect? Good idea. Ned From nobody Sun Jan 13 15:21:40 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B4F123FFD; Sun, 13 Jan 2019 15:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com 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 2tZJObT2cC-S; Sun, 13 Jan 2019 15:21:31 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFB012008A; Sun, 13 Jan 2019 15:21:31 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 4AC206A25F; Mon, 14 Jan 2019 00:21:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1547421689; bh=ugK50J3XhOo+v6EhRnpPY+cIA7F8TY5u8OgYVqmq3kA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=4I39GC46jhaVIxuGG2DjDv/7d75fg8LYi7cmELwZVLsMxCz/qFYj8rH5/yUrSG7ew 2gsa0x53EFT7vas1pSgwAYV2cX714NB+HV4JWgeO1CL/fKe23YNjlZp88YPHVGH0R5 WAv1NORV4ItdXfl7RoPyN4OUTivNRT1slenQuMemSpmiVHRpiTdkoSK+ZjxhXOVljq XoJxr+Jb8LFs3DOjkFLiYKltigUEwP6T6QhjkXlRrlMLPrJEZrMCZlgBvKLFWkZXKv 5V3YvXHAmlmYch/x8DAwZwfE7RIIcdxfxhxSIwUde74l2y+UhT95U+SII/GnjPu5Zq Ej8vq3GgVolsw== Received: from [10.168.3.2] (alcatraz.oxoe.int [192.168.32.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id A42A13C0028; Mon, 14 Jan 2019 00:21:28 +0100 (CET) To: Alissa Cooper , The IESG Cc: draft-ietf-extra-sieve-special-use@ietf.org, Jiankang Yao , extra-chairs@ietf.org, extra@ietf.org References: <154696317840.25571.13000547897657048147.idtracker@ietfa.amsl.com> From: Stephan Bosch Message-ID: Date: Mon, 14 Jan 2019 00:21:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <154696317840.25571.13000547897657048147.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 23:21:33 -0000 Hi Alissa, Op 08/01/2019 om 16:59 schreef Alissa Cooper: > Alissa Cooper has entered the following ballot position for > draft-ietf-extra-sieve-special-use-04: 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-extra-sieve-special-use/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please use the RFC 8174 boilerplate in Section 2. > > OK, will do. Kind regards, Stephan. From nobody Sun Jan 13 15:28:44 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8558F12008A; Sun, 13 Jan 2019 15:28:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <154742212344.14778.15643423403399115896@ietfa.amsl.com> Date: Sun, 13 Jan 2019 15:28:43 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-09.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 23:28:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Sieve Extension: File Carbon Copy (Fcc) Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-sieve-fcc-09.txt Pages : 15 Date : 2019-01-13 Abstract: The Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFC5230 and RFC5435 by adding a new tagged argument to the "vacation" and "enotify" actions respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-09 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-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 Sun Jan 13 15:30:23 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1B124408 for ; Sun, 13 Jan 2019 15:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=q8FgsXxK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MuJCJJ0q 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 1oy6u2jMV_-U for ; Sun, 13 Jan 2019 15:30:19 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7C5123FFD for ; Sun, 13 Jan 2019 15:30:19 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 6FE4627A32 for ; Sun, 13 Jan 2019 18:30:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 13 Jan 2019 18:30:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=jRt3paFDjdRekABYbll0oZ8I6Z7 wSO7npXZhmtZLCkk=; b=q8FgsXxKZT7uRfVF6AhnDmzl/s8a8nQIc61docrWKmx CW7BO/VdpnxAbst5i8BYfpaypu/wa2vrbmCYi+Rob3K2v6HomB1BRJnRNHryxq1k XrygHxXlb42KA2/eBPDqosftDJZI63hCGq8QMJcJdf0Rvn8ziD4UI3Ng+CBXs5g4 gC2uJyvXfNhFVZ8Vvf94wSrL77zfQnrvx9DaQDfc72MPX91Ku4lQUoyiynNs6vqM 9ItXvmZJsvcDAlGhJHxYl/BAZmwLrFNvLuhWuo+qzicQIqJORvmcnGJIj2MpP0Jg 2b6ddnJeQH8zhEsamQBre2rAPVl6JKu/PrQPDweR1Rw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jRt3pa FDjdRekABYbll0oZ8I6Z7wSO7npXZhmtZLCkk=; b=MuJCJJ0qmWlQly/VH3m/jC j9a9x42aPluJXn0FDUEYWpn1863aB9TAy8x2K251qKlqkU9QCbadk6a5VdhkU75W UbCF7imsr8pHqKQMrH7I7ap3kRBUOs+HC0J2/udTrRkc5V6jxF7C7LiqFN/9YGKT YZswWcLpMAq3zOToJqXcdDX2mDktHIpcr20xWenWjE9ceouxHAJ+F3FU4bDcvYhR iKZXnqoFlBat2nmizxd4Dc777DSk/o51+hQkxUQmQDirHqeYD4zHfLoQ8b5DJNue sAB1qhdtQHSb+eKD9cX1r01jw6ox2EDTxaXBXhL9ke1VcID0OjHTR4Z0+Pf2XewA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgedtgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefuvfhfhfhokffffgggjggtsehmtderredtfeejnecuhfhrohhmpe fmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeen ucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejgedrjeejrdekhedrvdehtdenuc frrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhmnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id EDB60E425A for ; Sun, 13 Jan 2019 18:30:16 -0500 (EST) To: extra@ietf.org References: <154742212344.14778.15643423403399115896@ietfa.amsl.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Sun, 13 Jan 2019 18:30:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <154742212344.14778.15643423403399115896@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------E51841AF17AE54B8EA12BC5F" Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-09.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 23:30:22 -0000 This is a multi-part message in MIME format. --------------E51841AF17AE54B8EA12BC5F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hopefully this draft addresses all of the IESG comments.  If it is lacking in that respect, suggested text would be greatly appreciated. On 1/13/19 6:28 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. > > Title : Sieve Extension: File Carbon Copy (Fcc) > Authors : Kenneth Murchison > Bron Gondwana > Filename : draft-ietf-extra-sieve-fcc-09.txt > Pages : 15 > Date : 2019-01-13 > > Abstract: > The Sieve Email Filtering Language provides a number of action > commands, some of which can generate additional messages on behalf of > the user. This document defines an extension to such commands to > allow a copy of any generated message to be filed into a target > mailbox. > > This document updates RFC5230 and RFC5435 by adding a new tagged > argument to the "vacation" and "enotify" actions respectively. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-09 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-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/ > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Ken Murchison Cyrus Development Team FastMail US LLC --------------E51841AF17AE54B8EA12BC5F Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------E51841AF17AE54B8EA12BC5F-- From nobody Mon Jan 14 03:59:55 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF75D131059 for ; Mon, 14 Jan 2019 03:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 70uzHZNBpmX1 for ; Mon, 14 Jan 2019 03:59:52 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1420D13104B for ; Mon, 14 Jan 2019 03:59:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547467174; d=isode.com; s=june2016; i=@isode.com; bh=BC0jEn65JHbkKAlQTfU61lEeMS3E6jJNmW8azD2QLew=; 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=qR36hyrjaMqwf3TYz5Uvqo88ssrlPCStGJ0AP/RYEUAfGVapudmOdvBGqQCu6wZ2D2X3/9 jHjYRpXFBQjU8VjLdrEPJLjS7I9eKaT+SDTFzLEGM2RtfvZnVQnONDAnuWQ4tm7C4z1NYB /d3I5GnkUqrP6uelSd8zYCRnscy3v8o=; Received: from [192.168.0.7] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 14 Jan 2019 11:59:33 +0000 To: extra@ietf.org, Michael Slusarz From: Alexey Melnikov Openpgp: preference=signencrypt Message-ID: <8c0e5e45-5646-f609-354a-077594228b9d@isode.com> Date: Mon, 14 Jan 2019 11:59:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: [Extra] AD review of draft-ietf-extra-imap-fetch-preview-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 11:59:54 -0000 Hi, This document is nearly ready for IETF LC and IESG review, but I have a few comments that require a bit of work to address: In Section 1: A server that supports the PREVIEW extension indicates this with one or more capability names consisting of "PREVIEW=3D" followed by a supported preview algorithm name. This format provides for future upwards-compatible extensions and/or the ability to use locally- defined preview algorithms. This is not reflected in the ABNF section (Section 7). See my comment on section 7 below. In Section 3.2: The algorithm used by the server to generate the preview is returned preceding the preview string. The server returns a variable-length string that is the generated preview for that message. Having an example at this point would make it easier for reader to understand the document. In Section 4.1: If the FUZZY algorithm generates a preview that is not based on the body content of the message and the LANGUAGE [RFC5255] extension is Is preview is not based on the body content, what is it based on? Do you mean header fields from the message? supported by the server, the preview text SHOULD be generated according to the the language rules that apply to human-readable text. In Section 5.1: How would the client know when to try to retrieve LAZY preview again? In Section 7: The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in ABNF [RFC5234]. It includes definitions from IMAP [RFC3501]. capability =3D/ "PREVIEW=3DFUZZY" This doesn't quite much what you specify in Section 1. Maybe change it to: capability =3D/ "PREVIEW=3D" preview-alg ? fetch-att =3D/ "PREVIEW" [SP "(" preview-alg-fetch *(SP preview-alg-fetch) ")"] msg-att-dynamic =3D/ "PREVIEW" SP "(" preview-alg SP nstring ")" preview-alg =3D "FUZZY" / preview-alg-ext preview-alg-ext =3D preview-atom ; New algorithms MUST be ; registered with IANA And you don't define the procedure for registering these in the IANA Considerations section. preview-mod-ext =3D preview-atom ; New priority modifiers MUST be ; registered with IANA As above: this needs to have the corresponding IANA Considerations text. In Section 10: There are no known additional security issues with this extension beyond those described in the base protocol described in IMAP4 [RFC3501]. I am not entirely convinced that this is true. This extension either requires more disk storage or more computation on the server. Both can cause some form of Denial-of-Service. (And disk storage space might be worth calling out as a separate operational consideration) Best Regards, Alexey From nobody Mon Jan 14 08:22:44 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4E4131149 for ; Mon, 14 Jan 2019 08:22:41 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 6IpBduonW0kQ for ; Mon, 14 Jan 2019 08:22:40 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4505131132 for ; Mon, 14 Jan 2019 08:22:39 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1ZUIC5IZK00FGSM@mauve.mrochek.com> for extra@ietf.org; Mon, 14 Jan 2019 08:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547482655; bh=WcXlgDvHdaAEXqjjzmxcmsx3mG+Fn6xbdCmnD8pyR4k=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=SIIPXvRAr+3IrYg8Wwl9wPiqPi4Qws/58CpcnDDP2z2u3ukA9YQXuudDuHdNLTxyl M6R3h+hmsXEquUKa1RPSPcDicmlITF86wiR1+r1rYl7m3h73XYUAv7e+MPigg3YHNW OzNijR9lqE6Qof/Vo0uHtDj2bOQP/3LV8RKUPkTo= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Mon, 14 Jan 2019 08:17:31 -0800 (PST) Cc: extra@ietf.org Message-id: <01R1ZUI9QVMA00004L@mauve.mrochek.com> Date: Mon, 14 Jan 2019 08:17:23 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 13 Jan 2019 18:30:17 -0500" References: <154742212344.14778.15643423403399115896@ietfa.amsl.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-09.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 16:22:42 -0000 Looks good to me. Ned > Hopefully this draft addresses all of the IESG comments.  If it is > lacking in that respect, suggested text would be greatly appreciated. > On 1/13/19 6:28 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. > > > > Title : Sieve Extension: File Carbon Copy (Fcc) > > Authors : Kenneth Murchison > > Bron Gondwana > > Filename : draft-ietf-extra-sieve-fcc-09.txt > > Pages : 15 > > Date : 2019-01-13 > > > > Abstract: > > The Sieve Email Filtering Language provides a number of action > > commands, some of which can generate additional messages on behalf of > > the user. This document defines an extension to such commands to > > allow a copy of any generated message to be filed into a target > > mailbox. > > > > This document updates RFC5230 and RFC5435 by adding a new tagged > > argument to the "vacation" and "enotify" actions respectively. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-09 > > https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-09 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-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/ > > > > _______________________________________________ > > Extra mailing list > > Extra@ietf.org > > https://www.ietf.org/mailman/listinfo/extra > -- > Ken Murchison > Cyrus Development Team > FastMail US LLC From nobody Mon Jan 14 09:22:15 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1D11311CA; Mon, 14 Jan 2019 09:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com 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 z4ZN3EkyowbR; Mon, 14 Jan 2019 09:22:06 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0701311BB; Mon, 14 Jan 2019 09:22:05 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id C8A676A25F; Mon, 14 Jan 2019 18:22:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1547486523; bh=8yAUMJN84wkItzEXjI8Ql9NySSWiDvrntZcXrgwaP2c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jjS+c39Hxhh66PJHjGkMbSvHzhMLD70wvWk+nMj+s2eY0TIhE/AhSyB8atGk0vKPc PlGbXA5l8PLy9r2+RPvzZJ+pajwuY9OrV3X/aMQSPSRZYoGAvN2nUKa5R+zICdvq3Y nhZG6zrb5ap4Jdg0yZZye6k/1Qbu58UXWOTqXo5DgtjfvsUiB7KexQIfYPLMpcZXIM V1CK3FYUKQchCtNywspdObm0DyQOVttdexvniv8A5B95kBQsiWBr3N6DRxO/WcJ9fs 3TMjUJcVKF2nPRaMIRHlS1mP/yB3Ke4Wc9KJdBEwoKxPRKngnPkKO8xB/0DSRI7CXN zCsCdCHooMnmA== Received: from [10.168.3.2] (alcatraz.oxoe.int [192.168.32.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 30E5A3C15C5; Mon, 14 Jan 2019 18:22:03 +0100 (CET) To: Adam Roach , Ned Freed Cc: extra@ietf.org, draft-ietf-extra-sieve-special-use@ietf.org, yaojk@cnnic.cn, The IESG , extra-chairs@ietf.org References: <154708857484.5207.16946770094550744825.idtracker@ietfa.amsl.com> <01R1TQUWRF7800004L@mauve.mrochek.com> <0d883bab-a1f2-d5b7-8586-3bc40603d6fa@nostrum.com> From: Stephan Bosch Message-ID: <401a89eb-6c53-eef5-7c96-1d4312eec14b@open-xchange.com> Date: Mon, 14 Jan 2019 18:22:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <0d883bab-a1f2-d5b7-8586-3bc40603d6fa@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] Adam Roach's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:22:07 -0000 Op 10/01/2019 om 08:44 schreef Adam Roach: > >> >>> If that's the intention, it might be clearer to simply say >>> "unnamed;" or, barring that, perhaps clarify in the Introduction >>> what is meant >>> by "anonymous." >> I'm not wild about anonymous but unnamed doesn't seem like an >> improvement to >> me. The mailbox does have a name and this kind of makes it sound like it >> doesn't. >> >> Maybe something like "mailbox identified only by" or something similar? > > > That would certainly work, and it's much clearer. OK, I'll make that change. Regards, Stephan. From nobody Wed Jan 16 19:27:43 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C4B130F55; Wed, 16 Jan 2019 19:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=rpZ8WdZN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CSBIlKOn 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 YT5wDTOWbfRD; Wed, 16 Jan 2019 19:27:34 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FF012785F; Wed, 16 Jan 2019 19:27:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id BA3221329; Wed, 16 Jan 2019 22:27:33 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 16 Jan 2019 22:27:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:cc:subject :content-type; s=fm1; bh=i4TYWfB/foQqr1OEacwQqX8Pn0VS4uNoz9BfLPl X0T0=; b=rpZ8WdZNTZ4atJeUZ6YhuBYg5XcGm9cXq9CJmaUpHRRldG0PfSYATCy UmOd9gRoorWFshOZcWt526vHRcTz6XIexu8iTSGxVzA5HXJfflibceXUhHIKZxg6 lXAhkUoYalmMM6cQLUa1lwmHI3mRgDL8LEVCz2d2p4YNTpfpbDS5TeYxbwrJ6A+T 1xO4jnqMm7/MOVoxMKC510NNnHaeWQaE5t3ylNxU5pG2MClueAW0nfj3uc51dXSG W6/i3AACDlszhrz3Y4kyPZlsR7X/YebUjclfRV/HTZ6/+gVhON775Sg28tcFrmDt gREL/BzdkZgl8kX9/v67W59YwDTpuHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=i4TYWfB/foQqr1OEacwQqX8Pn0VS4uNoz9BfLPlX0 T0=; b=CSBIlKOnOj1FbpmiRoFOcOo1SBKmZBEG+eusMTjbysKdoI+SMRzfGkY8a 9lwUSxT82B/3C77Q/VxlQHcrMK9+ACwpEwn+SgUP/vXoKp3dpBarfk4amuuUGC0s otbMIb8WJhakfkUEC3d6w2qQIYCASO1Gs9WF4am6zAaPfG3fFdKuWUDBOKvwB7yq 60I3iYZnmXUNqvHD6mLTclxtm1cXwlubJcoWt/NzyV3burOEfWqNwlNeqb1iksi3 PiRsz5nEKyLEY12RLfoKx7mS41BxZx2SpBbZfHFEU5KeWiVv4ryWv8bLfr6TlSK3 5Jds5JxOb8TK9dXvNMOAdCDFeKeyw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeeigdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefofgfkfffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurh honhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtgho mheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvg grmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AD7552042D; Wed, 16 Jan 2019 22:27:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-761-gc103c9b-fmstable-20190103v1bis X-Me-Personality: 56629417 Message-Id: Date: Wed, 16 Jan 2019 22:27:32 -0500 From: "Bron Gondwana" To: jmap@ietf.org Cc: extra@ietf.org Content-Type: multipart/alternative; boundary=2fff86c72db34a36af2878e0777a9af2 Archived-At: Subject: [Extra] I'm speaking about JMAP at Fosdem X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 03:27:36 -0000 --2fff86c72db34a36af2878e0777a9af2 Content-Type: text/plain Hi All, I'll be speaking at Fosdem in Brussels in a couple of weeks - just a lightning talk about JMAP and EXTRA work - telling people what's happening the open email standards world, and how to get involved. If anyone else is going to be in Brussels, I'd love to catch up. 2019-02-02 | 15:40:00 | H.2215 (Ferrer) | IMAP, JMAP and the future of open email standards I'll also be at CalConnect in Zurich the week after that, which I'll let the calsify list know about :) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --2fff86c72db34a36af2878e0777a9af2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

I'll be speaking at Fosdem in Bruss= els in a couple of weeks - just a lightning talk about JMAP and EXTRA wo= rk - telling people what's happening the open email standards world, and= how to get involved.  If anyone else is going to be in Brussels, I= 'd love to catch up.

2019-02-02 | 15:40:00 | H.2215 (Ferr= er) | IMAP, JMAP and the future of open email standards

I= 'll also be at CalConnect in Zurich the week after that, which I'll let = the calsify list know about :)

Cheers,

Bro= n.

<= div class=3D"signature">--
  Bron= Gondwana, CEO, FastMail Pty Ltd
 = ; brong@fastmailteam.com


--2fff86c72db34a36af2878e0777a9af2-- From nobody Mon Jan 21 16:48:29 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD11130E58 for ; Mon, 21 Jan 2019 16:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com 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 l8bPH3BfbkFM for ; Mon, 21 Jan 2019 16:48:26 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF077130E67 for ; Mon, 21 Jan 2019 16:48:25 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id B82BD6A27C; Tue, 22 Jan 2019 01:48:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1548118101; bh=hDFdp4cm5onYR/zsL7mQ7gLLbQdqOSQ45tOpdZfljls=; h=Date:From:To:In-Reply-To:References:Subject:From; b=AUjhQW1d2eVr0KPLqQ37g+qZdlCGjAEpitbIfseI8X+jaPiGzt/LGJi4KcPskMAHo d+xQnMz48BokJgEZUrcOvU+TQNpoLMovn275xlxHAwaPZyl5r/gQ44IDu4jvDYYXxr 385IQCRmOXgevBDrsMHQvpTJVXBstW3QZGsR4Kk8hthxAonmFh3lf66K0dzClbJQXe ceBWVOF/efzUivfLd/auRBcFB9xNXaswPCpAz1O15RJn6/OTzm65TiJuhnEtrQPaNH KFifO1dZnRRfKoJcj9hqzOdKfDQV/uRx/wq/YYANRdG+JvQgWcqBfsLjlRYufApmcg 9dzTI3H0c7erQ== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id A8D753C0028; Tue, 22 Jan 2019 01:48:21 +0100 (CET) Date: Mon, 21 Jan 2019 17:48:21 -0700 (MST) From: Michael Slusarz To: Alexey Melnikov , extra@ietf.org Message-ID: <1755730477.52872.1548118101625@appsuite.open-xchange.com> In-Reply-To: <8c0e5e45-5646-f609-354a-077594228b9d@isode.com> References: <8c0e5e45-5646-f609-354a-077594228b9d@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev3 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-fetch-preview-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 00:48:28 -0000 Thanks for the review/comments. Discussion below. > On January 14, 2019 at 4:59 AM Alexey Melnikov wrote: > > This document is nearly ready for IETF LC and IESG review, but I have a > few comments that require a bit of work to address: > > In Section 1: > > A server that supports the PREVIEW extension indicates this with one > or more capability names consisting of "PREVIEW=" followed by a > supported preview algorithm name. This format provides for future > upwards-compatible extensions and/or the ability to use locally- > defined preview algorithms. > > This is not reflected in the ABNF section (Section 7). See my comment on > section 7 below. Ack. Will address in Section 7. > In Section 3.2: > > The algorithm used by the server to generate the preview is returned > preceding the preview string. > > The server returns a variable-length string that is the generated > preview for that message. > > Having an example at this point would make it easier for reader to > understand the document. I think a counter-argument to an example here would be that we have yet to define the "FUZZY" algorithm, so any example would use terminology that has yet to have been explained. Notwithstanding this, how about this: Example: Retrieving preview information in a SELECTed mailbox C: A1 FETCH 1 (PREVIEW) S: * 1 FETCH (PREVIEW (FUZZY {15} S: Preview text! S: )) S: A1 OK FETCH complete. > In Section 4.1: > > If the FUZZY algorithm generates a preview that is not based on the > body content of the message and the LANGUAGE [RFC5255] extension is > > Is preview is not based on the body content, what is it based on? > Do you mean header fields from the message? I was thinking more of messages containing entirely non-textual data. For example: a message consisting of a single image/jpg MIME part. There is no "text" to use for preview data in this example. However, a server might want to instead provide the user a description of what the message contains. Such as "This message contains an image file of size 800x600 pixels". This description text should be generated in the language that the user has indicated via RFC 5255, if possible. > > supported by the server, the preview text SHOULD be generated > according to the the language rules that apply to human-readable > text. > > In Section 5.1: > > How would the client know when to try to retrieve LAZY preview again? I explicitly did not want to provide any specific retry duration recommendations, as there is no way of making a blanket statement on what that correct value can be across server implementations. Additionally, the expected use case would be to issue a single FETCH LAZY command when initially building the mailbox listing, and then issuing a background FETCH command without the LAZY modifier to return the data once generation is complete. Thus, there generally would only be a maximum of two FETCH commands issued for any message in the mailbox. We could add text describing this "maximum two FETCH approach" to make this clear, to help client implementers. Note that this recommended behavior is already demonstrated in Examples 4 & 5 in Section 6, so maybe we just need to point to those examples. > In Section 7: > > The following syntax specification uses the augmented Backus-Naur > Form (BNF) as described in ABNF [RFC5234]. It includes definitions > from IMAP [RFC3501]. > > capability =/ "PREVIEW=FUZZY" > > This doesn't quite much what you specify in Section 1. > Maybe change it to: > > capability =/ "PREVIEW=" preview-alg > ? That looks correct to me. > > fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP > preview-alg-fetch) ")"] > > msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")" > > preview-alg = "FUZZY" / preview-alg-ext > > preview-alg-ext = preview-atom ; New algorithms MUST be > ; registered with IANA > > And you don't define the procedure for registering these in the IANA > Considerations section. > > preview-mod-ext = preview-atom ; New priority modifiers MUST be > ; registered with IANA > > As above: this needs to have the corresponding IANA Considerations text. In a very early draft of the spec, I had this text (using old snippet language): This document also requests that IANA adds a new IMAP4 [RFC3501] snippet algorithms registry, which registers snippet algorithms by publishing a standards track or IESG-approved experimental RFC. This document constitutes registration of the FUZZY algorithm in that registry. I can resurrect that text and add similar language for modifiers, if agreed. If we do add a registry, I think the text in ABNF section should be changed from: "New algorithms MUST be registered with IANA" to: "New algorithm names MUST conform with the recommendations described in RFC 6648, Section 3" See: https://tools.ietf.org/html/rfc6648#section-3 > In Section 10: > > There are no known additional security issues with this extension > beyond those described in the base protocol described in IMAP4 > [RFC3501]. > > I am not entirely convinced that this is true. This extension either > requires more disk storage or more computation on the server. Both can > cause some form of Denial-of-Service. > (And disk storage space might be worth calling out as a separate > operational consideration) How about this text, adapted from SEARCH=FUZZY Security Considerations section (RFC 6203): Implementation of this extension might enable denial-of-service attacks against server resources, due to excessive memory or CPU usage during generation or increased storage usage if preview results are cached on the server after generation. Servers MAY limit the resources that preview generation uses. michael From nobody Tue Jan 22 02:58:12 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C1C130ED4 for ; Tue, 22 Jan 2019 02:58:10 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 kOjvYXncLmVn for ; Tue, 22 Jan 2019 02:58:08 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 62AFE130ED1 for ; Tue, 22 Jan 2019 02:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1548154687; d=isode.com; s=june2016; i=@isode.com; bh=voq9ti62S5yr7wE58wCcUIybyRuwnNkfVbGg0NRT81E=; 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=cRcam4GcoIwxsj0eqAzPlqEkxicrchctXvohLBZBnji6VbmUCh1grMO3drzemOHkei7EOe Inx5GuPLDn6FBgkO/y7fQ8HKKj+n1tHMZH03NZ+w+/haDoHBDND7iXQUw0LZUagzaMUmTl GHv5L+yISpjMDDarzx1y2L6hpu7e/J4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 22 Jan 2019 10:58:07 +0000 To: Michael Slusarz , extra@ietf.org References: <8c0e5e45-5646-f609-354a-077594228b9d@isode.com> <1755730477.52872.1548118101625@appsuite.open-xchange.com> From: Alexey Melnikov Message-ID: Date: Tue, 22 Jan 2019 10:57:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <1755730477.52872.1548118101625@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-fetch-preview-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 10:58:10 -0000 Hi Michael, On 22/01/2019 00:48, Michael Slusarz wrote: > Thanks for the review/comments. Discussion below. > > >> On January 14, 2019 at 4:59 AM Alexey Melnikov wrote: >> >> This document is nearly ready for IETF LC and IESG review, but I have a >> few comments that require a bit of work to address: >> >> In Section 1: >> >> A server that supports the PREVIEW extension indicates this with one >> or more capability names consisting of "PREVIEW=" followed by a >> supported preview algorithm name. This format provides for future >> upwards-compatible extensions and/or the ability to use locally- >> defined preview algorithms. >> >> This is not reflected in the ABNF section (Section 7). See my comment on >> section 7 below. > Ack. Will address in Section 7. > > >> In Section 3.2: >> >> The algorithm used by the server to generate the preview is returned >> preceding the preview string. >> >> The server returns a variable-length string that is the generated >> preview for that message. >> >> Having an example at this point would make it easier for reader to >> understand the document. > I think a counter-argument to an example here would be that we have yet to define the "FUZZY" algorithm, so any example would use terminology that has yet to have been explained. > > Notwithstanding this, how about this: > > Example: Retrieving preview information in a SELECTed mailbox > > C: A1 FETCH 1 (PREVIEW) > S: * 1 FETCH (PREVIEW (FUZZY {15} > S: Preview text! > S: )) > S: A1 OK FETCH complete. Yes, this looks good. I think this would certainly help understanding of "The algorithm used by the server to generate the preview is returned preceding the preview string". >> In Section 4.1: >> >> If the FUZZY algorithm generates a preview that is not based on the >> body content of the message and the LANGUAGE [RFC5255] extension is >> >> Is preview is not based on the body content, what is it based on? >> Do you mean header fields from the message? > I was thinking more of messages containing entirely non-textual data. > > For example: a message consisting of a single image/jpg MIME part. There is no "text" to use for preview data in this example. However, a server might want to instead provide the user a description of what the message contains. Such as "This message contains an image file of size 800x600 pixels". This description text should be generated in the language that the user has indicated via RFC 5255, if possible. Ok. Then I suggest you add your explanation as an example of why this might be needed. >> supported by the server, the preview text SHOULD be generated >> according to the the language rules that apply to human-readable >> text. >> >> In Section 5.1: >> >> How would the client know when to try to retrieve LAZY preview again? > I explicitly did not want to provide any specific retry duration recommendations, as there is no way of making a blanket statement on what that correct value can be across server implementations. > > Additionally, the expected use case would be to issue a single FETCH LAZY command when initially building the mailbox listing, and then issuing a background FETCH command without the LAZY modifier to return the data once generation is complete. Thus, there generally would only be a maximum of two FETCH commands issued for any message in the mailbox. This was not clear to me from the text. > We could add text describing this "maximum two FETCH approach" to make this clear, to help client implementers. Yes, this would be very helpful. > Note that this recommended behavior is already demonstrated in Examples 4 & 5 in Section 6, so maybe we just need to point to those examples. > > >> In Section 7: >> >> The following syntax specification uses the augmented Backus-Naur >> Form (BNF) as described in ABNF [RFC5234]. It includes definitions >> from IMAP [RFC3501]. >> >> capability =/ "PREVIEW=FUZZY" >> >> This doesn't quite much what you specify in Section 1. >> Maybe change it to: >> >> capability =/ "PREVIEW=" preview-alg >> ? > That looks correct to me. > > >> fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP >> preview-alg-fetch) ")"] >> >> msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")" >> >> preview-alg = "FUZZY" / preview-alg-ext >> >> preview-alg-ext = preview-atom ; New algorithms MUST be >> ; registered with IANA >> >> And you don't define the procedure for registering these in the IANA >> Considerations section. >> >> preview-mod-ext = preview-atom ; New priority modifiers MUST be >> ; registered with IANA >> >> As above: this needs to have the corresponding IANA Considerations text. > In a very early draft of the spec, I had this text (using old snippet language): > > This document also requests that IANA adds a new IMAP4 [RFC3501] Nit: RFC 3501 reference here is a distraction, as the whole document is an IMAP4 extension and snippets are not defined in RFC 3501. > snippet algorithms registry, which registers snippet algorithms by > publishing a standards track or IESG-approved experimental RFC. This > document constitutes registration of the FUZZY algorithm in that > registry. > > I can resurrect that text and add similar language for modifiers, if agreed. Yes, this is roughly what is needed. > If we do add a registry, I think the text in ABNF section should be changed from: > > "New algorithms MUST be registered with IANA" > > to: > > "New algorithm names MUST conform with the recommendations described in RFC 6648, Section 3" > > See: https://tools.ietf.org/html/rfc6648#section-3 I am happy with the reference, but I think it would be better to say both: "New algorithm names MUST be registered with IANA and MUST conform with the recommendations described in RFC 6648, Section 3" >> In Section 10: >> >> There are no known additional security issues with this extension >> beyond those described in the base protocol described in IMAP4 >> [RFC3501]. >> >> I am not entirely convinced that this is true. This extension either >> requires more disk storage or more computation on the server. Both can >> cause some form of Denial-of-Service. >> (And disk storage space might be worth calling out as a separate >> operational consideration) > How about this text, adapted from SEARCH=FUZZY Security Considerations section (RFC 6203): > > Implementation of this extension might enable denial-of-service > attacks against server resources, due to excessive memory or CPU usage during generation > or increased storage usage if preview results are cached on the server after > generation. Servers MAY limit the resources that preview generation uses. Yes, this is much better. Thank you, Alexey From nobody Tue Jan 22 12:06:21 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ED7126CC7; Tue, 22 Jan 2019 12:06:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <154818757924.13217.18132314785775453521@ietfa.amsl.com> Date: Tue, 22 Jan 2019 12:06:19 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-preview-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 20:06:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP4 Extension: Message Preview Generation Author : Michael M. Slusarz Filename : draft-ietf-extra-imap-fetch-preview-01.txt Pages : 13 Date : 2019-01-22 Abstract: This document specifies an IMAP protocol extension which allows a client to request that a server provide an abbreviated representation of a message that can be used by a client to provide a useful contextual preview of the message contents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-preview-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-fetch-preview-01 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 Tue Jan 22 12:35:58 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840C31310E4 for ; Tue, 22 Jan 2019 12:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com 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 IUGoZMf1-JgW for ; Tue, 22 Jan 2019 12:35:54 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8074613101B for ; Tue, 22 Jan 2019 12:35:54 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 259126A27C; Tue, 22 Jan 2019 21:35:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1548189351; bh=IRe3CHQri/JyhvY7NpQqH4TLeRqW1P5xYdZFxaJmBx0=; h=Date:From:To:In-Reply-To:References:Subject:From; b=ws1EBIG1rLmmo4E1tCpm2E9bckHs4Zn+WoUceomXQ2othMbqJfmPSaZfKV762MxKK j+uQdblLhwarqcX8oTVBM/OCtQj/xAW0ePSjycArfe5r1hfuBfXAslDtwTx61R0C1X R38AxPxLmmvghV8tCInQ3vdHV2viIJVxLzqipj0lbbN+sUq4SB0xQY9Plu9SlnMBmB WXp1Ty77p077PEFzGfiyPKfwMEj5RiIbP08oJFn6Bpy0ImJoaOaMN5q0Jg4KJnVJfK DF3OLg+A+FNUsbGQc4LwcKeZ5CgIrrVeFGsTjqYac2ZdqTnq+z3bJqhLYFSgMI3Rp/ luKAYn16N4W7Q== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 191CC3C0028; Tue, 22 Jan 2019 21:35:51 +0100 (CET) Date: Tue, 22 Jan 2019 13:35:50 -0700 (MST) From: Michael Slusarz To: Alexey Melnikov , extra@ietf.org Message-ID: <1199097368.56484.1548189351045@appsuite.open-xchange.com> In-Reply-To: References: <8c0e5e45-5646-f609-354a-077594228b9d@isode.com> <1755730477.52872.1548118101625@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev3 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-fetch-preview-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 20:35:57 -0000 I've edited the draft based on comments in this thread and have pushed -01. One comment requires further discussion: > > If we do add a registry, I think the text in ABNF section should be changed from: > > > > "New algorithms MUST be registered with IANA" > > > > to: > > > > "New algorithm names MUST conform with the recommendations described in RFC 6648, Section 3" > > > > See: https://tools.ietf.org/html/rfc6648#section-3 > > I am happy with the > reference, but I think it would be better to say both: > > "New algorithm names MUST be registered with IANA and MUST conform with the recommendations described in RFC 6648, Section 3" On additional review, and re-reading RFC 6648, I think the correct language is to omit the "MUST be registered" language. One of the goals of this spec is to allow flexibility for local implementers to expand the PREVIEW functionality as they see fit. (We are already thinking about at least one additional algorithm we might implement.) These additional algorithms/modifiers may only be relevant to a single project/customer/use-case however, so they are not necessarily something that will ever be standardized. RFC 6648, at least by my reading, explicitly allows this non-standardization path and simply asks someone implementing to follow some steps to attempt to avoid things like naming collisions. So to me, it seems like we shouldn't require any new PREVIEW algorithms to "MUST be registered with IANA" - instead, simply make sure they are semantically correct (ABNF), and follow agreed-upon conventions (RFC 6648), and that is all we ask. michael From nobody Wed Jan 23 07:04:25 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86180124C04 for ; Wed, 23 Jan 2019 07:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 Gw1NDxXXHowY for ; Wed, 23 Jan 2019 07:04:22 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B6DB212426A for ; Wed, 23 Jan 2019 07:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1548255862; d=isode.com; s=june2016; i=@isode.com; bh=ViQbcZQuC5eNYQqvCYtXIjlmetbhiGmRYvMzOwBq5oE=; 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=tfctXRH7fjryZHAFIwmvOjQjmyMgeEeiKwV8u5SqKcEcbbd+vg5H47BRpCLSVUT7SPx6J2 3obI7a4TzOfq/ybke6YTOv0gA5tx5hfrWVCzF2c+UjNs8q4vMO6mYSmG/BZnGfE3lPVwdf H4tEFPjDAcGl2Xjz0SqVmBFwkxGOXPs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 23 Jan 2019 15:04:21 +0000 To: Michael Slusarz , extra@ietf.org References: <8c0e5e45-5646-f609-354a-077594228b9d@isode.com> <1755730477.52872.1548118101625@appsuite.open-xchange.com> <1199097368.56484.1548189351045@appsuite.open-xchange.com> From: Alexey Melnikov Message-ID: <3e8d0400-e80e-d2b9-60ff-6f46e483338a@isode.com> Date: Wed, 23 Jan 2019 15:03:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <1199097368.56484.1548189351045@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-fetch-preview-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 15:04:24 -0000 Hi Michael, On 22/01/2019 20:35, Michael Slusarz wrote: > I've edited the draft based on comments in this thread and have pushed -01. > > One comment requires further discussion: > >>> If we do add a registry, I think the text in ABNF section should be changed from: >>> >>> "New algorithms MUST be registered with IANA" >>> >>> to: >>> >>> "New algorithm names MUST conform with the recommendations described in RFC 6648, Section 3" >>> >>> See: https://tools.ietf.org/html/rfc6648#section-3 >> I am happy with the >> reference, but I think it would be better to say both: >> >> "New algorithm names MUST be registered with IANA and MUST conform with the recommendations described in RFC 6648, Section 3" > On additional review, and re-reading RFC 6648, I think the correct language is to omit the "MUST be registered" language. > > One of the goals of this spec is to allow flexibility for local implementers to expand the PREVIEW functionality as they see fit. (We are already thinking about at least one additional algorithm we might implement.) These additional algorithms/modifiers may only be relevant to a single project/customer/use-case however, so they are not necessarily something that will ever be standardized. While this is true, it would still be useful to register these to avoid name collisions. This is probably the main point for having an IANA registry. > RFC 6648, at least by my reading, explicitly allows this non-standardization path and simply asks someone implementing to follow some steps to attempt to avoid things like naming collisions. For this one typically need to carve a namespace which has different registration rules (e.g. "First Come First Served"). It is possible to have different policies for such namespace and usual (intended to be standardized) registrations. > So to me, it seems like we shouldn't require any new PREVIEW algorithms to "MUST be registered with IANA" - instead, simply make sure they are semantically correct (ABNF), and follow agreed-upon conventions (RFC 6648), and that is all we ask. Personally, I prefer everything to be registered, even if it is not standardized. Maybe "SHOULD be registered with IANA"? What do other people think? Best Regards, Alexey From nobody Wed Jan 23 07:12:46 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C224E130E25 for ; Wed, 23 Jan 2019 07:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 wQsFoyBplDKL for ; Wed, 23 Jan 2019 07:12:23 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id E710A126BED for ; Wed, 23 Jan 2019 07:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1548256342; d=isode.com; s=june2016; i=@isode.com; bh=yxdiX1tj4rFGdyp6ARJCqhqurID4RYJOuJ6zbu7r5v4=; 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=hyHtqErt4IZ2o22EfEX/7G42TYXS4zk3/LnaCog0xOCEOyLB5+fnBGELr0e6eqC+Tl6zHZ vb0qHb3NRAeHHY8WBJa+YZhI8EHsPLADsowenWez00T2kov1XfxpY7c3JaRcToRcvRflD+ Bq7puxUACD+5hxm6quxHR5o1uiNXKzU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 23 Jan 2019 15:12:21 +0000 From: Alexey Melnikov To: Michael Slusarz , extra@ietf.org References: <8c0e5e45-5646-f609-354a-077594228b9d@isode.com> <1755730477.52872.1548118101625@appsuite.open-xchange.com> Message-ID: Date: Wed, 23 Jan 2019 15:11:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-fetch-preview-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 15:12:25 -0000 Hi Michael, 1 small comment on the latest version: On 22/01/2019 10:57, Alexey Melnikov wrote: > On 22/01/2019 00:48, Michael Slusarz wrote: >>> On January 14, 2019 at 4:59 AM Alexey Melnikov=20 >>> wrote: =C2=A0[snip] >>> >>>> In Section 7: >>>> >>>> =C2=A0=C2=A0=C2=A0 The following syntax specification uses the augmente= d Backus-Naur >>>> =C2=A0=C2=A0=C2=A0 Form (BNF) as described in ABNF [RFC5234].=C2=A0 It = includes=20 >>>> definitions >>>> =C2=A0=C2=A0=C2=A0 from IMAP [RFC3501]. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 capability=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =3D/ "PREVIEW=3DFUZZY" >>>> >>>> This doesn't quite much what you specify in Section 1. >>>> Maybe change it to: >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 capability=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D/ "PREVIEW=3D" preview-alg >>>> ? >>> That looks correct to me. You forgot to include this change in the latest revision of the document. Thank you, Alexey From nobody Thu Jan 24 15:18:18 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FEA13108C; Thu, 24 Jan 2019 15:18:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <154837189609.29291.4685601727023450116@ietfa.amsl.com> Date: Thu, 24 Jan 2019 15:18:16 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-05.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 23:18:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Sieve Email Filtering: Delivering to Special-Use Mailboxes Author : Stephan Bosch Filename : draft-ietf-extra-sieve-special-use-05.txt Pages : 11 Date : 2019-01-24 Abstract: The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes; e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-05 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-use-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-special-use-05 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 Fri Jan 25 07:11:07 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 872C3130E6C; Fri, 25 Jan 2019 07:11:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Jiankang Yao , extra@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org, draft-ietf-extra-sieve-special-use@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154842906547.29132.15463809031767416730.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2019 07:11:05 -0800 Archived-At: Subject: [Extra] Protocol Action: 'Sieve Email Filtering: Delivering to Special-Use Mailboxes' to Proposed Standard (draft-ietf-extra-sieve-special-use-05.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 15:11:06 -0000 The IESG has approved the following document: - 'Sieve Email Filtering: Delivering to Special-Use Mailboxes' (draft-ietf-extra-sieve-special-use-05.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/ Technical Summary The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes; e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into an anonymous mailbox that has a particular special-use attribute assigned. Working Group Summary The EXTRA WG meeting in IETF 102 had detailed discussion about this draft. The authors had updated it accordingly. Alexey reviewed the draft in detail and gave some significant comments. All identified issues were reflected in the new version of the draft. The WG has looked through this document in detail. It passed WGLC. The EXTRA WG meeting in IETF 103 thought that it is ready to move forward. Document Quality The document is in good shape and is ready to be published. Alexey Melnikov has indicated that he has implemented it. He gave some comments and suggestions based on implementation experiences. After WG's discussion, some comments and suggestions have been incorporated into the new version of this document. Personnel Document Shepherd - Jiankang Yao (EXTRA co-chair) Responsible Area Director - Alexey Melnikov From nobody Fri Jan 25 07:13:04 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C53130E65; Fri, 25 Jan 2019 07:13:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154842918277.29196.18458001085007130.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2019 07:13:02 -0800 Archived-At: Subject: [Extra] Protocol Action: 'Sieve Extension: File Carbon Copy (Fcc)' to Proposed Standard (draft-ietf-extra-sieve-fcc-09.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 15:13:03 -0000 The IESG has approved the following document: - 'Sieve Extension: File Carbon Copy (Fcc)' (draft-ietf-extra-sieve-fcc-09.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ Technical Summary The Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. Working Group Summary The EXTRA WG meeting during IETF 101 had detailed discussion about this draft. The authors had updated it accordingly. Before WGLC, several experts reviewed the draft in detail. All identified issues were reflected in the new version of the draft. The EXTRA WG meeting during IETF 102 decided to poll list for WGLC after the new version. During WGLC, some minor issues were identified and fixed in the new version. The WG has looked through this document in detail. Document Quality The document is in good shape and is ready to be published. One expert has indicated that he has implemented it. He noted that this was far more difficult to implement than he expected. Specially, section 4 of the document records the status of some known implementations. Personnel Document Shepherd - Jiankang Yao (EXTRA co-chair) Responsible Area Director - Alexey Melnikov From nobody Mon Jan 28 06:53:51 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC4124408; Mon, 28 Jan 2019 06:53:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-extra-imap-fetch-preview@ietf.org, extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154868722270.2936.10525185540009773914.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2019 06:53:42 -0800 Archived-At: Subject: [Extra] Last Call: (IMAP4 Extension: Message Preview Generation) to Proposed Standard X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 14:53:43 -0000 The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'IMAP4 Extension: Message Preview Generation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an IMAP protocol extension which allows a client to request that a server provide an abbreviated representation of a message that can be used by a client to provide a useful contextual preview of the message contents. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jan 28 14:02:45 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6044013124F for ; Mon, 28 Jan 2019 14:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.206 X-Spam-Level: X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=zuqVNs8A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uEmXEtw7 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 XFUhp3VWLjqb for ; Mon, 28 Jan 2019 14:02:28 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E067E13115A for ; Mon, 28 Jan 2019 14:02:27 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 922CC22B1A for ; Mon, 28 Jan 2019 17:02:26 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 28 Jan 2019 17:02:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= to:from:subject:message-id:date:mime-version:content-type; s= fm2; bh=BZ0hybJ1W65gatyhh5ttm5f7rs2k1QOleq5tySSnDi8=; b=zuqVNs8A HqTT+sehtgx3ttyVzf5qLoPYkr7ZvjLbsxB1ssGxFfGIOyxUr3RK3FoKZGvTitZL bj3BRAQqtWZEW7MoLMdLVToB5jGdvULEgy1EhJylajw5+n+rBRQw6LgSTxZEKHcq PtyQrMGE74r24Zoxv7olzl5AxxjMSSe4MN7Yexg7xWEh8Wg+bj6CQDBzC7GbcQJx jdWpxsx/prMjjPGi5uMNOqecVs9ZrFjOWnTxNlXVraDXEVpqreq6YXjVflZfBsmX BSGikVhbWN3vQWmLtnKfrwNdPwsWZMWNkX80b4j+VmiHfPfo7lZGUK78ZGNzWx4Z GoATSq+Zb7N1AA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=BZ0hybJ1W65gatyhh5ttm5f7rs2k1 QOleq5tySSnDi8=; b=uEmXEtw7hQ3SEa4q/T51u6ggtTMr324b6q7KVfmSiuYre f5V291KhAJ5YWx7R168xEvo1juYfHX290oJhzrHc3IflxrJYq/2VmRuiEKukYIj3 vFnUeZSZQKSVi8vFBcKdeq6cVD6EA08IOad5ExbilXQBDuVp9xaUqrvF+ksA4a2X GXa69o3d72TuO4wRtdEEJ/+VYolriz1E7XqQ7HxxlSMOki7fmxsAEblpibSRh5jK EHmR+JgNO3YUpI6imCGyBFGO3/mUyUI/gdK7ZB5JK22q6Ocnc9iJfNWiY1bVZAYy /t+/lMrcDunBe9EzgFzosh3SvwDCw8HuRNe7G0nrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrjedtgdduieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepvffhufhokffffgggtgesmhdtreertdefjeenucfhrhhomhepmf gvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecu kfhppeejgedrjeejrdekhedrvdehtdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurh gthhesfhgrshhtmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id BF4E8E461F for ; Mon, 28 Jan 2019 17:02:25 -0500 (EST) To: extra From: Ken Murchison Organization: FastMail US LLC Message-ID: <923c9a3b-4541-d255-5629-57bfb99e80b3@fastmail.com> Date: Mon, 28 Jan 2019 17:02:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------4D7CCFFA616C648EECBF4780" Content-Language: en-US Archived-At: Subject: [Extra] IMAP I18NLEVEL X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 22:02:33 -0000 This is a multi-part message in MIME format. --------------4D7CCFFA616C648EECBF4780 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All, Some of us at FastMail have been discussing implementing RFC 5255, namely the I18NLEVEL extensions, in the Cyrus IMAP server and we are wondering if any clients support and use them. -- Ken Murchison Cyrus Development Team FastMail US LLC --------------4D7CCFFA616C648EECBF4780 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------4D7CCFFA616C648EECBF4780-- From nobody Mon Jan 28 18:37:25 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E344131278 for ; Mon, 28 Jan 2019 18:37:22 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=cH5T9Xqg; dkim=pass (1536-bit key) header.d=taugh.com header.b=S0HsosPn 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 B6GnnHYn5MfY for ; Mon, 28 Jan 2019 18:37:20 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915B01312E7 for ; Mon, 28 Jan 2019 18:30:17 -0800 (PST) Received: (qmail 39531 invoked from network); 29 Jan 2019 02:30:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9a69.5c4fbab7.k1901; bh=11hsEa31RgU+Q0w3hHNP5kLVUjO/RCkMB9BDiaOJVU4=; b=cH5T9XqgjGVa26uBvyoRAis7vj9YXK4BpMj+ZOdPqLBIXzS7kCxxq4ovm/6MSbrvD8RKkJptPtolZbe7NaxWRlBuTsXEbYmpAbvOEvM05DF3rODgqvgzGW8Z7lEks55YOQrsN+ahMJYnqFISUjQTbRa0Cct6EAXkXi1yKX5IF14/E8ZeZW4FFbzM3FKii5u963lLR0BnCHVVcA/FDJ1wxGsNtcOmNfSvBoWCUg/EQr4O6/NmeS/8mLOo9di116Pp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9a69.5c4fbab7.k1901; bh=11hsEa31RgU+Q0w3hHNP5kLVUjO/RCkMB9BDiaOJVU4=; b=S0HsosPnrCTi1VvmOuj5p2k0JNUr8arerx9kuuET2zJJDjtOHRFnSNv4KF/v2IETD2E6R2/ZunpovVQSfnTV5wkt3CBimp8CoOymEnziNOyFS+CYmvddo7ZuuqmvP+fWpf6JXWFhu8wQ8HGjGM/oC9++YnlRkIurBltP6U8Mh0xgnk4VTDBK549ZOPUXBnaUh+SMBjVNlsqXM6TliJIE0ZreFVO3I3fp4ajKPxjgtVEd4eSfJQPscgy70oR8N9qh Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 29 Jan 2019 02:30:14 -0000 Received: by ary.qy (Postfix, from userid 501) id AAC7A200D6AC18; Mon, 28 Jan 2019 21:30:14 -0500 (EST) Date: 28 Jan 2019 21:30:14 -0500 Message-Id: <20190129023014.AAC7A200D6AC18@ary.qy> From: "John Levine" To: extra@ietf.org Cc: murch@fastmail.com In-Reply-To: <923c9a3b-4541-d255-5629-57bfb99e80b3@fastmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Extra] IMAP I18NLEVEL X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 02:37:23 -0000 In article <923c9a3b-4541-d255-5629-57bfb99e80b3@fastmail.com> you write: >Some of us at FastMail have been discussing implementing RFC 5255, >namely the I18NLEVEL extensions, in the Cyrus IMAP server and we are >wondering if any clients support and use them. Why 5255 rather than RFC 6855? It is my impression that in practice the UTF8 support in 6855 made the older stuff obsolete. Since Chris Newman was an author of both, he's the obvious person to ask for more info. From nobody Mon Jan 28 20:09:01 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE76130D7A for ; Mon, 28 Jan 2019 20:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=TxXRHzhc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=W4YPGhON 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 wzrlxD9jGqgN for ; Mon, 28 Jan 2019 20:08:59 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09537129B88 for ; Mon, 28 Jan 2019 20:08:59 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 764E0160C for ; Mon, 28 Jan 2019 23:08:58 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 28 Jan 2019 23:08:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=ZfEvrlZ1iciYtCHpNsRdPusTixcKQuGA4c7tX0z JF4Y=; b=TxXRHzhcB4wXt2ltBkkOiYYoAvB8/3J9rNPrf+Xlw1nbXHJ42BCtd6R YNFeKFAec6pgYNvtJrU+hWYWfjy+nylrKVgFhAnK0mnsfsrgm8yV0OEtMo3pA6An +JMMkUYomdGIanu6MphnabKoP/tHwOu52QsyNMnYGQOjHFIh37neNnhz/R49O/DI TXr0JhsB0InnlZrMdMM4/uvRmTjtIMb51z+vpzirC2uh0ex5A88tLDC//85meWO6 E9MY2Xc3hGs0cpdUpSOMj8QMBGVdpTdDwIbyJhDLII2RKXaAB9+gjILL5eFF82Xk VPxKtEPW355+SD5BQthI3HNcQTU6FCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=ZfEvrlZ1iciYtCHpNsRdPusTixcKQuGA4c7tX0zJF4Y=; b=W4YPGhON hVgBD4U2sWEMF8EtxYWleBYCrMu4qr15NfLFf94X5KtQsNDALYPZpetbXVH/YkBH 76/KzDTajWR1Jxm58Zl8jFQP0iOdRk4CQR73hTnNb93EiD5p3WKfuUQW4ThSSwPy 4UaMtaHCIWZLUUos185dP0iXwgimGYsLFEYtqjr2HWwivbFZRI5p9FKl1mfTrBw1 UwPPrgrDcqBrxu+UG8MYCSvGSC0+8tUsWmWN+huZ8aGATvN2TChKPizbvLMGQCys 7AEDJV4QIAOtq8LH24c7tipRUU/aWG9vIOtvoIirmEdwgdFZdTS3r6tNQZp6M8b+ S78q0cUaMIE2iw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrjedugdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefofgfkfffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurh honhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtgho mheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvg grmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BEB3D20252; Mon, 28 Jan 2019 23:08:57 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-823-g00de6f4-fmnext-20190129v2 X-Me-Personality: 56629417 Message-Id: Date: Mon, 28 Jan 2019 23:08:57 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=1d6a6807c3dd4ec0bd0baa21881bf82e Archived-At: Subject: [Extra] Shall we meet in Prague? X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 04:09:00 -0000 --1d6a6807c3dd4ec0bd0baa21881bf82e Content-Type: text/plain Hi all, The deadline for meeting submissions is coming up on Feb 8th. At the moment the only document we're still working on is IMAP4rev2. Congratulations to everybody for the successful work so far - we have been one of the most prolific working groups at the IETF in the past year! We also discussed rechartering the group to expand the scope slightly into SMTP submission. I expect we'll be doing that once IMAP4rev2 enters Working Group Last Call. My default for this working group will be to say "yes, we need to meeting Prague" as we still have ongoing work. If people think that we do NOT need to meet, then please say so to the list. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --1d6a6807c3dd4ec0bd0baa21881bf82e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

The deadline for meeting submission= s is coming up on Feb 8th.
At the moment the only documen= t we're still working on is IMAP4rev2.  Congratulations to everybod= y for the successful work so far - we have been one of the most prolific= working groups at the IETF in the past year!

We also dis= cussed rechartering the group to expand the scope slightly into SMTP sub= mission.  I expect we'll be doing that once IMAP4rev2 enters Workin= g Group Last Call.

=
My default for this working group will= be to say "yes, we need to meeting Prague" as we still have ongoing wor= k.  If people think that we do NOT need to meet, then please say so= to the list.

Cheers,

Bron.

<= div id=3D"sig56629417">
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--1d6a6807c3dd4ec0bd0baa21881bf82e-- From nobody Mon Jan 28 23:14:14 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F032A130F1B for ; Mon, 28 Jan 2019 23:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 lS6D3ftIj6dG for ; Mon, 28 Jan 2019 23:14:12 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73286130EFC for ; Mon, 28 Jan 2019 23:14:12 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0T7Dw1u117640; Tue, 29 Jan 2019 07:14:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=BEqTRtIn8t4qWkBop0MXf4qpji3e2oY1mD1+t3ojd60=; b=hewiAjP/PHZawtsBpKkgBcS0kAhY4hq1X4xuuQn+kY0sa8kPyAZHD94H2z1jKeIDpihQ w3bEIz9y+NoTok/rTbqp5J/ub385hM+8oq7E2dIEv+5oAYsVyME0zCuoy/fA8JXiYnbk gCkdZTFLo4PgXfr3SFXCCVgBQaCN1MqvaKDC2bXVrDKzmJio2cMVhs5eFEnoBK7God84 jtVfKDIfEgq+JcaYc+EzvHt6QAOjA7xT7rHNmjCaltkrijgyS+BSEVWJ0FaXPMYWvzVG F3YRNtSFi4tIioSVYOLQNlQgHdeboOFCAQuwSkNFqnFmkoPuMj5e1hpeDYDVjzZAdRXM Gw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2q8d2e2q09-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Jan 2019 07:14:07 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x0T7E7fM016725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Jan 2019 07:14:07 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0T7E6i8013216; Tue, 29 Jan 2019 07:14:06 GMT Received: from [10.145.183.37] (/10.145.183.37) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Jan 2019 23:14:06 -0800 From: "Chris Newman" To: "John Levine" Cc: extra@ietf.org, murch@fastmail.com Date: Mon, 28 Jan 2019 23:13:57 -0800 X-Mailer: MailMate (1.12.4r5594) Message-ID: <6A0B4726-75F2-40C2-AE36-DFB6F50DC05A@oracle.com> In-Reply-To: <20190129023014.AAC7A200D6AC18@ary.qy> References: <20190129023014.AAC7A200D6AC18@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9150 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=724 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901290055 Archived-At: Subject: Re: [Extra] IMAP I18NLEVEL X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 07:14:14 -0000 On 28 Jan 2019, at 18:30, John Levine wrote: > In article <923c9a3b-4541-d255-5629-57bfb99e80b3@fastmail.com> you > write: >> Some of us at FastMail have been discussing implementing RFC 5255, >> namely the I18NLEVEL extensions, in the Cyrus IMAP server and we are >> wondering if any clients support and use them. > > Why 5255 rather than RFC 6855? It is my impression that in practice > the UTF8 support in 6855 made the older stuff obsolete. > > Since Chris Newman was an author of both, he's the obvious person to > ask for more info. The two standards are orthogonal. I have most of an implementation of RFC 5255 on our server, but don't advertise it. The issue is we implemented an earlier draft of the specification which used a UCA-based comparator. I don't have time to implement/test i;unicode-casemap and consider that algorithm inferior to UCA. I'd be inclined to fix and advertise our implementation if a UCA-based comparator was registered and allowed as an alternative to i;unicode-casemap. But use of i;unicode-casemap was easier to get published at the time this was done. This could probably be fixed with a relatively short specification but I can't justify the time to write it. In the meantime; I'd recommend using JMAP for i18n sort since it gets that detail right :-) I have a full implementation of RFC 6855 although I ignored one or two of the backwards compatibility MUST/SHOULD rules which were necessary from a standards viewpoint and inappropriate from an implementer viewpoint :-). Basically RFC 5255 handles sorting and error text localization -- a nice to have feature but default behavior in IMAP is good enough. RFC 6855 handles UTF-8 email headers and mailbox names -- as EAI deploys, you'll start getting customer complaints if you don't implement this. So given limited time, I'd recommend doing RFC 6855 first. - Chris From nobody Tue Jan 29 01:25:10 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334B8130F46 for ; Tue, 29 Jan 2019 01:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com 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 oaTcJqwB27SI for ; Tue, 29 Jan 2019 01:25:06 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253034.outbound.protection.outlook.com [40.92.253.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3F1130F44 for ; Tue, 29 Jan 2019 01:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T79fLhM3DGknFFsSy/uZzQbO1YdSTD//aruTxe7IjAU=; b=hL0WPiv9nw7bjGkFX0j1O5rcHTop2ashvI1+1CYcFprc8cR9rEMuEMQtn2PQ1AiAy2KDGr+gbZBJSRUrntVVKf2+RdcVaUKCQ0CmaJKG2/XY3IbtKNKCzrlKJINvOTvKp2fNwJoOHMFXq6bUr14fUIoAwVlxGpOfnP7j/KWfG/u3XSlpwgzMtPlmIOWr5Sn3nXYNFdYtu9AhL94Jtgy5oDXa3aQcsjsaxneBl9nPBgrWlQmeRFbGrAlRcp5rbPuNKBPcIjLTM2/QYR7blEfPLwwv8/4/ssBuLJv6mofTraDBnx+rmCpI1FJ1fA6YR/tpZ5i1ZMzCc2u9fK+dvN3bgQ== Received: from PU1APC01FT047.eop-APC01.prod.protection.outlook.com (10.152.252.57) by PU1APC01HT101.eop-APC01.prod.protection.outlook.com (10.152.253.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10; Tue, 29 Jan 2019 09:24:55 +0000 Received: from TY2PR03MB4127.apcprd03.prod.outlook.com (10.152.252.53) by PU1APC01FT047.mail.protection.outlook.com (10.152.253.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Tue, 29 Jan 2019 09:24:55 +0000 Received: from TY2PR03MB4127.apcprd03.prod.outlook.com ([fe80::74f5:9d01:3ba6:9b0d]) by TY2PR03MB4127.apcprd03.prod.outlook.com ([fe80::74f5:9d01:3ba6:9b0d%3]) with mapi id 15.20.1580.016; Tue, 29 Jan 2019 09:24:55 +0000 From: pradeep xplorer To: Bron Gondwana , "extra@ietf.org" Thread-Topic: New draft waiting for approval: draft-ietf-extra Thread-Index: AQHUtj4LfD9dgjkTjEmdghDHBySYI6XF+d4f Date: Tue, 29 Jan 2019 09:24:55 +0000 Message-ID: References: <814e6863-887b-4bd4-bc97-9be1f563b0a9@www.fastmail.com> In-Reply-To: <814e6863-887b-4bd4-bc97-9be1f563b0a9@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:712E45592CCE626F7ADD3A10B5EACA992C5A9E60EC26C9CC8212C688CDC4FF26; UpperCasedChecksum:2E0D4FB0AD1EED2545C21E3D637288C94CD88A9ABCF03E0D72304EB1109377FA; SizeAsReceived:9024; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [By+5d02tXR7flh9AE9x9lzJWzwrNL7CL] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT101; 6:Tu/bQqANW6k4/47VYYByS91gyXjY7cAnlLLcvOrBatsu1m0yeyoRU+psnhF2B3xkk+ygL3tN3XnVL2fzjDPlg6awVQqDKruW2f4eoQ+eIgC+ot7ugz66KZAjlwMuhhaDIwQI1svjltR2Jz2c9HW2jFxI6CN1wJztilXQGKI63PJKkzOnswgpvZA2dl+IlNBV9GdzaROea9+gq1LM63LM3LnioIpb51abjIWMNDPpJabYe0tTsjE6VIfjpsGuMitYbtiVnXwoBZeyZH2qsuCH1FUGXtkOnM7YParAUGdWIeqGzD3Spe2N0tiNDDaAwoMMIjJZkx1uJvA8YAF5NmgQ1XSBvRNja4ygxoDh6b7WM+VelHDUlRukcfAXRGKQL59W4bCOC+G1zyVZolLksfL33xIrETQGH0pfnkEjpyKpxAVWUbXu6op/Gidjpv2Ol+KFHZhDhhUrNNhgHSkU5YKjwQ==; 5:K4Hhy8gu8MV4W+GX0T5wDVyTP40sGtRGV7wx7qZGsZOKubqPuN9nPnToZmcgIYICHdWvA8hYxvDxyuY7NPAiRE+0Akv3Bf5Zi9vkXJqZHVRrucU0cGVWo0yjvMasgPVZF3t6BRbvvM9nt0o9Ki5cCMkV1Xucj0PBp4FrzA7LLtvYU4wrRFqutZyI5FVqVXR4aJOxgETKXuvxbVwDRtvOBg==; 7:mAyTiGJKEwehCH6vI1hf9qeSrtL2gzqpezOC4wWMEbUtKqN5EEJotvE1uWzIKO9MeKseu5vLH8UqZ34webh+vX+XDlVUDBW7vpkdG5sWObpDND+6ecl3ia1VZok1gKeZSmrcONkJrSPdP5c/iJ2dBg== x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-exchange-slblob-mailprops: pIOhKJFJPnObM/5ELSn+ccLEhc3JAgwlwq70askgOoutEs9aV/krjMwTSj6ZinUZHLYF0d4r9Bn+cAassFvN+uKCLi19sWZvHvRO9gqFou4LqnfPfna3aS1GG1ziI1zgxz8R7D1lAEUDYAXVj0elS6vr6gDHmaFT25KmNl1FbqQLyhEE+tLdC2F7rrRIRB7DIjPburadvg4vfHpDwqxvtcRo6NKf8frksON+4okisSWmi5EBiZvg4JogcEjTH9cZiG8K73wjwloGR0UpqZ2qzzGta4TWz8wURcQcbPpOiItD/C3p8loO08vpQzKYpTxFaQjOc+CFWNnaRgBjvRC7wNVA7iQF3lUCKkmYPQDA9jiXslkZdwyL1AbUT6wz/Hauxx2mVM5mJnunD3kd3CnuUay5+2aNWnNelkxtRb5voq2oAkaF9E2dBJszQtWhRbpWA4sOkjWK4KWaFRF17xB2jGASBUt2sfhaw342aSiH28NiTtFhYGa3ZgJZVi6/H7iXIbDrYxtMroIDmdbLAB1uCAAfe97+llUk/BGT+Md/2Fdwnl67NpLSGxSPGXJZSA3IhQ50IMJG3Vz/R1/PVlD3iHNwrNLmi5jD4wyoLI95u9l4kQpTm5mhh/6MqKXnTDGwTBZX4zMqRke8E2Sk1zBNJi/rDjqRkAkmfztxic/vcXGF7RZN64EuXk/a+KnC+d34Zv1gMMxoSy7sH3+FFwnodOSqxtGkXvJu/GC1XZmsjuInIFNFghGr49ZBagDzTHyrTqZKniMuFRpU7ROz0QRpq5wfSZoS8aVmlUxuBp31J4eenMaS7fzr0gJ62dJiMWPoHvopi9FblYxywij/KyhdfM/IdTp7t1h60jIG3Ji7xwOniY5/JdePJ2xJleyN9Nvy2gi1pgQJBtEXyISo9Om93g== x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(201702181274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:PU1APC01HT101; x-ms-traffictypediagnostic: PU1APC01HT101: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:PU1APC01HT101; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT101; x-microsoft-antispam-message-info: sKpTD/R64poum/IujUjd/w+QIH0WVcxWLofo0Zq+EqSie+L8ZQA+Vr/NnlCYlXYC Content-Type: multipart/alternative; boundary="_000_TY2PR03MB412785236DABB9B73D0BD215B7970TY2PR03MB4127apcp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 54485d23-c432-40fe-8436-6091d627118c X-MS-Exchange-CrossTenant-Network-Message-Id: 958858c3-019d-416e-f8e1-08d685cba17a X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 54485d23-c432-40fe-8436-6091d627118c X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2019 09:24:55.2389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT101 Archived-At: Subject: Re: [Extra] New draft waiting for approval: draft-ietf-extra X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 09:25:08 -0000 --_000_TY2PR03MB412785236DABB9B73D0BD215B7970TY2PR03MB4127apcp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is it.. I am writing this from Dehradun, Ex sun employee without incom= e just have 1500rs and victim of 15 year cybercrime using my domains dhyanayoga.info, pradeepkumarxplorer.com explod= ingmoon.org so i dont know how i can get to Prague. Please suggest me which venue group you think this is. Many are on my blind cc i dont know who among them is preventing a solution= as they are not emailing me back and some of them suspected employed as investogators for their fun using th= e black company. https://datatracker.ietf.org/doc/draft-xplorer-device-association/?include_= text=3D1 Pradeep Kumar Xplorer ________________________________ From: Bron Gondwana Sent: Sunday, January 27, 2019 6:14 PM To: Pradeep Kumar Xplorer Subject: Fwd: New draft waiting for approval: draft-ietf-extra Hi Pradeep, I have rejected your upload, because it's not correctly named (it was just = named as the name of the working group, with no specific draft name, and al= so - drafts should be uploaded with your own name and then ask the working = group if it's willing to adopt the work. I don't believe that EXTRA is act= ually the correct venue for this draft either. If you submit by Feb 8th fo= r a BOF (Birds of Feather) you could get it addressed at the Prague IETF. Anyway, the first step if you do think EXTRA is the right venue is to uploa= d the draft under your own name (e.g. draft-xplorer-device-association-00) = and then email the mailing list (extra@ietf.org) and= ask for adoption. Regards, Bron. ----- Original message ----- From: IETF I-D Submission Tool To: extra-chairs@ietf.org Subject: New draft waiting for approval: draft-ietf-extra Date: Sunday, January 27, 2019 23:13 Hi, Chair approval is needed for posting of draft-ietf-extra-00. To approve the draft, go to this URL (note: you need to login to be able to= approve): https://datatracker.ietf.org/submit/status/100976/e56d6051c641a677efaa3bd= 4caf1148f/ File name : draft-ietf-extra Revision : 00 Submission date : 2019-01-27 Group : Email mailstore and eXtensions To Revise or Amend Title : Need for associating email address to device address an= d phone numbers and ability to send email from sms Document date : 2019-01-27 Pages : 3 File size : 5.0 KB Submitter : Pradeep Kumar Xplorer Abstract : This document describes the need for associating em= ail address to device address and phone numbers Authors: Pradeep Kumar Xplorer Best regards, The IETF Secretariat through the draft submission service -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_000_TY2PR03MB412785236DABB9B73D0BD215B7970TY2PR03MB4127apcp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here is it.. I am writing this from Dehradun, Ex sun employee without incom= e just have 1500rs and victim of 15 year
cybercrime using my domains dhyanayoga.info, pradeepkumarxplorer.com explod= ingmoon.org so i dont know how
i can get to Prague. Please suggest me which venue group you think this is.=

Many are on my blind cc i dont know who among them is preventing a solution= as they are not emailing me back
and some of them suspected employed as investogators for their fun using th= e black company.


Pradeep Kumar Xplorer



From: Bron Gondwana <b= rong@fastmailteam.com>
Sent: Sunday, January 27, 2019 6:14 PM
To: Pradeep Kumar Xplorer
Subject: Fwd: New draft waiting for approval: draft-ietf-extra
 
Hi Pradeep,

I have rejected your upload, because it's = not correctly named (it was just named as the name of the working group, wi= th no specific draft name, and also - drafts should be uploaded with your o= wn name and then ask the working group if it's willing to adopt the work.  I don't believe that EXTRA is act= ually the correct venue for this draft either.  If you submit by Feb 8= th for a BOF (Birds of Feather) you could get it addressed at the Prague IE= TF.

Anyway, the first step if you do think EXT= RA is the right venue is to upload the draft under your own name (e.g. draf= t-xplorer-device-association-00) and then email the mailing list (extra@ietf.org) and ask for adoption.

Regards,

Bron.

----- Original message -----
From: IETF I-D Submission Tool <idsubmi= ssion@ietf.org>
To: extra-chairs@ietf.org
Subject: New draft waiting for approval: d= raft-ietf-extra
Date: Sunday, January 27, 2019 23:13


Hi,

Chair approval is needed for posting of dr= aft-ietf-extra-00.

To approve the draft, go to this URL (note= : you need to login to be able to approve):
  https://datatracker.ietf.org/submit= /status/100976/e56d6051c641a677efaa3bd4caf1148f/

  File name    &n= bsp;  : draft-ietf-extra
  Revision    &nb= sp;   : 00
  Submission date : 2019-01-27
  Group     =       : Email mailstore and eXtensions To Revise o= r Amend

  Title     =       : Need for associating email address to devi= ce address and phone numbers and ability to send email from sms
  Document date   : 2019-01= -27
  Pages     =       : 3
  File size    &n= bsp;  : 5.0 KB

  Submitter    &n= bsp;  : Pradeep Kumar Xplorer <pradeepan88@hotmail.com>

  Abstract    &nb= sp;   :     This document describes the need = for associating email address to device
address     and phone = numbers



  Authors:
    Pradeep Kumar Xplorer &= lt;pradeepan88@hotmail.com>




Best regards,

The IETF Secretariat
through the draft submission service


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_000_TY2PR03MB412785236DABB9B73D0BD215B7970TY2PR03MB4127apcp_-- From nobody Tue Jan 29 13:14:39 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB13C13103B for ; Tue, 29 Jan 2019 13:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 fWeJwRKeD_Pg for ; Tue, 29 Jan 2019 13:14:31 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAE8131022 for ; Tue, 29 Jan 2019 13:14:30 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 3B9D5C0631; Tue, 29 Jan 2019 21:16:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1548796565; bh=+3C6LG4WYR2/nYOT6xUI0MK07xvogTJyg+XiLIpNF18=; h=From:To:Subject:Date:References:From; b=IONIvrwdi19s87y/yxCpEXjQfSmLNK8Qbl0V+Z7+WBRLWNNmZMWVjeMufNmEsJvKZ haJFoQdj9ak2So7ndE5kYr8GM6RMPk01ecythLihGWmBJYQcBWHjpqZTXoPDn5eslb 9XX2ugFP3L64t3WzEx7I2EIHbr8kj/hoHfvoAiDQ= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1548796564-2664-2661/10/11413; Tue, 29 Jan 2019 21:16:04 +0000 From: Arnt Gulbrandsen To: Bron Gondwana , extra@ietf.org Date: Tue, 29 Jan 2019 22:14:25 +0100 Message-Id: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Extra] Shall we meet in Prague? X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 21:14:34 -0000 I have almost dropped out of the groups, but if you do a Friends of IMAP dinner in Prague I would try to come. Arnt From nobody Tue Jan 29 13:31:07 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF8130FFE for ; Tue, 29 Jan 2019 13:31:05 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 Nz2-ElsbP_xv for ; Tue, 29 Jan 2019 13:31:03 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E79D130ED7 for ; Tue, 29 Jan 2019 13:31:03 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 47B63C0631; Tue, 29 Jan 2019 21:32:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1548797559; bh=KRsAif0/gG/3gp4wpzdKbgwCUtUB4yajrTUQYoClQx8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aQCRMNGMXEelfgJnWoD+qkH5xG3EqcfX2EGYJlpArptfWv71iprm6nVZga6VXlY0Q bWCOVWCaTUm6FUErazhT1H46j+vEaZS09YrS2+ZIsSTQPRTfnSw/VYlV9IfTwoiUzy YHyaPD6+iNOECF25FzY3VgOgQ4LO7P4kVUsO2Nkk= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1548797558-2663-2661/9/67; Tue, 29 Jan 2019 21:32:38 +0000 From: Arnt Gulbrandsen To: Ken Murchison Cc: extra@ietf.org Date: Tue, 29 Jan 2019 22:31:00 +0100 Mime-Version: 1.0 Message-Id: <3beec721-47a3-450d-8be3-517dadc9eca7@gulbrandsen.priv.no> In-Reply-To: <923c9a3b-4541-d255-5629-57bfb99e80b3@fastmail.com> References: <923c9a3b-4541-d255-5629-57bfb99e80b3@fastmail.com> User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.0 (ascii) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] IMAP I18NLEVEL X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 21:31:05 -0000 > Some of us at FastMail have been discussing implementing RFC > 5255, namely the I18NLEVEL extensions, in the Cyrus IMAP server > and we are wondering if any clients support and use them. I did the last drafts of that, when Chris was distracted. Noone's sent me mail about it until now. This might of course mean that noone's had problems understanding the prose, noone found typoxs, and noone needed help finding interop partners. But I fear that in this case, it's more likely to mean that the number of implementers approximates zero. Particularly since noone said they wanted to implement before publication; I only finished the document since doing that was simpler than getting it removed from the WG charter. Arnt From nobody Wed Jan 30 18:26:52 2019 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DD7130EBF for ; Wed, 30 Jan 2019 18:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=hRp7bgiG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Kx+1kWV+ 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 z8c-I5pYB6nO for ; Wed, 30 Jan 2019 18:26:48 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684F51271FF for ; Wed, 30 Jan 2019 18:26:48 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 304942318A; Wed, 30 Jan 2019 21:26:47 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 30 Jan 2019 21:26:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=TzgSXFEIoI52xvnK6miZpgZT8u2E 85/FRPwElGr5qQ4=; b=hRp7bgiGSxaipPdxG5albVl4nmVV37lge05soEZbAtLc sfIRJCVBrnNsHtLYLxzozrfJ3pebxgHJob1sOGQIggLmOvkNftTe79tXUSOYPCOR MN3IX0broe6mhdCxh51mDdYk7dfuwXbsgmm1hturlwq3ztU3dSDwHn5GSOlsG4lE kAXO4dG69LYi4pbmQVYymc/Wm4vzGsORXsELurrhnoUcDDy1IRy1vxItn9/FCNkT 8AMKRxiwWD1EljL4fwDVUT3UY7onfS71jx/NW4hhtV7xsZz1B2JsJAyfw/viSRY3 hmcqRt4PVFfMhtFvtuY9B4BLY/cMQre77NAQytV0tg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=TzgSXFEIoI52xvnK6 miZpgZT8u2E85/FRPwElGr5qQ4=; b=Kx+1kWV+u7FLRPpNQCauYcShXWVvrDM5c Q89HVqmDIHDcR+VTcXPVxInX0q0Fa2slDDpHxRZqrIuiy801SMjaMdQKuFJOJAS2 P4PcLtvRZOlHINDK5VOF5nrdWsvyAQuhuiqVwK62DqZjk9SlmRjg0yi+jssPDUBQ pzahn01GQ5lvF8Fd0uiEjND+ZydjcRSedBwe3wQkPd++WR1en02LI6vLH1x3vNG4 XVc3OBYDhVnCVen+tjhuQh9x6s/w2Og0UURguSq+yBPEjBTsSElFFNNFCogLrDx2 O3QpiSNmNFq2QcBJI+f0TTcNr9bAvb3n9VNJQh62G5fmSKvAAaguQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrjeehgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefofgfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfd eurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomheqnecuffhomhgrihhnpehprhgruggvvghpkhhumhgrrhigphhlohhrvghrrdgtoh hmpdhivghtfhdrohhrghdpvgigphhlohguihhnghhmohhonhdrohhrghenucfrrghrrghm pehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD3EA20386; Wed, 30 Jan 2019 21:26:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-825-ge9fd767-fmstable-20190130v1 X-Me-Personality: 56629417 Message-Id: <35c7ba78-c493-42ab-be74-e915e53f4efe@beta.fastmail.com> In-Reply-To: References: <814e6863-887b-4bd4-bc97-9be1f563b0a9@www.fastmail.com> Date: Wed, 30 Jan 2019 21:26:45 -0500 From: "Bron Gondwana" To: extra@ietf.org, "Pradeep Kumar Xplorer" Content-Type: multipart/alternative; boundary=177bdc0d03284c7fa9be846ef649bfb5 Archived-At: Subject: Re: [Extra] New draft waiting for approval: draft-ietf-extra X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 02:26:51 -0000 --177bdc0d03284c7fa9be846ef649bfb5 Content-Type: text/plain I can't help you with getting to Prague, but having read your draft in detail I can probably help avoid you wasting time. What you are asking for in the draft is not something that Ietf is capable of doing. Ietf is not a world government able to enforce the kind of changes you are requesting. The telephone numbering standard and the individual domain namespaces in which email addresses are allocated are not within our control. Even icann who control domain name space are constrained in what they can enforce by the contracts which already exist. So Ietf can propose ideas, but they have to be technically feasible and politically achievable, and I don't believe any working group within Ietf would be able to get a satisfactory implemention of your ideas. None of this prevents you from proposing a new draft and looking for support somewhere else, I may be wrong in my beliefs and you are welcome to venue shop within Ietf. You will need to name draft correctly within your own naming area rather than using the name of an existing working group however, as drafts named by a working group can only be accepted by consensus of that group. Regards, Bron. On Tue, Jan 29, 2019, at 20:25, pradeep xplorer wrote: > Here is it.. I am writing this from Dehradun, Ex sun employee without income just have 1500rs and victim of 15 year > cybercrime using my domains dhyanayoga.info, pradeepkumarxplorer.com explodingmoon.org so i dont know how > i can get to Prague. Please suggest me which venue group you think this is. > > Many are on my blind cc i dont know who among them is preventing a solution as they are not emailing me back > and some of them suspected employed as investogators for their fun using the black company. > > https://datatracker.ietf.org/doc/draft-xplorer-device-association/?include_text=1 > > Pradeep Kumar Xplorer > > > > > > *From:* Bron Gondwana > *Sent:* Sunday, January 27, 2019 6:14 PM > *To:* Pradeep Kumar Xplorer > *Subject:* Fwd: New draft waiting for approval: draft-ietf-extra > > Hi Pradeep, > > I have rejected your upload, because it's not correctly named (it was just named as the name of the working group, with no specific draft name, and also - drafts should be uploaded with your own name and then ask the working group if it's willing to adopt the work. I don't believe that EXTRA is actually the correct venue for this draft either. If you submit by Feb 8th for a BOF (Birds of Feather) you could get it addressed at the Prague IETF. > > Anyway, the first step if you do think EXTRA is the right venue is to upload the draft under your own name (e.g. draft-xplorer-device-association-00) and then email the mailing list (extra@ietf.org) and ask for adoption. > > Regards, > > Bron. > > ----- Original message ----- > From: IETF I-D Submission Tool > To: extra-chairs@ietf.org > Subject: New draft waiting for approval: draft-ietf-extra > Date: Sunday, January 27, 2019 23:13 > > > Hi, > > Chair approval is needed for posting of draft-ietf-extra-00. > > To approve the draft, go to this URL (note: you need to login to be able to approve): > https://datatracker.ietf.org/submit/status/100976/e56d6051c641a677efaa3bd4caf1148f/ > > File name : draft-ietf-extra > Revision : 00 > Submission date : 2019-01-27 > Group : Email mailstore and eXtensions To Revise or Amend > > Title : Need for associating email address to device address and phone numbers and ability to send email from sms > Document date : 2019-01-27 > Pages : 3 > File size : 5.0 KB > > Submitter : Pradeep Kumar Xplorer > > Abstract : This document describes the need for associating email address to device > address and phone numbers > > > > Authors: > Pradeep Kumar Xplorer > > > > > Best regards, > > The IETF Secretariat > through the draft submission service > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --177bdc0d03284c7fa9be846ef649bfb5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I can't help you with getting to Prague, but having r= ead your draft in detail I can probably help avoid you wasting time. Wha= t you are asking for in the draft is not something that Ietf is capable = of doing. Ietf is not a world government able to enforce the kind of cha= nges you are requesting. The telephone numbering standard and the indivi= dual domain namespaces in which email addresses are allocated are not wi= thin our control.

<= div style=3D"font-family:Arial;">Even icann who control domain name spac= e are constrained in what they can enforce by the contracts which alread= y exist.

So Ietf can propose ideas, but they have to be t= echnically feasible and politically achievable, and I don't believe any = working group within Ietf would be able to get a satisfactory implementi= on of your ideas.

<= div style=3D"font-family:Arial;">None of this prevents you from proposin= g a new draft and looking for support somewhere else, I may be wrong in = my beliefs and you are welcome to venue shop within Ietf. You will need = to name draft correctly within your own naming area rather than using th= e name of an existing working group however, as drafts named by a workin= g group can only be accepted by consensus of that group.

= Regards,

Bron.
On Tue, Jan 29, 2019, at 20:25,= pradeep xplorer wrote:
Here is it.. I am writing this from Dehra= dun, Ex sun employee without income just have 1500rs and victim of 15 ye= ar
cybercrime using my domains dhyanayoga.= info, pradeepkumarxplorer.com explodingmoon.org so i dont know how
i can get to Prague. Please suggest me which ve= nue group you think this is.

Many are on my blind cc i dont know who among them is = preventing a solution as they are not emailing me back
and some of them suspected employed as investogators for th= eir fun using the black company.


Pradeep Kumar Xplorer





From: Bron Gond= wana <brong@fastmailteam.com>
Sent: Sunday, January 27,= 2019 6:14 PM
To: Pradeep Kumar Xplorer
Subject: F= wd: New draft waiting for approval: draft-ietf-extra
 
Hi Pr= adeep,

I have rejected your upload, because it's not corre= ctly named (it was just named as the name of the working group, with no = specific draft name, and also - drafts should be uploaded with your own = name and then ask the working group if it's willing to adopt the work.  I don't believe that EXTRA is = actually the correct venue for this draft either.  If you submit by= Feb 8th for a BOF (Birds of Feather) you could get it addressed at the = Prague IETF.

Anyway, the first step if you do think EXTRA= is the right venue is to upload the draft under your own name (e.g. dra= ft-xplorer-device-association-00) and then email the mailing list (extra@ietf.org) and ask for adoption.

Regards,

Bron.

----- Original messag= e -----
From: IETF I-D Submis= sion Tool <idsubmission@ietf.org>
To: extra-chairs@ietf.org
Subject: New draft waiting for approval: draft-ietf-extra
Date: Sunday, January 27, 2019 23:1= 3


Hi,

Chai= r approval is needed for posting of draft-ietf-extra-00.

= To approve the draft, go to this URL (note: you need to login to be able= to approve):
  https://= datatracker.ietf.org/submit/status/100976/e56d6051c641a677efaa3bd4caf114= 8f/

  File name       = : draft-ietf-extra
  Rev= ision        : 00
  Submission date : 2019-01-27
  Group     = ;      : Email mailstore and eXtensions To Revi= se or Amend

  Title     &nb= sp;     : Need for associating email address to devi= ce address and phone numbers and ability to send email from sms
  Document date   : 20= 19-01-27
  Pages &n= bsp;         : 3
  File size    &nbs= p;  : 5.0 KB

  Submitter   =     : Pradeep Kumar Xplorer <pradeepan88@hotmail.com&g= t;

  Abstract      &nb= sp; :     This document describes the need for assoc= iating email address to device
address     and phone numbers



  Authors:
&nbs= p;   Pradeep Kumar Xplorer <pradeepan88@hotmail.com>
=




= Best regards,

The IETF Secretariat
through the draft submission service


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


____________________= ___________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/ex= tra


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com
=

--177bdc0d03284c7fa9be846ef649bfb5--