Sieve Email Filtering: Delivering to Special-Use Mailboxes
draft-ietf-extra-sieve-special-use-00

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 an anonymous mailbox that has a particular special-use attribute assigned.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 https://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 March 19, 2018.

Copyright Notice

Copyright (c) 2017 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.

Table of Contents

• 1. Introduction
• 2. Conventions Used in This Document
• 3. Test "specialuse_exists"
• 4. ":specialuse" Argument to "fileinto" Command
• 4.1. Interaction with ":create" Argument to "fileinto" Command
• 5. Sieve Capability Strings
• 6. Examples
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Author's Address

1. Introduction

Commonly, several mailboxes in an IMAP message store 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 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, 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 cannot find an anonymous mailbox that has a particular special-use attribute assigned. 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, which allows testing for the presence of a special-use attribute in the "/private/specialuse" 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.

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 whether a special-use attribute is assigned for a particular mailbox or - if omitted - any mailbox. It also adds the ability to file messages into an anonymous mailbox that has a particular special-use attribute assigned using a ":specialuse" argument for the "fileinto" command.

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].

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

3. Test "specialuse_exists"

Usage:  specialuse_exists [<mailbox: string>]
                          <special-use-flags: 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 flags listed in the "special-use-flags" argument:

1. at least one mailbox exists in the mail store that has that particular special-use flag assigned, and
2. 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:

1. the indicated mailbox exists,
2. that mailbox allows the user in whose context the Sieve script runs to "deliver" messages into it, and
3. that mailbox has all of the special-use flags listed in the "special-use-flags" argument assigned to it.

Refer to the specification of the "mailboxexists" test in Section 3.1 of RFC 5490 for a definition of when "delivery" of messages into a mailbox is deemed possible.

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

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

Normally, the "fileinto" command delivers the message in the mailbox specified using its positional mailbox argument. However, if the optional ":specialuse" argument is also specified, the "fileinto" command first checks whether a mailbox exists with the specified special-use flag 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 flag 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:

• An anonymous special-use mailbox, which has at least the special-use flag specified with the ":specialuse" argument assigned to it.
• 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 flag specified with the ":specialuse" argument MUST conform to the "use-attr" syntax described in Section 6 of RFC6154. Implementations SHOULD handle an invalid special-use flag 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 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.

More than one mailbox can have a particular special-use flag assigned. In that case, the mailbox that is chosen for delivery is implementation-defined. However, implementations MUST ensure that this choice is made consistently, so that the same mailbox is used every time.

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

The "mailbox" extension 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.

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.

If the server implementation supports the CREATE-SPECIAL-USE capability 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".

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.

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 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] and [SPECIAL-USE]. It is believed that this extension does not introduce any additional security concerns.

8. IANA Considerations

The following template specifies the IANA registration of the Sieve extension specified in this document:

   To: iana@iana.org
   Subject: Registration of new Sieve extension

   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, and it adds
                    the ability to file messages into an anonymous
                    mailbox that has a particular IMAP special-use
                    attribute assigned.
   RFC number:      this RFC
   Contact address: Sieve mailing list <sieve@ietf.org>

This information should be added to the list of sieve extensions given on http://www.iana.org/assignments/sieve-extensions.

9. Acknowledgements

Thanks to Barry Leiba, Alexey Melnikov, Ken Murchison, and Ned Freed for reviews and suggestions.

10. References

10.1. Normative References

10.2. Informative References

Author's Address