Email protocols
The Internet Message Access Protocol is anHistory
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 4rev1 (IMAP4), as detailed below:Original IMAP
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.IMAP2
The interim protocol was quickly replaced by the ''Interactive Mail Access Protocol'' (IMAP2), defined in (in 1988) and later updated by (in 1990). IMAP2 introduced the command/response tagging and was the first publicly distributed version.IMAP3
IMAP3 is an extremely rare variant of IMAP. It was published as in 1991. It was written specifically as a counter proposal to , which itself proposed modifications to IMAP2. IMAP3 was never accepted by the marketplace. The IESG reclassified RFC1203 "Interactive Mail Access Protocol - Version 3" as a Historic protocol in 1993. The IMAP Working Group used RFC 1176 (IMAP2) rather than RFC 1203 (IMAP3) as its starting point.IMAP2bis
With the advent of MIME, IMAP2 was extended to support MIME body structures and add mailbox management functionality (create, delete, rename, message upload) that was absent from IMAP2. This experimental revision was called IMAP2bis; its specification was never published in non-draft form. An internet draft of IMAP2bis was published by the IETF IMAP Working Group in October 1993. This draft was based upon the following earlier specifications: unpublished ''IMAP2bis.TXT'' document, , and (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).IMAP4
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.Advantages over POP
Connected and disconnected modes
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.Multiple simultaneous clients
The POP protocol requires the currently connected client to be the only client connected to the mailbox. In contrast, the IMAP protocol specifically allows simultaneous access by multiple clients and provides mechanisms for clients to detect changes made to the mailbox by other, concurrently connected, clients. See for example section 5.2 which specifically cites "simultaneous access to the same mailbox by multiple agents" as an example.Access to MIME message parts and partial fetch
Usually all Internet e-mail is transmitted in MIME format, allowing messages to have a tree structure where the leaf nodes are any of a variety of single part content types and the non-leaf nodes are any of a variety of multipart types. The IMAP4 protocol allows clients to retrieve any of the individual MIME parts separately and also to retrieve portions of either individual parts or the entire message. These mechanisms allow clients to retrieve the text portion of a message without retrieving attached files or toMessage state information
Through the use of flags defined in the IMAP4 protocol, clients can keep track of message state: for example, whether or not the message has been read, replied to, or deleted. These flags are stored on the server, so different clients accessing the same mailbox at different times can detect state changes made by other clients. POP provides no mechanism for clients to store such state information on the server so if a single user accesses a mailbox with two different POP clients (at different times), state information—such as whether a message has been accessed—cannot be synchronized between the clients. The IMAP4 protocol supports both predefined system flags and client-defined keywords. System flags indicate state information such as whether a message has been read. Keywords, which are not supported by all IMAP servers, allow messages to be given one or more tags whose meaning is up to the client. IMAP keywords should not be confused with proprietary labels ofMultiple mailboxes on the server
IMAP4 clients can create, rename, and delete mailboxes (usually presented to the user as folders) on the server, and copy messages between mailboxes. Multiple mailbox support also allows servers to provide access to shared and public folders. The ''IMAP4 Access Control List (ACL) Extension'' () may be used to regulate access rights.Server-side searches
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.Built-in extension mechanism
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 .Server push notifications
IMAP IDLE provides a way for the mail server to notify connected clients that there were changes to a mailbox, for example because a new mail has arrived. POP provides no comparable feature, and email clients need to periodically connect to the POP server to check for new mail.Disadvantages
While IMAP remedies many of the shortcomings of POP, this inherently introduces additional complexity. Much of this complexity (e.g., multiple clients accessing the same mailbox at the same time) is compensated for by server-side workarounds such as Maildir or database backends. The IMAP specification has been criticised for being insufficiently strict and allowing behaviours that effectively negate its usefulness. For instance, the specification states that each message stored on the server has a "unique id" to allow the clients to identify messages they have already seen between sessions. However, the specification also allows these UIDs to be invalidated with no restrictions, practically defeating their purpose. Unless the mail storage and searching algorithms on the server are carefully implemented, a client can potentially consume large amounts of server resources when searching massive mailboxes. IMAP4 clients need to maintain a TCP/IP connection to the IMAP server in order to be notified of the arrival of new mail. Notification of mail arrival is done through in-band signaling, which contributes to the complexity of client-side IMAP protocol handling somewhat. A private proposal, push IMAP, would extend IMAP to implement push e-mail by sending the entire message instead of just a notification. However, push IMAP has not been generally accepted and current IETF work has addressed the problem in other ways (see the Lemonade Profile for more information). Unlike some proprietary protocols which combine sending and retrieval operations, sending a message and saving a copy in a server-side folder with a base-level IMAP client requires transmitting the message content twice, once to SMTP for delivery and a second time to IMAP to store in a sent mail folder. This is addressed by a set of extensions defined by the IETF Lemonade Profile for mobile devices: URLAUTH () and CATENATE () in IMAP, and BURL () in SMTP-SUBMISSION. In addition to this, Courier Mail Server offers a non-standard method of sending using IMAP by copying an outgoing message to a dedicated outbox folder.Security
To cryptographically protect IMAP connections between the client and server, IMAPS on TCP port 993 can be used, which utilizes SSL/TLS. As of January 2018, TLS is the recommended mechanism. Alternatively,Dialog example
This is an example IMAP connection as taken froSee also
* List of mail server software * Comparison of email clients * Comparison of mail servers * IMAP IDLE * JSON Meta Application Protocol (JMAP) * Post Office Protocol (POP) * Push-IMAP *References
Further reading
* * * * *External links
* * — specification of IMAP version 4 revision 1 * — IMAP Implementation Suggestions RFC * — IMAP4 IDLE command {{Authority control Internet mail protocols