© Christian Draghici, 123RF.com

Eine Reihe von Protokoll-Extensions macht das betagte IMAP-4-Protokol weiterhin genießbar, was auch mobilen Clients hilft. Der Artikel stellt eine gesunde Mischung nützlicher Erweiterungen vor.

Als die erste Version des Internet Message Access Protocol 4 (IMAP 4) im Jahre 1994 erschien, erinnerten Mobiltelefone an Hundeknochen und konnten auch kaum mehr. Digitale Daten tröpfelten dank Telefonmodem in homöopathischen Dosen aus dem Internet. UMTS und mobile E-Mail-Clients gab es nicht, selbst E-Mails fanden erst zaghaft Verbreitung.

Anbaubedarf

Um IMAP 4 an die Erfordernisse der Moderne, insbesondere an mobile Clients anzupassen, hat die Network Working Group der Internet Engineering Task Force das IMAP-Protokoll in einer ganzen Reihe von RFCs um Extensions bereichert, die IMAP neue Möglichkeiten bescheren, ohne aber Clients und Servern, die ältere Versionen verwenden, damit auf die Füße zu treten.

Viele der Protokollerweiterungen befinden sich noch im Vorschlagsstadium, eine recht umfassende Liste (Abbildung 1) finden Interessierte im inoffiziellen IMAP-Wiki [1]. Einige der Erweiterungen sind zugleich Teil des Lemonade-Profils. (Lemonade steht für “License to Enhance Message Oriented Network Access for Diverse Environments”). Unter diesem Label versammelt das RFC 4550 [2] über 20 IMAP-Protokollerweiterungen, um explizit die Kommunikation mit mobilen Clients zu verbessern.

Abbildung 1: Das inoffizielle IMAP-Wiki zeigt nicht nur viele Erweiterungen an, sondern will auch in einer Matrix klären, welche IMAP-Server die Features bereits implementieren.

Während es bei den exotischeren dieser RFCs vorkommt, dass noch kein Server die zugehörige Extension implementiert hat, erstaunt bei anderen, dass der Server-Admin sie aktivieren muss, weil sie noch kein fester Bestandteil des Protokolls sind (Abbildung 2).

Abbildung 2: Der Wikipedia-Eintrag zu IMAP zeigt in einem Beispieldialog detailliert, wie sich ein Client mit einem IMAP-4-Server unterhält.

Der Artikel stellt eine Auswahl von häufig eingesetzten Erweiterungen vor und erklärt kurz ihren Einsatzzweck. Weitere Details stehen in den zugehörigen RFCs, die nicht selten Dutzende von Seiten lang sind. Auf einige der hier nicht besprochenen IMAP-Zusätze – etwa die Special-Use-Erweiterung – geht der Dovecot-Artikel ab Seite 34 ein.

Entdecker: »CAPABILITY«

Kein Zusatz, sondern eine wichtige Funktion von IMAP 4 ist das »CAPABILITY« -Kommando [3]. Der Client benutzt es, um zu erfahren, welche Erweiterungen der Server versteht. Dieser sendet eine lange Zeile zurück, die seine Fähigkeiten in Schlagworten auflistet.

Dabei taucht unter Umständen – und hier kommt die erste Erweiterung zum Einsatz – das »ID« -Kommando auf [4]. Ist diese Fähigkeit Server-seitig aktiviert, darf der Client Informationen über sich selbst an den Server schicken, etwa seine Versionsnummer und den Namen. Mit den Informationen sollen Server und Client laut RFC jedoch nicht versuchen, um Bugs herum zu arbeiten. Sie sollen vielmehr dem Postmaster dabei helfen, Bugs zu erkennen und an die Hersteller der Software weiterzugeben.

Stiller Beobachter: »IDLE«

Laut IMAP-4-Protokoll muss ein Client beim Server aktiv nachfragen, um zu erfahren, ob es neue E-Mails gibt oder ob jemand vorhandene E-Mails gelöscht hat. Besser wäre es – weil anlassbezogen und deshalb Ressourcen-sparend –, wenn der Server dem Client einen Tipp gäbe, sobald neue E-Mails eintrudeln. Zwar darf der Server gelegentlich mit »EXISTS« antworten (etwa wenn sich die Größe der Mailbox verändert), aber der Client kann sich auf dieses Verhalten nicht verlassen und muss trotzdem nachfragen.

Liefert der Server »IDLE« [5] als Fähigkeit zurück, kann der Client ihm erlauben unaufgefordert Nachrichten über neue E-Mails zu schicken, während er sich im »IDLE« -Modus befindet. Um diesen zu aktivieren, schickt er einen »IDLE« -Befehl an den Server, der mit einer so genannten Fortsetzungsaufforderung (»+« ) antwortet. So lange der »IDLE« -Status besteht, darf der Server Nachrichten auch ohne Sequenznummer senden (untagged), etwa »EXISTS« oder »EXPUNGE« . Der Client selbst darf in dieser Zeit keine eigenen Befehle senden.

Das Master-und-Slave-Spielchen endet, sobald der Client ein »DONE« schickt. In diesem Fall sendet der Server noch ausstehende ungetaggte Zeilen, um dann mit einer Sequenznummer auf das »DONE« zu reagieren. Hat der Client das IDLE-Kommando nach einer Weile noch nicht mit »DONE« beendet, darf ihn der Server aus der Leitung werfen, so denn ein Timeout definiert ist. Daher empfiehlt das RFC, dass Clients nach 29 Minuten ein erneutes »IDLE« absetzen, um diesem Schicksal zu entgehen.

Vorgefiltert: »NOTIFY«

»IDLE« hat den Nachteil, dass es weder kontrolliert noch beschränkt, welche Befehle der Server sendet und wie er auf bestimmte Ereignisse reagiert. Da Idle zudem nur für eine einzelne Mailbox funktioniert, bauen Server und Client für jede weitere Mailboxabfrage eine weitere TCP-Verbindung auf. »NOTIFY« [6] setzt hingegen den Client ans Steuer. Es erweitert »IDLE« so, dass der Client bestimmt, von welchen Mailboxen er Nachrichten erhalten will. Das macht »NOTIFY« zu einem Multi-Mailbox-IDLE und verschlankt zugleich die Kommunikation.

Über »NOTIFY SET« legt der Client sowohl die Postfächer als auch die Art von Informationen fest, die er erhalten will. Der Server schickt dann – zusammen mit der Antwort »FETCH« – eine Reihe von Attributen an den Client, der nun zum passiven Beobachter wird. Der »NOTIFY« -Effekt hält an, bis der Client einen neuen »NOTIFY« -Befehl absetzt oder eine Seite die IMAP-Verbindung kappt.

Da einige mobile Clients lediglich Updates für E-Mails wünschen, die ein bestimmtes Suchmuster erfüllen, definiert das »NOTIFY« -RFC zugleich zusätzliche Attribute für die »UPDATE« -Option, die in diesem Fall greifen.

Voll synchron: »QRESYNC«

Die Erweiterung »QRESYNC« [7] resynchronisiert fix die Mailboxen der Anwender. Es handelt sich um eine Erweiterung des »CONDSTORE« -Kommandos. Dies wiederum überprüft ein Postfach auf Statusänderungen, die auftreten, wenn ein Nutzer verschiedene E-Mail-Clients verwendet oder mehrere Nutzer sich eine Mailbox teilen. Ändert der Nutzer von Client A den Status einer E-Mail auf “ungelesen”, soll das auch Client B bemerken, der dafür jedoch die Mailbox erneut durchforsten muss (Resync).

Zwar entdeckt »CONDSTORE« solche Änderungen und löst Konflikte beim zeitgleichen Zugriff mehrerer Clients auf, doch müssen Thunderbird & Co. in diesem Fall noch die Kommandos »UID FETCH« und »UID SEARCH« absetzen. »QRESYNC« erlaubt hingegen einen Neuabgleich samt Aufspüren gelöschter Dateien in einem Abwasch. Über die dabei eingeführte Antwort »VANISHED« (die »EXPUNGED« ersetzt) lassen sich gelöschte E-Mails effizienter entdecken.

Der Client-seitige Einsatz des »SELECT« -Kommandos erspart konkurrierende Verbindungen zum Server, die nur bestehen, um solche Abgleiche zu verhindern. Von »QRESYNC« profitieren besonders Mobilgeräte, da sie ihre Daten aufgrund schlechter Netzabdeckungen öfter neu holen müssen. Kein Wunder, dass diese Erweiterung zu den anfangs erwähnten Lemonade-Extensions gehört.

Der Server muss jedoch, um »QRESYNC« zu verwenden, auch ein »ENABLE« [8] als Fähigkeit zurückliefern. Die gleichnamige Erweiterung erlaubt es den Clients, explizit eine bestimmte Fähigkeit zu aktivieren. Im Falle von »QRESYNC« verlangt das RFC von den Clients, dass diese zuvor ein gezieltes »ENABLE QRESYNC« an den Server schicken.

In Bewegung: »MOVE«

Bevor die IETF in einem hilfreichen RFC [9] die beiden Anweisungen »MOVE« und »UID MOVE« einführte, die es erlauben, E-Mails zwischen Mailboxen zu verschieben, gab es nur die Möglichkeit, dieses Ziel durch Kombinieren verschiedener unabhängiger Befehle (»COPY« , »STORE« und »EXPUNGE« ) zu erreichen.

Dieses Verhalten erwies sich in den Implementierungen gleich aus mehreren Gründen als suboptimal: Falls zwischen den drei Schritten die Kommunikation abbricht, bleiben Verschiebeprozesse auf halbem Wege stecken. Dieser Effekt verwirrt zugleich die Nutzer, da ihre Clients die E-Mails in diesem Zwischenzustand trotzdem anzeigen. Zudem verschiebt der dritte Schritt unter Umständen in geteilten Postfächern nicht allein die ausgewählten Nachrichten, sondern auch unbeabsichtigt die zum Löschen markierten E-Mails Dritter.

»MOVE« löst diese Probleme, wobei »UID MOVE« die Mails auf Basis ihres Unique Identifiers verschiebt. Damit die Clients erfahren, ob ein Server dieses Feature kennt, muss dieser auf die »CAPABILITY« -Anfrage mit einem »MOVE« antworten.

Schnellsuche: »ESEARCH«

Der IMAP-Standard bringt mit »SEARCH« und »UID SEARCH« bereits zwei Suchfunktionen mit. Erstere durchforstet E-Mails auf Basis ihrer Message Sequence Number (MSN), die zweite verwendet den Unique Identifier der E-Mails. Ein Nachteil besteht jedoch darin, dass sich die Anzahl der zurückgegebenen Resultate nicht einschränken lässt.

Das richtet »ESEARCH« [10], das den Suchenden verschiedene Ergebnisoptionen (Result Options) an die Hand gibt. So lassen sich Suchergebnisse auf einen Minimal- und Maximalwert einschränken oder sie geben nur eine bestimmte Anzahl an Ergebnissen zurück. Auch das Auffinden aller Ergebnisse klappt zügiger, weil die Suche die Ergebnisse als Sequenz-Set zurückgibt, was kompakter ist und Bandbreite spart. Noch dazu lässt sich dieses Set in einem Folgekommando weiterverwenden.

Neu: »SORT« und »THREAD«

Die beiden Erweiterungen »SORT« und »THREAD« teilen sich ein gemeinsames RFC [11]. Es überrascht schon, dass zumindest »SORT« kein fester Teil des IMAP-Protokolls ist. Doch auch die Darstellung von E-Mails in Form von Threads ist nicht wirklich neu und letztlich nur ein Sortieralgorithmus. »SORT« und »THREAD« finden Server-seitig statt, was bei den Clients Ressourcen spart (Abbildung 3). Beide Extensions müssen die zu sortierenden Begriffe nach den Erfordernissen von »I18NLEVEL=1« bearbeiten, das Bestandteil eines RFC [12] ist, das den Umgang mit internationalen Zeichensätzen regelt.

Abbildung 3: Die Inhalte von Mailboxen lassen sich, wie hier in Thunderbird, auch gezielt herunterladen und notfalls lokal sichern und durchsuchen.

Während der Server seine Sortierfähigkeit durch ein »SORT« als Antwort beglaubigt, weist er bei der »THREAD« -Fähigkeit auch gleich den Threading-Algorithmus mit aus. Eine Antwort vom Server lautet dann beispielsweise »THREAD=ORDEREDSUBJECT« . Hierbei handelt es sich um den einfacheren von zwei verfügbaren Threading-Algorithmen, den das RFC nicht ohne Humor als “Threading für Arme” vorstellt. Der Algorithmus sortiert die E-Mails zunächst nach dem Thema ihrer Überschrift und im zweiten Schritt – bei gleichen Betreffzeilen – nach dem Versanddatum, wobei »ORDEREDSUBJECT« solche Nachrichten dann in Threads verwandelt.

Das gibt natürlich Probleme, wenn jemand auf einen Thread antwortet, aber den Betreff verändert. In diesem Fall kommt der Algorithmus »REFERENCES« zum Zuge. Er ist wesentlich komplexer aufgebaut als »ORDEREDSUBJECT« und benötigt sechs Hauptschritte, um einen Thread zu erstellen. Diese erläutert – in allen Details – das RFC 5256 auf den Seiten 8 bis 11.

Erreichbarer: »UIDPLUS«

Auch »UIDPLUS« [13] gehört – so steht es in den ersten Zeilen des RFC – zu jenen Erweiterungen, die sich besonders um schlecht erreichbare Clients kümmern und Teil der Lemonade-Spezifikation ist. Die Extension soll Zeitaufwand und Ressourcenverbrauch reduzieren.

Dazu definiert sie ein zusätzliches Kommando: »UID EXPUNGE« löscht Nachrichten, die sowohl das »\Delete« -Flag anzeigen als auch über Unique Identifier (UID) verfügen, die im Sequenz-Set der aktuell ausgewählten Mailbox auftauchen. Es erweist sich insbesondere dann als geeignet, wenn ein zeitweilig nicht verbundener Client sich erneut mit dem Server synchronisiert.

Kommt nun dank der »UIDPLUS« -Erweiterung »UID EXPUNGE« statt »EXPUNGE« zum Einsatz, löscht der Client Nachrichten anderer Nutzer, die während seiner Auszeit zur Löschung markiert wurden, nicht mehr aus Versehen. In diesem Fall tritt nämlich das zweite Kriterium nicht ein, weil die UIDs der löschbereiten Nachrichten nicht zur Mailbox gehören. Relevanz erhält das Verhalten etwa bei geteilten Postfächern oder Nutzern von mobilen und festen Clients.

Listig: »LIST-EXTENDED«

Traditionell zeigen die Befehle »LIST« und »LSUB« die Inhalte von Mailboxen an. Neue IMAP-Erweiterungen haben aber einen Bedarf an speziellen Formen von Listen geweckt. Da »LIST« und »LSUB« von Haus aus nicht erweiterbar sind, mussten Clients stets eine Reihe von Kommandos verwenden, um die Wünsche der Erweiterungen zu erfüllen. Das zog diese Aufrufe mit jeder neuen Extension weiter in die Länge.

Die »LIST-EXTENDED« -Erweiterung [14] behebt das Problem, indem sie das vorhandene »LIST« -Kommando derart verändert, dass es keine speziellen Befehle mehr benötigt, sondern sich um diverse Optionen und Suchmuster ergänzen lässt. Die neue Syntax ist rückwärtskompatibel und kommt nur dann zum Einsatz, wenn das erste oder zweite Wort nach dem Kommando mit einer Klammer beginnt oder wenn das »LIST« -Kommando über mehr als zwei Parameter verfügt. Andernfalls dient der traditionelle »LIST« -Befehl als Fallback.

Klarnamen: »NAMESPACE«

Da IMAP 4 keinen Standard-Namensraum definiert, haben sich zwei allgemeine Namespace-Konventionen herauskristallisiert: Im “Personal Mailbox”-Modell repräsentiert der Standard-Namespace nur die persönlichen Postfächer des Benutzers. Das “Complete Hierarchy”-Modell schließt hingegen – neben den benutzereigenen – auch alle anderen digitalen Briefkästen mit ein, auf welche die Nutzer Zugriff haben. Das Problem der Modelle besteht hauptsächlich in dem mit ihnen verbundenen Konfigurationsaufwand.

Das Kommando »NAMESPACE« [15] erlaubt es Clients, automatisch die vom Server festgelegten Präfixe für Mailboxen zu entdecken (Abbildung 4) und so zwischen persönlichen Postfächern, Mailboxen anderer Nutzer sowie geteilten Ordnern zu unterscheiden. So kann der Admin öffentlichen Posteingängen (etwa Mailinglisten) das Präfix »public« zuweisen, geteilte Mailboxen mit »shared« auszeichnen und den benutzereigenen Briefkästen ein »private« voranstellen. Das erspart nicht nur Handarbeit, die Postkästen eines Namespace lassen sich so auch an verschiedenen Orten im Netzwerk aufbewahren und dürfen unterschiedliche Formate verwenden, zum Beispiel »Maildir« und »Mbox« .

Abbildung 4: Dieser IMAP-4-Server zeigt beim Offenbaren seiner Fähigkeiten, dass er unter anderem die »NAMESPACE«-Erweiterung, aber auch »IDLE« und »ID« beherrscht.

Alles erlaubt: »ACL«

Die über »NAMESPACE« zugeordneten Mailboxen weisen oft auch unterschiedliche Zugriffsrechte auf. Access Control Lists für Postfächer und die Erweiterung »ACL« [16] erlauben es dem Admin, mit IMAP-Kommandos Rechte zu betrachten und zu verändern. Das zugehörige RFC von 1997 entpuppte sich jedoch als nicht ausreichend, weshalb das RFC 4314 [17] folgte, um neue Zugriffsrechte zu definieren und Klarheit in die Rechtesituation zu bringen.

Neben dem String »ACL« muss der Server beim Aufruf von »CAPABILITY« über »RIGHTS=« auch die Rechte nennen, die er unterstützt. Aktuell gibt es elf Standardrechte sowie zwei virtuelle Rechte (»d« und »c« ), die aus Kompatibilitätsgründen gegenüber dem RFC 2086 bestehen. Mögliche Kommandos in Verbindung mit dem RFC sind »SETACL« , »GETACL« , »DELETEACL« sowie »LISTRIGHTS« und »MYRIGHTS« .

ACL-Einträge setzen sich aus zwei Komponenten (Access Identifier, Rechte) zusammen und lassen sich konkreten Postfächern zuordnen. Der Access Identifier besteht üblicherweise aus dem Namen eines Benutzers (als UTF8-String), wie ihn auch »LOGIN« und »AUTHENTICATE« akzeptieren. Pro Nutzer darf es allerdings mehrere Identifier geben.

Zudem definiert das RFC einen Identifier namens »anyone« , der auf eine generalisierte Identität verweist, die auch anonyme Anmeldungen einschließt. Ist einem Identifier ein »-« vorangestellt, bekommt der zugehörige Benutzer die so zugeordneten Rechte aberkannt.

Während kleine Buchstaben die Rechte der Benutzer anzeigen, reserviert das RFC Ziffern für die Rechtevergabe im Rahmen von Server-Implementierungen: Postmaster dürfen in diesem Fall bestimmte Rechte grundsätzlich spendieren oder verweigern und so beispielsweise dafür sorgen, dass die Benutzer nur ihre eigenen Mailboxen verwalten.