Internet Message Access Protocol
From Wikipedia, the free encyclopedia
The introduction to this article provides insufficient context for those unfamiliar with the subject. Please help improve the article with a good introductory style. |
The five-layer TCP/IP model |
---|
5. Application layer |
DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · RTP · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS (and SSL) · SDP · SOAP · GTP · STUN · NTP · (more) |
4. Transport layer |
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more) |
3. Network/internet layer |
IP (IPv4 · IPv6) · OSPF · IS-IS · BGP · IPsec · ARP · RARP · RIP · ICMP · ICMPv6 · IGMP · (more) |
2. Data link layer |
802.11 (WLAN) · 802.16 · Wi-Fi · WiMAX · ATM · DTM · Token ring · Ethernet · FDDI · Frame Relay · GPRS · EVDO · HSPA · HDLC · PPP · PPTP · L2TP · ISDN · ARCnet · LLTD · (more) |
1. Physical layer |
Ethernet physical layer · RS-232 · SONET/SDH · G.709 · Optical fiber · Coaxial cable · Twisted pair · (more) |
The Internet Message Access Protocol (commonly known as IMAP or IMAP4, and previously called Internet Mail Access Protocol, Interactive Mail Access Protocol (RFC 1064), and Interim Mail Access Protocol[1]) is an application layer Internet protocol operating on port 143 that allows a local client to access e-mail on a remote server. The current version, IMAP version 4 revision 1 (IMAP4rev1), is defined by RFC 3501. IMAP4 and POP3 (Post Office Protocol version 3) are the two most prevalent Internet standard protocols for e-mail retrieval. Virtually all modern e-mail clients and servers support both.
Contents |
[edit] E-mail protocols
This section does not cite any references or sources. (November 2007) Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed. |
IMAP supports both connected (online) and disconnected (offline) modes of operation. E-mail clients using IMAP generally leave messages on the server until the user explicitly deletes them. This and other facets of IMAP operation allow multiple clients to access the same mailbox. Most e-mail clients support either POP3 or IMAP to retrieve messages; however, fewer Internet Service Providers (ISPs) support IMAP. IMAP4 offers access to the mail store; the client may store local copies of the messages, but these are considered to be a temporary cache; the server's store is authoritative.
E-mail messages are generally sent to an e-mail server that stores received messages in the recipient's e-mail mailbox. The user later retrieves these messages with either a web browser or an e-mail client that uses one of a number of e-mail retrieval protocols. While some clients and servers preferentially use vendor-specific, proprietary protocols, most support the Internet standard protocols SMTP for sending e-mail and POP3 and IMAP4 for retrieving e-mail, allowing interoperability with other servers and clients. For example, Microsoft's Outlook client typically uses a proprietary protocol to communicate with an Exchange server as does IBM's Notes client when communicating with a Domino server, but all of these products also support SMTP, POP3, and IMAP4. Support for the Internet standard protocols allows many other e-mail clients such as Pegasus Mail or Mozilla Thunderbird (see comparison of e-mail clients) to access these servers and similarly allows the clients to be used with other servers (see list of mail servers).
E-mail clients can generally be configured to use either POP3 or IMAP4 to retrieve e-mail and in both cases use SMTP for sending. Most e-mail programs can also use Lightweight Directory Access Protocol (LDAP) for directory services.
Nearly all subscribers to individual Internet service provider e-mail accounts access their e-mail with client software that uses POP3.[citation needed]
IMAP is often used in large networks; for example, a college campus mail system. IMAP allows users to access new messages instantly on their computers, since the mail is stored on the network. With POP3, users either download the e-mail to their computer or access it via the web. Both methods take longer than IMAP, and the user must either download any new mail or "refresh" the page to see the new messages.
[edit] History
IMAP was designed by Mark Crispin in 1986 as a remote mailbox protocol, in contrast to the widely used POP, a protocol for retrieving the contents of a mailbox.[2]
[edit] 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 or its software exist; all known installations of the original protocol were updated to IMAP2. 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.
[edit] IMAP2
The interim protocol was quickly replaced by the Interactive Mail Access Protocol (IMAP2), defined in RFC 1064 and later updated by RFC 1176. IMAP2 introduced command/response tagging and was the first publicly distributed version.
[edit] 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 in IMAP2. This experimental revision was called IMAP2bis; its specification was never published in non-draft form. Early versions of Pine were widely distributed with IMAP2bis support (Pine 4.00 and later supports IMAP4rev1).
[edit] IMAP4
An IMAP Working Group formed in the IETF in the early 1990s and took over responsibility for the IMAP2bis design. The IMAP WG decided to rename IMAP2bis to IMAP4 to avoid confusion with a competing IMAP3 proposal from another group that never got off the ground. The expansion of the IMAP acronym also changed to the Internet Message Access Protocol.
Some design flaws in the original IMAP4 (defined by RFC 1730) that came out in implementation experience led to its revision and replacement by IMAP4rev1 two years later. There were very few IMAP4 client or server implementations due to its short lifetime.
[edit] IMAP4rev1
The current version of IMAP since 1996, IMAP version 4 revision 1 (IMAP4rev1), is defined by RFC 3501 which revised the earlier RFC 2060.
IMAP4rev1 is upwards compatible with IMAP2 and IMAP2bis; and is largely upwards-compatible with IMAP4. However, the older versions are either extinct or nearly so.
Unlike many older Internet protocols, IMAP4 natively supports encrypted login mechanisms. Plain-text transmission of passwords in IMAP4 is also possible. Because the encryption mechanism to be used must be agreed between the server and client, plain-text passwords are used in some combinations of clients and servers (typically Microsoft Windows clients and non-Windows servers). It is also possible to encrypt IMAP4 traffic using SSL, either by tunneling IMAP4 communications over SSL on port 993, or by issuing STARTTLS within an established IMAP4 session (see RFC 2595).
IMAP4 works over a TCP/IP connection using network port 143.
[edit] Advantages over POP3
[edit] Connected and disconnected modes of operation
When using POP3, 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.
[edit] Multiple clients simultaneously connected to the same mailbox
The POP3 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.
[edit] Access to MIME message parts and partial fetch
Nearly 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 separately retrieve any of the individual MIME parts 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 to stream content as it is being fetched.
[edit] Message 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. POP3 provides no mechanism for clients to store such state information on the server so if a single user accesses a mailbox with two different POP3 clients, state information--such as whether a message has been accessed--cannot be synchronized between the clients. The IMAP4 protocol supports both pre-defined 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. Adding user created tags to messages is an operation supported by some web-based email services, such as Gmail.
[edit] Multiple mailboxes on the server
IMAP4 clients can create, rename, and/or delete mailboxes (usually presented to the user as folders) on the server, and move messages between mailboxes. Multiple mailbox support also allows servers to provide access to shared and public folders.
[edit] 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.
[edit] Built-in extension mechanism
Reflecting the experience of earlier Internet protocols, IMAP4 defines an explicit mechanism by which it may be extended. Many extensions to the base protocol have been proposed and are in common use. IMAP2bis did not have an extension mechanism, and POP3 now has one defined by RFC 2449.
[edit] Disadvantages of IMAP
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.
Unless the mail store 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 explicitly request new email message content potentially causing additional delays on slow connections such as those commonly used by mobile devices. 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 remedied by a set of extensions defined by the IETF LEMONADE Working Group for mobile devices: URLAUTH (RFC 4467) and CATENATE (RFC 4469) in IMAP and BURL (RFC 4468) in SMTP-SUBMISSION. POP3 servers don't support server-side folders so clients have no choice but to store sent items on the client. Many IMAP clients can be configured to store sent mail in a client-side folder. In addition to the LEMONADE "trio", Courier Mail Server offers a non-standard method of sending using IMAP by copying an outgoing message to a dedicated outbox folder.
[edit] Common Server implementations
The following IMAP-servers are common:
- 602LAN SUITE Groupware
- Alt-N MDaemon
- Binc IMAP - uses Maildir format, designed to be familiar for users of qmail and qmail-pop3d
- Citadel
- CommuniGate Pro
- Courier Mail Server - uses Maildir format.
- Cyrus IMAP server - a "black box" server that provides access through POP3 and IMAP; uses a proprietary Maildir-esque scheme, and does indexing
- DBMail - includes an IMAP server that stores mail in an SQL database
- Dovecot - Secure IMAP server with Maildir and indexing
- Eudora Internet Mail Server
- FirstClass Server - FirstClass Server
- GNU Mailutils - uses Maildir or MH
- hMailServer - Free email server for Microsoft Windows
- IBM Lotus Domino Server
- IMail Server
- Kerio MailServer
- M-Box from Isode Limited
- MailEnable
- Mailtraq
- Merak Mail Server
- Mirapoint Email Appliance
- Microsoft Exchange Server
- Openwave Email MX
- Novell GroupWise
- Sun Java System Messaging Server
- UW IMAP - supports multiple formats including mbox, mbx, MMDF, tenex, mtx, MH, mx, and Usenet news spools.
- Zimbra
[edit] Common Client implementations
The following IMAP-clients are common (see also Comparison of e-mail clients):
- text-based clients:
- GUI clients:
- Apple Mail
- The Bat!
- Novell Evolution
- Claws Mail (formely Sylpheed-claws)
- Sylpheed
- Novell GroupWise Windows Client
- iPhone email client ("MobileMail")
- IMail
- KMail
- Eudora (e-mail client)
- Microsoft Outlook Express
- Microsoft Outlook
- Microsoft Entourage
- Windows Mail
- Mozilla Thunderbird
- Mulberry
- Pegasus Mail
- Opera Mail
- SeaMonkey Mail
- Becky
- GNUMail
- Emacs-based clients:
- Gnus
- VM/ViewMail
- Web-based clients:
The following e-mail services support IMAP access:
- AOL Mail
- AOL Instant Messenger
- Apple's .Mac
- FastMail.FM
- Gmail
- GMX Mail
- Hushmail - paid subscription
- Laposte.net
- Runbox
- Tuffmail
The following clients support IMAP on a Treo
- ChatterEmail
- Snappermail
[edit] See also
- E-mail client
- List of mail servers
- Post Office Protocol (POP3)
- Push-IMAP
- Simple Mail Access Protocol
- Simple Mail Transfer Protocol (SMTP)
- Webmail
- IMAP IDLE
[edit] References
[edit] External links
- RFC 3501 - specification of IMAP version 4 revision 1
- RFC 2683 - IMAP Implementation Suggestions RFC
- RFC 2177 - IMAP4 IDLE command
- The IMAP connection - resources for developers of programs using the IMAP protocol
- Infinite Ink's listing of products and service providers supporting IMAP
- Unofficial IMAP protocol wiki - resources for IMAP client and server developers