Internet Message Access Protocol (IMAP) - Version 4rev2
obsoletes
- rfc-3501 — INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
Extracted elements (26)
IMAP4rev2 requires Net-Unicode for mailbox names instead of IMAP4rev1's modified UTF-7 encoding. The change aligns mailbox naming with modern Unicode standards and removes the complexity of modified UTF-7, at the cost of backward incompatibility addressed by Appendix A.
The \Recent flag is deprecated in IMAP4rev2 because it could not be reliably implemented in concurrent multi-session environments: only the first session to SELECT a mailbox after new message arrival would see \Recent set, leading to unpredictable client behavior. IMAP4rev2 servers may still emit the untagged RECENT response for IMAP4rev1 compatibility; pure IMAP4rev2 clients should ignore it.
IMAP4rev2 is upward-compatible with IMAP4rev1 (RFC 3501), but mailbox names using modified UTF-7 (the IMAP4rev1 international naming convention) are not valid Net-Unicode. Appendix A describes the modified UTF-7 convention for servers that must interoperate with IMAP4rev1 clients.
IMAP4rev2 supports 63-bit body part and message sizes. Servers that support large message sizes must use the extended BODYSTRUCTURE syntax described in Appendix D; clients that do not support 63-bit sizes may misinterpret very large size values.
A server MUST implement a configuration in which plaintext password mechanisms are not permitted unless STARTTLS has been negotiated, TLS is in use on an Implicit TLS port, or equivalent protection is in place. A client MUST NOT send a LOGIN command if the LOGINDISABLED capability is advertised.
A server MUST send mailbox size updates (EXISTS response) automatically if a mailbox size change is observed during command processing. Only the EXPUNGE response can reduce the reported message count; an EXISTS response MUST NOT be used to reduce it.
A UID is an unsigned non-zero 32-bit value; combined with UIDVALIDITY it forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name, ever. UIDs MUST be assigned in strictly ascending order and MUST NOT change during the session.
Client and server implementations MUST implement the STARTTLS and LOGINDISABLED capabilities on cleartext ports, and MUST implement the AUTH=PLAIN capability on both cleartext and Implicit TLS ports. These are mandatory baseline security requirements.
If a server has an inactivity autologout timer for post-authentication sessions, its duration MUST be at least 30 minutes. Receipt of any command from the client resets the timer. No minimum is specified for pre-authentication timers.
If unique identifiers from a prior session fail to persist, UIDVALIDITY MUST be greater than the value used in the earlier session. UIDNEXT MUST NOT change unless new messages are added and MUST change whenever new messages are added, even if those messages are subsequently expunged.
Mailbox names MUST be encoded in Net-Unicode. Servers MUST prohibit creation of 8-bit mailbox names that do not comply with Net-Unicode. Clients MUST interpret any 8-bit mailbox names returned by LIST as Net-Unicode. This requirement differs from IMAP4rev1, which used modified UTF-7.
Non-synchronizing literals MUST NOT be larger than 4096 octets; any literal larger than 4096 bytes MUST be sent as a synchronizing literal. This restriction applies only to client-to-server transmission.
The SELECT command MUST cause the server to return untagged FLAGS, EXISTS, and LIST responses plus OK responses with PERMANENTFLAGS, UIDNEXT, and UIDVALIDITY response codes before the tagged OK. When deselecting an existing mailbox via a new SELECT, the server MUST return an untagged OK [CLOSED] response code.
The server MUST respond with a tagged BAD when STARTTLS is received on an Implicit TLS port. Once a client issues STARTTLS, it MUST NOT issue further commands until the server responds and TLS negotiation completes. After successful STARTTLS the client MUST discard cached capability information and SHOULD re-issue CAPABILITY.
Upon a client-initiated LOGOUT, the server MUST send an untagged BYE response before the tagged OK, and the client MUST read the tagged OK before closing the connection. A server SHOULD NOT unilaterally close the connection without first sending an untagged BYE with the reason.
When pipelining, if the client sends any command other than FETCH, STORE, or SEARCH, it MUST wait for the completion result response before sending a command that uses message sequence numbers, to avoid sequence-number invalidation from unsolicited EXPUNGE responses.
IMAP4rev2 operates over TCP on port 143 (cleartext) or port 993 (Implicit TLS). All protocol data is line-oriented (CRLF-terminated). Client commands are prefixed with a unique tag; server untagged responses are prefixed with '*'; command continuation requests are prefixed with '+'.
System flags are predefined tokens beginning with '\': \Seen, \Answered, \Flagged, \Deleted, \Draft. The \Recent flag is deprecated in IMAP4rev2. Specification-defined keywords include $Forwarded, $MDNSent, $Junk, $NotJunk, and $Phishing; $Junk and $NotJunk are mutually exclusive and clients MUST treat both being set as if neither is set.
The ENABLE command lets clients explicitly activate IMAP extensions. It is additive (multiple ENABLE commands accumulate), and extensions remain active for the entire connection once enabled. The server MUST send an untagged ENABLED response after each ENABLE command. ENABLE is only valid in the authenticated state before any mailbox is selected.
Section 12.1 registers the 'IMAP4rev2' capability token in the IANA IMAP Capabilities Registry, replacing the 'IMAP4rev1' token for servers implementing this revision. All previously registered IMAP4rev1 extensions are also valid IMAP4rev2 extensions unless otherwise noted.
Section 12.3 registers LIST Selection Options (SUBSCRIBED, REMOTE, RECURSIVEMATCH), LIST Return Options (SUBSCRIBED, CHILDREN, STATUS), and LIST Extended Data Items (OLDNAME, CHILDINFO) in the IANA LIST Extended registry, formalizing the incorporated LIST-EXTENDED extension.
Section 12.4 updates the IANA IMAP Mailbox Name Attributes registry (adding \NonExistent, special-use attributes, etc.) and the IMAP Response Codes registry (adding CLOSED, NOTSAVED, UNKNOWN-CTE, and others) to reflect capabilities now part of the IMAP4rev2 base protocol.
Server implementations MUST implement SASL AUTHENTICATE and MUST be configurable to reject plaintext passwords without TLS. Clients and servers SHOULD implement non-plaintext SASL mechanisms such as GSSAPI, SCRAM-SHA-256/SCRAM-SHA-256-PLUS, and EXTERNAL to avoid password exposure on the wire.
To prevent the STARTTLS plaintext command injection vulnerability (CERT-555316), servers MUST handle data received in the same TCP buffer after the STARTTLS CRLF by either treating it as the start of the TLS handshake or discarding it. Past server implementations that failed to do this allowed injection of post-STARTTLS commands in cleartext.
IMAP4rev2 defines four connection states: Not Authenticated (initial, requires credentials), Authenticated (mailbox must be selected), Selected (a mailbox is open for message access), and Logout (connection terminating). Transitions are driven by successful commands (AUTHENTICATE/LOGIN → Authenticated; SELECT/EXAMINE → Selected; CLOSE/UNSELECT → Authenticated; LOGOUT or connection close → Logout) or server greeting type (OK, PREAUTH, or BYE).
Strings are encoded as synchronizing literals ({count}CRLF + octets, requiring a '+' server continuation before client sends data), non-synchronizing literals ({count+}CRLF, no round-trip, max 4096 octets client-to-server only), or quoted strings (double-quoted UTF-8, no CR or LF). The non-synchronizing form MUST NOT be sent server-to-client.