Auch wenn die Beschreibung des IMAP-Standards [1] weit mehr als 100 Seiten umfasst, erklärt sie das Protokoll doch nur zum Teil. Der Autor Marc Crispin schreibt im RFC 3501: "Abgesehen vom Überblick über das Protokoll in Abschnitt 2 ist es nicht optimal auf diejenigen zugeschnitten, die die Handhabung des Protokolls verstehen wollen."
Ein erstes Beispiel dafür liefern Status-Informationen (Flags), die eine Mail besitzen kann. Der IMAP-Standard schreibt kaum vor, welche es genau gibt; Server und Client dürfen sich darum über zusätzliche Flags und deren Natur verständigen. Und: Flags können permanent (gelesen, wichtig), aber auch sitzungsbasiert sein (neu, gelöscht). Welche Flags es gibt, ist von Ordner zu Ordner unterschiedlich. Außerdem liegt die Flag-Tücke im logischen Detail: Wenn beispielsweise ein Client auf ein Verzeichnis nur lesend zugreifen darf, schafft er es nicht, permanente Flags zu verändern.
Obwohl IMAP alle Informationen auf dem Server speichert, bietet es auch Funktionen, die dem Client erlauben Details lokal zu speichern und über mehrere Logins erneut zu benutzen, zum Beispiel für das lokal vorgehaltene Inhaltsverzeichnis. Das ist nicht trivial, da sich zwischenzeitlich Änderungen am Mailverzeichnis ergeben können. Darum nummeriert IMAP die E-Mails sowohl lückenlos mit linear aufsteigenden Sequenznummern (etwa 1 bis 399) als auch mit so genannten Unique-IDs.
Unveränderliches ändern
Unique IDs sind für jede Mail eindeutig und sollten sich pro Mail nie ändern. Gegenteiliges kann gleichwohl in manchen Konstellationen passieren. Diese Fälle erkennt der Client anhand eines speziellen Unique-ID-Value auf dem Server und liest die Liste der Mails und Unique-IDs neu ein, um sich zu synchronisieren.
Disconnected IMAP, auch Offline IMAP genannt, speichert noch deutlich mehr Informationen auf dem Client und verhilft gewissermaßen IMAP auch noch zu den Vorteilen von POP3. Dabei hält der Mailclient den kompletten Datenbestand des Mail-Postfachs lokal vor. Der Nutzer kann Ordner offline anlegen, Mails verschieben, flaggen oder löschen. Beim nächsten Connect synchronisieren Client und Server alle Änderungen. Die Methode funktioniert nach anfänglichen Macken mittlerweile erstaunlich gut, und zwar - dank IMAPs Flexibilität - ohne ein eigenes Protokoll zu etablieren.
Gern auch unseriell
Funktional und komplex zugleich wird eine IMAP-Sitzung auch dadurch, dass der Client mehrere Kommandos parallel zum Server senden und die Antworten in anderer Reihenfolge erhalten kann. So darf der Client einen komplexen Suchbefehl an den Server senden und ohne auf das Ergebnis zu warten neue Mails hochladen oder Ordner anlegen. Damit der Client die eintreffenden Antworten seinen Anforderungen zuzuordnen weiß, taggt er sie, versieht sie also mit irgendeiner eindeutigen Kennung, die er sich aussuchen darf. Die Antworten des Servers tragen die gleiche Kennung. Schon der Login muss ein Tag benutzen, in diesem Beispiel »a1«:
a1 login User Password
Der Server antwortet daraufhin »a1 OK LOGIN OK«. In der Wahl des Tag ist der Client frei, solange er nie das gleiche Tag parallel mehrmals benutzt. Statt »a1« wie im Beispiel eben, wären »001« oder »abc« gleich gut gewesen.
Dummerweise fallen manche Antworten eines Servers mehrzeilig aus. Man unterscheidet darum zwischen getaggten und ungetaggten Antworten. Letztere beginnen mit einem Sternchen und enden mit einer getaggten Zeile. Das Kommando »NOOP« ist so ein Fall, das manchmal eine mehrzeilige Antwort und damit ungetaggte Antworten provoziert.