Zum Hauptinhalt springen

2. Protokollübersicht (Protocol Overview)

Das IMAP4rev1-Protokoll setzt einen zuverlässigen Datenstrom voraus, wie er von TCP bereitgestellt wird. Wenn TCP verwendet wird, hört ein IMAP4rev1-Server auf Port 143.

2.2. Befehle und Antworten (Commands and Responses)​

Eine IMAP4rev1-Verbindung besteht aus der Einrichtung einer Client/Server-Netzwerkverbindung, einer initialen Begrüßung vom Server und Client/Server-Interaktionen. Diese Client/Server-Interaktionen bestehen aus einem Client-Befehl, Serverdaten und einer Server-Abschluss-Ergebnisantwort.

Alle vom Client und Server übertragenen Interaktionen sind in Form von Zeilen, das heißt Zeichenketten, die mit einem CRLF enden. Der Protokollempfänger eines IMAP4rev1-Clients oder -Servers liest entweder eine Zeile oder eine Sequenz von Oktetten mit bekannter Anzahl, gefolgt von einer Zeile.

2.2.1. Client-Protokollsender und Server-Protokollempfänger (Client Protocol Sender and Server Protocol Receiver)​

Der Client-Befehl beginnt eine Operation. Jeder Client-Befehl wird mit einem Identifikator (typischerweise eine kurze alphanumerische Zeichenkette, z.B. A0001, A0002, usw.) präfixiert, der als „Tag" bezeichnet wird. Ein unterschiedlicher Tag wird vom Client für jeden Befehl generiert.

Clients müssen (MUST) die in dieser Spezifikation beschriebene Syntax strikt befolgen. Es ist ein Syntaxfehler, einen Befehl mit fehlenden oder überflüssigen Leerzeichen oder Argumenten zu senden.

Es gibt zwei Fälle, in denen eine Zeile vom Client keinen vollständigen Befehl darstellt. In einem Fall wird ein Befehlsargument mit einer Oktettanzahl zitiert (siehe Beschreibung des Literals in String unter Datenformate); im anderen Fall erfordern die Befehlsargumente Server-Feedback (siehe AUTHENTICATE-Befehl). In beiden Fällen sendet der Server eine Befehlsfortsetzungsanforderungsantwort, wenn er für die Oktette (falls zutreffend) und den Rest des Befehls bereit ist. Diese Antwort wird mit dem Token „+" präfixiert.

Hinweis: Wenn der Server stattdessen einen Fehler im Befehl erkennt, sendet er eine BAD-Abschlussantwort mit einem Tag, das dem Befehl entspricht (wie unten beschrieben), um den Befehl abzulehnen und zu verhindern, dass der Client mehr vom Befehl sendet.

Es ist auch möglich, dass der Server eine Abschlussantwort für einen anderen Befehl sendet (wenn mehrere Befehle laufen), oder ungetaggte Daten. In beiden Fällen ist die Befehlsfortsetzungsanforderung noch ausstehend; der Client führt die entsprechende Aktion für die Antwort aus und liest eine weitere Antwort vom Server. In allen Fällen muss (MUST) der Client einen vollständigen Befehl senden (einschließlich des Empfangs aller Befehlsfortsetzungsanforderungsantworten und Befehlsfortsetzungen für den Befehl), bevor er einen neuen Befehl initiiert.

Der Protokollempfänger eines IMAP4rev1-Servers liest eine Befehlszeile vom Client, analysiert den Befehl und seine Argumente und überträgt Serverdaten und eine Server-Befehlsabschluss-Ergebnisantwort.

2.2.2. Server-Protokollsender und Client-Protokollempfänger (Server Protocol Sender and Client Protocol Receiver)​

Vom Server an den Client übertragene Daten und Statusantworten, die nicht den Befehlsabschluss anzeigen, werden mit dem Token „*" präfixiert und werden ungetaggte Antworten (untagged responses) genannt.

Serverdaten können (MAY) als Ergebnis eines Client-Befehls gesendet werden oder können (MAY) einseitig vom Server gesendet werden. Es gibt keinen syntaktischen Unterschied zwischen Serverdaten, die aus einem bestimmten Befehl resultierten, und Serverdaten, die einseitig gesendet wurden.

Die Server-Abschluss-Ergebnisantwort zeigt den Erfolg oder Misserfolg der Operation an. Sie wird mit demselben Tag getaggt wie der Client-Befehl, der die Operation begonnen hat. Wenn also mehr als ein Befehl läuft, identifiziert der Tag in einer Server-Abschlussantwort den Befehl, auf den sich die Antwort bezieht. Es gibt drei mögliche Server-Abschlussantworten: OK (zeigt Erfolg an), NO (zeigt Misserfolg an) oder BAD (zeigt einen Protokollfehler wie unbekannten Befehl oder Befehlssyntaxfehler an).

Server sollten (SHOULD) die in dieser Spezifikation beschriebene Syntax strikt durchsetzen. Jeder Client-Befehl mit einem Protokollsyntaxfehler, einschließlich (aber nicht beschränkt auf) fehlende oder überflüssige Leerzeichen oder Argumente, sollte (SHOULD) mit einer BAD-Abschlussantwort abgelehnt werden.

2.3. Nachrichtenattribute (Message Attributes)​

Zusätzlich zu den Nachrichtenattributen (Message Attributes) unterstützt IMAP mehrere serverdefinierte Datenelemente. Diese Serverdatenelemente können je nach Serverimplementierung variieren und sind erweiterbar.

2.3.1. Nachrichtennummern (Message Numbers)​

Nachrichten werden entweder durch eine Nachrichtensequenznummer (Message Sequence Number) oder einen eindeutigen Identifikator (Unique Identifier, UID) identifiziert.

2.3.1.1. Eindeutiger Identifikator (UID) Nachrichtenattribut (Unique Identifier (UID) Message Attribute)​

Der eindeutige Identifikator (Unique Identifier, UID) ist ein 32-Bit-Wert, der einer Nachricht in einer Mailbox zugeordnet ist. Dieser eindeutige Identifikator muss (MUST) in der Mailbox über die Zeit hinweg eindeutig sein. UIDs ändern sich nicht, wenn Nachrichten gelöscht werden.

UIDs müssen (MUST) streng aufsteigend sein.

Jedes Mal, wenn eine Nachricht zur Mailbox hinzugefügt wird, wird ihr eine UID zugewiesen, die größer ist als jede zuvor verwendete UID, auch wenn frühere UIDs nicht mehr verwendet werden (d.h. wenn Nachrichten gelöscht wurden).

Die Eindeutigkeitsanforderung für UIDs erfordert, dass der Server einen Datensatz jeder zuvor verwendeten UID führt und sie nicht wiederverwendet. Der einfachste Weg, die Eindeutigkeit von UIDs zu garantieren, besteht darin, einfach UIDs monoton zuzuweisen, d.h. jeder neuen ankommenden Nachricht eine UID zuzuweisen, die um eins größer ist als die der vorherigen Nachricht.

2.3.1.2. Nachrichtensequenznummer-Nachrichtenattribut (Message Sequence Number Message Attribute)​

Die Nachrichtensequenznummer (Message Sequence Number) ist die relative Position einer Nachricht in der Mailbox. Nachrichtensequenznummern sind aufeinanderfolgende ganze Zahlen von 1 bis zur Gesamtzahl der Nachrichten in der Mailbox.

Nachrichtensequenznummern können sich ändern, wenn sich der Inhalt der Mailbox ändert. Insbesondere wenn Nachrichten gelöscht oder hinzugefügt werden, ändern sich alle Nachrichtensequenznummern nach der betroffenen Nachrichtensequenznummer.

Nachrichtensequenznummern sind nur während der Sitzung gültig. Wenn die Sitzung endet, verlieren die Nachrichtensequenznummern ihre Bedeutung.

2.3.2. Flags-Nachrichtenattribut (Flags Message Attribute)​

Flags sind Schlüsselwörter oder Token, die einer Nachricht zugeordnet sind. Es gibt zwei Arten von Flags: System-Flags und Schlüsselwörter.

System-Flags sind Flags mit besonderer Bedeutung, die mit dem Backslash-Zeichen („") beginnen. System-Flags sind:

  • \Seen - Die Nachricht wurde gelesen
  • \Answered - Die Nachricht wurde beantwortet
  • \Flagged - Die Nachricht ist markiert
  • \Deleted - Die Nachricht ist zum Löschen markiert
  • \Draft - Die Nachricht ist ein Entwurf
  • \Recent - Die Nachricht ist kürzlich angekommen (diese Sitzung)

Schlüsselwörter sind Flags, die vom Server oder Client definiert werden. Schlüsselwörter dürfen nicht (MUST NOT) mit einem Backslash beginnen.

2.3.3. Internes Datum-Nachrichtenattribut (Internal Date Message Attribute)​

Das interne Datum (Internal Date) ist das Datum und die Uhrzeit, zu der die Nachricht in der Mailbox ankam. Dies kann sich vom Date:-Header-Feld der Nachricht unterscheiden.

2.3.4. [RFC-2822] Größen-Nachrichtenattribut ([RFC-2822] Size Message Attribute)​

Die [RFC-2822]-Größe ist die Größe der Nachricht in Oktetten.

2.3.5. Envelope-Struktur-Nachrichtenattribut (Envelope Structure Message Attribute)​

Die Envelope-Struktur (Envelope Structure) sind die vom Nachrichten-Header abgeleiteten Informationen.

2.3.6. Body-Struktur-Nachrichtenattribut (Body Structure Message Attribute)​

Die Body-Struktur (Body Structure) sind Informationen über die MIME-Struktur der Nachricht.

2.4. Nachrichtentexte (Message Texts)​

Nachrichtentexte (Message Texts) umfassen den vollständigen Header und den Body der Nachricht. Nachrichtentexte müssen (MUST) im [RFC-2822]-Format sein.

Letztes Update am