Sieve Email Filtering: Delivering to Special-Use Mailboxes
Dovecot OyLars Sonckin Kaari 1602600EspooFinlandstephan.bosch@dovecot.fi
General
sievemailboxspecial-useThe 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.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
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.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 .Conventions for notations are as in Section 1.1,
including use of the "Usage:" label for the definition of action and tagged
arguments syntax.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:
at least one mailbox exists in the mail store that has that particular
special-use flag assigned, andthat 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:
the indicated mailbox exists, that mailbox allows the user in whose context the Sieve script runs
to "deliver" messages into it, andthat 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.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.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.A Sieve implementation that defines the "specialuse_exists" test and
the ":specialuse" argument for the "fileinto" command will advertise the
capability string "special-use".
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".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 example is used in a Sieve script that is triggered from an
IMAP event, rather than at message delivery . 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.[FIXME]Additional security considerations are discussed in
.The following template specifies the IANA registration of the Sieve
extension specified in this document:This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keywordThe Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox MetadataThe IMAP METADATA ExtensionSieve: An Email Filtering LanguageIMAP LIST Extension for Special-Use MailboxesSieve Email Filtering: Variables ExtensionINTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1Support for Internet Message Access Protocol (IMAP) Events in Sieve