IMAP4rev2

IMAP is a stateful mail-access protocol. RFC 9051 defines IMAP4rev2; it supersedes IMAP4rev1 in RFC 3501. Clients manage mailboxes and message state on the server, enabling multiple clients to view the same mailbox.

Connection and Commands #

IMAP uses a text protocol over TCP. Port 143 begins in cleartext and can negotiate TLS with STARTTLS; port 993 uses TLS from connection establishment. Clients must obtain capabilities, negotiate TLS before password authentication, and require certificate and hostname validation.

The protocol state constrains legal commands:

1. In not authenticated state, the client negotiates capabilities, TLS, and authentication.
2. In authenticated state, it can manage and list mailboxes.
3. In selected state, it has selected one mailbox and can fetch or change message state.
4. LOGOUT enters logout state and closes the session after the server’s untagged BYE and tagged completion response.

Each client command begins with a client-chosen tag. Server responses are either untagged (*), continuation requests (+), or tagged completion responses:

S: * OK IMAP4rev2 ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS SASL-IR
S: A001 OK completed
C: A002 STARTTLS
S: A002 OK begin TLS negotiation now

After TLS, the client sends CAPABILITY again because capabilities may differ. Use SASL authentication mechanisms rather than LOGIN when the server and client support them.

Mailboxes and Messages #

An authenticated connection can list, create, rename, subscribe to, and select mailboxes. SELECT opens a mailbox read-write; EXAMINE opens it read-only. Messages have sequence numbers that change as the mailbox changes and stable unique identifiers (UIDs) within a UIDVALIDITY epoch. Persistent clients must use UIDs, record UIDVALIDITY, and resynchronize when it changes.

Mailbox names are protocol strings rather than operating-system paths. Use LIST to discover hierarchy delimiters and names, preserve server-provided UTF-8 names, and quote or send them as literals when required. INBOX is case-insensitive; other names can be case-sensitive according to server rules.

System flags include \Seen, \Answered, \Flagged, \Deleted, and \Draft. A client marks a message deleted with STORE; EXPUNGE removes messages marked \Deleted. Avoid sequence numbers in workflows that can receive concurrent mailbox updates.

FETCH retrieves message attributes or body sections. SEARCH returns matching messages. IMAP literals carry data that cannot appear safely in quoted strings; the server can request a continuation before the client sends a synchronizing literal. A literal marker such as {4096}\r\n declares the exact following octet count. Parsers must consume that length rather than scan literal contents for line breaks.

Idle and Synchronization #

IDLE lets a client receive unsolicited mailbox changes while it remains connected. The client must terminate IDLE with DONE before sending another command. UID-based synchronization, UID FETCH, and server capability inspection avoid treating a mailbox snapshot as permanently stable.

While a mailbox is selected, untagged EXISTS, EXPUNGE, FETCH, and related responses report changes. An expunge renumbers later sequence numbers, so a client must update its sequence map immediately and continue identifying durable state by UID. Store the last known UID, flags, UIDVALIDITY, and relevant modification state; extensions such as CONDSTORE and QRESYNC can reduce transfer when both peers advertise them, but the fallback must perform a correct UID-based rescan.

IMAP transports message bytes and metadata; MIME defines email body structure and transfer encodings. Do not confuse IMAP’s line-oriented command encoding with a seven-bit packing scheme: IMAP command lines use ASCII syntax, while literals transport octets.

References #

• RFC 9051: IMAP4rev2
• RFC 8314: Cleartext Email Access