1. Wie man dieses Dokument liest (How to Read This Document)
1.1 Organisation dieses Dokuments (Organization of This Document)
Dieses Dokument ist aus der Sicht des Implementierers eines IMAP4rev2-Clients oder -Servers geschrieben. Über die Protokollübersicht in Abschnitt 2 hinaus ist es nicht für jemanden optimiert, der versucht, die Funktionsweise des Protokolls zu verstehen. Das Material in den Abschnitten 3, 4 und 5 liefert den allgemeinen Kontext und die Definitionen, mit denen IMAP4rev2 arbeitet.
Die Abschnitte 6, 7 und 9 beschreiben jeweils die IMAP-Befehle (Commands), Antworten (Responses) und Syntax. Die Beziehungen zwischen diesen sind so, dass es fast unmöglich ist, sie getrennt zu verstehen. Versuchen Sie insbesondere nicht, die Befehlssyntax allein aus dem Befehlsabschnitt abzuleiten; beziehen Sie sich stattdessen auf die „Formale Syntax" (Formal Syntax) (Abschnitt 9).
1.2 In diesem Dokument verwendete Konventionen (Conventions Used in This Document)
„Konventionen" sind grundlegende Prinzipien oder Verfahren. Dokumentkonventionen werden in diesem Abschnitt vermerkt.
In Beispielen zeigen „C:" und „S:" jeweils vom Client und Server gesendete Zeilen an. Beachten Sie, dass jede Zeile das abschließende CRLF enthält.
Die Schlüsselwörter „MUST", „MUST NOT", „REQUIRED", „SHALL", „SHALL NOT", „SHOULD", „SHOULD NOT", „RECOMMENDED", „NOT RECOMMENDED", „MAY" und „OPTIONAL" in diesem Dokument sind (müssen) wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.
Schlüsselwort-Entsprechungen:
- MUST = muss
- MUST NOT = darf nicht
- REQUIRED = erforderlich
- SHALL = muss
- SHALL NOT = darf nicht
- SHOULD = sollte
- SHOULD NOT = sollte nicht
- RECOMMENDED = empfohlen
- NOT RECOMMENDED = nicht empfohlen
- MAY = kann
- OPTIONAL = optional
Das Wort „can" (nicht „may") wird verwendet, um sich auf einen möglichen Umstand oder eine Situation zu beziehen, im Gegensatz zu einer optionalen Funktion des Protokolls.
„User" (Benutzer) wird verwendet, um sich auf einen menschlichen Benutzer zu beziehen, während „Client" sich auf die vom Benutzer ausgeführte Software bezieht.
„Connection" (Verbindung) bezieht sich auf die gesamte Sequenz der Client/Server-Interaktion von der anfänglichen Einrichtung der Netzwerkverbindung bis zu ihrer Beendigung.
„Session" (Sitzung) bezieht sich auf die Sequenz der Client/Server-Interaktion von dem Zeitpunkt, an dem ein Postfach ausgewählt wird (SELECT- oder EXAMINE-Befehl), bis zu dem Zeitpunkt, an dem die Auswahl endet (SELECT oder EXAMINE eines anderen Postfachs, CLOSE-Befehl, UNSELECT-Befehl oder Verbindungsbeendigung).
Der Begriff „Implicit TLS" bezieht sich auf die automatische Aushandlung von TLS, wann immer eine TCP-Verbindung auf einem bestimmten TCP-Port hergestellt wird, der von diesem Server ausschließlich für TLS-Verbindungen verwendet wird. Der Begriff „Implicit TLS" soll einen Kontrast zur Verwendung des STARTTLS-Befehls in IMAP bilden, der vom Client und Server verwendet wird, um TLS explizit über eine etablierte Klartext-TCP-Verbindung auszuhandeln.
Zeichen sind 8-Bit-UTF-8 (wovon 7-Bit-US-ASCII eine Teilmenge ist), sofern nicht anders angegeben. Andere Zeichensätze werden unter Verwendung eines „CHARSET" angegeben, wie in [MIME-IMT] beschrieben und in [CHARSET] definiert. CHARSETs haben wichtige zusätzliche Semantiken zusätzlich zur Definition eines Zeichensatzes; weitere Details finden Sie in diesen Dokumenten.
Es gibt mehrere Protokollkonventionen (Protocol Conventions) in IMAP. Diese beziehen sich auf Aspekte der Spezifikation, die nicht streng Teil des IMAP-Protokolls sind, aber allgemein akzeptierte Praxis widerspiegeln. Implementierungen müssen (müssen) sich dieser Konventionen bewusst sein und Konflikte vermeiden, unabhängig davon, ob sie die Konvention implementieren oder nicht. Beispielsweise darf (darf nicht) „&" nicht als Hierarchietrennzeichen (Hierarchy Delimiter) verwendet werden, da es mit der internationalen Benennungskonvention für Postfächer (Mailbox International Naming Convention) in Konflikt steht, und andere Verwendungen von „&" in Postfachnamen sind ebenfalls betroffen.
1.3 Besondere Hinweise für Implementierer (Special Notes to Implementors)
Implementierern des IMAP-Protokolls wird dringend empfohlen (empfohlen), das IMAP-Implementierungsempfehlungsdokument [IMAP-IMPLEMENTATION] in Verbindung mit diesem Dokument zu lesen, um die Feinheiten dieses Protokolls und den besten Weg zum Aufbau eines interoperablen Produkts zu verstehen.
IMAP4rev2 ist so konzipiert, dass es aufwärtskompatibel mit den Protokollen IMAP4rev1 [RFC3501], IMAP2 [IMAP2] und dem unveröffentlichten IMAP2bis [IMAP2BIS] ist. IMAP4rev2 ist weitgehend kompatibel mit dem in RFC 3501 beschriebenen IMAP4rev1-Protokoll und dem in [RFC1730] beschriebenen IMAP4-Protokoll; die Ausnahme sind bestimmte in [RFC1730] und [RFC3501] hinzugefügte Funktionen, die sich als problematisch erwiesen und anschließend entfernt oder durch bessere Alternativen ersetzt wurden.
Andere Kompatibilitätsprobleme mit IMAP2bis, der häufigsten Variante des früheren Protokolls, werden in [IMAP-COMPAT] erörtert. Eine vollständige Diskussion von Kompatibilitätsproblemen mit seltenen Varianten von [IMAP2] findet sich in [IMAP-HISTORICAL]; dieses Dokument ist hauptsächlich von historischem Interesse.