Sieve Email Filtering: Delivering to Special-Use Mailboxes
Open Xchange OyLars Sonckin kaari 1202600EspooFinlandstephan.bosch@open-xchange.com
ART
EXTRAsievemailboxspecial-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 a mailbox identified solely by a special-use
attribute.Commonly, several mailboxes in an
IMAP message store 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 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 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, 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 of the user's personal
mailboxes. 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.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
when, and only when,
they appear in all capitals, as shown here. Conventions for notations are as in Section 1.1,
including use of the "Usage:" label for the definition of action and tagged
arguments syntax.In 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.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:
at least one mailbox exists in the user's personal namespace
that has that particular special-use attribute
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 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 for a definition of when "delivery"
of messages into a mailbox is deemed possible.To clarify, a sequence of commands that a client
could send to perform an assessment without Sieve that is equivalent to the
"specialuse_exists" test is shown in the following IMAP protocol examples.First, the client queries which namespaces are available using the
NAMESPACE command :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
):Finally, using the MYRIGHTS command , 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:The MYRIGHTS response indicates that the the user has "insert" rights
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.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 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:
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.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
RFC6154. 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 is active. In that case,
the syntax of the special-use attribute 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 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 special-use attribute
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.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). This optional behavior can
be requested explicitly using the
"mailbox" extension,
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.If the server implementation supports the
CREATE-SPECIAL-USE capability 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.To clarify, a sequence of commands that a client
could send to perform an action without Sieve that is equivalent to the
"fileinto" action with the ":specialuse" argument is shown in the following
IMAP protocol examples. The following Sieve script is assumed:First, the client proceeds as in 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: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:
Finally, the client completes the delivery: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". 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.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.
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.Security considerations are discussed in ,
, and . 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.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.Thanks to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison,
and Ned Freed for reviews and suggestions.Thanks to the authors of RFC5490 from
which some descriptive text is borrowed in this document.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keywordAmbiguity of Uppercase vs Lowercase in RFC 2119 Key WordsThe IMAP METADATA ExtensionIMAP4 NamespaceSieve: An Email Filtering LanguageThe Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox MetadataIMAP LIST Extension for Special-Use MailboxesSieve Email Filtering: Variables ExtensionINTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1IMAP4 Access Control List (ACL) ExtensionSupport for Internet Message Access Protocol (IMAP) Events in SieveInternet Message Access Protocol version 4 - LIST Command Extensions