Zusammenfassung

  • 251 bestätigt den alten Envelope-Empfänger und verpflichtet den Server zur Weiterleitung; 551 weist ihn zurück und gibt dem Client nur eine mögliche neue Adresse.
  • Spätere Regeln erlauben dieselbe Verantwortung ohne Offenlegung: stilles Weiterleiten mit 250, nicht näher begründete Ablehnung mit 550.
  • Der korrigierte Pfad beweist weder Personenidentität noch eine globale Umbenennung. Eine dauerhafte Kontaktänderung braucht glaubwürdige Serverherkunft und eigene Autorisierung.

Gleiche Adresse, anderer Besitzer des Problems

Ein Client sendet RCPT TO an ein altes Postfach. Bei 251 ist der Empfängerschritt erfolgreich: Der Server hat die Nachrichtspflicht übernommen und wird weiterleiten. Bei 551 ist der Schritt dauerhaft fehlgeschlagen: Der Server hat nicht übernommen, auch wenn er im Text eine Alternative nennt.

Wer beides als „Empfänger umgezogen“ normalisiert, verliert den entscheidenden Zustand. Ein zweiter Versand nach 251 kann doppelt zustellen. Untätigkeit nach 551 kann verlieren. Die Ziffern ordnen Verantwortung; der neue Pfad ergänzt Wissen.

Die Gabel im SMTP von 1982

RFC 821 beschrieb Fälle, in denen der angegebene forward-path falsch war, der empfangende SMTP-Server aber das richtige Ziel kannte. Host, Benutzerteil oder beide konnten abweichen.

251 User not local; will forward nannte den künftigen Pfad und machte den Empfänger für die aktuelle Zustellung verantwortlich. 551 User not local; please try verweigerte die Annahme; der Sender musste umleiten oder dem ursprünglichen Benutzer einen Fehler liefern.

Damit war die Korrektur nie nur eine Adressauskunft. Sie war an die Entscheidung gebunden, ob die gegenwärtige Transaktion an dieser Stelle weiterbestand.

Eine Transaktion schreibt kein Adressbuch

Der Client kann korrekt handeln, ohne den Vorschlag zu speichern. Nach 251 gilt der alte Empfänger in dieser Transaktion als angenommen. Nach 551 ist ein Versuch mit dem neuen Pfad eine neue Aktion. Anzeigen, einmaliges Wiederholen und dauerhaftes Ersetzen sind nicht dasselbe.

RFC 5321 untersagt dem Server die Annahme, der Client werde seine Daten wirklich ändern oder die Information einem Menschen zeigen. Die Aussage über eigene Annahme ist verbindlich; die Hoheit über fremde Kontaktbestände ist es nicht.

Weiterleiten, ohne das Ziel zu verraten

Als RFC 2821 SMTP neu fasste, war silent forwarding verbreitet. Unternehmen versteckten interne Postfächer hinter stabilen Adressen, Menschen verbanden alte Konten mit privaten neuen Zielen. Die finale Adresse konnte für den Absender unerreichbar oder sensibel sein.

Annahme und Offenlegung wurden deshalb orthogonal. Ein Server kann mit 251 annehmen und offenlegen oder mit 250 annehmen und schweigen. Er kann mit 551 ablehnen und verweisen oder mit 550 ablehnen und nichts Adressspezifisches mitteilen. RFC 5321 empfiehlt Konfigurationsmöglichkeiten, um die verratenden Varianten einzuschränken.

Schweigen ändert nicht die Custody-Aussage. 250 bleibt Erfolg, 550 bleibt Ablehnung. Nur die Karte hinter dem nächsten Tor wird verborgen.

Umgezogen ohne öffentliches Nachsendeziel

RFC 3463 definierte X.1.6: Zielpostfach umgezogen, keine Weiterleitungsadresse. Das aktuelle IANA-Register der erweiterten SMTP-Statuscodes führt diesen permanenten Fehler weiter.

Vielleicht existiert kein Ersatz, vielleicht kennt der Server ihn nicht, vielleicht darf er ihn nicht nennen oder nur der interne Forwarder kann ihn erreichen. Aus der Bewegung entsteht kein Recht, Header, alte Spuren oder externe Verzeichnisse nach einer vermeintlichen Identität zu durchsuchen.

RFC 3464 warnt, dass DSNs wie gewöhnliche Mail gefälscht werden können. Es erkennt außerdem Empfänger an, die automatisch weiterleiten, ohne das Ziel offenzulegen. Implementierungen sollen diese Vertraulichkeit schützen können. Der Weg kann fortgesetzt werden, ohne an den Absender zurückgespiegelt zu werden.

Maschinenlesbare Korrektur als langlebiger Angriff

Normalerweise entscheidet ein SMTP-Client anhand des Codes und kann freien Text ignorieren. Der Ersatzpfad in 251 und 551 ist eine Ausnahme, wenn Software ihn nutzen will. Eine manipulierte Antwort kann dadurch dauerhaft in Automatisierung eindringen.

RFC 5321 warnt vor automatischer Änderung künftigen Verhaltens, etwa des Adressbuchs, ohne Gewissheit über die Authentizität des Servers. Ein Angreifer in der Mitte kann ein anderes Postfach einsetzen. Wird es gespeichert, überlebt der Angriff die Verbindung.

Auch ein authentischer Server beweist nur die Herkunft der Erklärung. Er beweist nicht, dass dieselbe Person das neue Postfach kontrolliert, dass der Wechsel endgültig ist oder dass sein Administrator das kanonische Kontaktverzeichnis eines Benutzers ändern darf. Authentizität begrenzt Fälschung, nicht Bedeutung.

Alias ändert den Envelope-Empfänger

RFC 5598 trennt gewöhnliches MTA-Relaying vom Alias. Ein Relay nähert die Mail ihrem Ziel, ohne die Envelope-Adressen zu ändern. Ein Empfänger-Alias reicht sie an alternative Empfänger weiter und behält Inhalt sowie üblicherweise den ursprünglichen MailFrom bei.

Mechanisch ändert sich womöglich nur RCPT TO. Semantisch hat der zuerst benannte Empfänger einen anderen gewählt. Ein späterer Fehler kann zum ursprünglichen Autor zurückkehren, der von dieser verborgenen Entscheidung nichts weiß.

Weiterleitung verschiebt operative Verantwortung, aber sie schreibt weder sichtbares To, Message-ID noch persönliche Identität automatisch um. 251 und 551 sind lokale Aussagen über einen Envelope, keine weltweite Namensänderung.

Begrenzte Korrektur als Stärke

Die Codes hielten vier Fragen auseinander: annehmen, weiterleiten, offenlegen, merken. Spätere Datenschutzregeln entfernten nicht die Funktion, sondern die Annahme, jede bekannte Adresse müsse veröffentlicht werden.

SMTP konnte einer Nachricht helfen, einem umgezogenen Postfach zu folgen, ohne zu behaupten, der Mensch sei im Internet umbenannt worden. Gerade diese Begrenzung machte stilles wie offenes Forwarding kompatibel.