IMAP LIST extension for special-use mailboxes
Huawei Technologies+1 646 827 0648barryleiba@computer.orghttp://internetmessagingtechnology.org/Googlenicolson@google.com
Applications
Message ORGanization Working GroupIMAPemail
Some IMAP message stores include special-use mailboxes, such as those
used to hold draft messages or sent messages. Many mail clients allow
users to specify where draft or sent messages should be put, but
configuring them requires that the user know which mailboxes the
server has set aside for these purposes. This extension adds new
mailbox flags that a server MAY include in IMAP LIST command responses
to identify special-use mailboxes to the client, easing configuration.
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested, and should
be sent to morg@ietf.org.
Some IMAP message stores include special-use mailboxes, such as those
used to hold draft messages or sent messages. Many mail clients allow
users to specify where draft or sent messages should be put, but
configuring them requires that the user know which mailboxes the
server has set aside for these purposes. This extension adds new
mailbox flags that a server MAY include in IMAP LIST command responses
to identify special-use mailboxes to the client, easing configuration.
In addition, this extension adds an OPTIONAL parameter on the IMAP
CREATE command, allowing a client to assign a special use to a mailbox
when it is created. Servers MAY choose to support this part of the
extension, but are not required to.
In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client.
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 RFC 2119 .
Please remove this section and its subsections.Added wording about list-extended; added reference to RFC 5258; added example;
added registration of list-extended return option.
Changed CREATE syntax to use RFC 4466; added reference to RFC 4466; fixed example.
Added "\Archive" use flag.
Noted that multiple mailboxes might have the same flag in some implementations.
Changed some use flag names to be more general: \All (was \AllMail),
\Junk (was \Spam), \Flagged (was \Starred).
An IMAP server that supports this extension MAY include any or all of the
following flags in responses to the non-extended IMAP LIST command.
The new flags are
included along with existing flags, such as "\Marked" and "\Noselect".
A given mailbox may have none, one, or more than one of these flags.
In some cases, a special use is advice to a client about what to put
in that mailbox. In other cases, it's advice to a client about what to
expect to find there.
For the extended list command , this extension adds
a new return option, "SPECIAL-USE". The new special-use flags SHOULD be
returned if the client specifies the SPECIAL-USE return option, and MAY
be returned even if the client does not specify it.
The new flags defined here are as follows:
This mailbox is used to hold draft messages -- typically, messages that
are being composed but have not yet been sent.
In some server implementations, this might be a virtual mailbox,
containing messages from other mailboxes that are marked with the
"\Draft" message flag.
Alternatively, this might just be advice that a client put
drafts here.
This mailbox presents all messages marked in some way as "important".
When this special use is supported, it is likely to represent a
virtual mailbox collecting messages (from other mailboxes) that are
marked with the "\Flagged" message flag.
This mailbox is the inbox, where new incoming mail is placed by default.
This will normally be the same as the mailbox with the name "inbox", as
defined in the base IMAP protocol .
This mailbox is where messages deemed to be junk mail are held.
Some server implementations might put messages here automatically.
Alternatively, this might just be advice to a client-side spam filter.
This mailbox is used to hold copies of messages that have been sent.
Some server implementations might put messages here automatically.
Alternatively, this might just be advice that a client save
sent messages here.
This mailbox is used to hold messages that have been deleted, or marked
for deletion.
In some server implementations, this might be a virtual mailbox,
containing messages from other mailboxes that are marked with the
"\Deleted" message flag.
Alternatively, this might just be advice that a client that chooses
not to use the IMAP "\Deleted" model should use this as its trash
location.
In server implementations that strictly expect the IMAP "\Deleted"
model, this special use is likely not to be supported.
This mailbox presents all messages in the user's message store.
Implementations MAY omit some messages, such as, perhaps, those in \Trash
and \Junk.
When this special use is supported, it is almost certain to represent a
virtual mailbox.
This mailbox is used to archive messages.
The meaning of an "archival" mailbox is server-dependent; typically, it will be used to
get messages out of the inbox, or otherwise keep them out of the user's way, while still
making them accessible.
All of the above flags are OPTIONAL, and any given server or message
store may support any combination of the flags, or none at all.
In some server or message store implementations it might be possible for
multiple mailboxes to have the same special-use flag.
There is no capability string associated with this feature.
As an OPTIONAL feature, a server MAY allow clients to designate a
mailbox, at creation, as having one or more special uses. This
extension defines the "USE" parameter to the IMAP CREATE command
for that purpose (using the syntax defined in RFC 4466 section 2.2
).
The new OPTIONAL "USE" parameter is followed by a parenthesized list
of zero or more special-use flags, as defined above.
In some server implementations, some special uses may imply automatic
action by the server.
For example, creation of a "\Junk" mailbox
might cause the server to start placing messages that have been
evaluated as spam into the mailbox.
In some server implementations, some special uses may result in a
mailbox with unusual characteristics or side effects.
For example, creation of an "\All" mailbox might cause the server to
create a virtual mailbox, rather than a standard one, and that mailbox
might behave in unexpected ways (COPY into it might fail, for example).
Servers MAY allow the creation
of a special-use mailbox even if one so designated already exists, having
the effect of moving the special use from the old mailbox to the
new one. Alternatively, servers MAY refuse the creation, considering
the designation to be a conflict.
If the server can not create a mailbox with the designated special use
defined, for whatever reason, it MUST NOT create the mailbox, and MUST
respond to the CREATE command with a tagged NO response.
An IMAP server that supports this OPTIONAL feature will advertise the
CREATE-SPECIAL-USE capability string. Clients MUST NOT use the "USE"
parameter unless the server advertises the capability.
This example shows an IMAP LIST response from a server that supports
this extension. Note that not all of the flags are used. This server
also supports the Child Mailbox extension .
This example shows an IMAP LIST response from a server that supports
this extension. The client uses the extended IMAP LIST command.
This example shows an IMAP CREATE command that might be
used to create a mailbox designated to hold draft and
sent messages. It also attempts to create a mailbox
that will contain all the user's messages, but the server
does not support that special use for this user's message
store.
The following syntax specification uses the augmented Backus-Naur Form (BNF)
as described in .
"USE" SP "(" [use-flag *(SP use-flag)] ")"
; Extends "create-param" from RFC 4466 use-flag
; Extends "mbx-list-oflag" from IMAP base "SPECIAL-USE"
; Extends "return-option" from
; LIST-extended
"\All" /
"\Archive" /
"\Drafts" /
"\Flagged" /
"\Inbox" /
"\Junk" /
"\Sent" /
"\Trash" /
use-flag-ext
"\" atom
; Reserved for future extensions. Clients
; MUST ignore list flags they do not understand
; Server implementations MUST NOT generate
; extension flags except as defined by
; future standards-track revisions of or
; extensions to this specification.
LIST response:
There are no security issues with conveying special-use
information to a client.
CREATE command "USE" parameter:
In some server implementations, some special uses may imply automatic
action by the server. For example, creation of a "\Junk" mailbox
might cause the server to start placing messages that have been
evaluated as spam into the mailbox. Server implementors SHOULD
consider the consequences of allowing a user (or client program)
to designate the target of such automatic action.
This document defines a new IMAP capability.
IANA is asked to add "CREATE-SPECIAL-USE"
to the imap4-capabilities registry.
This document defines a new IMAP4 List Extended return option.
IANA is asked to add "SPECIAL-USE"
to the imap4-list-extended registry, as follows:
To: iana@iana.org
Subject: Registration of LIST-EXTENDED option SPECIAL-USE
LIST-EXTENDED option name: SPECIAL-USE
LIST-EXTENDED option type: RETURN
LIST-EXTENDED option description: Request special-use mailbox information
Published specification: [[this RFC]]
Security considerations: none
Intended usage: COMMON
Person and email address to contact for further information:
Authors' Addresses at the end of [[this RFC]]
Owner/Change controller: iesg@ietf.org
Key words for use in RFCs to Indicate Requirement LevelsHarvard UniversityAugmented BNF for Syntax Specifications: ABNFBrandenburg InternetWorkingTHUS plc.Internet Message Access ProtocolUniversity of WashingtonCollected Extensions to IMAP4 ABNFIsode LimitedInternet Message Access Protocol version 4 - LIST Command ExtensionsIBM T.J. Watson Research CenterIsode LimitedThe Internet Message Action Protocol (IMAP4) Child Mailbox ExtensionMicrosoftMicrosoft