Zusammenfassung

  • RFC 3516 ließ den IMAP-Server das MIME-Content-Transfer-Encoding entfernen und den dekodierten Abschnitt per BINARY liefern. literal8 konnte dabei auch NUL tragen. Diese Ausgabe war eine transformierte Sicht, nicht die ursprüngliche Nachrichtenserialisierung.
  • Größe und Teilbereichskoordinaten bezogen sich auf dekodierte Daten. Speicherung, FETCH BODY, CRLF, kodierte Header und kryptografisch erfasste Bytes behielten eigene Grenzen.

Base64 machte beliebige Daten auf Mailwegen transportierbar, die nicht alle Oktette unverändert beförderten. Beim IMAP-Abruf musste ein Client dadurch unter Umständen die größere Darstellung laden, nur um sie sofort wieder zu dekodieren. RFC 3516 nannte langsame Funkverbindungen und Streaming-Medien als Fälle, in denen der Aufwand spürbar wurde.

Die im April 2003 veröffentlichte Erweiterung verschob diese Arbeit auf den Server. Wer BINARY in CAPABILITY meldete, konnte FETCH BINARY beantworten, das Transfer-Encoding des ausgewählten MIME-Abschnitts entfernen und das Ergebnis senden. Weniger Übertragungsvolumen bedeutete jedoch nicht, dass der Client die ursprünglichen Nachrichtenbytes erhielt.

Jeder IMAP-Body-Abschnitt besitzt ein Content-Transfer-Encoding, ausdrücklich oder implizit als 7bit. MIME verbindet damit einen Dekodieralgorithmus und den Wertebereich der dekodierten Daten. Base64 und quoted-printable verändern die Darstellung. Selbst eine Identitätstransformation kann einen Bereich bezeichnen, den das ursprüngliche IMAP-Literal nicht ausdrückt, etwa wenn NUL vorkommt.

Der Server hatte deshalb zwei logische Aufgaben. Zunächst führte er die CTE-Dekodierung aus. Danach bestimmte er den Bereich des Ergebnisses. Eine Oktettfolge allein entschied noch nicht, welches Protokollelement sie tragen durfte.

Für den erweiterten Bereich führte RFC 3516 literal8 ein. Nach Tilde und Längenangabe dürfen beliebige Oktette einschließlich NUL folgen. Bleiben die Daten achtbittig und ohne NUL, sollte der Server stattdessen eine gewöhnliche Zeichenfolge senden. So kann der Client den engeren Bereich erkennen, ohne den ganzen Strom abzusuchen.

Die Längenangabe belegt exakt den Umfang dieses Antwortteils, nicht das Speicherformat. Sie verrät nicht, ob der Server unkodierte Nutzdaten speicherte, sie gerade aus Base64 erzeugte, Zeilenenden anpasste oder eine andere zulässige interne Form verwendete.

BINARY.PEEK trennte den Mailboxzustand. Wie BODY.PEEK setzt es nicht stillschweigend \\Seen. Eine ungelesene Nachricht ist eine nützliche Zustandsaussage, aber kein Herkunftsnachweis für die Daten. Auch die PEEK-Antwort bleibt eine vom Server erzeugte dekodierte Sicht.

BINARY.SIZE bezeichnete die Länge nach Entfernung des CTE, also die erwartete Länge der passenden BINARY-Antwort. Es war weder die kodierte Länge noch die physische Belegung noch die Größe der vollständigen Nachricht. Muss der Server zum Zählen dekodieren, kann die Anfrage teuer sein; davor warnte das Dokument ausdrücklich.

Teilabrufe benutzten Koordinaten innerhalb der dekodierten Daten. Eine Position im Base64-Text oder in FETCH BODY zeigt nicht zwingend auf denselben Inhalt. Wer einen Fortsetzungszähler aus der falschen Darstellung übernimmt, erhält möglicherweise einen formal korrekten Ausschnitt vom falschen Anfang.

Bei unbekanntem CTE durfte der Server nichts erraten. BINARY und BINARY.SIZE mussten mit NO [UNKNOWN-CTE] scheitern. Der Code belegte die fehlende Fähigkeit für diese Transformation, nicht automatisch eine beschädigte Nachricht.

RFC 4466 änderte später den Rahmen der IMAP-Antwortcodes, RFC 9051 übernahm den Binärmechanismus in IMAP4rev2. Für heutige Traces sind diese Fassungen wichtig. Kodierter Body, dekodierter Abschnitt und gespeicherte Darstellung blieben dennoch verschiedene Datenzustände.

Headerkodierung lag auf einer anderen Ebene. RFC-2047-Encoded-Words bringen Nicht-ASCII-Text in bestimmte Headerfelder; sie sind nicht das CTE eines MIME-Bodys. RFC 3516 untersagte deshalb ihre Konvertierung bei BINARY FETCH oder APPEND. Ein Auftrag zur Body-Dekodierung war keine Erlaubnis, jede kodiert wirkende Folge umzuschreiben.

Zeilenorientierter Text erhielt eine weitere kontrollierte Anpassung. Der Server musste ihn unabhängig von der internen Speicherung mit IMAP-CRLF übertragen. Das machte die Schnittstelle interoperabel, aber die Antwort ungeeignet als forensisches Abbild lokaler Zeilenendbytes.

Die Speichergrenze war ausdrücklich. Ein Server durfte binären Inhalt unkodiert halten. Trotzdem musste BODYSTRUCTURE ihn so beschreiben, als nutze er ein vom Basis-IMAP akzeptiertes CTE, und FETCH BODY musste diese angekündigte Form liefern. Die Schnittstelle war Vertrag, kein Speicherabzug.

APPEND führte in Gegenrichtung. Der Client konnte NUL-haltige Daten als literal8 anfügen. Unterstützte das Ziel keinen Binärspeicher, musste der Server mit UNKNOWN-CTE ablehnen. Andernfalls durfte er das CTE ändern, solange keine Nutzdaten verloren gingen.

Verlustfreie Nutzdaten bedeuten nicht identische Nachrichtenbytes. Base64, quoted-printable und direkte Darstellung rekonstruieren denselben Inhalt aus verschiedenen Folgen. CTE-Header, Faltung und Zeilenenden gehören zur Serialisierung. Eine inhaltstreue Änderung kann daher Hash oder Signatur über diese Serialisierung ungültig machen.

RFC 3516 warnte selbst, unnötige Kodierungsänderungen machten die meisten bereits auf die Nachricht angewandten kryptografischen Operationen unbrauchbar. Das widerspricht der Verlustfreiheitsregel nicht. Die eine schützt wiedergewinnbaren Inhalt, die andere hängt von exakten Bytes und einbezogenen Headern ab. „Verlustfrei“ dokumentiert nicht den Eingang des Prüfers.

Auch Clients blieben für MIME-Dekodierung verantwortlich. BINARY war eine Optimierung für bestimmte Lagen, kein universelles Speicherformat. Unterstützende Clients sollten weiterhin selbst CTE dekodieren können. Eine ausgehandelte schnelle Route darf die normale Route nicht ersetzen.

Heng Lus Trennung symbolischer und operativer Realität ordnet die Belege. BINARY in CAPABILITY ist eine Fähigkeitsbehauptung. BINARY.SIZE verspricht die Länge einer Sicht. Das gezählte Literal ist eine Beobachtung auf einer Verbindung. Speicherbytes, RFC-5322-Nachricht, MIME-Nutzdaten, Anzeige und Signatureingang liegen auf verwandten, nicht austauschbaren Ebenen.

Eine belastbare Kette bewahrt Nachrichtenkennung und Kontext, BODYSTRUCTURE, Abschnitt, CTE, Befehl, \\Seen-Wirkung, Antwortcode, Bereich, Länge, Offset und Hash der gelieferten Bytes. Wenn Originalidentität zählt, braucht sie einen getrennten Raw-Abruf samt Hash. Für Signaturen sind Kanonisierung und genaue Prüferbytes festzuhalten.

Dann widersprechen sich zwei wahre Aussagen nicht: Der Server lieferte den dekodierten Body korrekt, doch dessen Hash stimmt nicht mit der serialisierten Nachricht überein. RFC 3516 definierte die Transformation zwischen beiden Tatsachen.

Der historische Nutzen war handfest: Binärinhalte mussten beim IMAP-Abruf nicht jedes Mal die für einen anderen Transport entworfene Kodierung mitschleppen. Die bleibende Lehre betrifft Belege. Der Server dekodierte den Body, der Client erhielt nützliche Oktette; die Originalnachricht brauchte weiterhin eigenen Abruf, Hash und Nachweis.

Quellen