Internet Message Access Protocol - Version 4
obsoleted by
Extracted elements (31)
CLOSE is explicitly faster than EXPUNGE-then-LOGOUT/SELECT when many messages are deleted, because CLOSE suppresses the untagged EXPUNGE responses that the client would typically ignore. This avoids substantial unnecessary traffic in bulk-delete scenarios.
Unique identifiers (UIDs) were introduced alongside message sequence numbers specifically to support offline and disconnected clients that need to resynchronize state from a previous session. Sequence numbers change as messages are expunged, making them unsuitable for cross-session correlation.
IMAP4 is designed to be upward compatible from IMAP2. Obsolete IMAP2 commands (FIND ALL.MAILBOXES, FIND MAILBOXES, SUBSCRIBE MAILBOX, UNSUBSCRIBE MAILBOX) and responses (MAILBOX, COPY, STORE) are preserved in appendices for backward compatibility with IMAP2 clients.
A client MUST be prepared to accept any server response at all times, including unilateral server data not explicitly requested. Certain server data MUST be recorded by the client because it affects interpretation of subsequent commands and responses.
A server MUST send mailbox size updates (EXISTS untagged response) automatically if a size change is observed during command processing. The client implementation MUST record mailbox size updates and MUST NOT assume any command after initial selection will return the size.
Any command not defined in this specification or a standards-track revision MUST use the 'X' prefix (e.g., XFOO). Any untagged responses issued by experimental commands MUST also be X-prefixed; servers MUST NOT send such responses unless the client first issued the associated experimental command.
For APPEND or COPY to a nonexistent destination mailbox, unless it is certain the mailbox cannot be created, the server MUST send the '[TRYCREATE]' response code as a hint to the client to CREATE the mailbox and retry the operation.
If a server has an inactivity autologout timer, that timer MUST be of at least 30 minutes' duration. Receipt of any command from the client during that interval should suffice to reset the timer.
If an APPEND is unsuccessful for any reason, the mailbox MUST be restored to its state before the attempt; no partial appending is permitted. If the destination mailbox does not exist, the server MUST return an error and MUST NOT automatically create it.
If the COPY command is unsuccessful for any reason, server implementations MUST restore the destination mailbox to its state before the COPY attempt. The flags and internal date of copied messages SHOULD be preserved.
If unique identifiers from an earlier session fail to persist to a new session, the UIDVALIDITY value MUST be greater than in the earlier session. Server implementations MUST implicitly include the UID data item in any FETCH response caused by a UID command.
Implementations MUST encode binary data (any string with NUL characters) into a textual form such as BASE64 before transmitting. Unencoded binary strings are not permitted in IMAP4 protocol exchanges.
Servers that send untagged responses while no command is in progress MUST address flow control by either verifying the data does not exceed the transport's available window size or using non-blocking writes. EXPUNGE responses MUST NOT be sent when no command is in progress.
The DELETE command MUST preserve the highest-used unique identifier of the deleted mailbox so that a new mailbox with the same name cannot reuse those identifiers, unless the new incarnation has a different UIDVALIDITY value.
The mailbox name INBOX is reserved to mean 'the primary mailbox for this user on this server'. It is an error to attempt to delete INBOX; renaming INBOX is permitted, which creates a new empty INBOX in its place.
The SEARCH command MUST return a tagged NO (not BAD) if the server does not support the specified CHARSET. MIME-encoded strings in RFC 822/MIME headers and content-transfer-encodings MUST be decoded before matching.
When creating a mailbox with the same name as a previously deleted mailbox, the new mailbox's unique identifiers MUST be greater than any used in the previous incarnation, unless the new incarnation has a different UIDVALIDITY value.
Each client command is prefixed with a unique tag (e.g., A0001). The server completion response carries the matching tag, allowing multiple commands to be in progress simultaneously. Untagged responses use '*' and command continuation requests use '+'.
Status response codes are returned in square brackets within OK/NO/BAD responses: ALERT (user-visible alert required), PERMANENTFLAGS, READ-ONLY, READ-WRITE, TRYCREATE, UIDVALIDITY, and UNSEEN. Server-specific codes SHOULD use an 'X' prefix; clients MUST ignore unrecognized codes.
The AUTHENTICATE command performs a server-challenge/client-answer exchange using BASE64-encoded data. Optionally it negotiates a protection mechanism applied to all subsequent protocol data; once active, data is framed as ciphertext buffers each preceded by a 4-octet network-byte-order length field.
The CAPABILITY command causes the server to return a single untagged CAPABILITY response with 'IMAP4' as the first listed capability before the tagged OK. Capabilities other than 'IMAP4' refer to extensions or amendments; no capability is enabled without explicit client action.
The CLOSE command silently expunges all \Deleted messages and returns to authenticated state without sending untagged EXPUNGE responses. SELECT, EXAMINE, and LOGOUT also implicitly close the selected mailbox without expunging.
The FETCH command retrieves per-message data items: BODY[section] (specific MIME part by dot-delimited path), BODYSTRUCTURE (MIME structure), ENVELOPE (parsed RFC 822 headers), FLAGS, INTERNALDATE, RFC822.SIZE, and UID. Fetching BODY[section] implicitly sets \Seen; BODY.PEEK suppresses this.
The PARTIAL command retrieves a byte range of a single message data item (RFC822, RFC822.HEADER, RFC822.TEXT, or BODY[section]) by starting octet (1-based) and count. The response does not indicate the range; multiple concurrent PARTIALs of the same item cannot be streamed without synchronization.
The SEARCH command searches for messages matching criteria including flag state, header fields (FROM, TO, CC, BCC, SUBJECT, HEADER), body text, date ranges (BEFORE/ON/SINCE for internal date; SENTBEFORE/SENTON/SENTSINCE for RFC 822 Date), and size (LARGER/SMALLER). Multiple keys are ANDed; OR and NOT are also supported.
The SELECT command opens a mailbox and transitions to selected state. Before returning OK, the server MUST send FLAGS, EXISTS, RECENT, and UIDVALIDITY untagged responses; it SHOULD also send UNSEEN and PERMANENTFLAGS. Only one mailbox may be selected per session at a time.
The UID command variant interprets message sets as unique identifiers rather than sequence numbers for FETCH, COPY, STORE, and SEARCH. UIDs are strictly ascending, persist across sessions, and are never reused within a mailbox incarnation. UIDVALIDITY is sent at selection to detect invalidation.
IMAP4 includes a LOGIN command that transmits the user password in plaintext, which is insecure on networks subject to eavesdropping. The AUTHENTICATE command provides stronger authentication and optional session-level integrity and privacy protection via a negotiated protection mechanism.
IMAP4 defines four server states: Non-Authenticated (initial, credentials required), Authenticated (post-login, mailbox not yet selected), Selected (mailbox open for message access), and Logout (session terminating, connection closing). Transitions occur via LOGIN/AUTHENTICATE, SELECT/EXAMINE, CLOSE/failed-SELECT, and LOGOUT/shutdown.
A literal string is encoded as '{<count>}CRLF' followed by exactly the specified number of octets. For client-to-server literals, the client MUST wait for a '+' command continuation response before sending the octet data (even for zero-length literals).
When a protection mechanism is negotiated via AUTHENTICATE, subsequent protocol data is transmitted as length-prefixed ciphertext buffers: a 4-octet network-byte-order field giving the length of the following ciphertext, repeated for each buffer. Maximum buffer length is defined by the mechanism.