Internet Message Access Protocol

Grundprinzip und Aufbau

Das Internet Message Access Protocol (IMAP), ursprünglich Interactive Mail Access Protocol, ist ein Netzwerkprotokoll zum Lesen und Verwalten von E-Mails. Es stellt für E-Mails eine Art Netzwerkdateisystem bereit. Im Gegensatz zu einem Verfahren, bei dem Nachrichten hauptsächlich auf einem einzelnen Rechner gespeichert werden, bleiben bei IMAP die E-Mails, Ordnerstrukturen und Einstellungen auf dem Mailserver.

IMAP ist textbasiert und arbeitet im TCP/IP-Protokollstapel auf der Anwendungsschicht. Es nutzt TCP als Transportschicht und IP, sowohl IPv4 als auch IPv6. Der normale IMAP-Port ist 143/TCP; für IMAP mit TLS ist Port 993/TCP vorgesehen. Der aktuelle Standard ist RFC 9051.

Ein Mail-Client fordert vom Server jeweils nur die Informationen an, die gerade benötigt werden. Beim Öffnen eines Ordners lädt er beispielsweise eine aktuelle Nachrichtenliste. Soll der Inhalt einer Nachricht angezeigt werden, wird dieser gezielt vom Server abgerufen. Dadurch besitzen mehrere Clients denselben aktuellen Stand einer Mailbox. Suchen und andere Verwaltungsaufgaben können auf dem Server ausgeführt werden, ohne dass jeder Client eine vollständige lokale Kopie aller Ordner benötigt.

IMAP unterstützt mehrere Ordner innerhalb einer Mailbox. Server können eingehende Nachrichten automatisch filtern und in verschiedene Ordner einsortieren. Über Zugriffsrechte können auch mehrere Benutzer gleichzeitig auf dieselben Ordner und Daten zugreifen. Die Erweiterung IMAP IDLE ermöglicht eine sofortige Benachrichtigung des Clients über neue Nachrichten (Push), wodurch regelmäßiges Nachfragen (Polling) und damit unnötiger Datenverkehr vermieden werden.

Nachrichtenverwaltung und typische Sitzung

Zu den zentralen Aufgaben von IMAP gehören das Auswählen von Ordnern, das Abrufen von Nachrichteninformationen, das Anzeigen von Headern und das Setzen von Flags. Flags sind Kennzeichnungen wie „\Answered“, „\Flagged“, „\Deleted“, „\Seen“ und „\Draft“. Sie speichern beispielsweise, ob eine Nachricht beantwortet, markiert, gelöscht, gelesen oder als Entwurf gekennzeichnet ist.

Eine gekürzte IMAP4rev1-Sitzung aus RFC 3501, Kapitel 8, zeigt den typischen Ablauf:

• Der Server begrüßt den Client mit „* OK IMAP4rev1 Service Ready“.
• Der Client meldet sich mit „a001 login mrc secret“ an; der Server bestätigt die Anmeldung mit „a001 OK LOGIN completed“.
• Mit „a002 select inbox“ wird der Ordner „inbox“ ausgewählt. Der Server meldet unter anderem „18 EXISTS“, also 18 vorhandene Mails, sowie „2 RECENT“. Außerdem zeigt „UNSEEN 17“ an, dass Mail Nr. 17 die erste ungelesene Nachricht ist.
• Mit „a003 fetch 12 full“ fordert der Client Informationen zu Mail Nr. 12 an. Die Antwort enthält unter anderem das Flag „\Seen“, das Zustelldatum „17-Jul-1996 02:44:25 -0700“, die Größe „4286“ Byte und Angaben aus dem Header wie Datum, Betreff, Absender, Empfänger, CC und Message-ID.
• Mit „a004 fetch 12 body[header]“ werden alle Header dieser Nachricht angefordert. Der Server liefert beispielsweise Datum, From, Subject, To, cc, Message-Id, MIME-Version und Content-Type.
• Mit „a005 store 12 +flags \deleted“ wird Mail Nr. 12 als gelöscht markiert. Die Antwort zeigt nun die Flags „\Seen \Deleted“.
• Mit „a006 logout“ beendet der Client die Sitzung; der Server antwortet mit „* BYE IMAP4rev1 server terminating connection“ und bestätigt die Abmeldung.

Ohne Internetverbindung zum Mailserver ist der Zugriff in der Regel nicht möglich. Einige Clients speichern deshalb lokale Kopien und gleichen diese nach Wiederherstellung der Verbindung mit dem Server ab. Wegen der zentralen Speicherung auf einem externen Server müssen außerdem Datenschutz und die Verschlüsselung der Verbindung berücksichtigt werden.

Unterschiede zu POP und Authentifizierung

Im Vergleich zum Post Office Protocol (POP) verwaltet IMAP die Nachrichtenordner direkt auf dem Server. Wird eine Nachricht mit IMAP als gelesen markiert, sehen alle anderen Clients diese Markierung ebenfalls. Gelöschte Nachrichten verschwinden von allen synchronisierten Geräten. Nachrichten können serverseitig durchsucht werden; dadurch müssen Clients nicht alle Ordner vollständig speichern. Rechenarbeit und Speicherplatz werden damit teilweise vom Client auf den Server verlagert.

Der Server darf nicht autorisierten Benutzern den Zugriff auf eine Mailbox verweigern. Vor dem Zugriff auf E-Mails muss sich der Benutzer authentifizieren, normalerweise mit Benutzername und Passwort. Auf der IMAP-Protokollebene wird das Passwort dabei im Klartext übertragen. Deshalb können Mailserver verlangen, dass Clients das Passwort nur über eine zuvor verschlüsselte Sitzung senden. Als alternative Netzwerk-Authentifikationsprotokolle nennt der Artikel beispielsweise GSSAPI und Kerberos.

Verschlüsselte Verbindungen

Zum Schutz der übertragenen Daten kann die Verbindung mit SSL/TLS verschlüsselt werden. Dafür gibt es zwei Verfahren.

Bei STARTTLS wird zunächst über Port 143 eine unverschlüsselte Verbindung aufgebaut. Anschließend initiiert der Client mit dem Kommando STARTTLS eine verschlüsselte Sitzung. Alle danach übertragenen Daten werden über diese Verbindung verschlüsselt. STARTTLS ist als Protokollerweiterung ausdrücklich in der Spezifikation vorgesehen.

Bei IMAPS (Internet Message Access Protocol Secure) wird die Verbindung bereits beim Verbindungsaufbau durch SSL verschlüsselt. Der Server erkennt dies am reservierten Port 993. Nach dem Aufbau der SSL-Verbindung wird mindestens IMAPv4 verwendet. Die SSL-Schicht arbeitet für IMAP transparent: Das IMAP-Protokoll selbst muss dafür nicht geändert werden. RFC 8314 bevorzugt IMAPS gegenüber STARTTLS und gegenüber vollständig unverschlüsseltem IMAP.

Clients, Server und Weiterentwicklung

Fast alle gängigen E-Mail-Programme unterstützen IMAP, allerdings in unterschiedlichem Umfang. Viele Clients beherrschen vor allem den grundlegenden Nachrichtenabruf. Nur wenige nutzen den vollständigen Funktionsumfang der Server, etwa die Rechtevergabe für den gemeinsamen Zugriff mehrerer Benutzer auf einen Ordner. Als Beispiele mit erweiterter IMAP-Unterstützung nennt der Artikel Alpine/Pine, Gnus, Mulberry, Microsoft Outlook ab Version 2007, Evolution sowie Mozilla Thunderbird und SeaMonkey. Zur einfachen Unterstützung werden unter anderem Apple Mail, Windows Mail, Pegasus Mail, KMail, mutt, The Bat und Opera bis Version 12 gezählt; Microsoft Outlook erscheint in beiden Auswahlgruppen.

Viele Mailserver unterstützen IMAP. Einige Provider schränken die Funktion ein oder verlangen dafür ein höheres Entgelt, weil bei IMAP mehr Daten auf dem Server verbleiben und durchschnittlich mehr Daten übertragen werden. Cyrus war 1996 der erste Server mit einer als Internetstandard empfohlenen IMAP-Version. UW IMAP folgte ebenfalls 1996 und war zuvor ein Proof of Concept der University of Washington. Undokumentierte Erweiterungen und die Übernahme solcher Erweiterungen zwischen UW IMAP und Cyrus führten dazu, dass Konformität und Kompatibilität bei IMAP als notorisch strittig gelten.

Der Courier Mail Server löste sich vom mbox-Konzept und speichert Nachrichten nach dem Maildir-Konzept. Stabilität und Leistungsfähigkeit dieses Speicherkonzepts sind wichtige Kriterien für IMAP-Server. Weitere genannte Server und Systeme sind Citadel Groupware Server, Dovecot, Mercury MTS für NetWare und Windows sowie die Dokumentenmanagement-Systeme agorum core und Alfresco. Groupware-Lösungen wie Kerio Connect, Kolab-Server, Lotus Domino, Microsoft Exchange Server und Zarafa integrieren IMAP ebenfalls fest.

Die Entwicklung verlief über mehrere Versionen: Im Juli 1988 schlug Mark Crispin die zweite Version vor. Im Februar 1991 wurde eine dritte Version veröffentlicht. Im Dezember 1994 erschien die erste nicht mehr experimentelle vierte Version. Im Dezember 1996 wurde festgestellt, dass eine von mehreren undokumentierten Versionen weit verbreitet war; die erste Revision der vierten Version wurde im März 2003 nochmals geändert.

Die Dokumentation besteht aus zahlreichen grundlegenden, ergänzenden und erweiternden RFCs. Dazu gehören RFC 3501 für IMAP4rev1, RFC 2177 für IMAP IDLE, RFC 2595 für TLS mit IMAP, POP3 und ACAP, RFC 4314 für Zugriffssteuerungslisten (ACL), RFC 5255 für Internationalisierung, RFC 5256 für SORT und THREAD, RFC 5738 für UTF-8-Unterstützung, RFC 6851 für MOVE sowie RFC 7162 für CONDSTORE und QRESYNC. Weitere Erweiterungen betreffen unter anderem Quoten, Komprimierung, Suchfunktionen, Metadaten, spezielle Mailboxen und die Synchronisation getrennter Clients.