Internet Message Access Protocol - Version 4rev1
obsoleted by
- rfc-3501 — INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
obsoletes
- rfc-1730 — Internet Message Access Protocol - Version 4
Extracted elements (26)
CLOSE is significantly faster than EXPUNGE followed by LOGOUT or SELECT when many messages are deleted, because CLOSE silently removes \Deleted messages without sending untagged EXPUNGE responses (which the client would typically ignore anyway). This avoids unnecessary round-trip overhead.
Mailbox international naming uses a modified UTF-7 encoding rather than standard UTF-7 to avoid five specific conflicts: UTF-7's '+' shift conflicts with USENET names, '/' in BASE64 conflicts with hierarchy delimiters, and UTF-7's prohibition of unencoded '\', '~', and multiple alternate forms are all problematic. Modified UTF-7 uses '&' for shifting and ',' instead of '/'.
IMAP4rev1 is designed to be upward compatible from IMAP2 and the unpublished IMAP2bis protocols. Obsolete commands, responses, and data formats that an IMAP4rev1 implementation may encounter when used with earlier implementations are described separately in [IMAP-OBSOLETE].
A server MUST send mailbox size updates automatically if a mailbox size change is observed during command processing. A client implementation MUST record mailbox size updates and MUST NOT assume any command after initial mailbox selection will return the mailbox size.
Before returning OK to SELECT, the server MUST send untagged FLAGS, EXISTS, RECENT, and UIDVALIDITY responses to define the initial mailbox state. If the client cannot change permanent flags, the server SHOULD send PERMANENTFLAGS. If the mailbox is read-only, the server MUST prefix the tagged OK with '[READ-ONLY]'.
Clients MUST NOT send multiple commands without waiting if an ambiguity would result. Specifically, if the client sends any command other than FETCH, STORE, or SEARCH, it MUST wait for a response before sending a command with message sequence numbers, because EXPUNGE responses are prohibited only during FETCH/STORE/SEARCH.
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 SHOULD suffice to reset the timer.
If an APPEND fails for any reason, the mailbox MUST be restored to its state before the APPEND attempt; no partial appending is permitted. If the destination mailbox does not exist, the server MUST NOT automatically create it and MUST send '[TRYCREATE]' unless creation is certainly impossible.
If unique identifiers from an earlier session fail to persist to a new session, the UIDVALIDITY value MUST be greater than the one used in the earlier session. UIDs MUST be strictly ascending in the mailbox at all times.
The CAPABILITY response MUST include 'IMAP4rev1' as one of the listed capabilities. Capability names beginning with 'AUTH=' indicate a supported authentication mechanism.
The DELETE command MUST NOT remove inferior hierarchical names. If the mailbox has inferiors and no \Noselect attribute, deleting it removes its messages and assigns \Noselect to the name. The highest-used UID of a deleted mailbox MUST be preserved so new mailboxes with the same name don't reuse identifiers.
The UID of a message MUST NOT change during the session, and SHOULD NOT change between sessions. If UIDs cannot be preserved across sessions, each subsequent session MUST have a new UIDVALIDITY larger than any previously used.
Unencoded binary strings (any string containing NUL characters) are not permitted. Implementations MUST encode binary data into a textual form such as BASE64 before transmitting.
Each message has a 32-bit Unique Identifier (UID) that is strictly ascending within the mailbox and persists across sessions. UIDs, combined with the UIDVALIDITY value, form a 64-bit identifier guaranteed never to refer to any other message in the mailbox.
Message sequence numbers are relative positions (1 to mailbox size), ordered by ascending UID. They are reassigned during the session when messages are expunged; all subsequent message sequence numbers are decremented after an expunge.
Server responses are either tagged (completion responses matching the client command tag), untagged (prefixed with '*', sent unilaterally or as data), or command continuation requests (prefixed with '+'). There are three tagged completion responses: OK (success), NO (failure), BAD (protocol error).
Six system flags are pre-defined, all prefixed with '\': \Seen, \Answered, \Flagged, \Deleted, \Draft, and \Recent. \Recent is a session-only flag the client cannot alter; \Deleted marks messages for removal by EXPUNGE.
The AUTHENTICATE command performs a BASE64-encoded challenge-response exchange for the specified authentication mechanism. If a protection mechanism is negotiated, subsequent data is framed with a 4-octet network-byte-order length field followed by ciphertext.
The FETCH command retrieves message data using named data items: BODY[<section>] fetches specific MIME body parts or header fields; BODY.PEEK[] is the non-flag-altering variant; ENVELOPE returns parsed RFC-822 header fields; BODYSTRUCTURE returns MIME structure; RFC822.SIZE returns message size in octets.
The SEARCH command searches for messages matching one or more keys; multiple keys are ANDed. Defined keys include flag tests (ANSWERED, DELETED, SEEN, etc.), header field substring matches (FROM, TO, SUBJECT, HEADER), size comparisons (LARGER, SMALLER), date comparisons (BEFORE, SINCE, SENTBEFORE, SENTSINCE), and logical operators (NOT, OR).
The UID command takes COPY, FETCH, SEARCH, or STORE as an argument and performs the equivalent operation using UIDs instead of message sequence numbers. UID SEARCH and UID FETCH always return a UID data item regardless of the data items requested.
The AUTHENTICATE command MAY negotiate a protection mechanism that provides integrity and privacy for all subsequent protocol interactions, taking effect immediately after the authentication exchange concludes. Authentication mechanisms and protection mechanisms are each independently optional.
The LOGIN command transmits the user's password in plaintext. Servers should consider requiring the use of a privacy protection mechanism (from AUTHENTICATE) before permitting the LOGIN command, especially on networks where eavesdropping is possible.
IMAP4rev1 defines four server states: Non-Authenticated (initial, credentials required), Authenticated (mailbox selection required), Selected (mailbox open), and Logout (connection closing). Transitions are driven by successful LOGIN/AUTHENTICATE (→Authenticated), SELECT/EXAMINE (→Selected), CLOSE or failed SELECT (→Authenticated), and LOGOUT/disconnection (→Logout).
A literal string is encoded as an open brace, octet count, close brace, CRLF, followed immediately by the octet data (for server-to-client). For client-to-server literals, the client MUST wait for a '+' command continuation request before sending the octet data.
When an AUTHENTICATE protection mechanism is active, the stream of command and response octets is processed into ciphertext buffers, each transferred as a 4-octet network-byte-order length field followed by the ciphertext data.