From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8579.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc8579.txt (limited to 'doc/rfc/rfc8579.txt') diff --git a/doc/rfc/rfc8579.txt b/doc/rfc/rfc8579.txt new file mode 100644 index 0000000..519395d --- /dev/null +++ b/doc/rfc/rfc8579.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Bosch +Request for Comments: 8579 Open Xchange Oy +Category: Standards Track May 2019 +ISSN: 2070-1721 + + + Sieve Email Filtering: Delivering to Special-Use Mailboxes + +Abstract + + The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows + clients to identify special-use mailboxes, e.g., where draft or sent + messages should be put. This simplifies client configuration. In + contrast, the Sieve mail filtering language (RFC 5228) currently has + no such capability. This memo defines a Sieve extension that fills + this gap: it adds a test for checking whether a special-use attribute + is assigned for a particular mailbox or any mailbox, and it adds the + ability to file messages into a mailbox identified solely by a + special-use attribute. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to 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 are provided without warranty as + described in the Simplified BSD License. + + + +Bosch Standards Track [Page 1] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + +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 + + Commonly, several mailboxes in an IMAP message store [IMAP] have a + special use. For example, there can be a special-use mailbox for + storing the user's draft messages, for keeping copies of sent + messages, and for collecting spam messages that were classified as + such at delivery. The SPECIAL-USE capability [SPECIAL-USE] of the + IMAP protocol defines mailbox attributes that identify these special + mailboxes explicitly to the client. This way, client configuration + is simplified significantly. Using the CREATE-SPECIAL-USE capability + [SPECIAL-USE], IMAP clients can also configure these attributes + dynamically based on user preference. + + Unlike the IMAP protocol, the Sieve mail filtering language [SIEVE] + currently cannot freely access these special-use mailbox attributes. + Particularly, the Sieve interpreter has no means to identify a + mailbox with a particular special-use attribute. This would be very + useful, for example, to find the user's "Spam" mailbox at delivery. + + In Sieve, limited access to the special-use attributes is provided + using the "mboxmetadata" extension [SIEVE-MAILBOX], which allows + testing for the presence of a special-use attribute in the "/private/ + specialuse" IMAP METADATA [IMAP-METADATA] entry of a mailbox. Still, + not all implementers will be willing to add the complexity of the + IMAP METADATA capability just to provide access to special-use + attributes to the Sieve interpreter. + + + + + + +Bosch Standards Track [Page 2] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + + This document defines an extension to the Sieve mail filtering + language that adds the ability to freely access mailbox special-use + attributes. It adds a test called "specialuse_exists" that 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 adds the ability to file messages into a + personal mailbox identified by a particular special-use attribute + rather than the mailbox's name. This is achieved using 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. + + Conventions for notations are as described in Section 1.1 of [SIEVE], + including 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 for editorial clarity and is + not part of the command. + +3. Test "specialuse_exists" + + Usage: specialuse_exists [] + + + 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. + + + + + + + + +Bosch Standards Track [Page 3] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + + 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. + + Refer to the specification of the "mailboxexists" test in Section 3.1 + of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of + messages into a mailbox is deemed possible. + +3.1. Equivalent IMAP Operations + + To clarify, the following IMAP protocol examples show a sequence of + [IMAP] commands that a client could send to perform an assessment + without Sieve that is equivalent to the "specialuse_exists" test. + + First, the client queries which namespaces are available using the + NAMESPACE command [NAMESPACE]: + + C: A01 NAMESPACE + S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/")) + S: A01 OK NAMESPACE command completed + + Subsequently, 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 determines + the access rights it has for the mailbox or mailboxes that have all + the requested attributes assigned. This way, it can determine + whether messages can be saved to any of those. In this example, an + "\Archive" special-use mailbox is sought: + + + + +Bosch Standards Track [Page 4] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + + C: A03 MYRIGHTS Archive/Default + S: * MYRIGHTS Archive/Default lrwsip + S: A03 OK Myrights completed + + The MYRIGHTS response indicates that the user has "insert" rights + [IMAP-ACL] for the "Archive/Default" mailbox, meaning that the client + can deliver (APPEND) messages to that mailbox and that the Sieve + "specialuse_exists" test would yield "true" in this case. + +4. ":specialuse" Argument to "fileinto" Command + + Usage: fileinto [:specialuse ] + + + Normally, the "fileinto" command delivers the message in the mailbox + specified using its positional mailbox argument, which is the name of + the mailbox. However, if the optional ":specialuse" argument is also + specified, the "fileinto" command first checks whether a mailbox + exists in the user's personal namespace [NAMESPACE] with the + specified special-use attribute assigned to it. If that is the case, + that special-use mailbox is used for delivery instead. If there is + no such mailbox or if the specified special-use attribute is unknown + to the implementation in general, the "fileinto" action proceeds as + it would without the ":specialuse" argument. + + Summarizing, if the ":specialuse" argument is specified, the + "fileinto" command deals with two mailboxes that may or may not exist + and may, in fact, be equal: + + o A special-use mailbox in the user's personal namespace, which has + at least the special-use attribute specified with the + ":specialuse" argument assigned to it. The name for this mailbox + is not relevant here; it is only identified by the assigned + special-use attribute. + + o The default mailbox named by the positional string argument of the + "fileinto" command, which is used when the special-use mailbox is + not found. + + The special-use attribute specified with the ":specialuse" argument + conforms to the "use-attr" syntax described in Section 6 of RFC 6154 + [SPECIAL-USE]. Implementations SHOULD handle an invalid special-use + attribute in the same way as an invalid mailbox name is handled. The + string parameter of the ":specialuse" argument is not a constant + string, which means that variable substitutions are allowed when the + "variables" extension [VARIABLES] is active. In that case, the + syntax of the special-use attribute is only verified at runtime. + + + + +Bosch Standards Track [Page 5] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + + If neither the special-use mailbox nor the default mailbox exists, + the "fileinto" action MUST proceed exactly as it does in case the + ":specialuse" argument is absent and the mailbox named by its + positional argument does not exist. The various options for handling + this situation are described in Section 4.1 of RFC 5228 [SIEVE]. + + More than one mailbox in the user's personal namespace can have a + particular special-use attribute assigned. If one of those mailboxes + is, in fact, the default mailbox named by the positional string + argument of the "fileinto" command, that mailbox MUST be used for + delivery. If the default mailbox is not one of the options, the + mailbox that is chosen for delivery is implementation defined. + However, while the set of mailboxes to which the involved special-use + attribute 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 assignments of the special-use attribute 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 fallback. 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. + +4.1. Mailboxes Created Implicitly by the "fileinto" Command + + Before attempting to deliver the message into the specified mailbox, + the "fileinto" command may implicitly create the mailbox if it does + not exist (see Section 4.1 of RFC 5228 [SIEVE]). This optional + behavior can be requested explicitly using the "mailbox" extension + [SIEVE-MAILBOX], which adds the optional ":create" argument to the + "fileinto" command. If the ":create" argument is specified with + "fileinto", it instructs the Sieve interpreter to unconditionally + create the specified mailbox if needed. Note that the ":create" + argument has no effect when the implicit creation of mailboxes for + delivery is the default behavior. + + When the ":specialuse" argument is present, this behavior does not + change; the Sieve interpreter will implicitly create the specified + default mailbox if needed. This need arises when both the special- + use mailbox and the default mailbox are not found. + + + + + +Bosch Standards Track [Page 6] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + + If the server implementation supports the CREATE-SPECIAL-USE + capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special- + use attributes to new mailboxes), it SHOULD assign the special-use + attribute specified with the ":specialuse" argument to the newly + created mailbox. + +4.2. Equivalent IMAP Operations + + To clarify, the following IMAP protocol examples show a sequence of + [IMAP] commands that a client could send to perform an action without + Sieve that is equivalent to the "fileinto" action with the + ":specialuse" argument. The following Sieve script is assumed: + + require "fileinto"; + require "special-use"; + + fileinto :specialuse "\\Archive" "INBOX/Archive"; + + First, the client proceeds as in Section 3.1 to find out whether the + indicated special-use attribute is assigned to any mailbox in the + user's personal namespace. If a matching special-use mailbox is + found, the message is delivered there using the IMAP APPEND command. + If no matching special-use mailbox is found, the client attempts 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 does not 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 + + + + + + + + + + + + + + + + + +Bosch Standards Track [Page 7] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + + 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 + C: Subject: afternoon meeting + C: Message-Id: + 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 + + The following example saves the message in the mailbox where messages + deemed to be junk mail are held. This mailbox is identified using + the "\Junk" special-use attribute. If no mailbox has this attribute + assigned, the message is filed into the mailbox named "Spam". If the + mailbox named "Spam" does not exist either, the result of this Sieve + script is implementation dependent, e.g., it may trigger an error or + the mailbox may be created implicitly. + + require "fileinto"; + require "special-use"; + + fileinto :specialuse "\\Junk" "Spam"; + + The following very similar example explicitly handles the case in + which neither a "\Junk" special-use mailbox nor the "Spam" mailbox + exists. In that case, a mailbox called "Spam" is created, and the + message is stored there. Additionally, the "\Junk" special-use + attribute may be assigned to it. + + require "fileinto"; + require "special-use"; + require "mailbox"; + + fileinto :specialuse "\\Junk" :create "Spam"; + + + +Bosch Standards Track [Page 8] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + + The following example is used in a Sieve script that is triggered + from an IMAP event rather than at message delivery [IMAPSIEVE]. This + Sieve script redirects messages to an automated recipient that + processes junk mail 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. + + + + + + + + +Bosch Standards Track [Page 9] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + +8. IANA Considerations + + IANA has registered the Sieve extension specified in this document in + the "Sieve Extensions" registry at : + + 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 + +9. References + +9.1. Normative References + + [IMAP-METADATA] + Daboo, C., "The IMAP METADATA Extension", RFC 5464, + DOI 10.17487/RFC5464, February 2009, + . + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [KEYWORDS-UPD] + Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [NAMESPACE] + Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, + DOI 10.17487/RFC2342, May 1998, + . + + [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email + Filtering Language", RFC 5228, DOI 10.17487/RFC5228, + January 2008, . + + [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, . + + + +Bosch Standards Track [Page 10] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + + [SPECIAL-USE] + Leiba, B. and J. Nicolson, "IMAP LIST Extension for + Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, + March 2011, . + + [VARIABLES] + Homme, K., "Sieve Email Filtering: Variables Extension", + RFC 5229, DOI 10.17487/RFC5229, January 2008, + . + +9.2. Informative References + + [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, + . + + [IMAP-ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", + RFC 4314, DOI 10.17487/RFC4314, December 2005, + . + + [IMAPSIEVE] + Leiba, B., "Support for Internet Message Access Protocol + (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, + November 2012, . + + [LIST-EXTENDED] + Leiba, B. and A. Melnikov, "Internet Message Access + Protocol version 4 - LIST Command Extensions", RFC 5258, + DOI 10.17487/RFC5258, June 2008, + . + +Acknowledgements + + Thanks to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison, + and Ned Freed for reviews and suggestions. + + Thanks to the authors of RFC 5490 [SIEVE-MAILBOX], from which some + descriptive text in this document is borrowed. + + + + + + + + + + + + + +Bosch Standards Track [Page 11] + +RFC 8579 Sieve: Special-Use Mailboxes May 2019 + + +Author's Address + + Stephan Bosch + Open Xchange Oy + Lars Sonckin kaari 12 + Espoo 02600 + Finland + + Email: stephan.bosch@open-xchange.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bosch Standards Track [Page 12] + -- cgit v1.2.3