Zusammenfassung

  • RFC 2017 ergänzte message/external-body um den Zugriffstyp URL: In der Nachricht stand die Abrufbeschreibung, nicht der externe Datenkörper.
  • Faltung und Kodierung schützten die Darstellung des Verweises, bewiesen aber weder Erreichbarkeit noch stabile Identität, Echtheit oder Erlaubnis.
  • Typabgleich, ausdrückliche Zustimmung und Content-MD5 waren getrennte Kontrollen; die amtlichen Quellen belegen keine breite Einführung.

MIME hatte den abwesenden Körper schon vor RFC 2017 vorgesehen. RFC 1521 nannte FTP, anonymes FTP, TFTP, lokale Dateien und einen Mailserver als Zugangswege. Die neue Spezifikation registrierte URL. Ein gleichnamiger Pflichtparameter bezeichnete den Abrufweg; der innere Entity-Header kündigte den erwarteten Medientyp an.

Nicht jede URL-Form erfüllte diesen Zweck. RFC 2017 erlaubte nur Verfahren, die tatsächlich ein Objekt abrufen. mailto wurde ausdrücklich ausgeschlossen, weil es ein Postfach und eine Sendehandlung bezeichnet, nicht unmittelbar die Daten des externen Körpers. Gleiche Syntaxfamilie bedeutet nicht gleiche Wirkung.

Für lange Werte im Mail-Header definierte das Dokument eine Folge zitierter URL-word-Teile von höchstens vierzig Zeichen, getrennt durch linearen Leerraum. Der Empfänger entfernte Anführungszeichen und Leerraum, um die Adresse wiederherzustellen. Unkodierte Leerzeichen, Steuerzeichen, Anführungszeichen, Rückwärtsschrägstriche und Achtbit-Oktette mussten zuvor nach den historischen Regeln von RFC 1738 kodiert werden.

Damit war die Übertragung der Darstellung gelöst. Ob das Ziel existierte, Anmeldedaten akzeptierte, über dieselbe Vertrauensgrenze weiterleitete oder später dieselben Bytes lieferte, blieb offen. Ein korrekt rekonstruierter Verweis ist noch kein empfangenes Objekt.

Die Typentscheidung fiel vor dem Abruf

Der innere Header erklärte den Medientyp im Voraus. RFC 2017 verlangte Übereinstimmung mit der vom Programm tatsächlich verwendeten abgerufenen Fassung, weil bereits unumkehrbare Entscheidungen gefallen sein konnten. Die Wahl eines Decoders oder Handlers gibt einer noch ungeprüften Deklaration praktische Macht.

Der „phantom body“ sollte beim URL-Zugriff leer bleiben. Diese Leere bestätigte, dass keine kleine Ersatzkopie in der Nachricht steckte. Beim Zugriffstyp mail-server hatte derselbe Bereich dagegen eine andere Aufgabe: Er trug den auszuführenden Befehl.

RFC 2046 ersetzte RFC 1521 kurz darauf und behielt das Modell bei. Für externe Körper verlangte es eine Content-ID, um Cache und spätere Quittungen zuzuordnen. Noch wichtiger war die Sicherheitswarnung: Das Auflösen eines external-body lässt den Empfänger eine vom Absender bestimmte Operation ausführen. Die Software soll sie erklären und ausdrückliche Erlaubnis einholen.

Korrekte Syntax erteilt keine Zustimmung. Ein passender Digest ist ebenfalls keine Unterschrift. RFC 2017 erlaubt Content-MD5, um die Integrität der geholten Bytes und ihre Entsprechung zur Absicht des Absenders zu prüfen, stellt aber klar, dass dies keine digitale Signatur ist. RFC 1864 zieht dieselbe Grenze.

Nachricht und entferntes Objekt besitzen daher unterschiedliche Beweisketten. Die Prüfung der Nachricht authentifiziert nicht automatisch Daten, die später über ein anderes Protokoll eintreffen. Der Weg kann umgelenkt, der Inhalt verändert werden. Eine URL beschreibt einen Abruf, keine dauerhafte Inhaltsidentität.

Die heutigen Verzeichnisse führen RFC 2017 weiterhin als Proposed Standard; die Errata-Suche zeigte bei dieser Prüfung keinen passenden Eintrag. RFC 1738, dessen Kodierung historisch zugrunde lag, ist inzwischen obsolet; RFC 3986 beschreibt die spätere allgemeine URI-Syntax. Daraus folgen weder Verbreitung noch Nutzungserfolg oder eine direkte Linie zu heutigen Produkten.

Der historische Wert liegt in der Trennung: Adresse empfangen, Abruf erlauben, Bytes erhalten, Typ bestätigen und Integrität prüfen sind verschiedene Tatsachen. Wer sie in einem Status zusammenfasst, übernimmt eine Verantwortung, die RFC 2017 nicht beseitigt hat.

Quellen