Internet Message Access Protocol

IMAP was designed with the goal of permitting complete management of an email box by multiple email clients; therefore, clients generally leave messages on the server until the user explicitly deletes them. An IMAP server typically listens on port number 143. IMAP over SSL/TLS (IMAPS) is assigned the port number 993.

Virtually all modern e-mail clients and servers support IMAP, which along with the earlier POP3 (Post Office Protocol) are the two most prevalent standard protocols for email retrieval. Many webmail service providers such as Gmail and Outlook.com also support both IMAP and POP3.

An IMAP Working Group formed in the IETF in the early 1990s took over responsibility for the IMAP2bis design. The IMAP WG decided to rename IMAP2bis to IMAP4 to avoid confusion.

When using POP, clients typically connect to the e-mail server briefly, only as long as it takes to download new messages. When using IMAP4, clients often stay connected as long as the user interface is active and download message content on demand. For users with many or large messages, this IMAP4 usage pattern can result in faster response times.

After successful authentication, the POP protocol provides a completely static view of the current state of the mailbox, and does not provide a mechanism to show any external changes in state during the session (the POP client must reconnect and re-authenticate to get an updated view). In contrast, the IMAP protocol provides a dynamic view, and requires that external changes in state, including newly arrived messages, as well as changes made to the mailbox by other concurrently connected clients, are detected and appropriate responses are sent between commands as well as during an IDLE command, as described in RFC 4314) may be used to regulate access rights.

IMAP4 provides a mechanism for a client to ask the server to search for messages meeting a variety of criteria. This mechanism avoids requiring clients to download every message in the mailbox in order to perform these searches.

Reflecting the experience of earlier Internet protocols, IMAP4 defines an explicit mechanism by which it may be extended. Many IMAP4 extensions to the base protocol have been proposed and are in common use. IMAP2bis did not have an extension mechanism, and POP now has one defined by RFC 4469) in IMAP, and BURL (") BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) S: a003 OK FETCH completed C: a004 fetch 12 body[header] S: * 12 FETCH (BODY[HEADER] {342} S: Subject:IMAP4rev1WGmtgsummaryandminutes S: Message-Id:<B27397-0100000@cac.washington.edu> S: