Collected Extensions to IMAP4 ABNF
updated by
updates
Extracted elements (25)
Extensibility for the APPEND command was structured slightly differently from other commands (SELECT, FETCH, STORE, etc.) in order to preserve backward compatibility with the existing BINARY and MULTIAPPEND extensions that had already defined append syntax independently.
RFC 4466 collects ABNF extensions to IMAP4 commands from IMAPEXT, LEMONADE, and individual documents into one place to minimize cross-references and to define reusable building blocks for future extensions that can be combined compatibly.
SELECT/EXAMINE optional parameters may operate in two modes: a global state change affecting the whole session, or a per-mailbox state change lasting only for the selected state duration. A subsequent SELECT/EXAMINE without the parameter cancels its per-mailbox effect.
The APPEND command allows only a single append-message unless the MULTIAPPEND capability is present; servers not advertising MULTIAPPEND must reject multi-message APPENDs. The non-synchronizing '+' in literal8 is only valid when both BINARY and LITERAL+ are supported.
Any parameter or modifier not defined by extensions that the server supports MUST be rejected with a BAD response. This applies to SELECT, EXAMINE, CREATE, RENAME, FETCH, STORE, and SEARCH extensions.
For a given extended SEARCH command, the SEARCH and ESEARCH untagged responses SHOULD be mutually exclusive — only one of them should be returned.
Implementations MUST accept IMAP command token strings in a case-insensitive fashion, as the use of uppercase or lowercase in defining token strings is for editorial clarity only.
The CHARSET argument to SEARCH MUST be registered with IANA, as specified in the search-program ABNF production.
Unless specified otherwise by an extension, any return item name SHOULD appear only once in an ESEARCH response.
Optional parameters to SELECT and EXAMINE commands are added as a parenthesized list of attribute/value pairs appearing after the mailbox name. Parameter values, if present, always appear in parentheses (except mandatory number or sequence-set values).
The APPEND command is extended to support multiple messages (MULTIAPPEND) and binary data with NULs (BINARY). The new syntax is: 'APPEND mailbox 1*append-message' where each append-message consists of append-opts (flags, date-time, extensions) followed by append-data.
The ESEARCH untagged response returns structured search results as name/value pairs. It begins with an optional search correlator (TAG) identifying the causing command, an optional UID indicator, and then one or more search-return-data pairs in any order.
The extended CREATE command accepts an optional parenthesized list of attribute/value CREATE parameters after the mailbox name, enabling future extensions to turn on or off behaviors during mailbox creation. No CREATE parameters are defined in this document.
The extended RENAME command accepts an optional parenthesized list of attribute/value RENAME parameters after the new mailbox name, enabling future extensions. No RENAME parameters are defined in this document.
The FETCH and UID FETCH commands are extended to include optional fetch modifiers, expressed as a parenthesized list of attribute/value pairs appearing after the data item specification. No fetch modifiers are defined in this document.
The Namespace-Response ABNF is updated to conform to RFC 4234 ABNF syntax and to reference RFC 3501 non-terminals. The three namespace slots are Personal, Other Users', and Shared. Namespace-Response-Extension allows attribute/value extension pairs.
The SEARCH command is extended with an optional RETURN clause containing result options: 'SEARCH [RETURN (options)] [CHARSET charset] search-keys'. Individual options may contain parenthesized parameters. No result options are defined in this document.
The STORE and UID STORE commands are extended to include optional store modifiers as a parenthesized list of attribute/value pairs inserted between the sequence-set and the store-att-flags. No store modifiers are defined in this document.
As IMAP parsers grow more complex due to extensions, the risk of parser bugs including buffer overflow, denial of service, and other security coding errors increases. Implementers are encouraged to take care when extending existing implementations, and future extensions should strive for consistency and simplicity.
Extensions to IMAP commands permitted in NOT AUTHENTICATED state are particularly sensitive because the attacker community is larger before authentication and some servers run with elevated privileges in that state. This document does not extend any NOT AUTHENTICATED commands; future extensions to such commands should favor simplicity over extensibility.
The ESEARCH response wire format is: '* ESEARCH' [SP '(' 'TAG' SP tag-string ')'] [SP 'UID'] *(SP search-modifier-name SP search-return-value) CRLF, as illustrated by 'S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28'.
The literal8 encoding is '~{' number ['+'] '}' CRLF *OCTET, where number is the octet count and the '+' non-synchronizing marker is only allowed when both LITERAL+ and BINARY extensions are supported by the server.
The status-att-val production is redefined per RFC 3501 errata to enumerate five attribute/value pairs: MESSAGES (number), RECENT (number), UIDNEXT (nz-number), UIDVALIDITY (nz-number), UNSEEN (number). Extensions should extend this production using tagged-ext syntax.
The tagged-ext-label (used for extension/parameter names) is defined as: tagged-label-fchar *tagged-label-char, where fchar = ALPHA / '-' / '_' / '.' and label-char adds DIGIT and ':', making it a valid RFC 3501 atom.
The tagged-ext-val (used for extension parameter values) is either a tagged-ext-simple (sequence-set or number) or a parenthesized tagged-ext-comp. This is the recommended overarching syntax for all IMAP extension values.