Internet Message Access Protocol

Incoming email messages are sent to an email server that stores messages in the recipient's email box. The user retrieves the messages with an email client that uses one of a number of email retrieval protocols. While some clients and servers preferentially use vendor-specific, proprietary protocols, almost all support POP and IMAP for retrieving email – allowing free choice between many e-mail clients such as Pegasus Mail or Mozilla Thunderbird to access these servers, and allows the clients to be used with other servers.

Email clients using IMAP generally leave messages on the server until the user explicitly deletes them. This and other characteristics of IMAP operation allow multiple clients to manage the same mailbox. Most email clients support IMAP in addition to Post Office Protocol (POP) to retrieve messages. IMAP offers access to the mail storage. Clients may store local copies of the messages, but these are considered to be a temporary cache.

IMAP was designed by Mark Crispin in 1986 as a remote access mailbox protocol, in contrast to the widely used POP, a protocol for simply retrieving the contents of a mailbox.

It went through a number of iterations before the current VERSION 4rev2 (IMAP4), as detailed below:

The original Interim Mail Access Protocol was implemented as a Xerox Lisp Machine client and a TOPS-20 server.

No copies of the original interim protocol specification or its software exist. Although some of its commands and responses were similar to IMAP2, the interim protocol lacked command/response tagging and thus its syntax was incompatible with all other versions of IMAP.

The interim protocol was quickly replaced by the Interactive Mail Access Protocol (IMAP2), defined in RFC 1203 in 1991. It was written specifically as a counter proposal to RFC 1064 (IMAP2). The IMAP2bis.TXT draft documented the state of extensions to IMAP2 as of December 1992. Early versions of Pine were widely distributed with IMAP2bis support (Pine 4.00 and later supports IMAP4rev1).

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: