The IMAP ENABLE Extension
Extracted elements (16)
Extension designers are discouraged from creating extensions that require ENABLE unless there is no good alternative. Extensions that cause potentially incompatible behavior changes to deployed server responses have a higher complexity cost than those that do not.
The ENABLE extension was created because some extensions require the server to know whether a client supports them before sending unsolicited responses. Prior to ENABLE, extensions used indirect signals (like CONDSTORE using SELECT/FETCH parameters) to infer client support; ENABLE provides an explicit mechanism.
The ENABLE command can be pipelined without restriction; for example, ENABLE can be immediately followed by SELECT, or LOGIN can be immediately followed by ENABLE.
Clients SHOULD only include extensions in the ENABLE command that need to be enabled by the server. At publication time, CONDSTORE is the only such extension.
If the argument is a supported extension that needs to be enabled, the server MUST enable the extension for the duration of the connection. Once enabled, there is no way to disable it.
If the argument is an extension known to the server but not specifically permitted to be enabled using ENABLE, the server MUST ignore the argument.
If the argument to ENABLE is not an extension known to the server, the server MUST ignore the argument.
If the ENABLE command is successful, the server MUST send an untagged ENABLED response.
The ENABLE command is only valid in the authenticated state before any mailbox is selected. Clients MUST NOT issue ENABLE once they SELECT/EXAMINE a mailbox.
The server MUST NOT change the CAPABILITY list as a result of executing ENABLE; a CAPABILITY command issued after ENABLE MUST list the same capabilities as before.
When multiple ENABLE commands are issued in a session, each corresponding ENABLED response SHOULD only contain extensions enabled by the corresponding ENABLE command. ENABLE is additive across commands.
The ENABLE command allows an IMAP client to explicitly indicate which extensions it supports, causing the server to activate those extensions for the duration of the connection. It takes a list of capability names as arguments.
The ENABLED response is an untagged server response to the ENABLE command, containing a space-separated listing of capability names that the server supports and successfully enabled. It may contain no capabilities if none were successfully enabled.
IANA has added 'ENABLE' to the IMAP4 Capabilities Registry as a result of this document.
This extension is believed not to add any security considerations beyond those already present in the base IMAP protocol (RFC 3501).
The ENABLE command syntax is: 'ENABLE' followed by one or more SP-separated capability names. The ENABLED response syntax is: 'ENABLED' followed by zero or more SP-separated capability names. Both are extensions to the command-any and response-data non-terminals from RFC 3501.