Zusammenfassung

  • RFC 733 vereinheitlichte die Form von ARPANET-Textnachrichten zwischen Hosts; der RFC definierte weder einen vollständigen Maildienst noch dessen Benutzeroberfläche.
  • Die gemeinsame Grammatik kam, während der Versand noch FTP-Befehle nutzte und ältere Vorschläge sowie lokale Parser unterschiedliche Erwartungen geprägt hatten.

Analyse

Die schnelle Lösung blieb innerhalb von FTP

1973 wurde Netzpost bereits mit zwei Befehlen des File Transfer Protocol übertragen: MAIL und MLFL. Damit ließ sich eine Nachricht im lokalen Mailsystem des Empfängers ablegen. Einheitliche Header ergaben sich daraus aber nicht. Ein Host konnte Absender, Betreff oder Datum in einer Form senden, die ein anderer nicht zuverlässig erkannte. Für FTP war die gesamte Nachricht einschließlich Header schlicht Nutzdaten.

RFC 524 schlug ein umfangreicheres Mailprotokoll innerhalb des FTP-Befehlsraums vor. Der Autor erläuterte auch, warum FTP die Grundlage sein sollte: FTP war weit verbreitet implementiert, das vorgeschlagene vereinheitlichte Protokoll auf Benutzerebene dagegen nicht. RFC 561 wählte einen schnelleren Zwischenweg. Statt auf neue Zustellbefehle zu warten, schlugen vier Autoren eine Textkonvention für Nachrichten vor, die bereits mit MAIL oder MLFL übertragen wurden. From, Date und Subject erhielten erkennbare Formen; weitere Felder blieben möglich. Die Autoren hielten ausdrücklich fest, dass sich diese Lösung schneller umsetzen lasse als eine Änderung des Mailprotokolls.

Der Eingriff blieb begrenzt. RFC 561 ersetzte den Transport nicht, sondern sollte dessen Daten für Menschen und Software verständlicher machen. Die Flexibilität ließ eine Lücke: Weitere Felder konnten ergänzt werden, doch für Empfänger und andere Angaben gab es noch keine gemeinsame Syntax.

Ein RFC-Titel konnte mehr versprechen als der Inhalt

RFC 680 erschien 1975 unter dem Titel „Message Transmission Protocol“ und erweiterte die Nachrichtenfelder. Der Text definiert Header und ihre beabsichtigte Bedeutung, aber nicht den Übertragungsvorgang zwischen Hosts. RFC 724, ein Vorschlag zur Überarbeitung, berichtet, RFC 680 sei nur begrenzt verbreitet und nie formell als offizieller ARPANET-Standard angenommen worden. Einige Implementierer hätten ihn dennoch wie einen Standard behandelt.

RFC 724 beschreibt außerdem eine unmittelbarere Quelle von Einfluss: bereits eingesetzte Mailsoftware. Nach Darstellung der Autoren erzeugten TENEX-Systeme mehr Netzpost als andere Hosttypen; ihre To- und Cc-Syntax sei dadurch zur De-facto-Konvention geworden. TENEX-Leseprogramme erwarteten zunehmend diese Form. Multics-Systeme probierten andere Formate aus. Laut dem Bericht beschwerten sich daraufhin Nutzer, TENEX-Mailprogramme könnten ihre Nachrichten nicht parsen. Das ist der zeitgenössische Bericht eines Komitees, keine Zählung aller Hosts. Er zeigt dennoch, weshalb ein offizieller Dokumenttitel das Format nicht allein festlegte: Die bereits ausgetauschten Nachrichten und laufenden Parser formten die Erwartungen.

RFC 733 standardisierte die Grenze

RFC 733 erschien im November 1977 und löste RFC 561, RFC 680 sowie den Vorschlag RFC 724 ab. Der Text ordnete die Syntax von ARPANET-Textnachrichten, darunter Empfängeradressen und Verweise auf gespeicherte Adresslisten. Im Vorwort heißt es, die Arbeit sei ein Jahr lang im Mailumfeld selbst diskutiert worden; mehr als zwanzig Personen hätten mitgewirkt. Das belegt einen Arbeitsprozess, aber nicht, dass jedes System das Ergebnis übernahm.

Der RFC grenzt seinen Zweck ausdrücklich ein: Er definiert das Nachrichtenformat, das zwischen Hosts übertragen wird. Er schreibt weder vor, welche Funktionen ein lokales Mailsystem unterstützen muss, noch wie Programme zum Schreiben und Lesen aussehen sollen. Strukturierte Felder waren möglich; welche ein Host automatisch verarbeitete, blieb ihm überlassen. Die Autoren erwarteten, dass das gemeinsame Format den unmittelbaren Bedarf decken und Entwicklern Zeit für ein separates Mailübertragungsprotokoll „sachgerecht“ geben würde.

Das war ein pragmatischer Kompromiss: erst die Nachrichtenform gemeinsam machen, die Gestaltung des lokalen Dienstes aber offenlassen. Absender und Empfänger konnten unterschiedliche Systeme nutzen, ohne dieselbe Oberfläche zu haben. Daraus entstand jedoch nicht automatisch Kompatibilität. Parser mussten weiterhin geschrieben werden, und die tatsächliche Übernahme hing von den Hosts ab, die sie ausführten.

Spätere Standards machten die Trennung deutlicher

1982 definierte RFC 821 das Simple Mail Transfer Protocol als Übertragungsmechanismus zwischen Hosts über einen zuverlässigen, geordneten Datenstrom. RFC 822 spezifizierte im selben Jahr separat das Format von ARPA-Internet-Textnachrichten und löste RFC 733 ausdrücklich ab. Zusammen gelesen trennen die beiden Dokumente zwei Fragen: Wie wird eine Nachricht transportiert, und wie ist ihr Inhalt aufgebaut?

Die Quellen tragen eine begrenzte historische Aussage, aber nicht die Behauptung, RFC 733 habe E-Mail erfunden oder alle Mailsysteme sofort vereinheitlicht. RFC 724 berichtet von einer weit verbreiteten, aber informellen Header-Konvention. RFC 733 liefert eine formelle Syntax und grenzt ihren Umfang ab. RFC 821 und RFC 822 dokumentieren später getrennte Standards für Transport und Inhalt. Keines dieser Dokumente misst, wie viele Hosts jede Regel umsetzten oder wann ein bestimmtes System wechselte.

Quellen und Beweisgrenzen

Die Primärquellen sind RFC 524, RFC 561, RFC 680, RFC 724, RFC 733, RFC 821 und RFC 822. Die Aussagen über TENEX und Multics sind dem zeitgenössischen RFC 724 zugeschrieben und werden nicht zu einer netzweiten Übernahmequote verallgemeinert. Heng Lus spätere Note 64 zu minimaler Anfangsspezifikation, lokalen künftigen Entscheidungen und freiwilliger Übernahme dient nur als analytische Perspektive. Sie belegt nicht die Absichten der Autoren in den 1970er-Jahren.

Quellen