Skip to main content

Sieve Email Filtering: Delivery by MAILBOXID
RFC 9042


Murray Kucherawy
(Barry Leiba)

No Objection

Alvaro Retana
Erik Kline
Roman Danyliw
(Deborah Brungard)
(Martin Vigoureux)

No Record

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

Murray Kucherawy
(was No Objection) Yes
Alvaro Retana
No Objection
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment (2021-03-12 for -07)
Thank you for this document, which I found clear and easy to read.

I would only like to bring up again Magnus unanswered comment about formal syntax, and hope that the working group can address that before the document moves forward. Thread starting here:

Martin Duke
No Objection
Comment (2020-12-11 for -06)
* Do I understand the example correctly in Section 4.1?

- If "Fnosuch" and "" exist, it gets filed to Fnosuch.
- If "Fnosuch" exists but "" does not, it's filed to Fnosuch but is created as well.
- If "Fnosuch" does not exist, it goes to "", which is created if necessary.

If not, some additional clarification here would be useful.

* Similarly, am I correct that Section 6's example is functionally equivalent to Section 4's example (although not demonstrating use of the test)? If so, the "Note to implementers" might as well make that clear as well.
Robert Wilton
No Objection
Comment (2020-12-16 for -06)

Thanks for this document.  It was easy to read/understand.

One minor suggestion.  It would perhaps be better to use "SHOULD" rather than "It is advisable" in section 4.2.

One nit: "end run" rather than "endrun"?

Roman Danyliw
No Objection
Éric Vyncke
No Objection
Comment (2020-12-13 for -06)
Thank you for the work put into this document. This extension seems obvious and quite useful.

Please find below one some nits.

I hope that this helps to improve the document,



As a side note about the document shepherd's write-up, so much I liked the WG summary, so much I am surprized by the similar section 7 and 8 ;-)

Should the example be delimited by <CODE BEGINS> <CODE ENDS> ?
Barry Leiba Former IESG member
Yes (for -06)

Benjamin Kaduk Former IESG member
No Objection
No Objection (2020-12-19 for -06)
[edited to add: please respond to the secdir review.  Adding the :mailboxid
that takes precedence over the human-readable name does seem to be a case
where retrofitting functionality in can leave some rough edges.]

Section 1

Thanks to the document shepherd for noting the lack of specific mention
in the Introduction that RFC 5228 is updated (and how).  Because the
Abstract and Introduction are supposed to be able to stand separately,
some text similar to what is in the Abstract should also be present in
the Introduction.

Section 3

   Scripts which use the following extensions MUST explicitly require
   the capability "mailboxid".

(editorial) since it may not be immediately clear "what follows", I'd
consider s/the following extensions/the extensions defined in this

Section 4.1

At risk of piling on, my suggested rewording for the initial paragraph
here would be:

% For servers that support the [RFC5490] mailbox extension, the
% ":mailboxid" modifier may be specified together with the ":create"
% modifier.  However, in this case the ":mailboxid" modifier has no
% effect, with the ":create" modifier causing the mailbox to be created
% and otherwise interacting as normal with all other extensions.

Section 5

   This document extends the definition of the ":fcc" argument defined
   in [RFC8580] so that it can optionally be used with the ":mailboxid"

Is it normal to make this kind of behavior change without a formal
"Updates:" relationship?

Section 6

   a) the READ-WRITE response code is present for the mailbox (see
   Section 7.1 of [RFC3501]), if IMAP Access Control List (ACL)
   [RFC4314] is not supported by the server, or

Just to confirm, if the server does not provide response codes at all,
the client has to assume that delivery is not possible to that folder?

   b) the user has 'p' or 'i' rights for the mailbox (see Section 5.2 of

I'm not sure where the 'p' comes from; it is mentioned (as "p", with
double quotes) only once in §2.2, as part of the statement that
rights defined in RFC 2028 MUST NOT be present in the "RIGHTS="
capability.  In particular, following the reference suggests that it is
'e' and 'i' that correspond to READ-WRITE.

Section 9

There are quite a few extensions listed at
and this document only discusses the interaction of the "mailboxid"
extension with a handful of them.  I did not attempt to examine all
extensions that are currently registered to check for potential
interactions with "mailboxid" that might have security-relevant
considerations, but I encourage the authors and/or shepherd to ensure
that such a check has been made.

Section 14

I find it interesting that the changelog for the -04 reports that RFC
5490 has been moved to normative, but it shows up as informative now (in
the -06) with no other changelog mention.  (I don't currently have a
position on which classification of reference is more appropriate for

However, it seems like RFCs 3501 and 4314 need to be normative, since
they are used to determine the behavior of the "mailboxidexists" test.
Deborah Brungard Former IESG member
No Objection
No Objection (for -06)

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

Magnus Westerlund Former IESG member
(was Discuss) No Record
No Record (2021-03-09 for -07)
Clearing my discuss as I step down. The text in section 4.1 was addressed, however I do question the removal of the formal syntax if that was the right thing to do? Have not received an answer and I think the responsible AD should have a discussion with the WG if this was the right step.