2. Protokollübersicht (Protocol Overview)

2.1 Link-Ebene (Link Level)

Das IMAP4rev2-Protokoll setzt einen zuverlässigen Datenstrom voraus, wie er von TCP bereitgestellt wird. Wenn TCP verwendet wird, lauscht ein IMAP4rev2-Server auf Port 143 (Klartextport) oder Port 993 (Impliziter TLS-Port).

2.2 Befehle und Antworten (Commands and Responses)

Eine IMAP4rev2-Verbindung (Connection) besteht aus der Einrichtung einer Client/Server-Netzwerkverbindung, einer anfänglichen Begrüßung vom Server und Client/Server-Interaktionen. Diese Client/Server-Interaktionen bestehen aus einem Client-Befehl (Client Command), Serverdaten (Server Data) und einer Server-Abschluss-Ergebnisantwort (Server Completion Result Response).

Alle vom Client und Server übertragenen Interaktionen erfolgen in Form von Zeilen, d.h. Zeichenketten, die mit CRLF enden. Der Protokollempfänger eines IMAP4rev2-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. Jedem Client-Befehl ist ein Identifikator vorangestellt (typischerweise eine kurze alphanumerische Zeichenkette, z.B. A0001, A0002 usw.), der als "Tag" bezeichnet wird. Der Client generiert für jeden Befehl ein anderes Tag. Formaler ausgedrückt: Der Client sollte (sollte) für jeden Befehl ein eindeutiges Tag generieren, aber ein Server muss (muss) die Wiederverwendung von Tags akzeptieren.

Clients müssen (müssen) der in dieser Spezifikation beschriebenen Syntax streng folgen. 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 Oktettzahl zitiert (siehe die Beschreibung von Literal in Abschnitt 4.3); im anderen Fall erfordern die Befehlsargumente Server-Feedback (siehe den AUTHENTICATE-Befehl in Abschnitt 6.2.2). In beiden Fällen sendet der Server eine Befehlsfortsetzungsanforderungsantwort (Command Continuation Request Response), wenn er für die Oktette (falls zutreffend) und den Rest des Befehls bereit ist. Diese Antwort hat das Token "+" als Präfix.

Hinweis: Wenn der Server stattdessen einen Fehler im Befehl erkannt hat, 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 nicht getaggte Daten (Untagged Data). In beiden Fällen ist die Befehlsfortsetzungsanforderung noch ausstehend; der Client ergreift die geeignete Aktion für die Antwort und liest eine weitere Antwort vom Server. In allen Fällen muss (muss) der Client einen vollständigen Befehl senden (einschließlich des Empfangs aller Befehlsfortsetzungsanforderungsantworten und des Sendens von Befehlsfortsetzungen für den Befehl), bevor er einen neuen Befehl initiiert.

Der Protokollempfänger eines IMAP4rev2-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 keine Befehlsvollständigung anzeigen, haben das Token "*" als Präfix und werden als nicht getaggte Antworten (Untagged Responses) bezeichnet.

Serverdaten können (kann) als Ergebnis eines Client-Befehls gesendet werden oder können (kann) 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 wie der Client-Befehl getaggt, der die Operation begonnen hat. Wenn also mehr als ein Befehl läuft, identifiziert das 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 Fehler an) oder BAD (zeigt einen Protokollfehler an, wie z.B. einen nicht erkannten Befehl oder einen Befehlssyntaxfehler).

Antworten und Daten, die vom Server an den Client gesendet werden, dürfen (darf nicht) keine Befehls-Tags verwenden, die nicht in der formalen Syntax (Formal Syntax) beschrieben sind.

Die Server-Abschluss-Ergebnisantwort kann (kann) einen optionalen Antwortcode (Response Code) enthalten, der zusätzliche Informationen über den Abschlussstatus bereitstellt. Antwortcodes bestehen aus Daten, die in eckige Klammern ([...]) eingeschlossen sind. Clients, die einen bestimmten Antwortcode nicht verstehen, müssen (müssen) in der Lage sein, diesen Antwortcode ohne nachteilige Auswirkungen zu akzeptieren. Dies bedeutet, dass jeder Antwortcode sicher zu jeder Abschlussantwort hinzugefügt werden kann, ohne Probleme für ältere Clients zu verursachen.

Der Protokollempfänger eines IMAP4rev2-Clients liest Antworten vom Server und verarbeitet sie entsprechend.

---

2.3 Nachrichtenattribute (Message Attributes)

Zusätzlich zu Nachrichtentexten (Message Texts) sind mehrere Attribute (Attributes) mit jeder Nachricht verbunden. Diese Attribute können entweder über die Nachrichtensequenznummer (Message Sequence Number) oder die eindeutige Kennung (Unique Identifier, UID) abgerufen werden.

2.3.1 Nachrichtennummern (Message Numbers)

Nachrichten haben zwei Formen der Identifikation: Nachrichtensequenznummer und eindeutige Kennung (UID).

2.3.1.1 Eindeutige Kennung (UID) Nachrichtenattribut (Unique Identifier (UID) Message Attribute)

Eine eindeutige Kennung (Unique Identifier, UID) ist ein 32-Bit-Wert ohne Vorzeichen ungleich Null, der einer Nachricht zugeordnet ist. Der Hauptzweck der UID besteht darin, eine Kennung für die Nachricht bereitzustellen, die über mehrere IMAP-Sitzungen (Sessions) hinweg bestehen bleibt. Der Server muss (muss) sicherstellen, dass jeder Nachricht im Postfach eine eindeutige UID zugewiesen wird.

Im Gegensatz zu Nachrichtensequenznummern steigt die UID einer Nachricht streng an (aber nicht notwendigerweise aufeinanderfolgend), auch während der Sitzung. Der Server muss (muss) sicherstellen, dass wenn eine neue Nachricht zum Postfach hinzugefügt wird, die UID der neuen Nachricht größer ist als die UID jeder vorhandenen Nachricht im Postfach.

Eine Ausnahme von der Einzigartigkeit und dem strengen Anstieg der UID ist der UID-Gültigkeitswert (UIDVALIDITY Value). Der UIDVALIDITY-Wert ist mit dem Postfach verbunden und wird mit dem Postfach zurückgegeben (z.B. in SELECT- und EXAMINE-Antworten). Der UIDVALIDITY-Wert wird verwendet, um zu erkennen, ob die UIDs im Postfach zurückgesetzt wurden.

Der UIDVALIDITY-Wert muss (muss) größer als Null sein. Der Hauptzweck des UIDVALIDITY-Werts besteht darin, in Fällen, in denen die UID-Persistenz nicht aufrechterhalten werden kann, eine Garantie zu bieten. Beispielsweise muss (muss) der Server in den folgenden Fällen in zukünftigen Sitzungen einen anderen UIDVALIDITY-Wert verwenden:

1. Einem Postfach muss (muss) ein neuer UIDVALIDITY-Wert zugewiesen werden, wenn Nachrichten, die vorhandenen UIDs entsprechen, im Postfach nicht mehr gültig sind. Zum Beispiel, wenn das Postfach gelöscht und neu erstellt wird.

2. Zur Klarstellung: Wenn ein altes Postfach gelöscht und ein neues Postfach mit demselben Namen erstellt wird, muss (muss) das neue Postfach einen anderen UIDVALIDITY-Wert als das alte Postfach haben.

3. Ein Postfach darf (darf nicht) von einem IMAP-Server zu einem anderen IMAP-Server verschoben werden, ohne seinen UIDVALIDITY-Wert zu ändern, es sei denn, beide IMAP-Server bieten Zugriff auf ein gemeinsames Postfach-Repository. Sonderfall: Der Server kann (kann) ein Postfach mit einem anderen UIDVALIDITY-Wert einem anderen Benutzer neu zuweisen, während derselbe Name beibehalten wird.

4. Die Kombination aus Postfachname, UIDVALIDITY und UID muss (muss) für immer auf eine einzelne unveränderliche (oder gelöschte) Nachricht auf diesem Server verweisen. Insbesondere dürfen (dürfen) sich das interne Datum (Internal Date), RFC822.SIZE, die Hülle (Envelope), die Körperstruktur (Body Structure) und die Nachrichtentexte (alle BODY[...]-Abrufdatenelemente) niemals ändern. Dies schließt keine Nachrichtensequenznummern ein, noch Attribute, die durch einen STORE-Befehl gesetzt werden können (wie FLAGS). Wenn eine Nachricht gelöscht wird, darf (darf nicht) ihre UID unter demselben UIDVALIDITY-Wert nicht wiederverwendet werden.

2.3.1.2 Nachrichtensequenznummer-Nachrichtenattribut (Message Sequence Number Message Attribute)

Eine Nachrichtensequenznummer (Message Sequence Number) ist eine relative Position von 1 bis zur Anzahl der Nachrichten im Postfach. Diese Position muss (muss) nach aufsteigenden eindeutigen Kennungen geordnet sein. Wenn jede neue Nachricht hinzugefügt wird, wird ihr eine Nachrichtensequenznummer zugewiesen, die um 1 höher ist als die Anzahl der Nachrichten im Postfach vor dem Hinzufügen dieser neuen Nachricht.

Nachrichtensequenznummern können während der Sitzung neu zugewiesen werden. Wenn beispielsweise eine Nachricht dauerhaft aus dem Postfach entfernt (expunged) wird, wird die Nachrichtensequenznummer aller nachfolgenden Nachrichten dekrementiert. Die Anzahl der Nachrichten im Postfach wird ebenfalls dekrementiert. Ebenso kann einer neuen Nachricht eine Nachrichtensequenznummer zugewiesen werden, die zuvor von einer anderen Nachricht vor einer Löschung gehalten wurde.

Zusätzlich zum Zugriff auf Nachrichten über ihre relative Position im Postfach können Nachrichtensequenznummern in mathematischen Berechnungen verwendet werden. Wenn beispielsweise ein nicht getaggtes "11 EXISTS" empfangen wird und zuvor ein nicht getaggtes "8 EXISTS" empfangen wurde, sind drei neue Nachrichten mit den Nachrichtensequenznummern 9, 10 und 11 angekommen. Als weiteres Beispiel: Wenn Nachricht 287 in einem Postfach mit 523 Nachrichten die UID 12345 hat, gibt es genau 286 Nachrichten mit niedrigeren UIDs und 236 Nachrichten mit höheren UIDs.

2.3.2 Flags-Nachrichtenattribut (Flags Message Attribute)

Eine Nachricht hat eine Liste von null oder mehr benannten Token (Named Tokens), die als "Flags" bezeichnet werden, die mit ihr verbunden sind. Ein Flag wird durch Hinzufügen zu dieser Liste gesetzt und durch Entfernen gelöscht. Es gibt zwei Arten von Flags in IMAP4rev2: Systemflags (System Flags) und Schlüsselwörter (Keywords). Ein Flag beider Typen kann permanent oder nur für die Sitzung sein.

Ein Systemflag ist ein Flagname, der in dieser Spezifikation vordefiniert ist und mit "" beginnt. Bestimmte Systemflags (\Deleted und \Seen) haben spezielle Semantiken, die an anderer Stelle in diesem Dokument beschrieben werden. Die derzeit definierten Systemflags sind:

• \Seen - Nachricht wurde gelesen
• \Answered - Nachricht wurde beantwortet
• \Flagged - Nachricht ist für dringende/besondere Aufmerksamkeit "markiert"
• \Deleted - Nachricht ist zur späteren Entfernung durch EXPUNGE "gelöscht"
• \Draft - Nachricht hat die Erstellung nicht abgeschlossen (als Entwurf markiert)
• \Recent - Dieses Flag wurde in IMAP4rev1 verwendet und ist jetzt veraltet

Ein Schlüsselwort (Keyword) wird durch die Serverimplementierung definiert. Schlüsselwörter beginnen nicht mit "". Server können (können) dem Client erlauben, neue Schlüsselwörter im Postfach zu definieren (siehe die Beschreibung des PERMANENTFLAGS-Antwortcodes für weitere Informationen). Einige Schlüsselwörter, die mit "$" beginnen, sind ebenfalls in dieser Spezifikation definiert.

Dieses Dokument definiert mehrere Schlüsselwörter, die ursprünglich nicht in [RFC3501] definiert waren, aber von Client-Implementierungen als nützlich befunden wurden. Diese Schlüsselwörter sollten (sollten) von Serverimplementierungen unterstützt werden (in SEARCH erlaubt und in APPEND-, COPY- und MOVE-Befehlen erlaubt und beibehalten):

$Forwarded - Nachricht wurde an eine andere E-Mail-Adresse weitergeleitet

$MDNSent - Nachrichtsdispositionsbenachrichtigung (Message Disposition Notification) wurde gesendet

$Junk - Nachricht enthält Junk/Spam

$NotJunk - Nachricht enthält keinen Junk

$Phishing - Nachricht ist wahrscheinlich eine Phishing-E-Mail

$Junk und $NotJunk schließen sich gegenseitig aus. Wenn mehrere davon für eine Nachricht gesetzt sind, muss (muss) der Client sie so behandeln, als wäre keine gesetzt, und sollte (sollte) beide auf dem IMAP-Server deaktivieren.

Andere registrierte Schlüsselwörter finden Sie in der "IMAP and JMAP Keywords"-Registrierung [IMAP-KEYWORDS-REG]. Neue Schlüsselwörter sollten (sollten) in dieser Registrierung unter Verwendung des in [RFC5788] spezifizierten Verfahrens registriert werden.

Ein Flag kann auf Flag-Basis permanent oder nur für die Sitzung sein. Permanente Flags (Permanent Flags) sind solche, die der Client dauerhaft zu den Nachrichtenflags hinzufügen oder daraus entfernen kann; das heißt, gleichzeitige und nachfolgende Sitzungen werden jede Änderung an permanenten Flags sehen. Änderungen an Sitzungsflags (Session Flags) sind nur in dieser Sitzung gültig.

2.3.3 Internes Datum-Nachrichtenattribut (Internal Date Message Attribute)

Ein internes Datum (Internal Date) Nachrichtenattribut ist das interne Datum und die Uhrzeit der Nachricht auf dem Server. Dies ist nicht das Datum und die Uhrzeit im [RFC5322]-Header, sondern ein Datum und eine Uhrzeit, die widerspiegeln, wann die Nachricht empfangen wurde. Bei über [SMTP] zugestellten Nachrichten ist dies das Datum und die Uhrzeit der endgültigen Zustellung der Nachricht, wie in [SMTP] definiert. Bei Nachrichten, die durch die IMAP4rev2-COPY- oder APPEND-Befehle erstellt wurden, ist dies das von diesen Befehlen angegebene Datum und die Uhrzeit.

2.3.4 RFC822.SIZE-Nachrichtenattribut (RFC822.SIZE Message Attribute)

RFC822.SIZE ist die Anzahl der Oktette in der Nachricht, wenn die Nachricht im [RFC5322]-Format ausgedrückt wird. Diese Größe sollte (sollte) mit dem Ergebnis eines "FETCH BODY[]"-Befehls übereinstimmen. Wenn die Nachricht intern in einem anderen Format gespeichert ist, berechnet der Server die Größe und speichert sie oft für die spätere Verwendung, um die Notwendigkeit einer Neuberechnung zu vermeiden.

2.3.5 Hüllenstruktur-Nachrichtenattribut (Envelope Structure Message Attribute)

Eine Hüllenstruktur (Envelope Structure) ist eine analysierte Darstellung des [RFC5322]-Headers der Nachricht. Beachten Sie, dass die IMAP-Hüllenstruktur nicht dasselbe ist wie eine [SMTP]-Hülle.

2.3.6 Körperstruktur-Nachrichtenattribut (Body Structure Message Attribute)

Eine Körperstruktur (Body Structure) ist eine analysierte Darstellung der [MIME-IMB]-Körperstrukturinformationen der Nachricht.

2.4 Nachrichtentexte (Message Texts)

Zusätzlich zur Möglichkeit, den vollständigen [RFC5322]-Text einer Nachricht abzurufen, ermöglicht IMAP4rev2 das Abrufen von Teilen des vollständigen Nachrichtentexts. Insbesondere ist es möglich, den [RFC5322]-Nachrichtenheader (Message Header), den [RFC5322]-Nachrichtenkörper (Message Body), einen [MIME-IMB]-Körperteil (Body Part) oder einen [MIME-IMB]-Header abzurufen.

---