Zusammenfassung

  • RFC 2231 zählt Fortsetzungsabschnitte ab null lückenlos hoch. Zeichensatz und optionale Sprache stehen nur am Anfang des ersten kodierten Teils; die Nummern, nicht die Reihenfolge im Header, bestimmen den Zusammenbau.
  • Ein erfolgreich rekonstruiertes filename bleibt ein Vorschlag aus Content-Disposition. RFC 2183 verlangt, Pfade zu verwerfen, Überschreiben und gefährliche Ziele zu verhindern und keine Ausführung ohne ausdrückliche Nutzerhandlung zuzulassen.

Eine Transportgrenze ist keine Zeichengrenze

Das folgende, eigens gebildete Beispiel verteilt einen Wert auf drei Parameter:

filename*0*=utf-8'en'Quarterly%20; filename*1*=review%20; filename*2=final.pdf

Teil null nennt UTF-8 und eine optionale Sprache und beginnt den Inhalt. Teil eins führt die Prozentkodierung fort. Teil zwei endet unkodiert. Sind 0, 1 und 2 vollständig und eindeutig vorhanden, lautet der logische Wert Quarterly review final.pdf.

Die physische Reihenfolge darf der Empfänger nicht übernehmen. MIME-Parameter sind grundsätzlich ungeordnet; ein Zwischenknoten kann *2 vor *0 stellen. RFC 2231 schreibt deshalb Nullbeginn, Schritte von genau eins, keine Lücken und keine führenden Nullen vor. Eine Implementierung gruppiert nach dem gemeinsamen Grundnamen, erkennt mehrdeutige Duplikate, prüft die Reihe und fügt sie nach Index zusammen.

Erst danach wird dekodiert. Zeichensatz und Sprache werden einmal am Anfang angegeben, nicht für jeden Abschnitt neu. Die Fortsetzungsgrenze dient dem Transport und kann mitten in den Oktetten eines UTF-8-Zeichens liegen. Wer jeden Teil einzeln als Text deutet, erzeugt möglicherweise Ersatzzeichen oder ein anderes Ergebnis als ein zweiter Parser.

Eine belastbare Verarbeitung trennt daher: Namen analysieren; eine eindeutige, lückenlose Reihe validieren; Nutzdaten nummerngerecht verbinden; Prozentfolgen in Oktette zurückführen; diese einmal im angegebenen Zeichensatz interpretieren; den Text anschließend einer getrennten Dispositionsrichtlinie übergeben. Der Sicherheitsteil von RFC 2231 ist knapp, doch Grammatik und einmalige Anfangsdeklaration stützen diese Reihenfolge.

Ein verstandener Wert ist noch keine Anweisung

RFC 2231 erweitert die Darstellung. Es überträgt dem Absender keine Kontrolle über das lokale Dateisystem. RFC 2183, das Content-Disposition definiert, beschreibt filename als vorgeschlagenen Namen für das Abspeichern eines Body-Teils.

Der empfangende Mail-Client soll diesen Namen nicht blind verwenden. Verzeichnisanteile sind zu ignorieren; allenfalls die letzte Komponente bleibt Kandidat. Die Anwendung muss unbeabsichtigtes Überschreiben, System- und Startbereiche, Spezialdateien, Pipes sowie ausführbare Dateien in Suchpfaden vermeiden. Allein das Speichern darf keine Ausführung ohne eine ausdrückliche Nutzeraktion auslösen.

Auch ein korrektes UTF-8-Ergebnis kann ../, absolute Pfade, Steuerzeichen, bidirektionale Markierungen, reservierte Namen oder eine irreführende Endung enthalten. Prozentdekodierung bereinigt nichts. Ein gültiger Zeichensatz authentifiziert den Absender nicht. Die Übereinstimmung von Name und Content-Type beweist keine Harmlosigkeit. Keine dieser Prüfungen erlaubt Ersetzen, Öffnen, Ausführen oder Zuschreiben.

Die Kontrollflächen bleiben getrennt. Der MIME-Parser beurteilt die Struktur. Der Decoder bestimmt den Text. Eine lokale Namensrichtlinie erzeugt einen sicheren Kandidaten. Der Speichermechanismus beschränkt den Zielort und regelt Kollisionen. Nutzer oder autorisierte Richtlinie entscheiden erst danach über Öffnung und Ausführung. Ein bestandenes Tor ist kein Ausweis für das nächste.

Auch Autorennamen haben eine belegte Grenze

RFC 2231 nennt Ned Freed und Keith Moore als Autoren. Der abgelöste Vorgänger RFC 2184 trägt dieselben beiden Namen. Damit ist die gemeinsame Urheberschaft dieses Mechanismus vollständig bezeichnet.

Patrik Fältström gehört zur Geschichte der Internationalisierung des Internets, aber nicht als Autor von RFC 2231 oder RFC 2184. RFC 3490, die frühere IDNA-Spezifikation, nennt Fältström gemeinsam mit Paul Hoffman und Adam Costello. Thematische Nachbarschaft darf nicht zu einer erfundenen Autorschaft werden. Dokument, Autorengruppe und technischer Vertrag bleiben unterscheidbar.

Freeds breiteres Wirken für E-Mail und Medientypen ist im IETF Datatracker dokumentiert. Nathaniel Borenstein schildert in seinem Nachruf, wie sein Wunsch nach reicherer E-Mail auf Freeds Konzentration auf Robustheit und Interoperabilität traf. RFC 2045 strukturiert MIME-Nachrichtenkörper, RFC 2047 behandelt Nicht-ASCII-Text in Headern, RFC 2231 löst das engere Parameterproblem.

Die Begrenzung schützt vor falscher Verallgemeinerung. Ein Stern im Feldnamen aktiviert die Regeln nicht automatisch in jedem Protokoll; die definierende Spezifikation muss sie übernehmen. Internationalen Text zu transportieren, macht aus ihm keine Identitätsbehauptung.

HTTP übernahm die Kodierung, nicht die Fortsetzung

RFC 8187 verwendet für HTTP eine verwandte Form kodierter Parameter und verlangt UTF-8, schließt aber die Fortsetzungen aus RFC 2231 aus. HTTP brauchte sie nicht. Technische Abstammung bedeutet keine identische Oberfläche.

RFC 6266 wiederholt für HTTP Content-Disposition den entscheidenden Status: Der Dateiname ist ein Hinweis. Empfänger entfernen Pfadbestandteile, behalten die Kontrolle über das Verzeichnis und behandeln gefährliche Erweiterungen, Steuerzeichen und besondere Namen. Ein Server darf ein Etikett vorschlagen, aber nicht das Dateisystem des Clients beherrschen.

RFC 2231 hinterlässt somit eine doppelte Strenge. Interoperabilität verlangt genaue Nummerierung, eine Anfangsdeklaration und deterministische Rekonstruktion. Sicherheit verlangt ebenso genau zu benennen, was das Ergebnis nicht beweist. Eine wiederhergestellte Zeichenfolge ist verständlich, aber noch lange nicht vertrauenswürdig.

Quellen