Zusammenfassung

  • RFC 934 konnte eine mit Bindestrich beginnende Zeile als Grenze zwischen eingekapselten Nachrichten lesen. Ein Weiterleitungsagent setzte vor gleich aussehende Nutzdaten ; ein Burst-Agent entfernte dieses Zeichenpaar wieder.
  • Die Umkehrung funktioniert je Schicht. Bei weiterer Einkapselung wächst jedoch dieselbe Zeile um ein zusätzliches Präfix, sodass der transportierte Zustand nicht größenneutral bleibt.
  • MIME deklarierte später eine pro Multipart-Einheit gewählte Boundary, die im Inhalt nicht vorkommen darf. RFC 2046 begründet die Abweichung von RFC 934 ausdrücklich mit wachsender Zeilenlänge und möglichem SMTP-Line-Wrapping.

Ein Zeichen erhält seine Rolle erst im Parser

Die Mail-Syntax war nicht formlos, bevor RFC 934 erschien. RFC 822 trennt Header und Body an der ersten Leerzeile. In strukturierten Header-Feldern können Anführungszeichen, Klammern und Backslashes Grammatik statt Nutzdaten sein. Ihre Wirkung gilt aber nicht überall, sondern nur im Feld und Zustand, in dem der Parser diese Regeln anwendet.

Das ist mehr als eine terminologische Feinheit. Ein Bindestrich besitzt keine weltweite Befehlsgewalt. Er wird nur innerhalb einer bekannten Hülle und an einer bekannten Stelle als mögliche Struktur gelesen. Derselbe Bytewert kann in einer inneren Nachricht Text sein und in der äußeren Nachricht eine Grenze. Wer diese Schichten verwechselt, lässt eine äußere Syntax über inneren Inhalt entscheiden.

RFC 934 beschrieb dafür einen forwarding agent und einen bursting agent. Der erste erstellt vor dem Versand den äußeren Entwurf, der zweite zerlegt ihn nach der Zustellung. Der äußere Text kann Einleitung, eingekapselte Nachrichten und Abschluss enthalten. Seine anfängliche Encapsulation Boundary ist jede Zeile, die mit beginnt.

Damit lassen sich Nachrichten einfach aneinanderreihen; eine Grenze kann zugleich Ende und Anfang sein, und zwei benachbarte Grenzen stehen für eine leere Nachricht. Aber eine innere Zeile kann ebenfalls ohne syntaktische Absicht mit einem Bindestrich beginnen. Ohne zusätzliche Information kann der Burst-Agent nicht wissen, ob er Text ausgeben oder die innere Nachricht beenden soll.

Der äußere Agent markierte nur seine eigene Zuständigkeit

RFC 934 schlug Character Stuffing vor. Trifft der Weiterleitungsagent im eingekapselten Text auf eine Zeile, die wie eine Boundary beginnt, gibt er vor der Originalzeile Bindestrich plus Leerzeichen aus. Aus - Vermerk wird in der äußeren Darstellung - - Vermerk. Erkennt der Burst-Agent am Zeilenanfang , behandelt er dies nicht als Boundary und gibt den Rest aus. Erst die echte Boundary beendet die aktuelle Nachricht.

Diese Ergänzung ist keine Neuinterpretation des Originals. Der äußere Agent wird weder Autor der inneren Zeile noch Eigentümer ihrer Bedeutung. Er hinterlässt eine lokal lesbare Markierung, damit seine eigene Grammatik den Text nicht als Steuerinformation missversteht. Beim Verlassen dieser Grammatik wird genau diese Markierung zurückgenommen.

RFC 822 beschreibt für netzspezifische Transformationen ein verwandtes Muster: Die Eigenheiten des verlassenen Netzes werden entfernt, eine kanonische Form wird erreicht, anschließend werden die Eigenheiten des nächsten Netzes angewandt. Die Verfahren sind nicht identisch. Gemeinsam ist die Rechenschaftspflicht einer lokalen Veränderung: Herkunft, Geltungsbereich und Umkehrweg müssen erkennbar bleiben.

Umkehrbar ist nicht gleich zusammensetzungsneutral

RFC 934 kann zu Recht sagen, dass das Verfahren rekursive Weiterleitungen erlaubt. Eine Schicht schützt ihre Kollisionszeile; die korrespondierende Schicht stellt sie wieder her. Der Zwischenzustand bleibt dabei aber nicht unverändert.

Nach der ersten Hülle lautet eine ursprüngliche Zeile - Vermerk nun - - Vermerk. Ein zweiter Weiterleitungsagent sieht wiederum eine bindestrichführende Zeile und fügt sein eigenes hinzu. Außen steht dann - - - Vermerk. Jede Schicht darf nur die eigene Ergänzung entfernen. Würde eine äußere Schicht alle ähnlich aussehenden Präfixe löschen, zerstörte sie möglicherweise innere Syntax oder die ursprünglichen Daten.

Nach korrekter Rückwärtsfolge ist der Originaltext wieder da. Unterwegs ist er länger. Ein Encoder-Decoder-Roundtrip beweist daher nur eine enge Eigenschaft. Er beweist nicht, dass Relays die wachsende Zeile transportieren, dass kein Gateway sie umbricht, dass Normalisierung die Umkehrinformation bewahrt oder dass eine Untersuchung noch zuordnen kann, welche Schicht welches Präfix eingefügt hat.

Gerade diese Zwischenrepräsentation ist die laufende Wirklichkeit. Sie wird versendet, gefiltert, begrenzt und protokolliert. Wer nur das am Ende rekonstruierte Dokument aufbewahrt, kann nicht zeigen, ob die Systeme dazwischen die Darstellung erhielten, die die Rekonstruktion erst ermöglichte.

RFC 934 kannte die Grenze zwischen Text und bestehender Praxis. Sie wollte Änderungen an bereits vorhandenen Weiterleitungsagenten klein halten. Für Kompatibilität mit älteren Burst-Agenten schlägt sie Leerzeilen um Boundaries vor, merkt jedoch an, dass ein streng konformer Sender diese Leerzeilen nicht erzeugen sollte. Ein veröffentlichter Text verdrängt keine laufende Implementierung; Koordination entsteht nur in der tatsächlich kompatiblen Menge von Schreibern und Lesern.

MIME verlagerte die Kollisionsarbeit

RFC 2045 nennt RFC 934 und RFC 822 als Vorarbeiten für MIME. MIME führt beschriebene Entities und Multipart-Bodies ein. Das ist eine gemeinsame Syntax für Beteiligte, die sie verwenden, nicht der Beweis, dass ältere Nachrichten dadurch rückwirkend anders funktionieren.

Nach RFC 2046 deklariert eine Multipart-Entity einen boundary-Parameter. Der Delimiter beginnt mit zwei Bindestrichen und diesem Wert. Er darf im eingekapselten Teil weder allein noch als Zeilenpräfix vorkommen; verschachtelte Multipart-Entities brauchen verschiedene Werte. Die Aufgabe liegt nun beim Komponierer: Er muss eine Boundary wählen, die mit seinem Inhalt nicht kollidiert.

Die Boundary ist weiterhin keine globale Wahrheit. Sie wirkt, weil der Header dieser Entity sie deklariert und weil der Empfänger gerade diese Multipart-Grammatik liest. Dieselbe Zeichenfolge in einem Plain-Text-Body eröffnet keine Struktur.

RFC 2046 hält die historische Abgrenzung ausdrücklich fest. Die zwei Bindestriche dienen unter anderem einer groben Kompatibilität mit RFC 934 und dem leichteren Suchen nach Grenzen. Multipart folgt aber nicht der RFC-934-Quotierung eingebetteter Bindestrichzeilen, weil die Zeilen bei jeder Ebene wachsen und SMTP-Implementierungen lange Zeilen manchmal umbrechen. Bei tiefer Verschachtelung wird der temporäre Zustand selbst zum Interoperabilitätsproblem.

Die ältere Regel war damit nicht sinnlos. Sie löste eine reale Kollision mit einer kleinen, umkehrbaren Zustandsmaschine. MIME wählte für einen breiteren, typisierten und verschachtelbaren Körper eine andere Kostenstelle: Boundary auswählen und ihre Abwesenheit im Inhalt sicherstellen, statt jede kollidierende Nutzdatenzeile wiederholt zu verändern.

Strukturelle Autorität braucht ein Ablaufdatum

Die übertragbare Frage lautet: Wann darf ein Marker Struktur sein, und wann muss er wieder Daten werden? In RFC 934 signalisiert nur der äußeren Schicht, dass diese innere Zeile keine ihrer Boundaries ist; beim Burst verschwindet das Signal. In MIME gilt eine Boundary nur innerhalb der Entity, die sie deklariert.

Gefährlich wird es, wenn Transitmarkierungen als Original gespeichert werden, wenn Präfixe ohne Kenntnis ihres Urhebers entfernt werden oder wenn Daten als Kontrolle gelesen werden, bevor die passende Hülle feststeht. Es braucht keine institutionelle Deutungshoheit über Zeichenfolgen. Es braucht einen kleinen deterministischen Vertrag, lokale Prüfung, sichtbare Änderung und eine sichere Umkehrung dessen, was die eigene Schicht getan hat.

Der wachsende Bindestrich ergänzt diese Prüfung um eine Mengenfrage: Wie verändert sich das Format bei wiederholter Zusammensetzung, wer misst die Expansion, wo trifft sie auf Grenzen, und welche Normalisierung zerstört den notwendigen Rückweg? Erst diese Fragen machen aus einer Escape-Regel einen belastbaren Betriebsentwurf.

Quellen und Evidenzgrenzen

Der geschlossene Belegsatz besteht aus RFC 822, RFC 934, RFC 2045 und RFC 2046. Er belegt historische Syntax, Stuffing und Bursting sowie den dokumentierten MIME-Kontrast. Er belegt keine universelle Verbreitung, kein Verhalten eines heutigen Produkts, keine gemessene Verschachtelungshäufigkeit und keine Sicherheit eines bestimmten Parsers.