Zusammenfassung

  • RFC 1524 ließ verschiedene Mailreader gemeinsame mailcap-Regeln nutzen. Die Nachricht erklärte ihren MIME Content-Type; lokale Suchreihenfolge, Regel und Test bestimmten Anzeigen, Erzeugen, Bearbeiten oder Drucken.
  • Unter UNIX wurde die passende Regel zur Bourne-Shell-Kommandozeile, in die Medientypwerte oder temporäre Dateinamen eingesetzt wurden. Treffer, erfolgreicher Test und Prozessende belegten weder Echtheit noch Sicherheit oder Nutzerabsicht.

Ein gemeinsamer Name, unterschiedliche Rechner

MIME ermöglichte 1993 den Transport von Bildern, Audio und mehrteiligen Körpern im Internet-Mail-System. Eine Typangabe installierte aber keinen Betrachter beim Empfänger. Rechner unterschieden sich bei Programmen, Fenstersystemen, Terminals und Geräten.

RFC 1524 schlug eine lokale Indirektion vor. Traf ein Mailreader auf einen unbekannten Nicht-Text-Typ, konnte er in einer externen Datei nach installierten Hilfsprogrammen suchen. Ein Standort installierte eine Binärdatei und ergänzte eine Zeile; mehrere unabhängig entwickelte Reader konnten dieselbe Fähigkeit nutzen.

Das gemeinsame Protokoll blieb dünn. Die Nachricht lieferte den Typnamen. Welches lokale Programm daraus eine Handlung machte, entschied der Empfängerstandort.

Die erste anwendbare Regel gewann

Die wirksame Konfiguration entstand aus der virtuellen Verkettung mehrerer mailcap-Dateien. Ein Eintrag musste zum Content-Type passen, die verlangte Aktion beschreiben und einen optionalen test= bestehen. Der erste passende Eintrag wurde verwendet.

Damit war Reihenfolge Verhalten. Im UNIX-Anhang stand die Nutzerdatei vor mehreren Systemorten; MAILCAPS konnte den gesamten Suchpfad ersetzen. Administratoren konnten einen gemeinsamen Standard setzen, Nutzer ihn ergänzen oder überstimmen. Gleiche Bytes führten deshalb unter verschiedenen Konten nicht zwingend zum gleichen Programm.

Pflichtfelder waren Medientypmuster und Anzeigebefehl. Optionale Felder trennten Erzeugen, typisiertes Erzeugen, Bearbeiten, Drucken und Testen. needsterminal verlangte eine interaktive Umgebung, copiousoutput empfahl Scrollen oder Paging. Ein Format zu „unterstützen“ sagte noch nicht, welche Operation zugelassen war.

Der Test durfte ein beliebig komplexes Programm starten, etwa zur Prüfung von Architektur, Fenstersystem oder Audiohardware. Rückgabewert null bedeutete, dass der Eintrag in dieser Umgebung galt. Er war kein Urteil über die empfangenen Inhaltsbytes.

Die Regel wurde ausführbarer Shell-Text

Für UNIX definierte RFC 1524 die Aktionsfelder als vollständige Kommandozeilen für die Bourne Shell, praktisch mit /bin/sh -c davor. %t stand für Typ und Subtyp, %{name} für einen Content-Type-Parameter, %n für die Zahl der Teile, %F für abwechselnde Typ- und Dateinamen und %s für eine Datei mit dem Körper.

Der Weg führte somit über Headeranalyse, Regelauswahl, Quote-Verarbeitung, Wertersetzung und Argumentbildung bis zur Betriebssystemausführung. Jeder Übergang brauchte einen eigenen Beleg. Ein syntaktisch zulässiger Parameter konnte falsch gruppiert werden. Ein gestarteter Prozess konnte einen anderen Gegenstand lesen als beabsichtigt.

Mit %s änderte sich auch der Datenpfad. Ohne das Zeichen lasen Anzeige- und Editierbefehle von der Standardeingabe. Mit ihm musste der Reader unter Umständen eine temporäre Datei anlegen. Der RFC warnte, dass sie nach Befehlsende nicht als vorhanden gelten durfte; ein Hintergrundprozess musste benötigte Daten selbst sichern.

nametemplate konnte eine Endung wie .gif erzwingen. Das half endungsabhängigen Programmen, bewies aber weder den Dateiinhalt noch Absenderidentität oder Ungefährlichkeit.

Erzeugen war ein eigener Übergang

Ein compose-Programm lieferte Daten, die der aufrufende Mailclient mit dem konfigurierten Typ versah. composetyped konnte Content-Type und weitere Header selbst ausgeben. Für eine nötige Transportkodierung blieb grundsätzlich der Aufrufer verantwortlich, sofern der Produzent sie nicht ausdrücklich deklarierte.

Ausgewählte Regel, Produzent, Bytes, Typ, Kodierung und endgültige Nachricht blieben getrennte Aufzeichnungen. Der erfolgreiche Editorlauf bestätigte nicht die nachfolgenden Schritte.

Erweiterbarkeit erteilte kein Vertrauen

RFC 1524 warnte, der Mechanismus könne das Abrutschen in MIME-Sicherheitsprobleme erleichtern, und verlangte Vorsicht bei automatisch ausgeführten Programmen. Er dokumentierte keinen benannten Angriff und kein konkretes Produktversagen. Belegt ist eine Architekturgrenze: Eine entfernte Beschreibung erhält nur deshalb lokale Wirkung, weil eine verantwortete Regel sie mit einer Aktion verbindet.

RFC 2045, 2046 und 2048 überarbeiteten MIME; RFC 6838 aktualisierte die Medientypregistrierung. Registrierung macht Namen und Dokumentation teilbar. Sie installiert keinen Handler, weist keine gewinnende Regel nach und autorisiert keine Ausführung.

Eine Untersuchung muss empfangene Bytes und Typ, wirksame mailcap-Dateien samt Reihenfolge, angeforderte Aktion, Regel und Test, expandierten Befehl, stdin oder temporäre Datei, Prozess und Resultat, sichtbare Ausgabe und Nutzerentscheidung verknüpfen. „Anhang geöffnet“ löscht genau den Übergang, an dem Beschreibung zu Macht wurde.

Quellen