IMAP LIST Extension for Special-Use Mailboxes
Extracted elements (20)
Multiple mailboxes may share the same special-use attribute, and servers may either permit or refuse creation of a duplicate-attribute mailbox. This flexibility accommodates different server implementations rather than mandating a single-mailbox-per-use constraint.
Special-use attributes are designed to be user-specific rather than mailbox-specific. A mailbox shared between users Adam and Barb would not automatically serve as both users' \Sent mailbox; each user independently designates which mailbox carries a given special use for them.
The 'CREATE-SPECIAL-USE' capability is kept separate from 'SPECIAL-USE' because CREATE support for special-use designation is OPTIONAL while the extended LIST return/selection support is a distinct, separately advertised feature. This allows servers to support one without the other.
The METADATA mechanism (/private/specialuse) provides an alternative path for clients to read and potentially modify special-use attributes on existing mailboxes, bridging between the static CREATE-time assignment and runtime reconfiguration, but only when the server supports both this extension and RFC 5464.
There is no capability string related to the support of special-use attributes on the non-extended LIST command. Support for the extended LIST command 'SPECIAL-USE' capability is separate from returning attributes in non-extended LIST responses.
A server supporting the METADATA tie-in MUST check the validity of changes to special-use attributes done through metadata in the same way it checks validity for the CREATE command. It MUST NOT blindly accept client-set metadata that would result in unsupported special uses or other invalid states.
Clients MUST ignore list attributes they do not understand. Server implementations MUST NOT generate extension attributes (use-attr-ext) except as defined by future Standards-Track revisions or extensions to this specification.
Clients MUST NOT use the 'USE' parameter on the CREATE command unless the server advertises the 'CREATE-SPECIAL-USE' capability. The 'CREATE-SPECIAL-USE' and 'SPECIAL-USE' capability strings are distinct; a server supporting both functions MUST advertise both.
If the client specifies the 'SPECIAL-USE' return option, the LIST command MUST return the new special-use attributes on those mailboxes that have them set.
If the client specifies the 'SPECIAL-USE' selection option, the LIST command MUST return only those mailboxes that have a special-use attribute set. The 'SPECIAL-USE' return option is implied by the 'SPECIAL-USE' selection option.
If the server cannot create a mailbox with the designated special use, it MUST NOT create the mailbox and MUST respond to the CREATE command with a tagged NO response. If the failure is related to the special-use attribute, the server SHOULD include the 'USEATTR' response code in the tagged response.
Supporting implementations of the extended LIST command MUST include the 'SPECIAL-USE' capability string in response to an IMAP CAPABILITY command.
An optional 'USE' parameter is added to the IMAP CREATE command, allowing clients to designate a mailbox at creation time as having one or more special uses. It is followed by a parenthesized list of zero or more special-use attributes. Servers advertise support via the 'CREATE-SPECIAL-USE' capability string.
If a server supports both this extension and the METADATA extension (RFC 5464), the special-use attributes for a mailbox SHOULD be tied to the metadata entry '/private/specialuse'. The value is either NIL or a space-separated list of special-use attributes as they appear in LIST responses.
Seven new optional mailbox attributes are defined for use in IMAP LIST responses: \All (all messages), \Archive (archived messages), \Drafts (draft messages), \Flagged (flagged/important messages), \Junk (spam/junk mail), \Sent (sent message copies), and \Trash (deleted messages). A given mailbox may have none, one, or more than one of these attributes.
The 'USEATTR' response code is defined for inclusion in a tagged NO response when a CREATE command fails because the specified special-use attribute is not supported or cannot be assigned to the specified mailbox.
IANA added 'USEATTR' to the IMAP Response Codes registry, 'CREATE-SPECIAL-USE' and 'SPECIAL-USE' to the IMAP 4 Capabilities registry, 'SPECIAL-USE' as both a selection option and a return option to the IMAP4 List Extended registry, and '/private/specialuse' to the IMAP METADATA Mailbox Entry registry.
Conveying special-use information to a client exposes extra information that could be of value to an attacker — for example, knowing that \All contains pointers to every message the user has. If the IMAP channel is not protected from passive eavesdropping, this disclosure could be an issue.
Some special uses may imply automatic server action (e.g., creating \Junk may cause the server to route spam there). Implementors SHOULD consider the consequences of allowing a user or client to designate the target of such automatic action, particularly the risk of false positives being deposited into a shared mailbox and exposing private mail to others.
The formal ABNF defines 'use-attr' as one of the seven named attributes (\All, \Archive, \Drafts, \Flagged, \Junk, \Sent, \Trash) or a 'use-attr-ext' (backslash followed by an atom) reserved for future extensions. 'create-param' is extended with 'USE SP '(' [use-attr *(SP use-attr)] ')'.