Internet Message Access Protocol (IMAP)

1. What is IMAP?

The Internet Message Access Protocol, known as IMAP, provides access to electronic mail and mailbox management on a remote server. POP3 often downloads messages to a client and may remove server copies. IMAP keeps mailbox state on the server, allowing multiple clients to work with the same folders.

IMAP treats the server as the source of mailbox state. A mail user agent (MUA) on a computer, phone, or tablet displays state obtained from the server. Reading a message, changing a flag, moving it, or deleting it sends a command; the result may then appear in other clients. This includes message flags, folder hierarchy, sent mail, and drafts. The current protocol revision is IMAP4rev2, defined by RFC 9051 in 2021. It replaced RFC 3501, which specifies IMAP4rev1 and remains widely encountered in deployed servers and clients. A client can maintain several sessions, but each session has its own selected-mailbox state and must process server updates.

2. Key characteristics of IMAP

IMAP provides server-side mailbox access and state management. The main characteristics of this model include:

• Server-side storage and synchronization

  The server stores messages and their state, while the MUA retrieves and updates this information. The scope of synchronization depends on permissions and server configuration. It can include:

  • Message state: Read and answered flags are stored on the server. After synchronization, reading a message on one device may be shown on the others.
  • Folder hierarchy: A user can create, delete, and rename folders, called mailboxes in IMAP, when permitted. Clients read this hierarchy from the server.
  • Sent and draft items: Sent and draft folders can be shared by clients when the server and client configuration use the same mailboxes. A draft saved on one device can then be continued on another.
  • Deletions: Deleting a message usually sets the $\\Deleted$ flag. The message remains in the mailbox until EXPUNGE or CLOSE removes it.
• Stateful connection and session management

  An IMAP session has state: after authentication, a client can remain connected and select a mailbox. After SELECT, the server reports values such as the message count, flags, and mailbox updates. The IDLE extension lets a server send unsolicited information about new messages or changes. The client ends IDLE by sending DONE and can then issue another command. The protocol tracks the selected mailbox and its state.

• Partial fetching

  A client does not need to download an entire message to display or classify it. It can request selected message parts through partial fetching. This allows headers, MIME structure, and body text to be retrieved separately, reducing transfer of attachments. BODY.PEEK can retrieve content without setting the \Seen flag. For example, a client can:

  • Retrieve only the headers of new messages ('ENVELOPE' or 'BODY[HEADER]') to quickly display the sender, subject, and date.
  • Fetch the message's structure ('BODYSTRUCTURE') to see that it contains, for instance, a plain text part and a 5 MB PDF attachment, without downloading the attachment.
  • Download only the plain text part of a multi-part message ('BODY[1]'), ignoring the HTML version or attachments.
  • This selective downloading capability improves performance by reducing transferred data on mobile devices and over slow or metered internet connections.
• Message flags

  IMAP defines a system of flags for tracking message state. The server maintains them, and clients can view or modify them. The \\Deleted flag represents deferred deletion: the message remains available until EXPUNGE or CLOSE. EXPUNGE removes marked messages from the selected mailbox, and sequence numbers can change afterward. Basic system flags include:

  • $\\Seen$: The message has been read.
  • $\\Answered$: The message has been replied to.
  • $\\Flagged$: The message has been marked for special attention (often displayed as a star or flag).
  • $\\Deleted$: The message has been marked for deletion but has not yet been permanently removed.
  • $\\Draft$: The message is a draft.
  • Earlier revisions also defined the $\\Recent$ flag; IMAP4rev2 marks it as deprecated. Servers can support custom user-defined keywords. System flags have fixed meanings, while keywords can depend on the server. A client can add keywords when the server advertises their support.
• Communication ports

  IMAP uses specific network ports:

  • Port 143: The IMAP port for a connection without TLS and for starting STARTTLS negotiation. A client security policy should block continued plain-text transmission when protection is required. STARTTLS should complete before authentication when encryption is required.
  • Port 993: The IMAP-over-TLS port known as IMAPS. The TLS handshake starts after connection, before IMAP commands. RFC 8314 prefers this variant for secure mail access. The client sends no IMAP commands before the TLS negotiation has completed, and the server presents a certificate for verification.

3. IMAP session states

An IMAP session moves through states that determine which commands are available. A connection starts non-authenticated, can become authenticated and selected, and ends with LOGOUT and a closed TCP connection.

1. Non-authenticated state

   This is the initial state after a TCP connection is established. The client is not authenticated. It can request server capabilities (CAPABILITY), start TLS (STARTTLS), or authenticate (LOGIN, AUTHENTICATE). Mailbox data is unavailable in this state.

2. Authenticated state

   After LOGIN or AUTHENTICATE, the session enters the authenticated state. The client can list mailboxes (LIST), create them (CREATE), delete them (DELETE), rename them (RENAME), and subscribe to them (SUBSCRIBE). To work with messages, it must select a mailbox with SELECT or EXAMINE.

3. Selected state

   This state follows SELECT, which provides read/write access, or EXAMINE, which provides read-only access. The client can use FETCH, STORE, COPY, and SEARCH. One mailbox is selected at a time on a connection.

4. Logout state

   The client sends LOGOUT to end the session. The server returns BYE, closes the connection, and performs the required closing work. Messages marked \Deleted are permanently removed after EXPUNGE or CLOSE.

4. IMAP commands

Every client command has a tag, such as A001 or A002. The tag lets the client match a server response to its request. A response with the same tag completes a command, while untagged responses can report mailbox updates. A client can send commands ahead of replies where the protocol state permits it. Responses contain the tag, a status (OK, NO, or BAD), and data. After a mailbox is selected, the server can report new messages or flag changes asynchronously, so the client should update its local view.

• LOGIN and AUTHENTICATE: LOGIN username password is a simple authentication method. AUTHENTICATE can use a SASL (Simple Authentication and Security Layer) mechanism.
• CAPABILITY: A001 CAPABILITY requests supported IMAP revisions and extensions. A server may advertise IMAP4rev2, IMAP4rev1, and extensions such as IDLE and MOVE. When advertised, MOVE can move messages between mailboxes in one command. A client should inspect this list before using extension commands.
• LIST: A002 LIST "" * requests a list of available mailboxes. The server returns each name, hierarchy delimiter, and attributes, such as whether it can contain subfolders.
• SELECT: A003 SELECT "INBOX" opens INBOX for read/write access. The response includes values such as the message count (EXISTS) and available flags. Servers that also support IMAP4rev1 can additionally return the older RECENT and UNSEEN data.
• FETCH: This command retrieves selected message data. The selected data can include headers, body text, and MIME structure. Examples:
  • 'A004 FETCH 1:10 (ENVELOPE)': Fetches the 'ENVELOPE' (basic headers like From, To, Subject, Date) for messages 1 through 10.
  • 'A005 FETCH 12 (BODY[TEXT])': Fetches the plain text body of message 12.
  • 'A006 UID FETCH 4821 (BODYSTRUCTURE)': Fetches the MIME structure of the message with Unique ID 4821, allowing the client to see all its parts without downloading them.
• UIDs and message sequence numbers: Message sequence numbers are counters (1, 2, 3...) for the selected mailbox. They can change during a session, for example after a message is removed. Unique Identifiers (UIDs) remain stable while UIDVALIDITY remains valid, and a server must not reuse a UID after expunging a message under the same UIDVALIDITY. A change of UIDVALIDITY invalidates stored identifiers, so a client should perform a full synchronization and pair UIDs with UIDVALIDITY when using UID commands (UID FETCH, UID STORE, UID COPY). This prevents a client from confusing messages after sequence numbers change. A UID is a protocol value, not the number displayed to a user.
• STORE: This command modifies message flags. 'A007 UID STORE 4822 +FLAGS (\Seen)' marks the message with UID 4822 as read. 'A008 UID STORE 4823 -FLAGS (\Flagged)' removes the "flagged" (starred) status.
• SEARCH: Enables server-side searching. 'A009 SEARCH FROM "support@company.com" SINCE 1-Jan-2024' asks the server to return the sequence numbers of all messages from that sender received since the start of 2024.
• EXPUNGE: Messages marked with the '\Deleted' flag are not actually removed until the client issues an 'EXPUNGE' command. This two-step process gives the user a chance to "undelete" messages before they are permanently gone. After removal, sequence numbers of remaining messages can change, so a client using UIDs must account for UIDVALIDITY.

5. IMAP security

An IMAP connection without negotiated protection can send login credentials and message content in clear text. TLS provides confidentiality and record integrity after its parameters are negotiated, while certificate validation can authenticate the server. Two main connection-protection methods are used:

• IMAPS (IMAP over SSL/TLS) on port 993

  The client connects to port 993, and TLS starts before IMAP commands are sent. Later session traffic uses TLS protection according to the cryptographic configuration.

• STARTTLS on port 143

  The client connects to port 143 and begins negotiation in plain text, then sends STARTTLS. If the server supports the extension, both sides negotiate TLS and protect later communication. A client policy should require STARTTLS to succeed when the connection must be encrypted.

IMAP stores mailbox state on the server and exposes it to multiple clients. View consistency depends on synchronization, extension support, and server and client configuration. After reconnecting, a client should account for changes made while it was disconnected.