Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT)

Ken Murchison <> Wed, 09 January 2019 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35C87130E6C; Wed, 9 Jan 2019 08:19:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key) header.b=H5XI/Ukp; dkim=pass (2048-bit key) header.b=E5Xip+ph
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fYHGcrO-Qv3R; Wed, 9 Jan 2019 08:19:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 539B6127B4C; Wed, 9 Jan 2019 08:19:27 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 79EB92208B; Wed, 9 Jan 2019 11:19:25 -0500 (EST)
Received: from mailfrontend2 ([]) by compute5.internal (MEProxy); Wed, 09 Jan 2019 11:19:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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: <xms:Cx82XM-40JInM6n_Uw0Sn-jxjcOQW4aWeG3rw0a0JNYlVZku65dJjw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedugdekjeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcu ofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepjeegrdejjedrkeehrddvhedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomhenucevlhhush htvghrufhiiigvpedt
X-ME-Proxy: <xmx:Cx82XA6Yt9jUlaR8DWT_bF3okcLy0XRPsB6LgZ5VgXYhvlLWBKQOew> <xmx:Cx82XE4ITwSvgOB8It-dzdYIFczm_cznMWfTPooIXCXfk9_Ch_kYjA> <xmx:Cx82XLGfCP9VxYKOxiG5oQz5rIVCzXGj6Eb9DDs3o43aUozzfdjI2g> <xmx:DR82XPF5iDYi1qs_k0HstUY8_G_IX5n0ttC5kKntDv1UYHHj3mcaBQ>
Received: from localhost.localdomain ( []) by (Postfix) with ESMTPA id 3E3A11026D; Wed, 9 Jan 2019 11:19:23 -0500 (EST)
To: Ned Freed <>, Eric Rescorla <>
Cc:, Jiankang Yao <>,, The IESG <>,
References: <> <>
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: <>
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-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

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
>> 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.

>> 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:
> 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