Internet Message Access Protocol

IMAP is a redirect to this article. Further meanings are listed under IMAP (disambiguation) .

Internet Message Access Protocol
Family:	Internet protocol family
Operation area:	Read and manage email
Ports :	143 / TCP 993 / TCP (only with TLS )
IMAP in the TCP / IP protocol stack : application IMAP transport TCP Internet IP ( IPv4 , IPv6 ) Network access Ethernet Token bus Token ring FDDI ...
Default:	RFC 3501

The Internet Message Access Protocol ( IMAP ), originally Interactive Mail Access Protocol , is a network protocol that provides a network file system for e-mail .

IMAP was designed in the 1980s with the advent of personal computers in order to resolve dependencies on individual client computers for mail communication . For this purpose, IMAP extends the functions and processes of Post Office Protocol (POP) so that users can save and leave their mails, folder structures and settings on the (mail) servers . The (PC) clients access the information on the servers directly online and may have to accommodate copies of it. While a POP user has either lost all e-mails after losing his PC or receives e-mails that have already been deleted, IMAP users always keep their e-mails on the servers and, even across multiple and different clients, always have uniform access.

The Simple Mail Access Protocol (SMAP) is an approach to combine the functionality of IMAP with the Simple Mail Transfer Protocol (SMTP), which is otherwise required for sending e-mails.

Protocol properties

IMAP is a text-based protocol for accessing e-mails that are on a mail server . A mail client only sends requests to the server for information that is currently required. Would a user z. B. see the contents of a folder, the client fetches a current message list for the relevant folder from the server. If the content of a mail is to be displayed, it is loaded from the server. Since all data remain on the server, they all show the same, current database of a mailbox - even when using several clients. In addition, local storage of the data is unnecessary and extended options such as searching through mails are carried out on the server.

With IMAP it is also possible to access different folders within a mailbox. Many servers can also sort incoming mails directly into different folders ( filter ). By setting access rights for folders in a mailbox, several users can access the same data at the same time . The IMAP IDLE extension enables immediate notification to clients ( pushing ) when a new mail arrives. This avoids unnecessary data traffic that would result from constant inquiries ( polling ) from a client. If you do not have an internet connection to your mail server, you can usually no longer access your mail. Some clients solve this problem by creating local copies of the mail that they can access in offline mode . When the Internet connection is restored, the data is compared ( synchronized ) with the mail server again .

Because the data is stored centrally on an external server, your own data protection must also be taken into account. The connection to the server should therefore be encrypted .

Example of an IMAP session (IMAP4rev1 example from RFC 3501 , Chapter 8 - shortened):

Client	server	Explanation
	* OK IMAP4rev1 Service Ready	Server welcomes the client
a001 login mrc secret		Client logs on
	a001 OK LOGIN completed	Server confirms registration
a002 select inbox		Client selects inbox as the active folder
	* 18 EXISTS * FLAGS (\ Answered \ Flagged \ Deleted \ Seen \ Draft) * 2 RECENT * OK [UNSEEN 17] Message 17 is the first unseen message a002 OK [READ-WRITE] SELECT completed	18 mails available Defined flags 2 urgent mails (e.g. new mails) Mail no. 17 has not been read. All older ones have already been read. Client is allowed to make changes to mails
a003 fetch 12 full		Client requests information on mail no.12
	* 12 FETCH (FLAGS (\ lakes) INTERNAL DATE "17-Jul-1996 02:44:25 -0700" RFC822.SIZE 4286 ENVELOPE ("Wed, Jul 17, 1996 2:23:25 -0700 (PDT)" "IMAP4rev1 WG mtg summary and minutes" (("Terry Gray" NIL "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu")) ((NIL NIL "imap" "cac.washington.edu")) (("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL "<[e-mail]>") BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 302892)) a003 OK FETCH completed	Mail has already been read on July 17th, 1996 sent over 4kB mail header : date Subject Sender (From) Sender (sender) Answer to Receiver (To) Copy recipient (CC) BCC and In-Reply-To not specified Message ID
a004 fetch 12 body [header]		Client wants all headers for mail no.12
	* 12 FETCH (BODY [HEADER] {342} Date: Wed, Jul 17, 1996 02:23:25 -0700 (PDT) From: Terry Gray <[e-mail]> Subject: IMAP4rev1 WG mtg summary and minutes To: [e-mail] cc: [e-mail], John Klensin <[e-mail]> Message-Id: <[e-mail]> MIME version: 1.0 Content-Type: TEXT / PLAIN; CHARSET = US-ASCII ) a004 OK FETCH completed	Server sends requested mail headers
a005 store 12 + flags \ deleted		Mark mail no. 12 as deleted
	* 12 FETCH (FLAGS (\ Seen \ Deleted)) a005 OK + FLAGS completed
a006 logout		Client logs off
	* BYE IMAP4rev1 server terminating connection a006 OK LOGOUT completed

Clients

IMAP is now supported by almost all common e-mail programs . However, there are big differences in the level of support. Many clients only support basic message retrieval functions (which is sufficient for most users). Only a few programs use the full range of functions that IMAP servers offer. This includes, for example, the assignment of rights for different users to jointly access a folder.

Selection of clients with extended IMAP support:

• Alpine / Pine
• Wildebeest
• Mulberry (almost complete support)
• Microsoft Outlook (from version 2007)
• evolution
• Mozilla Thunderbird , SeaMonkey

Selection of clients with simple IMAP support:

• Apple Mail
• Windows Mail
• Pegasus Mail
• KMail
• Microsoft Outlook
• mutt
• Opera (only up to version 12)
• The Bat

server

Many mail servers now support IMAP. However, some providers suppress the functionality (or charge a higher fee), since with IMAP more data is stored on the server and the average transfer volume also increases.

Cyrus was the first server to use a version of IMAP that was recommended as the Internet standard. UW IMAP followed suit in the same year and was previously proof of concept for IMAP. This server from the University of Washington extends IMAP, but this has not been documented and has nevertheless been adopted by Carnegie Mellon University in its Cyrus. This approach of the two universities with the first implementations meant that conformity and compatibility with IMAP is notoriously controversial.

With the Courier Mail Server came the departure from the mbox concept, which is now considered unsuitable. Courier saves the e-mails according to the maildir concept. The stability and performance of the storage concept is an essential criterion of servers for IMAP.

In addition to the ones mentioned, the following IMAP servers are also used in the Unix environment:

• Citadel Groupware Server
• Dovecot

Messaging products also offer IMAP interfaces on other platforms and in the commercial sector.

• Mercury MTS for Netware and Windows
• agorum's core is a open source - document management system with IMAP access
• Alfresco is an open source - document management system that supports IMAP access.

In addition, groupware solutions build IMAP firmly into their concept:

• Kerio Connect
• Kolab server
• Lotus Domino
• Microsoft Exchange Server
• Zarafa

Advantages and disadvantages

advantage	disadvantage
Messages are stored separately on the server Quick first access to the mailbox The contents of the mailbox are always up to date	A connection to the server must be established for each unread message To save a copy of a sent message, it must be uploaded a second time Higher server load - especially when searching and sorting

Authentication

The server can deny access to a mailbox for unauthorized users. In any case, the user has to authenticate himself before he can gain access to mail. This is done by logging in with a username and password . The password is transmitted in clear text at the IMAP protocol level . Mail servers can therefore forbid clients from transmitting the password if no encrypted session has been established beforehand.

Alternatively, other network authentication protocols (e.g. GSSAPI , Kerberos ) can also be used.

Encryption

IMAPS in the TCP / IP protocol stack :

application	IMAP
transport	SSL / TLS
	TCP
Internet	IP ( IPv4 , IPv6 )
Network access	Ethernet	Token bus	Token ring	FDDI	...

To protect the data from third parties during transmission, the data connection can be encrypted using SSL / TLS . There are two different methods for this:

STARTTLS

After an unencrypted data connection has been established with the server (port 143), an encrypted session can be initiated using the STARTTLS command so that all subsequent data sent over this connection are only transmitted in encrypted form. This protocol extension is fixed in the protocol specification.

IMAPS

When using IMAPS, the connection to the server is encrypted using SSL while the connection is being established . Another port must be used so that the server recognizes this. Port 993 was reserved for this.

After the SSL connection has been established, at least IMAPv4 is used. The SSL layer is transparent to the IMAP protocol ; i.e. no changes are made to the IMAP protocol.

In RFC 8314 , the use of IMAPS is preferred over STARTTLS and completely unencrypted IMAP.

history

In July 1988, Mark Crispin proposed the second version of the SUMEX-AIM protocol for testing on the Internet. SUMEX-AIM means " Stanford University Medical Experimental Computer for Artificial Intelligence in Medicine " and means a networked project for artificial intelligence in medicine across the USA .

In February 1991, the third version was published as an alternative to Crispin's new second version from August 1990.

In December 1994 the first non-experimental and fourth version was published. In December 1996, it was discovered that one of several undocumented versions of the protocol was widely used, and the first revision of the fourth version, which was changed again in March 2003.

Specifications

The IMAP documentation is made up of a large number of basic, supplementary, or broadening RFCs .

• RFC 1731 - IMAP4 Authentication Mechanisms
• RFC 1732 - IMAP4 Compatibility With IMAP2 And IMAP2BIS
• RFC 1733 - Distributed Electronic Mail Models In IMAP4
• RFC 2061 - IMAP4 Compatibility With IMAP2BIS
• RFC 2062 - Internet Message Access Protocol - Obsolete Syntax
• RFC 2087 - IMAP4 QUOTA Extension
• RFC 2088 - IMAP4 non-synchronizing literals
• RFC 2177 - IMAP4 IDLE command
• RFC 2180 - IMAP4 Multi-Accessed Mailbox Practice
• RFC 2193 - IMAP4 Mailbox Referrals
• RFC 2195 - IMAP / POP AUTHorize Extension for Simple Challenge / Response
• RFC 2221 - IMAP4 Login Referrals
• RFC 2342 - IMAP4 Namespace
• RFC 2595 - Using TLS with IMAP, POP3 and ACAP
• RFC 2683 - IMAP4 Implementation Recommendations
• RFC 2971 - IMAP4 ID Extension
• RFC 3348 - IMAP4 Child Mailbox Extension
• RFC 3501 - Internet Message Access Protocol - Version 4rev1
• RFC 3502 - IMAP MULTIAPPEND Extension
• RFC 3503 - Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)
• RFC 3516 - IMAP4 Binary Content Extension
• RFC 3656 - The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
• RFC 3691 - IMAP UNSELECT command
• RFC 4314 - IMAP4 Access Control List (ACL) Extension
• RFC 4315 - Internet Message Access Protocol (IMAP) - UIDPLUS Extension
• RFC 4466 - Collected Extensions to IMAP4 ABNF
• RFC 4467 - Internet Message Access Protocol (IMAP) - URLAUTH Extension
• RFC 4469 - Internet Message Access Protocol (IMAP) - CATENATE Extension
• RFC 4549 - Synchronization Operations for Disconnected IMAP4 Clients
• RFC 4551 - IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
• RFC 4731 - IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned
• RFC 4959 - IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response
• RFC 4978 - The IMAP COMPRESS Extension
• RFC 5032 - WITHIN Search Extension to the IMAP Protocol
• RFC 5092 - IMAP URL Scheme
• RFC 5161 - The IMAP ENABLE Extension
• RFC 5162 - IMAP4 Extensions for Quick Mailbox Resynchronization
• RFC 5182 - IMAP Extension for Referencing the Last SEARCH Result
• RFC 5255 - Internet Message Access Protocol Internationalization
• RFC 5256 - Internet Message Access Protocol - SORT and THREAD Extensions
• RFC 5257 - Internet Message Access Protocol - ANNOTATE Extension
• RFC 5258 - Internet Message Access Protocol version 4 - LIST Command Extensions
• RFC 5464 - The IMAP METADATA Extension
• RFC 5465 - The IMAP NOTIFY Extension
• RFC 5530 - IMAP Response Codes
• RFC 5550 - The Internet Email to Support Diverse Service Environments (Lemonade) Profiles
• RFC 5593 - Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
• RFC 5738 - IMAP Support for UTF-8
• RFC 5788 - IMAP4 Keyword Registry
• RFC 5819 - IMAP4 Extension for Returning STATUS Information in Extended LIST
• RFC 5957 - Display-Based Address Sorting for the IMAP4 SORT Extension
• RFC 6154 - IMAP LIST Extension for Special-Use Mailboxes
• RFC 6203 - IMAP4 Extension for Fuzzy Search
• RFC 6785 - Support for Internet Message Access Protocol (IMAP) Events in Sieve
• RFC 6851 - Internet Message Access Protocol (IMAP) - MOVE Extension
• RFC 7162 - IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)
• RFC 7377 - IMAP4 Multimailbox SEARCH Extension

literature

• Peer Heinlein , Peer Hartleben: POP3 and IMAP - mail server with Courier and Cyrus . Open Source Press, September 2007, ISBN 978-3-937514-11-6

Individual evidence

1. ↑ http://www.iana.org/assignments/port-numbers
2. ↑ ^{a b} M. Crispin: RFC 1064 - Interactive Mail Access Protocol - Version 2 . Internet Engineering Task Force. July 1988. Retrieved February 5, 2015.
3. ^ IMAP: The Internet Message Access Protocol - Brief Overview and History . University of Washington. 1996. Retrieved January 20, 2012.
4. ^ M. Crispin: Pine won't search my IMAP mail . Google. February 8, 2003. Retrieved May 8, 2011.
5. ↑ IMAP4 status . University of Washington. 1996. Retrieved January 20, 2012.
6. ↑ Changes to the Cyrus IMAP Server 2.3.x since . Carnegie Mellon University. Retrieved May 8, 2011.
7. ↑ P. Heinlein, P. Hartleben: The book of IMAP: building a mail server with Courier and Cyrus . Google. P. 107. Retrieved May 8, 2011.
8. ↑ PB Koetter: UW IMAP, Courier, Cyrus and Dovecot in direct comparison . Linux New Media. Retrieved May 8, 2011.
9. ^ The Seeds of Artificial Intelligence . In: Educational Research Information Center . United States Department of Education . Retrieved February 5, 2015.
10. ^ J. Rice: RFC 1203 - Interactive Mail Access Protocol - Version 3 . Internet Engineering Task Force. February 1991. Retrieved February 5, 2015.
11. ^ M. Crispin: RFC 1176 - Interactive Mail Access Protocol - Version 2 . Internet Engineering Task Force. August 1990. Retrieved February 5, 2015.
12. ^ M. Crispin: RFC 1730 - Internet Message Access Protocol - Version 4 . Internet Engineering Task Force. December 1994. Retrieved February 5, 2015.
13. ↑ M. Crispin: RFC 2061 - IMAP4 compatibility with IMAP2bis . Internet Engineering Task Force. December 1996. Retrieved February 5, 2015.
14. ^ M. Crispin: RFC 2060 - Internet Message Access Protocol - Version 4rev1 . Internet Engineering Task Force. December 1996. Retrieved February 5, 2015.
15. ^ M. Crispin: RFC 3501 - Internet Message Access Protocol - Version 4rev1 . Internet Engineering Task Force. March 2003. Retrieved February 5, 2015.
16. ↑ IMAP / POP RFCs . Internet Engineering Task Force . Archived from the original on September 4, 2011. Info: The archive link was automatically inserted and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved July 31, 2011.