RFC 8579

Sieve Email Filtering: Delivering to Special-Use Mailboxes

πŸ“… published May 2019, from ietf

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

Part 1 of 3 🧚

Here's the title block, bestie πŸŽ€

  • RFC number: 8579
  • Title: Sieve Email Filtering: Delivering to Special-Use Mailboxes
  • Author: S. Bosch, Open Xchange Oy
  • Category: Standards Track
  • Date: May 2019
  • ISSN: 2070-1721
  • Obsoletes/Updates: The title block doesn't list any RFCs that this one obsoletes or updates.

Abstract ✨

okay so the SPECIAL-USE capability of IMAP (RFC 6154) lets clients figure out which mailboxes are special-use, like where drafts or sent messages should go πŸ’Œ which makes client setup way easier. but the Sieve mail filtering language (RFC 5228) currently has zero of that πŸ’€ this memo fills that gap! it adds a test that checks whether a special-use attribute is assigned to a particular mailbox or to any mailbox, and it lets messages get filed into a mailbox identified only by a special-use attribute πŸ¦‹

Status of This Memo 🌸

this is an Internet Standards Track document πŸ‘‘

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 7841 πŸ“š

for the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8579 πŸ”—

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 🫢

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. please actually read these, because they spell out your rights and restrictions for this document βš–οΈ code components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

Table of Contents πŸ“

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
3.  Test "specialuse_exists"  . . . . . . . . . . . . . . . . . .   3
  3.1.  Equivalent IMAP Operations  . . . . . . . . . . . . . . .   4
4.  ":specialuse" Argument to "fileinto" Command  . . . . . . . .   5
  4.1.  Mailboxes Created Implicitly by the "fileinto" Command  .   6
  4.2.  Equivalent IMAP Operations  . . . . . . . . . . . . . . .   7
5.  Sieve Capability Strings  . . . . . . . . . . . . . . . . . .   8
6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction πŸŽ€

okay so several mailboxes in an IMAP message store [IMAP] usually have a special use. for example, you might have one for your draft messages, one for keeping copies of sent messages, and one for collecting spam that got classified as spam at delivery πŸ—‘οΈ the SPECIAL-USE capability [SPECIAL-USE] of IMAP defines mailbox attributes that explicitly tell the client which mailboxes are the special ones, so client configuration gets way simpler ✨ and with the CREATE-SPECIAL-USE capability [SPECIAL-USE], IMAP clients can even set these attributes dynamically based on user preference πŸ¦‹

but Sieve, the mail filtering language [SIEVE], currently can't freely access these special-use mailbox attributes 😭 like, the Sieve interpreter has no way to identify a mailbox with a particular special-use attribute. that would be sooo useful for finding the user's "Spam" mailbox at delivery πŸ™ˆ

in Sieve, there's limited access through the "mboxmetadata" extension [SIEVE-MAILBOX]. it lets you test for a special-use attribute in the /private/specialuse IMAP METADATA [IMAP-METADATA] entry of a mailbox. still, not every implementer is up for adding the complexity of the IMAP METADATA capability just to give the Sieve interpreter access to special-use attributes πŸ’…

so this document defines a Sieve extension that lets you freely access mailbox special-use attributes πŸ’– it adds a test called specialuse_exists, which checks 1) whether a special-use attribute is assigned for a particular mailbox, or 2) whether any of the user's personal mailboxes have a special-use attribute assigned. it also lets you file messages into a personal mailbox identified by a particular special-use attribute, instead of by the mailbox's name. you do this with the new :specialuse argument for the fileinto command [SIEVE] 🌈

2. Conventions Used in This Document ✨

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [KEYWORDS] [KEYWORDS-UPD] when, and only when, they appear in all capitals, as shown here. πŸ“– (capitals only, bestie, lowercase doesn't count πŸ™…)

conventions for notations are as described in Section 1.1 of [SIEVE], including the use of the "Usage:" label for the definition of the action and the syntax of tagged arguments 🧩

in [IMAP] examples, "C:" and "S:" indicate lines sent by the client and server, respectively. if such lines are wrapped without a new "C:" or "S:" label, then the wrapping is just for editorial clarity and isn't part of the command πŸ’Œ

3. Test "specialuse_exists" πŸ¦‹

Usage:  specialuse_exists [<mailbox: string>]
                         <special-use-attrs: string-list>

if the "mailbox" string argument is omitted, the specialuse_exists test yields "true" if all of the following statements are true for each of the special-use attributes listed in the special-use-attrs argument:

a. at least one mailbox exists in the user's personal namespace [NAMESPACE] that has that particular special-use attribute assigned.

b. that mailbox allows the user in whose context the Sieve script runs to "deliver" messages into it.

if the mailbox argument is specified, the specialuse_exists test yields "true" if all of the following statements are true:

a. the indicated mailbox exists.

b. that mailbox allows the user in whose context the Sieve script runs to "deliver" messages into it.

c. that mailbox has all of the special-use attributes listed in the special-use-attrs argument assigned to it.

for a definition of when "delivery" of messages into a mailbox is deemed possible, refer to the specification of the "mailboxexists" test in Section 3.1 of RFC 5490 [SIEVE-MAILBOX] πŸ”

3.1. Equivalent IMAP Operations 🧠

to make this clearer, the following IMAP protocol examples show a sequence of [IMAP] commands that a client could send to do an assessment without Sieve that's equivalent to the specialuse_exists test πŸ’‘

first, the client asks which namespaces are available, using the NAMESPACE command [NAMESPACE]:

C: A01 NAMESPACE
S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/"))
S: A01 OK NAMESPACE command completed

then, when no particular mailbox is of interest (i.e., the specialuse_exists test has no mailbox argument), the client lists all mailboxes with special-use attributes in the two returned personal namespaces. this extended LIST command requires the LIST-EXTENDED IMAP capability [LIST-EXTENDED] 🌸

C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*")
    RETURN (SPECIAL-USE)
S: * LIST (\Drafts) "/" INBOX/Drafts
S: * LIST (\Trash) "/" INBOX/Trash
S: * LIST (\Sent) "/" INBOX/Sent
S: * LIST (\Archive) "/" Archive/Default
S: A02 OK LIST command completed

finally, using the MYRIGHTS command [IMAP-ACL], the client checks the access rights it has for the mailbox or mailboxes that have all the requested attributes assigned. that way it can tell whether messages can be saved to any of them. in this example, an "\Archive" special-use mailbox is being looked for πŸ‘€

C: A03 MYRIGHTS Archive/Default
S: * MYRIGHTS Archive/Default lrwsip
S: A03 OK Myrights completed

the MYRIGHTS response shows that the user has "insert" rights [IMAP-ACL] for the "Archive/Default" mailbox πŸŽ‰ which means the client can deliver (APPEND) messages to that mailbox, and the Sieve specialuse_exists test would yield "true" in this case πŸ₯°

4. ":specialuse" Argument to "fileinto" Command ✨

Okay bestie, the :specialuse argument is the main character of this section πŸ’– Here's the usage:

Usage:  fileinto [:specialuse <special-use-attr: string>]
                 <mailbox: string>

So normally, fileinto drops the message into whatever mailbox you name with its positional argument πŸ“¬. But if you also add :specialuse, it first checks whether there's a mailbox in the user's personal namespace [NAMESPACE] that has that special-use attribute assigned to it. If it finds one, that special-use mailbox wins πŸ†. If there's no such mailbox, or the attribute isn't known to the implementation in general, fileinto just acts like :specialuse was never there 🫢

Summing it up, when :specialuse shows up, fileinto is juggling two mailboxes that may or may not exist, and they might even be the same one πŸ‘―

  • A special-use mailbox in the user's personal namespace, which has at least the special-use attribute from the :specialuse argument assigned to it. Its name doesn't matter here, because it's only identified by that attribute 🏷️
  • The default mailbox named by the positional string argument of fileinto, which gets used when the special-use mailbox can't be found πŸ“

The special-use attribute you pass with :specialuse has to follow the "use-attr" syntax from Section 6 of RFC 6154 [SPECIAL-USE]. Implementations SHOULD handle an invalid special-use attribute the same way they handle an invalid mailbox name πŸ™ˆ The string parameter of :specialuse isn't a constant, so variable substitutions are allowed when the "variables" extension [VARIABLES] is active. In that case, the syntax of the special-use attribute only gets checked at runtime ⏱️

If neither the special-use mailbox nor the default mailbox exists, the "fileinto" action MUST proceed exactly as it would if :specialuse were absent and the mailbox named by its positional argument didn't exist 😭 The different ways of handling that situation are described in Section 4.1 of RFC 5228 [SIEVE].

More than one mailbox in the personal namespace can have a particular special-use attribute, and if one of them is the default mailbox named by the positional string argument, that mailbox MUST be used for delivery πŸ‘‘ If the default mailbox isn't one of the options, the mailbox that gets picked is implementation defined. Still, as long as the set of mailboxes with that attribute stays the same, implementations SHOULD make sure the choice is consistent, so the same mailbox gets used every time πŸ’… On the flip side, the chosen mailbox MAY change once the attribute assignments that matter for the choice get changed (usually through user interaction) πŸ¦‹

If delivery to the special-use mailbox fails for reasons that aren't about it not existing, the Sieve interpreter MUST NOT try the default mailbox as a fallback afterwards 🚫 Instead, it MUST proceed exactly as it would if :specialuse were absent and delivery to the mailbox named by its positional argument failed. This stops messages from getting unexpectedly spread across two mailboxes when there are transient or intermittent delivery failures 🧚

4.1. Mailboxes Created Implicitly by the "fileinto" Command

Before trying to deliver the message into the specified mailbox, the "fileinto" command may implicitly create that mailbox if it doesn't exist (see Section 4.1 of RFC 5228 [SIEVE]). You can ask for this behavior explicitly with the "mailbox" extension [SIEVE-MAILBOX], which adds an optional :create argument to fileinto. If :create is specified, the Sieve interpreter unconditionally creates the specified mailbox if needed πŸ› οΈ Note that :create has no effect when implicit creation is already the default behavior πŸ™ƒ

When :specialuse is present, nothing changes here: the Sieve interpreter will still implicitly create the specified default mailbox if needed. That need pops up when both the special-use mailbox and the default mailbox can't be found 🌸

If the server implementation supports the CREATE-SPECIAL-USE capability [SPECIAL-USE] for IMAP (meaning it lets you assign special-use attributes to new mailboxes), it SHOULD assign the special-use attribute specified with :specialuse to the newly created mailbox πŸŽ€

4.2. Equivalent IMAP Operations

To clarify, the following IMAP protocol examples show a sequence of [IMAP] commands a client could send to do, without Sieve, the same thing that the fileinto action does with the :specialuse argument 🧠 The following Sieve script is assumed:

require "fileinto";
require "special-use";

fileinto :specialuse "\\Archive" "INBOX/Archive";

First, the client follows Section 3.1 to find out whether the indicated special-use attribute is assigned to any mailbox in the user's personal namespace πŸ” If it finds a matching special-use mailbox, the message gets delivered there with the IMAP APPEND command. If there's no matching special-use mailbox, the client tries to deliver the message to the indicated default mailbox:

C: A04 APPEND INBOX/Archive {309}
S: A04 NO [TRYCREATE] Mailbox does not exist: INBOX/Archive

In this example, the default mailbox doesn't exist either πŸ₯² In that case, the client MAY create the default mailbox and assign the indicated special-use attribute to it:

C: A05 CREATE INBOX/Archive (USE (\Archive))
S: A05 OK Create completed

Finally, the client completes the delivery πŸŽ‰

C: A06 APPEND INBOX/Archive {309}
S: + OK
C: Date: Wed, 18 Jul 2018 22:00:09 +0200
C: From: mooch@owatagu.siam.example
C: To: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting
C: Message-Id: <Q234234-01012222@owatagu.siam.example>
C: MIME-Version: 1.0
C: Content-Type: text/plain; charset=UTF-8
C:
C: Hi Fred, do you think we can meet again at 3:30 tomorrow?
C:
S: A06 OK [APPENDUID 1533375901 2312] Append completed.

5. Sieve Capability Strings 🧩

A Sieve implementation that defines the "specialuse_exists" test and the :specialuse argument for the "fileinto" command will advertise the capability string special-use πŸ’œ

6. Examples πŸ“

Here's the first one. This script saves the message in the mailbox where junk mail gets held. That mailbox is found through the "\Junk" special-use attribute πŸ—‘οΈ If no mailbox has that attribute assigned, the message goes into the mailbox named "Spam". And if the "Spam" mailbox doesn't exist either, the result of this Sieve script is implementation dependent. For example, it may trigger an error or the mailbox may be created implicitly πŸ€·β€β™€οΈ

require "fileinto";
require "special-use";

fileinto :specialuse "\\Junk" "Spam";

The next one is very similar, but it explicitly handles the case where neither a "\Junk" special-use mailbox nor the "Spam" mailbox exists. In that situation, a mailbox called "Spam" gets created and the message is stored there. The "\Junk" special-use attribute may also be assigned to it ✨

require "fileinto";
require "special-use";
require "mailbox";

fileinto :specialuse "\\Junk" :create "Spam";

This last example is used in a Sieve script that's triggered by an IMAP event rather than at message delivery [IMAPSIEVE] πŸ‘€ The script redirects messages to an automated recipient that processes junk mail, but only if those messages are copied or moved into a mailbox that has the "\Junk" special-use attribute assigned πŸ€–

require "imapsieve";
require "special-use";
require "environment";
require "variables";

if environment :contains "imap.mailbox" "*" {
    set "mailbox" "${1}";
}

if allof(
    environment "imap.cause" "COPY",
    specialuse_exists "${mailbox}" "\\Junk") {
    redirect "spam-report@example.org";
}

7. Security Considerations πŸ”

Security considerations are discussed in [SIEVE], [VARIABLES], and [SPECIAL-USE]. It is believed that this extension does not introduce any additional security concerns πŸ™

Note that this specification explicitly restricts the special-use mailbox to the user's personal namespace. First, this avoids the need to search the entire mail storage for mailboxes that have a particular special-use attribute assigned. This could put undue load on the system, while shared special-use mailboxes are deemed of limited use with the currently defined special-use attributes. Secondly, it prevents security concerns with shared mailboxes that have special-use attributes assigned that apply to all users. Searching the entire mail storage for special-use mailboxes could lead to messages unexpectedly or even maliciously being filed to shared mailboxes. 😱

This restriction could be lifted for particular future special-use attributes, but such new attributes should have a clear application for shared mailboxes, and the security concerns should be considered carefully 🧐

8. IANA Considerations πŸ›οΈ

IANA has registered the Sieve extension specified in this document in the "Sieve Extensions" registry at https://www.iana.org/assignments/sieve-extensions:

Capability name: special-use
Description:     adds a test for checking whether an IMAP
                 special-use attribute is assigned for a
                 particular mailbox or any mailbox; also adds
                 the ability to file messages into a mailbox
                 identified solely by a special-use attribute.
RFC number:      RFC 8579
Contact address: Sieve discussion list <sieve@ietf.org>

9. References πŸ“š

9.1. Normative References πŸ’–

okay bestie, these are the docs this spec leans on the hardest, so you need them for real πŸ“šβœ¨


9.2. Informative References 🌸

these ones are the background reading, super helpful for context but not strictly needed to implement the thing 🧚


Acknowledgements πŸ™

big thank yous to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison, and Ned Freed for reviewing and giving suggestions 🫢

also a shoutout to the authors of RFC 5490 [SIEVE-MAILBOX], since some of the descriptive text in this doc was borrowed from them πŸ“–πŸ’œ


Author's Address ✨

Stephan Bosch
Open Xchange Oy
Lars Sonckin kaari 12
Espoo  02600
Finland

Email: stephan.bosch@open-xchange.com
πŸ“¦ where this page comes from