Zusammenfassung

  • RFC 3462 verlangte multipart/report als äußersten MIME-Container. Darin standen zwingend zuerst eine menschenlesbare Erklärung und danach ein typisierter Maschinenbericht; optional folgte die ursprüngliche Nachricht oder ein nützlicher Ausschnitt.
  • Der Container erleichterte Erkennung, nicht Vertrauen. report-type kündigte den MIME-Untertyp des zweiten Teils an, doch auch ein gefälschter Bericht konnte formal korrekt sein und gefährliche Automatisierung auslösen.

Ein Ereignis hatte zwei Leser

Freier Text kann einen Fehler erklären, wechselt aber mit Sprache, Produkt und Urteil. Strukturierte Felder lassen sich zuverlässig sortieren, helfen einem Absender jedoch kaum bei der Frage, ob er eine Adresse ändern oder erneut senden soll. Die historische Aufgabe bestand nicht darin, eine Darstellung zu bevorzugen. Beide mussten zusammen reisen, ohne dieselbe Beweiskraft zu beanspruchen.

Der im Januar 2003 veröffentlichte RFC 3462 regelte diese Verpackung. Der Klartext, der RFC-Editor-Eintrag, die Datatracker-Seite, die Dokumentgeschichte, Referenzen, spätere Verweise und die Errata-Suche bilden den überprüfbaren Normbestand. Der Text ersetzte RFC 1892 und machte aus einer Benachrichtigungsform eine allgemeine Familie von MIME-Berichten.

multipart/report musste der äußerste MIME-Inhaltstyp sein. Neben der für Multipart nach RFC 2046 erforderlichen boundary war report-type vorgeschrieben. Dessen Wert benannte den MIME-Untertyp des zweiten Body-Teils. Eine Software konnte im äußeren Header erkennen, dass ein Bericht vorlag, und vor dem vollständigen Lesen wissen, welche Maschinenstruktur zu erwarten war.

Reihenfolge war Bedeutung

Der erste Teil war obligatorisch und für Menschen bestimmt. Er durfte jeden in einer Norm festgelegten MIME-Typ, eine passende Sprache und Zeichenkodierung sowie multipart/alternative für mehrere Darstellungen verwenden. Diese Freiheit war funktional: Eine brauchbare Erklärung richtet sich an ihr Publikum.

Der zweite Teil war ebenfalls obligatorisch, aber maschinenlesbar. Ein registrierter Medientyp hielt ein Ereignis der Nachrichtenverarbeitung fest und konnte Expertendetails enthalten. Für Zustellstatusmeldungen verwendete RFC 3464 message/delivery-status. Der generische Container legte weder die SMTP-Anforderung aus RFC 3461 noch die erweiterten Statuscodes aus RFC 3463 fest. RFC 3462 bestimmte Ort und Art des Maschinenbefunds, nicht die Zustellwirklichkeit selbst.

Ein dritter Teil war optional. Er gab die Originalnachricht oder einen für Diagnose und Zuordnung nützlichen Ausschnitt zurück. Ohne ausdrückliche Auswahl sollte grundsätzlich die ganze Nachricht zurückkommen; das kostete Bandbreite und konnte Inhalte offenlegen. War ein sicherer Rückweg für Achtbit- oder Binärdaten ungewiss, durfte der Erzeuger legal in Siebenbit-MIME umkodieren oder nur text/rfc822-headers senden. Solche Header standen in der Tradition von RFC 822, waren aber keine vollständige Nachricht und durften nicht als message/rfc822 ausgegeben werden.

Damit entstand eine kleine Beweisordnung. Teil eins erklärte, Teil zwei war berechenbar, Teil drei lieferte Kontext. Überzeugende Prosa war kein Statusfeld. Ein Statusfeld war nicht das ursprüngliche Objekt. Eine Header-Auswahl war nicht die vollständige Nachricht. Der gemeinsame Umschlag hob diese Grenzen nicht auf.

Erkennung verlieh keine Echtheit

Die äußere Position ermöglichte eine schnelle Auswahl anhand des Content-Type. Das IANA-Verzeichnis der Medientypen gab den Untertypen einen gemeinsamen Namensraum. Die Hülle trug später Dispositionsbenachrichtigungen aus RFC 3798, revidiert durch RFC 8098, sowie internationalisierte Zustellstatus nach RFC 6533.

RFC 3462 warnte ausdrücklich, dass die Struktur ihren Inhalt nicht authentisierte. Ein gefälschter negativer Bericht konnte eine Mailingliste oder ein Verzeichnis dazu bringen, eine gültige Adresse zu entfernen: automatische Pflege würde zum Denial of Service. Ein gefälschter positiver Bericht konnte eine nicht erfolgte Zustellung glaubhaft erscheinen lassen. Eine Signatur über die gesamte Struktur hätte Fälschungen erschweren können, lag aber außerhalb des Standards.

Syntax beweist nur, dass Bytes einer Grammatik folgen. Sie beweist weder Urheberschaft noch Ereignis noch menschliche Kenntnisnahme. Wer diese Ebenen in einer Automatisierung zusammenzieht, macht aus einem Parsergebnis eine nicht vorgesehene Betriebsvollmacht.

Heng Lus spätere Lehre von den Realitätsebenen hilft, empfangenes Dokument, Parserauslegung, reales Mailereignis und Verwaltungsentscheidung zu trennen. Seine Betonung des tatsächlich laufenden Codes lenkt den Blick auf MIME-Baum, Erzeuger, Authentisierung und automatischen Verbraucher. Das sind spätere redaktionelle Blickwinkel, keine Behauptung über private Absichten der RFC-Autoren.

RFC 3462 machte Berichte nicht wahr. Es machte sichtbar, wo Erklärung, maschinelle Aussage und zurückgegebenes Material lagen. Die Struktur koordinierte ihre Verarbeitung; Vertrauen brauchte weiterhin eine andere Grundlage.

Quellen