RFC 8579
Sieve Email Filtering: Delivering to Special-Use Mailboxes
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 Notice π
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
:specialuseargument 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 πβ¨
[IMAP-METADATA]Daboo, C., "The IMAP METADATA Extension", RFC 5464, DOI 10.17487/RFC5464, February 2009,<https://www.rfc-editor.org/info/rfc5464>.[KEYWORDS]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<https://www.rfc-editor.org/info/rfc2119>.[KEYWORDS-UPD]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,<https://www.rfc-editor.org/info/rfc8174>.[NAMESPACE]Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, DOI 10.17487/RFC2342, May 1998,<https://www.rfc-editor.org/info/rfc2342>.[SIEVE]Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008,<https://www.rfc-editor.org/info/rfc5228>.[SIEVE-MAILBOX]Melnikov, A., "The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March 2009,<https://www.rfc-editor.org/info/rfc5490>.[SPECIAL-USE]Leiba, B. and J. Nicolson, "IMAP LIST Extension for Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, March 2011,<https://www.rfc-editor.org/info/rfc6154>.[VARIABLES]Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, DOI 10.17487/RFC5229, January 2008,<https://www.rfc-editor.org/info/rfc5229>.
9.2. Informative References πΈ
these ones are the background reading, super helpful for context but not strictly needed to implement the thing π§
[IMAP]Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,<https://www.rfc-editor.org/info/rfc3501>.[IMAP-ACL]Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005,<https://www.rfc-editor.org/info/rfc4314>.[IMAPSIEVE]Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, November 2012,<https://www.rfc-editor.org/info/rfc6785>.[LIST-EXTENDED]Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, DOI 10.17487/RFC5258, June 2008,<https://www.rfc-editor.org/info/rfc5258>.
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
- ietf: rfc8579 2019-05
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms