6.4.4. Interactive Mail Access Protocol (IMAP2/IMAP4)

Die IMAP-Protokolle stellen eine funktionelle Weiterentwicklung der POP-Protokolle dar. Wesentliche neue Eigenschaften sind: IMAP bietet Voraussetzungen, daß man in verschiedenen Umgebungen (Arbeitsplatzrechner, mobile Station unterwegs) dieselbe "Mail-Umgebung" vorfindet.

Die Klient/Server-Architektur von IMAP ist mit der von POP identisch. Anstelle des POP-Servers ist jetzt natürlich ein IMAP-Server vorhanden. Dieser verwendet standardmäßig den TCP-Port 143. IMAP basiert wiederum auf dem bekannten NVT-ASCII-Zeichensatz, wobei der Klient Kommandos an den Server sendet und letzterer diese in einer entsprechenden Weise beantwortet.

Im Gegensatz zu ähnlichen Protokollen wie FTP oder SMTP beginnt ein Kommando jedoch nicht mit dem Protokollelement, sondern mit einem Tag. Dieses besteht normalerweise aus einer kurzen alphanumerischen Zeichenkette (z.B. A0001), die vom Klienten vorgegeben wird. Der Antwort des Servers ist genau dieses Tag wieder vorangestellt. Dadurch wird es dem Klienten möglich, die Antwort des Servers dem zugehörigen Kommando zuzuordnen (beispielsweise, wenn mehrere Kommandos gerade in Abarbeitung sind). Die folgende Tabelle gibt eine Übersicht über mögliche Kommandos, wobei einige Kommandos andere voraussetzen (beispielsweise kann auf eine Mailbox erst nach einem erfolgreichen LOGIN-Kommando zugegriffen werden).

Kommando Kurzbeschreibung
CAPABILITY liefert eine Liste von Fähigkeiten, die der Server unterstützt
NOOP tut nichts (kann z.B. zum Test auf neue Nachrichten verwendet werden)
LOGOUT beendet die IMAP-Verbindung seitens des Klienten
AUTHENTICATE signalisiert einen gewünschten Authentifizierungsmechanismus (z.B. Kerberos)
LOGIN Authentifizierung mit Nutzerkennzeichen und Paßwort (beides wird im Klartext übertragen)
SELECT wählt eine Mailbox aus, so daß auf deren Nachrichten zugegriffen werden kann
EXAMINE identisch zu SELECT, jedoch nur lesender Zugriff erlaubt
CREATE erzeugt eine neue Mailbox
DELETE löscht eine Mailbox
RENAME ändert den Namen einer Mailbox
SUBSCRIBE fügt einen Mailboxnamen zur Liste der aktiven Mailboxen hinzu
UNSUBSCRIBE entfernt einen Mailboxnamen von der Liste der aktiven Mailboxen
LIST liefert eine Untermenge der für den Klienten verfügbaren Mailboxnamen
LSUB liefert eine Untermenge der Namen der aktiven Mailboxen
STATUS liefert den Status der spezifizierten Mailbox
APPEND fügt eine Nachricht an eine bestehende Mailbox an
CHECK überprüft die aktuelle Mailbox (implementationsspezifisches Kommando; evtl. äquivalent zu NOOP)
CLOSE entfernt alle als gelöscht markierten Nachrichten aus der Mailbox und schließt diese
EXPUNGE entfernt alle als gelöscht markierten Nachrichten aus der Mailbox
SEARCH sucht nach einer Nachricht, die bestimmte (möglicherweise recht komplexe) Suchkriterien erfüllt
FETCH holt alle oder ausgewählte Teile der Daten, die zu einer Nachricht gehören
STORE ändert ausgewählte Teile der Daten, die zu einer Nachricht gehören (gegenwärtig sind nur Manipulationen der Flags definiert)
COPY kopiert die spezifizierten Nachrichten an das Ende einer anderen Mailbox
UID liefert eindeutige Bezeichner anstelle der Sequenznummer der Nachricht

Die Antworten des Servers werden in zwei Arten unterteilt - in tagged und untagged responses. Alle Statusmeldungen des Servers, die nicht den Abschluß des Kommandos anzeigen, werden als untagged responses bezeichnet. Ihnen wird zur Kennzeichnung ein '*' vorangestellt. Den tagged responses ist dagegen das Tag des zugehörigen Kommandos, über dessen Erfolg bzw. Mißerfolg sie Auskunft geben, vorangestellt. Die beiden Kommandos PREAUTH und BYE sind immer untagged.

Antwort Kurzbeschreibung
OK Untagged ist es eine informelle Mitteilung des Servers, und tagged zeigt es die erfolgreiche Ausführung eines Kommandos an.
NO Untagged ist es eine allgemeine Warnung des Servers, und tagged zeigt es an, daß ein Kommando nicht fehlerfrei ausgeführt werden konnte.
BAD Untagged ist es ein interner Fehler, für den kein Kommando bestimmt werden kann, und tagged zeigt es einen Fehler auf IMAP-Ebene (z.B. ungültiges Kommando) an.
PREAUTH Begrüßung, die anzeigt, daß bereits eine Authentifizierung stattgefunden hat und daher kein LOGIN-Kommando notwendig ist.
BYE Zeigt an, daß der Server die Verbindung beendet (z.B. nach einem LOGOUT-Kommando).

Die grundlegende Funktionsweise von IMAP wollen wir uns an einem kleinen Beispiel ansehen. Zu diesem Zweck existieren auf dem Rechner caliban die drei Nutzer erni, bert und kermit. Wir wollen nun von einem anderen Rechner (rac2) aus auf die Mailbox des Nutzers kermit zugreifen:

rac2:501:~>telnet caliban 143
Trying 134.109.192.189...
Connected to caliban.informatik.tu-chemnitz.de.
Escape character is '^]'.
* OK caliban.informatik.tu-chemnitz.de IMAP2bis Service 7.8(100) at Wed, 29 Jan 1997 13:35:07 +0100 (MET)
Der IMAP-Server erwartet nun unsere Eingaben, d.h., als erstes muß sich der Nutzer kermit mittels seines Paßwortes authentifizieren:
A001 LOGIN kermit XXXXXXXX
A001 OK LOGIN completed
Als nächstes wählen wir (d.h. natürlich der Nutzer kermit) die Mailbox aus. Diese liegt in unserem Beispiel im Homeverzeichnes unter dem Namen Mailbox.
A002 SELECT ~/Mailbox
* 3 EXISTS
* FLAGS (\Answered \Flagged \Deleted \Seen)
* 0 RECENT
A002 OK [READ-WRITE] SELECT completed
Als Ergebnis erhalten wir die Information, daß in der Mailbox drei Nachrichten enthalten sind und seit der letzten Anfrage auch keine weiteren hinzugekommen sind.
Nun sehen wir uns den Status der drei Nachrichten an:
A003 FETCH 1:3 FLAGS
* 1 FETCH (FLAGS ())
* 2 FETCH (FLAGS (\Seen))
* 3 FETCH (FLAGS (\Seen \Answered))
A003 OK FETCH completed
Die erste Nachricht besitzt keine Flags, wurde also noch nicht einmal gelesen. Die zweite haben wir dagegen schon gelesen und die dritte bereits beantwortet.
Jetzt können wir damit beginnen, den Body der E-Mail zu holen. Zuerst fordern wir Informationen zum Aufbau des Body an:
A004 FETCH 1:3 BODY
* 1 FETCH (BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 33 1))
* 2 FETCH (BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 31 1))
* 3 FETCH (BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 35 1))
A004 OK FETCH completed
Alle drei Nachrichten bestehen also aus reinem ASCII-Text (was bei MIME-Mails nicht immer der Fall sein muß). Wir sehen uns also die erste Nachricht an:
A005 FETCH 1 BODY[1]
* 1 FETCH (BODY[1] {33}
Das ist eine ungelesene E-Mail.
 FLAGS (\Seen))
A005 OK FETCH completed
Wenn eine neue E-Mail eintrifft, so möchten wir eigentlich recht schnell darüber informiert werden. Zu diesem Zweck kann der UA in regelmäßigen Abständen (z.B. alle 5 Minuten) eine NOOP-Anfrage an den Server senden und erhält daraufhin diese Information:
A006 NOOP
* 4 EXISTS
* 1 RECENT
A006 OK NOOP completed


Vertiefung:

IMAP4-Spezifikation (Proposed Standard):

IMAP-Referenz: Sonstige Informationen:
© Uwe Hübner, Heino Gutschmidt, 2.7.1998