Zusammenfassung

  • RFC 821 erlaubte eine ausdrückliche Relay-Folge vor dem Zielpostfach; jeder Relay entfernte den eigenen Namen aus dem Vorwärtspfad und setzte ihn an den Rückwärtspfad.
  • RFC 1123 stellte gewöhnliche Zustellung auf universelle Domainnamen und DNS MX. Empfänger mussten die alte Syntax weiterhin annehmen, durften die Zwischenstationen aber verwerfen und die letzte Domain benutzen.
  • Modernes SMTP trennt Erkennen, Relay-Berechtigung und Ausführung: Ein Server darf die Route ignorieren, ablehnen oder in einem begrenzten Ausnahmefall exakt ausführen.

Dieselbe Zeichenfolge, verschiedene Befugnisse

Ein Client sendet:

RCPT TO:<[Relay alpha, Relay beta]:[Postfach user in Domain gamma]>

Das Postfach des Nutzers in Domain gamma ist das absolute Ziel. Alpha und beta bilden die gewünschte Relay-Folge. Ein Parser kann beides fehlerfrei auseinanderhalten, ohne beidem dieselbe Wirkung zu geben.

Ein Server entfernt die Liste und löst gamma.example auf. Ein anderer verweigert das Relaying. Ein dritter nutzt die Route während einer autorisierten Diagnose und verbindet zuerst zu alpha.example. Alle drei haben dieselbe Grammatik verstanden. Ob daraus ein Netzpfad entsteht, entscheidet erst die aktuelle Richtlinie.

Rückwärtskompatibilität kann also bewusst unvollständig sein: Sie schützt alte Eingaben vor Fehlinterpretation, nicht jede frühere Macht dieser Eingaben.

Als der Reiseplan im Envelope mitwanderte

RFC 822 definierte route-addr als optionale Route vor der absoluten Adresse. Der Absender konnte Hosts oder Übertragungsdienste nennen; die Route blieb vom eigentlichen Postfach getrennt.

RFC 821 führte diese Trennung im SMTP-Envelope aus. Sein Beispiel setzte die Relays ONE und TWO vor JOEs Postfach in Domain THREE: Das Postfach war das Ziel, ONE und TWO waren der Weg.

Erreichte die Nachricht einen genannten Relay, nahm der Server seinen Bezeichner aus dem forward-path, setzte ihn an den Anfang des reverse-path, wurde zum SMTP-Sender und kontaktierte den nächsten Host. Der noch offene Hinweg schrumpfte; ein möglicher Rückweg für Fehler wuchs.

Trotzdem durfte der Relay den Auftrag ablehnen. Eine Hostliste war nie eine allgemeine Zugangsberechtigung. RFC 821 hielt die Pfade außerdem von To, From und CC getrennt. Transportanweisung und vom Autor sichtbare Nachricht waren unterschiedliche Datensätze.

Der dauerhafte Name ersetzte eine kurzlebige Wegbeschreibung

1989 verlangte RFC 1123, dass Sender die explizite Source-Route-Form nicht mehr erzeugen. Die Begründung war architektonisch: Internet-Mail hatte universelle Namensgebung statt Source Routing gewählt. SMTP stellte Konnektivität bereit, DNS global eindeutige und ortsunabhängige Namen, und MX deckte den wichtigsten früheren Bedarf für Relay-Listen ab.

Relays blieben bestehen. Neu war, wer sie auswählte. Der Sender nennt die Zieldomain; diese veröffentlicht Mail Exchanger; jeder beteiligte Server wählt nach heutiger Autorisierung, Erreichbarkeit und Richtlinie. Ändert sich die Topologie, kann die Domain DNS aktualisieren, ohne dass alle Korrespondenten ihre gespeicherten Adressen ändern.

Das Postfach kann dadurch stabiler bleiben als eine Folge von Zwischenstationen. Aus Routingwissen wurde wieder Infrastrukturzustand statt Teil einer dauerhaften Identität.

Syntax annehmen, Anweisung entfernen

RFC 1123 erklärte die alte Form nicht zum Syntaxfehler. Ein Empfänger musste sie akzeptieren. Implementierte er die historische Relay-Funktion nicht, sollte er die endgültige Postfachdomain direkt versuchen. Im Beispiel werden die Relays ALPHA und BETA entfernt und JOEs Postfach unmittelbar an Domain GAMMA geroutet.

RFC 2821 präzisierte die Grenze. Empfangssysteme müssen Source Routes erkennen, sollen sie aber abstreifen und die Postfachdomain verwenden, als wäre die Liste nie vorhanden gewesen. Routennamen dürfen nicht in den reverse-path kopiert werden. Bekannte Interpunktion allein rekonstruiert nicht mehr das Rückwegverfahren von RFC 821.

Ohne Parser können alte Clients scheitern oder Trennzeichen als local-part-Daten missverstanden werden. Mit automatischer Ausführung kann ein Legacy-Token einen Zwischenserver außerhalb heutiger Policy wählen. Erkennung schützt Interoperabilität; Nichtbefolgung schützt die Vertrauensgrenze.

Der heutige Standard bewahrt eine geregelte Ausnahme

RFC 5321 enthält A-d-l, die kommagetrennte Domain-Liste, weiterhin in der normativen Pfadgrammatik. Die Notiz fasst den Kompromiss zusammen: Die Form muss angenommen, sollte nicht erzeugt und sollte ignoriert werden.

Ein Server darf Relay-Dienst oder eine Adresse mit Route ablehnen. Er darf die Liste ignorieren und das letzte Ziel verwenden. Entscheidet er sich aber für ihre Ausführung, muss er zuerst an die erste genannte Domain senden und darf keine Abkürzung erraten. Auch eine veraltete Funktion hat bei bewusster Nutzung eine genaue Semantik.

Der Standard beschreibt eine Migrationsfalle. Manche Sender verwendeten ungültige endgültige Namen und verließen sich darauf, dass ein Zwischen-Relay sie auflöste. Entfernt ein konformer Server die Route, tritt diese Abhängigkeit offen zutage. Die Zeichenfolge bleibt grammatisch zulässig, während ihre alte Erfolgsbedingung verschwunden ist.

Debugging oder schwere vorübergehende Konfigurationsfehler können eine Ausnahme rechtfertigen. Die Befugnis entsteht dann durch eine ausdrückliche Betreiberentscheidung, nicht durch das bloße Aufschreiben von Hostnamen.

Im Header blieb ein anderes Fossil

RFC 5322 führt die route in der veralteten Adressgrammatik von Nachrichtenkopfzeilen und empfiehlt, sie bei der Interpretation zu ignorieren. Alte Archive bleiben damit lesbar, ohne historische Zeichen in einen aktiven SMTP-Befehl zu verwandeln.

Eine Route in einem alten To belegt weder die Envelope-Empfänger noch die tatsächlich durchlaufenen Server. Dafür braucht es Transaktionsdaten, Verbindungen und Received-Spuren mit jeweils eigenen Grenzen.

Quellen und Grenzen

RFC 821, RFC 822, RFC 1123, RFC 2821, RFC 5321 und RFC 5322 belegen Grammatik und Normenwandel. Sie messen keine heutige Verbreitung, Produktvorgaben, Filterquoten oder Zustellerfolge.

Die historische Aussage ist enger: SMTP behielt die Pflicht, eine alte Route zu verstehen, und entzog ihr die standardmäßige Befugnis, die wirkliche Route zu bestimmen.