Skip to main content

Sieve Email Filtering: Delivering to Special-Use Mailboxes
RFC 8579

Yes

(Alexey Melnikov)
(Ben Campbell)

No Objection

Alvaro Retana
(Deborah Brungard)
(Eric Rescorla)
(Ignas Bagdonas)
(Martin Vigoureux)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana
No Objection
Warren Kumari
No Objection
Comment (2019-01-08 for -04)
Thanks to shwethab@cisco.com for the OpsDir review.
Adam Roach Former IESG member
Yes
Yes (2019-01-09 for -04)
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.
Alexey Melnikov Former IESG member
Yes
Yes (for -04)

                            
Ben Campbell Former IESG member
Yes
Yes (for -04)

                            
Benjamin Kaduk Former IESG member
Yes
Yes (2019-01-09 for -04)
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.
Alissa Cooper Former IESG member
No Objection
No Objection (2019-01-08 for -04)
Please use the RFC 8174 boilerplate in Section 2.
Deborah Brungard Former IESG member
No Objection
No Objection (for -04)

                            
Eric Rescorla Former IESG member
No Objection
No Objection (for -04)

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -04)

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -04)

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -04)

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -04)

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -04)

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -04)