IMAP Technical Reference (RFC 9051)

What This Reference Covers

RFC 9051 defines IMAP4rev2 — the Internet Message Access Protocol, version 4 revision 2. IMAP is the protocol email clients use to access mailboxes on a remote server. Unlike POP3, which downloads and optionally deletes messages, IMAP keeps messages on the server and lets clients manage them in place: read, search, flag, move, and delete without transferring entire messages.

RFC 9051 was published in August 2021 and obsoletes RFC 3501 (IMAP4rev1). It incorporates many extensions that were previously separate RFCs into the base protocol, including NAMESPACE, MOVE, CONDSTORE, ENABLE, and LITERAL-. Most IMAP servers in production still advertise IMAP4rev1 — full IMAP4rev2 adoption is ongoing.

This page covers the connection model, capability mechanism, authentication, mailbox operations, key extensions, and TLS requirements. Use the mxio IMAP Server Test to check your server's capabilities and TLS configuration.

Connection Model (§2)

An IMAP session has four states, and the client moves through them in sequence:

Not Authenticated ──LOGIN/AUTH──▶ Authenticated ──SELECT──▶ Selected
                                                  │
                                                  └─EXAMINE──▶ Selected (read-only)

Not Authenticated

The connection is established but no credentials have been presented. The server sends a greeting and the client can issue CAPABILITY, STARTTLS, or AUTHENTICATE/LOGIN commands. Most servers restrict available commands to these until authentication succeeds.

Authenticated

The client has proven its identity. It can now list mailboxes, subscribe/unsubscribe, create/delete/rename mailboxes, and check status. It cannot yet read messages — a mailbox must be selected first.

Selected

The client has opened a specific mailbox with SELECT (read-write) or EXAMINE (read-only). It can now fetch messages, search, flag, copy, move, and expunge. The server sends unsolicited updates about new messages and flag changes in the selected mailbox.

Logout

The client sends LOGOUT. The server responds with BYE and closes the connection.

CAPABILITY Mechanism (§6.1.1)

The CAPABILITY command returns the list of extensions and features the server supports. This is the foundation for feature negotiation — clients inspect capabilities to determine which commands and behaviors are available.

"The CAPABILITY command requests a listing of capabilities that the server supports." — RFC 9051 §6.1.1

Servers may advertise different capabilities before and after TLS negotiation. A common pattern: the server omits AUTH=PLAIN from the pre-TLS capability list (to prevent credentials being sent in cleartext) and adds it after STARTTLS completes. The IMAP Server Test captures capabilities at each phase and reports the final set.

Required Capabilities

RFC 9051 requires IMAP4rev2 servers to support these capabilities as part of the base protocol:

Servers advertising only IMAP4rev1 (the previous version) may not support all of these.

Authentication (§6.2)

IMAP supports two authentication paths:

LOGIN Command

The LOGIN command sends a username and password in cleartext. It must only be used over an encrypted connection (TLS). Servers that advertise LOGINDISABLED prohibit LOGIN and require AUTHENTICATE instead.

"The LOGIN command MUST NOT be used (and a server MUST reject it) when LOGINDISABLED capability is advertised." — RFC 9051 §6.2.3

AUTHENTICATE Command

The AUTHENTICATE command uses SASL (Simple Authentication and Security Layer) to negotiate an authentication mechanism. Common mechanisms:

The SASL-IR capability (SASL Initial Response, RFC 4959) allows the client to send authentication data in the same command as AUTHENTICATE, saving a round-trip. The IMAP Server Test reports whether SASL-IR is advertised.

Mailbox Operations (§6.3, §6.4)

Listing Mailboxes

The LIST command returns the mailbox hierarchy. RFC 9051 enhanced LIST to replace several older commands (LSUB, and the LIST-EXTENDED extension from RFC 5258):

* LIST (\HasChildren) "." "INBOX"
* LIST (\HasNoChildren) "." "INBOX.Sent"
* LIST (\HasNoChildren \Drafts) "." "INBOX.Drafts"
* LIST (\HasNoChildren \Jstrash) "." "INBOX.Trash"

Special-use mailbox flags (\Drafts, \Sent, \Trash, \Junk, \Archive) defined in RFC 6154 tell email clients which folders serve which roles, so they do not need to guess by name.

Selecting a Mailbox

SELECT opens a mailbox for read-write access. The server responds with the mailbox state:

• EXISTS — Total number of messages
• RECENT — Number of messages flagged as recently arrived (removed in IMAP4rev2 — replaced by UNSEEN)
• FLAGS — Flags defined in this mailbox (e.g., \Seen, \Flagged, \Deleted, \Draft)
• PERMANENTFLAGS — Flags the client can change permanently
• UIDVALIDITY — A value that, combined with message UIDs, uniquely identifies messages across sessions
• UIDNEXT — The predicted next UID value

Fetching Messages

The FETCH command retrieves message data. Clients can request specific parts to minimize bandwidth:

This selective fetching is a fundamental IMAP advantage over POP3 — clients can display a message list with subjects and sizes without downloading full messages.

Key Extensions

IDLE (RFC 2177)

IDLE provides push notifications. The client sends IDLE, and the server holds the connection open, sending unsolicited updates when new messages arrive or flags change. Without IDLE, clients must poll at intervals (e.g., every 5 minutes), which introduces latency and wastes bandwidth.

"The IDLE command is sent from the client to the server when the client is ready to accept unsolicited mailbox update messages." — RFC 2177 §3

IDLE is one of the most important capabilities for user experience. The IMAP Server Test reports whether the server advertises it.

CONDSTORE and QRESYNC (RFC 7162)

CONDSTORE assigns a modification sequence number to every message state change. QRESYNC builds on this to allow clients to quickly resynchronize a mailbox after disconnection — the client provides its last known state, and the server returns only what changed.

Together, these extensions make IMAP practical for mobile clients that connect and disconnect frequently. Without them, each reconnection requires re-downloading the full message list and flag state.

MOVE (RFC 6851)

The MOVE command atomically moves messages between mailboxes. Before MOVE, clients had to COPY the message, set \Deleted on the original, and EXPUNGE — a three-step process that could leave duplicates if the connection dropped mid-operation.

MOVE is included in the IMAP4rev2 base protocol.

COMPRESS (RFC 4978)

COMPRESS=DEFLATE enables zlib compression on the connection after negotiation. This reduces bandwidth usage, which matters for clients on slow or metered connections. Compression is negotiated once and applies to all subsequent data in both directions.

TLS Requirements (§2.1)

RFC 9051 strengthens TLS requirements compared to RFC 3501:

"IMAP client and server implementations MUST implement TLS 1.2 or newer." — RFC 9051 §2.1

Two connection models are supported:

1. Implicit TLS (port 993) — TLS handshake completes before any IMAP data is exchanged. This is the recommended model per RFC 8314.

2. STARTTLS (port 143) — Connection starts in plaintext. The client issues STARTTLS, the server responds OK, and TLS is negotiated. The IMAP session continues over the encrypted connection.

RFC 8314 §3.2 recommends implicit TLS over STARTTLS for IMAP, because it eliminates the plaintext phase where STARTTLS commands could be stripped by a network attacker.

IMAP vs. POP3

POP3 (RFC 1939) is simpler but fundamentally a download protocol. IMAP is the standard for modern multi-device email access.

Quick Reference

---

This reference covers RFC 9051 — Internet Message Access Protocol (IMAP) — Version 4rev2, authored by A. Melnikov and B. Leiba. Supplementary RFCs referenced: RFC 3501 (IMAP4rev1, obsoleted), RFC 8314 (implicit TLS for mail protocols), RFC 2177 (IDLE), RFC 7162 (CONDSTORE/QRESYNC), RFC 6851 (MOVE), RFC 4978 (COMPRESS), RFC 4959 (SASL-IR), RFC 6154 (special-use mailboxes), RFC 1939 (POP3). Content on this page is an editorial interpretation; see the original RFCs for normative text. RFC content is subject to the IETF Trust's Legal Provisions.