--- 1/draft-ietf-extra-sieve-special-use-02.txt 2018-09-05 09:13:14.940618738 -0700 +++ 2/draft-ietf-extra-sieve-special-use-03.txt 2018-09-05 09:13:14.960619217 -0700 @@ -1,18 +1,18 @@ EXTRA S. Bosch Internet-Draft Dovecot Oy -Intended status: Standards Track March 5, 2018 -Expires: September 6, 2018 +Intended status: Standards Track September 5, 2018 +Expires: March 9, 2019 Sieve Email Filtering: Delivering to Special-Use Mailboxes - draft-ietf-extra-sieve-special-use-02 + draft-ietf-extra-sieve-special-use-03 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 @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 6, 2018. + This Internet-Draft will expire on March 9, 2019. Copyright Notice Copyright (c) 2018 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -50,30 +50,30 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Test "specialuse_exists" . . . . . . . . . . . . . . . . . . 3 4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 4 - 4.1. Interaction with ":create" Argument to "fileinto" Command 5 - 5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 5 - 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 4.1. Mailboxes Created Implicitly by the "fileinto" Command . 5 + 5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 6 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 10.2. Informative References . . . . . . . . . . . . . . . . . 8 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 10.2. Informative References . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 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. 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- @@ -180,80 +180,91 @@ "variables" extension [VARIABLES] is active. In that case, the syntax of the special-use flag is only verified at runtime. If neither the special-use mailbox nor the default mailbox exists, the "fileinto" action MUST proceed exactly as it does in case the ":specialuse" is 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 RFC5228 [SIEVE]. More than one mailbox in the user's personal namespace can have a - particular special-use flag assigned. In case of such ambiguity, the - mailbox that is chosen for delivery is implementation-defined. - However, while the set of mailboxes to which the involved special-use - flags are assigned remains unchanged, implementations MUST 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). + particular special-use flag 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 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. -4.1. Interaction with ":create" Argument to "fileinto" Command +4.1. Mailboxes Created Implicitly by the "fileinto" Command - The "mailbox" extension [SIEVE-MAILBOX] adds the optional ":create" - argument to the "fileinto" command. If the optional ":create" - argument is specified with "fileinto", it instructs the Sieve - interpreter to create the specified mailbox if needed, before - attempting to deliver the message into the specified mailbox. + 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 RFC5228 [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 combined with the ":specialuse" argument, the ":create" argument - instructs the Sieve interpreter to create the specified default - mailbox if needed. This need arises when both the special-use and - the default mailbox are not found. + 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. If the server implementation supports the CREATE-SPECIAL-USE - capability [SPECIAL-USE] for IMAP, i.e. it allows assigning special- - use flags to new mailboxes, it SHOULD assign the special-use flag + capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special- + use flags to new mailboxes) it SHOULD assign the special-use flag specified with the ":specialuse" argument to the newly created mailbox. 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". + 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 handles the case in which neither - a "\Junk" special-use mailbox nor the "Spam" mailbox exist. 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. + The following very similar example explicitly handles the case in + which neither a "\Junk" special-use mailbox nor the "Spam" mailbox + exist. 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"; 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 @@ -368,15 +379,15 @@ [IMAPSIEVE] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, November 2012, . Author's Address Stephan Bosch Dovecot Oy - Lars Sonckin Kaari 10 + Lars Sonckin Kaari 12 Espoo 02600 Finland Email: stephan.bosch@dovecot.fi