Zusammenfassung

  • Eine explizite SMTP-Source-Route war veränderlicher Umschlagzustand: Jedes Relay verbrauchte sein erstes Element im Forward-Path und übertrug es in den Reverse-Path.
  • Route und absolutes Postfach waren verschieden, ebenso SMTP-Umschlag und sichtbare Felder To: oder From:. Der Pfad authentifizierte weder Autor noch tatsächlich durchlaufene Stationen.
  • MX und global deutbare Domainnamen verlagerten die gewöhnliche Routenwahl zu MTA, DNS und lokaler Richtlinie. Alte Syntax zu verstehen bedeutete nicht mehr, ihr Transit zu gewähren.

Ein Weg schrumpfte, der andere sammelte Zustand

Nach MAIL FROM konnte ein SMTP-Client folgenden Empfänger nennen:

RCPT TO:<@ONE,@TWO:JOE@THREE>

RFC 821 bezeichnet das RCPT-Argument als Forward-Path. JOE@THREE ist das absolute Postfach. @ONE,@TWO ist die Source-Route dorthin. Der Standard trennt beide Begriffe ausdrücklich, obwohl sie in einer gemeinsamen Zeichenfolge stehen.

Erkennt ONE sich im ersten Element, entfernt es @ONE. Übrig bleibt @TWO:JOE@THREE. Zugleich stellt ONE die eigene Kennung dem Reverse-Path voran. Aus einer noch auszuführenden Anweisung wird Zustand für den Weg, auf dem eine spätere Unzustellbarkeit zurückgemeldet werden kann.

Die Route war deshalb nicht nur eine ausführliche Schreibweise der Zieladresse. Ihr vorderer Teil wurde an jeder passenden Station verbraucht; der Rückweg sammelte den bereits übernommenen Abschnitt. Ein Relay führte eine definierte Zustandsänderung aus.

Der Umschlag war nicht der Briefkopf

Der Reverse-Path aus MAIL FROM ist ein Wert der SMTP-Transaktion. Er muss nicht dem sichtbaren From: entsprechen, ist nicht Reply-To: und beweist keine Urheberschaft. Seine Aufgabe liegt bei Transportverantwortung und späteren Fehlermeldungen.

Auch der Forward-Path aus RCPT TO ist keine vorgeschriebene Kopie von To: oder Cc:. Ein Inhalt kann mehrere Umschlagempfänger haben; ein Bcc-Empfänger bleibt im Text unsichtbar; ein sichtbarer Name muss in dieser Transaktion kein Empfänger sein.

RFC 822 trennte in route-addr Route und addr-spec und riet ohne besonderen Bedarf von Source-Routing ab. Die historische Nähe der Schreibweisen erlaubt dennoch nicht, Nachrichtenformat und Transportumschlag gleichzusetzen.

Wenn ONE seinen Namen in den Reverse-Path setzt, schreibt es also nicht den Autor um. Ein Archiv, das nur die ausgelieferte Nachricht speichert, kann die eingegangene Route vollständig verlieren. Beweise müssen nach ihrer Protokollschicht aufbewahrt werden.

Am Ausgang konnte ONE anders heißen als am Eingang

RFC 821 verlangt beim Einfügen in den Reverse-Path den Namen, unter dem das Relay in der ausgehenden Umgebung bekannt ist. Es sollte nicht blind die Bezeichnung aus der eingehenden Umgebung kopieren.

Das war für Gateways zwischen unterschiedlichen Namensräumen entscheidend. Eine scheinbar vollständige Nutzerroute hing dennoch von lokalem Kontext ab. Dieselbe Maschine konnte auf beiden Seiten verschieden bezeichnet werden; der Rückweg musste für den nächsten Bereich interpretierbar sein.

Ist der aktuelle Server nicht das erste Element des Forward-Path, darf er dieses Element nicht eigenmächtig löschen. Es kann die Wahl des nächsten SMTP-Servers steuern. Verbrauchsrecht entsteht aus der Übereinstimmung von Position und Identität.

Diese Übereinstimmung ist keine kryptografische Beglaubigung. Die Route beweist weder Domainkontrolle noch ehrlichen Durchlauf jeder genannten Station. Selbst ein gewachsener Reverse-Path ist ein Fehlerbehandlungsmechanismus, kein unveränderliches Herkunftsprotokoll.

MX verschob die Entscheidung aus der Adresse

RFC 974 ordnet einer Zieldomain Mail-Exchanger mit Präferenzen zu. Der sendende MTA fragt die Domain ab und probiert geeignete Kandidaten nach den Regeln. Der Nutzer kann bei user@domain bleiben, während sich die zuständigen Server ändern.

MX speichert keine serielle Source-Route in DNS. Die Exchanger sind keine nacheinander zu durchlaufenden Wegpunkte. RFC 974 warnt davor, rekursiv den MX eines MX zu verfolgen und daraus aufwendige Routen zu bauen.

Damit wurden stabiles Ziel und veränderlicher Weg getrennt. Der Nutzer benennt, wohin die Nachricht gehört. Der MTA entscheidet beim Versand, wohin er als Nächstes verbindet, und kann aktuelle Erreichbarkeit sowie lokale Regeln berücksichtigen.

Das verändert die Reparaturfläche. Eine veraltete Source-Route steckt womöglich in Adressbüchern, Aliasen und Warteschlangen. Eine MX-Änderung kann der verantwortliche Domainbetreiber an zentraler Stelle vornehmen. Topologiewissen wird Entscheidungsergebnis statt Bestandteil der Identität.

Die Abschaffung begann auf der Erzeugerseite

RFC 1123 sagt, ein Sender-SMTP solle in RCPT keine explizite @...:-Source-Route senden. Die Architektur entschied sich für universelle Benennung: user@domain, global sinnvolle Domainnamen und MX sollten den Hauptbedarf decken.

Der Receiver-SMTP musste die Syntax weiterhin akzeptieren. Akzeptieren heißt hier zunächst erkennen und parsen, nicht beliebigen Relay-Dienst zusagen. Implementiert der Server den gewünschten Weg nicht, kann er unter den beschriebenen Bedingungen die direkte Zustellung an die Domain rechts vom letzten @ versuchen.

Diese Asymmetrie ist eine Migrationsstrategie. Neue Clients vermehren die alte Form nicht mehr; alte Queues, Gateways, Aliase und Programme bleiben lesbar. Die Fähigkeit zur Interpretation überlebt die Befugnis zur normalen Erzeugung.

Würden Grammatik und Nutzung gleichzeitig verschwinden, zerbräche installierter Zustand abrupt. Behielte jede erkannte Route ihre volle Weisungskraft, gäbe es keinen Ruhestand. Kompatibilität bedeutet, einen alten Wunsch lesen und anschließend eine heutige Entscheidung treffen zu können.

Parser-Kompatibilität ist keine Open-Relay-Zusage

Ein Server kann @ONE,@TWO:JOE@THREE korrekt zerlegen und den Transit dennoch wegen Authentisierung, Quellnetz, Ziel oder lokaler Anti-Missbrauchsregeln verweigern. Syntaxerkennung und Relay-Autorisierung sind getrennte Kontrollen.

RFC 2821 erklärt Source-Routes für deprecated. Server müssen auf die Syntax vorbereitet sein, sollten die Route gewöhnlich ignorieren und dürfen Relay ablehnen. Clients sollten sie nicht erzeugen.

Wird die Route ignoriert, dürfen ihre Zwischenstationen nicht in den Reverse-Path kopiert werden. Das Verschieben aus RFC 821 gehört zum historischen Modus, der die Route tatsächlich verwendet. Es ist kein allgemeiner Umbau jeder modernen SMTP-Nachricht.

Wählt ein Server ausnahmsweise den Routengebrauch, muss er zur ersten angegebenen Domain senden und darf keine Abkürzung erraten. Klar ignorieren oder ablehnen ist nachvollziehbarer, als einzelne Elemente stillschweigend neu zu ordnen.

Die Aussage „Source-Route akzeptiert“ ist daher ohne Stufe wertlos. Wurde nur die Grammatik akzeptiert, der Empfänger angenommen, Relay autorisiert oder nach DATA Verantwortung übernommen? Jede Stufe hat andere Folgen.

In Mail-Inseln war Nutzerwissen eine Routing-Ressource

RFC 1711 beschreibt 1994 explizites Source-Routing als Einbau eines gewünschten MTA in die Adresse. Erreicht die Nachricht dieses MTA, entfernt es sich selbst und routet den Rest weiter.

In einer Welt locker verbundener „Mail-Inseln“ konnte ein Nutzer wissen, welches Gateway eine ferne Insel erreichte. Dieses Wissen in die Adresse zu schreiben, ergänzte Erreichbarkeitsinformation, die die Infrastruktur noch nicht allgemein bereitstellte.

Mit wachsender Internet-Verbindung wurde das Topologiewissen des Endnutzers für den Normalfall überflüssig und alterte schlecht. RFC 1711 nennt außerdem uneinheitliche Behandlung durch Relays als Grund für die Ablehnung.

Das ist eine historische Bewertung von 1994, keine heutige Messung. Sie beweist nicht, dass alle Gateway- oder Diagnosefälle zugleich verschwanden. Sie dokumentiert aber, wie ein früher Vorteil zur Last wurde: Die statische Karte des Nutzers konkurrierte mit dynamischen Systemen näher am aktuellen Zustand.

Percent-Hack, UUCP-Bang-Pfade und Gateway-Abbildungen gehören in die Nachbarschaft, sind aber nicht dieselbe Grammatik und führen nicht zwingend dieselbe Forward/Reverse-Transformation aus. Der Gegenstand bleibt @relay1,@relay2:user@host.

Obsolet hieß weiterhin lesbar

RFC 5321 erklärt, MX habe den normalen Bedarf für explizite Source-Routes beseitigt; die Forderung nach Fully Qualified Domain Names habe die letzte bedeutende allgemeine Begründung entfernt. Clients sollten sie nur in ungewöhnlichen Fällen wie Diagnose oder einem schweren vorübergehenden DNS-Problem einsetzen.

Server erkennen die obsolete Syntax weiter. Sie können Relay ablehnen, die Route ignorieren und das Endziel behandeln oder sie in engen Ausnahmen regelgerecht verwenden. Grammatische Existenz verleiht keine operative Normalität.

Ignorieren garantiert keine Rettung. Manche alten Adressen verließen sich auf Namen, die nur in einer Zwischenumgebung auflösbar waren. Nach Entfernung der Route kann die endgültige Domain global bedeutungslos sein. Kompatibilität kann einen verlorenen lokalen Namensraum nicht erraten.

Die Frage „unterstützt oder nicht“ ist deshalb zu grob. Erkannt, aufbewahrt, ignoriert, abgelehnt und verwendet sind verschiedene Zustände. Hinzu kommen Auflösung des Endziels und der Zeitpunkt der Verantwortungsübernahme.

Geschriebener Weg ist kein durchlaufener Weg

Ein gespeichertes @ONE,@TWO beweist zunächst nur diese Zeichenfolge. Ohne Sitzungsdaten ist nicht belegt, dass ONE sich entfernte, TWO kontaktiert oder THREE erreicht wurde. Dafür braucht es Antworten, Endpunkte, Auflösung, Queue und Zeit.

Umgekehrt beweist ein normalisiertes JOE@THREE nicht, dass keine Route einging. Ein Grenz-MTA kann sie entfernt, ein Sammler nur das Postfach gespeichert oder der Nachrichtentext sie nie enthalten haben.

Ein belastbarer Datensatz bewahrt Rohargument, Parse-Ergebnis, use/ignore/reject-Entscheidung, nächsten Hop und Resultat getrennt. Die normalisierte Form ist eine nützliche Projektion, darf aber die empfangene Evidenz nicht ersetzen.

Auch der Reverse-Path authentifiziert die Relays nicht. Er unterstützt die Fehlerführung; er garantiert weder einen einzigen ehrlichen Durchlauf noch die Kontrolle über jeden Namen. Schlussfolgerungen dürfen nicht stärker sein als das spezifizierte Feld.

Grenze der Quellen

RFC 821, RFC 822, RFC 974, RFC 1123, RFC 1711, RFC 2821 und RFC 5321 belegen Grammatik, normative Übergänge und historische Einordnung. Sie messen keine heutige Verbreitung, Produktkonformität, offenen Relays, Angriffe oder Zustellquoten.

Sie machen SMTP-Source-Routing auch nicht zu IPv4-LSRR oder -SSRR. Ähnliche Wörter übertragen weder Schicht noch Objekt, Verarbeiter, Bedrohung oder Autorität.