Re: [Extra] Benjamin Kaduk's Yes on draft-ietf-extra-sieve-special-use-04: (with COMMENT)

Ned Freed <> Thu, 10 January 2019 07:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D20113118A; Wed, 9 Jan 2019 23:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.207
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dLO39Gk1BPuE; Wed, 9 Jan 2019 23:45:23 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FA51131188; Wed, 9 Jan 2019 23:45:23 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <>; Wed, 9 Jan 2019 23:40:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 by (PMDF V6.1-1 #35243) id <>; Wed, 9 Jan 2019 23:40:15 -0800 (PST)
Cc: The IESG <>,,,,
Message-id: <>
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" <>
References: <>
To: Benjamin Kaduk <>
Archived-At: <>
Subject: Re: [Extra] Benjamin Kaduk's Yes on draft-ietf-extra-sieve-special-use-04: (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: 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
> for more information about IESG DISCUSS and COMMENT positions.

> The document, along with other ballot positions, can be found here:

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------

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