Zusammenfassung

  • RFC 2049 machte Unwissen berechenbar, ohne Unterstützung jedes künftigen Media-Subtyps zu verlangen.
  • Unbekannte Transferkodierungen, Zeichensätze und nichttextuelle Subtypen fielen auf application/octet-stream zurück; rohe Nichttext-Bytes sollten nicht als Text erscheinen.
  • „Safe“ betraf bekannte RFC-821/822-konforme Systeme und den Schutz vor versehentlicher Anzeige, nicht Datei, Absender, Integrität, Darstellung oder Ergebnis.

Konformität musste das Nichtwissen ordnen

Ein offenes Typensystem wächst schneller als installierte Software. Vollständige Formatunterstützung hätte Konformität bei jeder Erweiterung veralten lassen; ohne Fallback hätten Clients dieselben Bytes drucken, ausführen oder unterschiedlich erraten können.

RFC 2049 setzte deshalb einen Boden. Ein konformer User Agent erzeugte MIME-Version: 1.0, erkannte Content-Transfer-Encoding, dekodierte quoted-printable und base64 und unterschied 7bit, 8bit und binary. Konnte der Transport 8bit oder binary nicht tragen, musste der Sender kodieren und korrekt kennzeichnen. Das Label beschrieb eine Umkehrung, bewies aber keine unveränderten Bytes.

War Content-Transfer-Encoding unbekannt, half auch ein vertrauter Content-Type nicht. Die MIME entity wurde zu application/octet-stream. Erst musste die dargestellte Oktettfolge gewonnen werden, dann durfte ein Medientyp interpretiert werden.

EID 5470 erläutert, dass der Originalsatz grammatisch dem Encoding einen Content-Type zuschreibt, und schlägt „MIME entity with“ vor. Der Status Held for Document Update macht dies zu einer aufgezeichneten Klärung, nicht zu bereits ersetztem Normtext.

Die Oberfamilie lieferte nur wenig Wissen

Bei text waren US-ASCII-Anzeige und zumindest ein Hinweis auf andere charsets Pflicht. Ein unbekannter Text-Subtype durfte nur bei bekanntem charset und nach canonical-to-local conversion roh angeboten werden; unbekannter charset bedeutete octet-stream.

Unbekannte Bild-, Audio- und Video-Subtypen fielen ebenfalls zurück. Bei application musste base64 oder quoted-printable entfernt und das Ergebnis in eine Benutzerdatei gelegt werden können. Verwahrung war keine Ausführungserlaubnis. RFC 2046 warnte, dass ein allgemeiner Viewer die Risiken seines gefährlichsten Formats erbt.

Für Composite Types galten eigene Regeln: mixed, alternative und digest erkennen; unbekanntes multipart als mixed behandeln; message/rfc822 rekursiv darstellen; unbekanntes message als octet-stream behandeln. Ein völlig unbekannter Content-Type wurde parameterloses octet-stream. Speichern oder Programmauswahl blieben lokale Optionen.

„Safe“ endete vor der Wirkung

RFC 2049 nannte korrekt markierte Daten sicher versendbar, weil ein konformes System sie wenigstens als undifferenziertes Binary behandelte und nicht auf den Bildschirm eines ahnungslosen Nutzers spritzte. Zudem sollten bekannte RFC-821/822-konforme Systeme weder gebrochen werden noch die Daten brechen.

Opake Bytes können dennoch schädlich sein. Ein Handler kann verwundbar sein. Erfolgreiches Decoding belegt weder Absenderidentität noch Integrität, Zustimmung, korrektes Rendering oder menschliche Wahrnehmung. Ein Hinweis auf den charset oder eine Speicheroption konnte die Mindestanforderung erfüllen. Nützliche Ablehnung gehörte zum Vertrag.

Schlechte MTAs waren Realität, nicht Erlaubnis

Das Dokument verzeichnete viele weit verbreitete, nichtkonforme MTAs, die Nachrichten für lokale Speicherformen änderten oder schlicht defekt waren. NUL, TAB, nachgestellte Leerzeichen, lange Zeilen, nichtinvariante Zeichen, ein einzelner Punkt und führendes From konnten beschädigt werden. Base64 erfüllte die engste portable Alphabet- und Zeilenregel; quoted-printable überstand nicht jedes genannte Gateway.

Die RFC erklärte ausdrücklich, dies seien keine MTA-Empfehlungen. RFC 821 verbot Whitespace-Änderung und Zeilenumbruch; das Verhalten war BAD und invalid. Robustheit durfte den Defekt nicht zur Norm waschen.

Die heutige RFC-Editor-Seite nennt Draft Standard; der historische Text sagt Standards Track und November 1996. Das ist Dokumentstatus, keine Einsatzmessung. Verified EID 3933 korrigiert die encoded-word-Referenz zu RFC 822 und RFC 2047, ohne Anzeigetext zur Identität zu machen.

Das bleibende Ergebnis war diszipliniertes Nichtwissen: Bekanntes dekodieren, Unbekanntes isolieren und Byte-Verwahrung nicht mit Verständnis verwechseln.

Quellen