Zusammenfassung

  • RFC 1344 trennte den Transport in einer homogenen Mail-Umgebung vom Gateway zwischen verschiedenen Umgebungen. Änderte ein Relay den Inhalt, musste es den zweiten Rollenvertrag übernehmen.
  • MIME erlaubte eine unverstandene Nachricht vollständig zurückzugeben, große Objekte zu teilen, externe Daten zu verlagern oder Bytes durch Transfer-Encoding zu schützen. Diese Operationen behaupteten nicht dieselbe Art von Treue.
  • Eine Konvertierungsspur und ein vorgeschlagenes Verbot des Absenders machten Handlung sichtbar. Spätere Standards bewahrten zusätzlich Verlust, ursprüngliche und endgültige Adresse sowie allgemeine und native Fehlercodes.

Die Spur begann dort, wo Neutralität endete

MIME war so angelegt, dass Bilder, Audio und zusammengesetzte Inhalte über vorhandene Internet-Mail-Transporte laufen konnten. Ein MTA musste die Bedeutung eines Body Parts nicht kennen, um ihn weiterzugeben. Gerade diese technische Anspruchslosigkeit schützte die Trennung zwischen Beförderung und Interpretation.

RFC 1344 definierte Mail Transport als Bewegung innerhalb einer im Wesentlichen homogenen Umgebung. Ein Gateway verband deutlich verschiedene Mail-Welten. Dort konnte eine Inhaltsänderung unvermeidlich werden; im bloßen Transport galt sie im Allgemeinen als unzulässig.

Ein SMTP-Relay über eine teure interkontinentale Strecke mochte eine GIF-Datei in eine kleinere JPEG-Darstellung verwandeln wollen. Das konnte Kapazität sparen. Zugleich setzte es Unterstützung am Ziel voraus und konnte Details entfernen. Der Text erlaubte dem Relay nicht, diese Entscheidung hinter dem Wort Optimierung zu verstecken. Es sollte seine Rolle als Gateway neu bestimmen.

Der Rollenwechsel folgte damit der Operation, nicht der Hardware. Wer annahm und weitergab, konnte Transport belegen. Wer auswählte, welche Darstellung weiterging, brauchte einen anderen Nachweis.

Eine Rückgabe musste das gescheiterte Objekt erhalten

Textförmige Fehlermeldungen funktionierten leidlich, solange die ursprüngliche Nachricht ebenfalls Text war. Bild- oder Audiodaten als Zeichenfolge zurückzugeben zerstörte die Nutzbarkeit des Belegs.

RFC 1344 zeigte eine MIME-Multipart-Struktur: ein verständlicher Erklärungsteil und daneben die vollständig gekapselte abgewiesene Nachricht als message/rfc822. Die Transportsoftware musste den Inhalt nicht interpretieren. Sie musste seine Grenze bewahren.

Der RFC begrenzte das Beispiel ausdrücklich. Es war eine mögliche Form, kein bereits standardisiertes Format für Ablehnungen und Bestätigungen. Dafür sei weitere IETF-Arbeit nötig. Darstellbarkeit und interoperable Praxis blieben getrennte Tatsachen.

RFC 3464 spezifizierte später maschinenlesbare Delivery Status Notifications. Der Bericht konnte Nachricht und einzelne Empfänger korrelieren, die vom Absender genannte Adresse neben der nach Weiterleitung sichtbaren Endadresse bewahren und einen transportunabhängigen Status gemeinsam mit dem fremden Originalcode tragen. Der allgemeine Code schuf Vergleichbarkeit; der native Code erhielt die Diagnose.

Eine schützende Kodierung war keine neue Darstellung

An einer ASCII–EBCDIC-Grenze konnten bestimmte Zeichen beschädigt werden. Base64 oder quoted-printable veränderte die Übertragungsform, damit sich die ursprünglichen Bytes nach dem Durchgang wiederherstellen ließen. Das Gateway schützte das Objekt vor dem Kanal.

Eine Bildkonvertierung entschied anders. JPEG konnte kleiner und GIF auf manchen damaligen Systemen bequemer sein. Doch die erfolgreiche Erzeugung des Zielformats bewies weder visuelle Gleichheit noch Unterstützung durch den Empfänger. Aktion und Eignung lagen auf verschiedenen Ebenen.

message/partial adressierte Größenbeschränkungen. Ein sendendes oder empfangendes Gateway konnte eine Nachricht aufteilen oder zusammensetzen. Weil Grenzen weiter unten oft nur geschätzt wurden, bewiesen korrekte Fragmente noch keine vollständige Rekonstruktion.

Bei message/external-body konnte das Gateway Daten abrufen, näher beim Empfänger speichern oder die Referenz verändern. Der RFC schlug auch vor, Originalverweis und expandierte Kopie als Alternativen zu behalten. Damit blieb die Herkunft sichtbar, obwohl eine lokale Fassung den Zugriff vereinfachte.

Das vorgeschlagene Verbot gehörte nicht allen Beteiligten

Für Formatänderungen empfahl RFC 1344 nachdrücklich Trace-Information, vermutlich in Received. Eine andere Darstellung sollte einen verantwortlichen Übergang im Pfad hinterlassen.

Zusätzlich wurden Content-Conversion: prohibited und permitted vorgeschlagen. Das war kein Nachweis einer universellen Standardisierung. Ohne Angabe würden viele Gateways Erlaubnis annehmen. Außerdem stand die Wahl dem Absender, nicht jedem Empfänger zu.

Diese Asymmetrie zeigt die Wissensverteilung. Das Gateway kennt Leitungskosten und lokale Konverter. Der Absender kennt das Original. Der Empfänger kennt Werkzeug und Zweck. Eine Header-Zeile kann die Entscheidung des Gateways zurechenbar machen; sie kann fehlende Zustimmung nicht erfinden.

RFC 2156 unterschied im MIXER-Gateway zwischen X.400 und RFC 822/MIME später Conversion Prohibition, Verbot bei Informationsverlust, nicht unterstütztem Medium, Umwandlung mit Verlust und Fehlschlag. Ein Trace-Element markierte die Konvertierung. Semantische Entsprechung und kein wesentlicher Informationsverlust gehörten zur vollen Unterstützung. Das beweist keine flächendeckende Übernahme des Vorschlags von 1992, wohl aber, dass „relayed“ kein ausreichender Zustand war.

Der nächste Server war nicht der letzte Beobachter

Eine vollständige Kette umfasst Original, Transportannahme, erkannte Grenze, Gateway-Entscheidung, Ergebnisobjekt, nächste Annahme, Status je Empfänger, Darstellung im Client und menschliche Verwendung. Jeder Schritt braucht seine eigene Evidenz.

Ein Konverter kann korrekt enden, während der Client das Format nicht öffnet. SMTP kann die Nachricht annehmen, bevor ein einzelnes Postfach scheitert. Eine nahe Kopie kann veraltet sein. Ein DSN kann Zustellung melden, ohne Lesen zu beobachten.

RFC 1344 erklärte, Sicherheitsfragen nicht zu behandeln. Es ist deshalb kein Beleg für Angriff oder Missbrauch. Seine dauerhafte Aussage ist enger: Eine Inhaltsänderung ist eine Ausübung von Entscheidungsmacht. Der Datensatz muss diese Macht zeigen, ohne ihr Ergebnisse zuzuschreiben, die außerhalb des Gateways liegen.

Quellen

Die Quellen belegen Dokumentstatus, beschriebene Mechanismen und spätere Evidenzstrukturen. Sie belegen keine konkrete Einführung, keinen Angriff, keine Verbreitungsquote, keine universelle Konvertierungsregel, gleiche Darstellung, Zustellung, Zustimmung oder menschliche Wirkung.