Zusammenfassung

  • Gewöhnliche SMTP-Post nennt im Reverse-Path ein Ziel für spätere Zustellberichte. Eine Benachrichtigung verwendet MAIL FROM:<>, damit ihr eigenes Scheitern keine weitere Benachrichtigung auslöst.
  • Der Nullpfad ist ein gültiger Wert des SMTP-Umschlags, nicht dasselbe wie ein fehlendes sichtbares From: und weder Vertrauensbeweis noch Freistellung von Prüfungen. HELO und SPF lassen weiterhin eine Bewertung des sendenden Hosts zu.
  • Strukturierte DSNs machten Empfängerergebnisse und Zuordnung genauer, hielten aber am terminalen Absender fest. Wo der entfernte Bericht endet, geht die Pflicht zur Bearbeitung an den lokalen Betreiber zurück.

Das zweite Schreiben entsteht erst nach der Annahme

Solange ein SMTP-Client verbunden ist, kann der Server einen ungültigen Empfänger oder eine unzulässige Nachricht unmittelbar ablehnen. Die negative Antwort läuft über die bestehende Sitzung; der Client weiß, dass er die Nachricht noch besitzt. Eine zusätzliche E-Mail ist nicht nötig.

Schwieriger wird es nach einer positiven Antwort auf DATA. Damit hat der Empfänger die Verantwortung für Zustellung, Weiterleitung oder einen späteren Bericht übernommen. Erst danach kann sich herausstellen, dass das nächste System unerreichbar ist, ein Postfach nicht mehr existiert oder eine Verteilerliste auf ein ungültiges Ziel expandiert. Die ursprüngliche Verbindung ist beendet. Der Fehler selbst muss zur Nachricht werden und an den Reverse-Path des ursprünglichen Umschlags gehen.

Gäbe man dieser Meldung wiederum eine normale Rücksendeadresse, entstünde ein neues Versprechen. Kann sie nicht zugestellt werden, folgt eine Meldung an ihren Absender. Scheitert auch diese, folgt die nächste. Zuverlässigkeit hätte keinen natürlichen Abschluss.

Schon RFC 821 beschrieb 1982 sowohl die Pflicht eines Relays, einen später entdeckten Fehler zu melden, als auch die Gefahr von Meldungen über Probleme mit Meldungen. Die knappe Lösung lautete MAIL FROM:<>.

Die Winkelklammern bezeichnen kein Postfach mit leerem Namen. Sie sagen, dass für diese Transaktion kein entferntes Ziel für einen weiteren Zustellbericht existiert. Erzeuger, Verbindung, Empfänger und Spurinformationen verschwinden nicht. Entfernt wird nur die rückwärts gerichtete Kante, die sonst eine weitere Fehlernachricht verlangen würde.

Ein leerer Wert wurde zur Pflicht

RFC 1123 machte die Unterstützung des leeren Reverse-Path verbindlich. Ein Server darf MAIL FROM:<> nicht allein deshalb als fehlerhaft behandeln, weil keine gewöhnliche Mailbox angegeben ist.

Zugleich vervollständigte der Standard die Abbruchregel. Eine nach der Annahme erzeugte Fehlerbenachrichtigung muss den Nullpfad tragen. Ist die ursprüngliche Rücksendeadresse bereits null, darf keine Benachrichtigung erzeugt werden. Beide Seiten gehören zusammen: Wer Null pauschal ablehnt, verliert legitime Infrastrukturpost; wer ihn akzeptiert, aber darauf antwortet, stellt die Rekursion wieder her.

Der leere Wert transportiert also positive Information. Er unterscheidet „vergessen“ von „bewusst beendet“. Systeme, die aus Gründen der Datenvollständigkeit jeden Leerwert durch eine vermutete Adresse ersetzen, können genau die Kontrollinformation zerstören, die das Netz stabil hält.

Umschlag und sichtbarer Absender führen verschiedene Gespräche

Der Reverse-Path ist Teil der SMTP-Transaktion. From: im Nachrichtenkopf erklärt dem Leser einen Absender; Reply-To: kann einen Ort für eine überlegte menschliche Antwort nennen. Eine automatisch erzeugte Zustellmeldung darf im sichtbaren From den betreibenden Dienst bezeichnen und zugleich im Umschlag MAIL FROM:<> verwenden.

Das ist kein Widerspruch. Die Kopfzeile führt ein menschliches Gespräch, der Umschlag verteilt maschinelle Haftung für einen Zustellfehler. Kopiert eine Automatisierung From oder Reply-To in den leeren Umschlag, weil eine Adresse „fehlt“, verbindet sie eine absichtlich entfernte Kante wieder.

RFC 5321 bindet diese Bedeutung an die Annahmegrenze nach DATA. Ist ein Fehler bereits während der Transaktion sicher erkennbar, ist eine frühe Ablehnung meist sauberer: Der tatsächlich verbundene Client erhält die Antwort, und es entsteht kein Bounce an einen möglicherweise gefälschten Reverse-Path.

Manche Fehler zeigen sich notwendigerweise später – etwa temporäres DNS-Versagen, nachgelagerte Gateways, asynchrone Verarbeitung oder Listenexpansion. Dann ist die Meldung unvermeidlich. Der Nullabsender begrenzt das neu entstandene Risiko auf genau einen Ast.

Backscatter löst er nicht vollständig. Ein Angreifer kann in einer gewöhnlichen Nachricht die Adresse eines Unbeteiligten als Reverse-Path fälschen. Nimmt ein Server zunächst an und weist später ab, erreicht die erste Meldung dennoch das Opfer. Der Nullpfad verhindert nur weitere Meldungen über diese Meldung. Frühe Ablehnung, Hostautorisierung und Missbrauchskontrollen schützen andere Übergänge.

Das Ende der Fernmeldung ist keine Erlaubnis zum Vergessen

Kann eine legitime DSN selbst nicht zugestellt werden, muss das externe Gespräch enden. Das betriebliche Problem bleibt. RFC 5321 erlaubt lokale Protokollierung oder Übermittlung von Informationen über Fehler bei Nullabsender-Nachrichten und nennt die Möglichkeit, sie einem Postmaster vorzulegen, der das Mailsystem reparieren kann.

Diese lokale Route darf keine neue externe DSN erzeugen. Der Unterschied ist organisatorisch: Eine entfernte Meldung gibt dem ursprünglichen Reverse-Path Auskunft über die übernommene Zustellpflicht. Eine lokale Eskalation sagt dem Betreiber, dass selbst der terminale Bericht gescheitert ist und Warteschlange, Routing oder Konfiguration untersucht werden müssen.

Queue-ID, ursprünglicher Umschlag, Ergebnisse je Empfänger, letzte Diagnose und Wiederholungsgrenze bleiben wichtige, datenschutzgerecht zu speichernde Belege. <> bestimmt, wer nicht erneut angeschrieben werden darf; es bestimmt nicht, welche Fakten gelöscht werden dürfen.

DSN strukturierte den Bericht, nicht die nächste Rückfahrt

Frühe Unzustellbarkeitsmeldungen bestanden aus produktspezifischem Text. Das erschwerte die maschinelle Zuordnung zu Nachricht und Empfänger. RFC 3461 führte die SMTP-Erweiterung für Delivery Status Notifications ein. ENVID dient der Korrelation eines Umschlags, RET steuert den zurückgesandten Originalinhalt, ORCPT bewahrt den ursprünglichen Empfänger. NOTIFY kann SUCCESS, FAILURE oder DELAY verlangen; der allein stehende Wert NEVER verlangt keinen Bericht.

Diese Parameter beschreiben Berichtspräferenzen. Sie sollen die Annahme eines sonst gültigen MAIL- oder RCPT-Befehls nicht verändern. Vor allem überstimmen sie den Endzustand nicht: Für eine Nachricht mit nullem MAIL FROM darf ein MTA keine DSN erzeugen, auch wenn im sichtbaren Kopf eine plausible Absenderadresse steht.

Eine ausgesandte DSN verwendet ihrerseits den Nullabsender. In ihrer Transaktion wird RET nicht gesetzt; falls NOTIFY erscheint, ist nur NEVER zulässig. Ein Bericht kann also reich an Zustellbelegen sein und trotzdem jede Rückmeldung über sich selbst ausschließen.

RFC 3464 definierte das Format als multipart/report vom Typ delivery-status: eine menschenlesbare Erklärung, einen maschinenlesbaren Teil message/delivery-status und – je nach Rückgabe- und Datenschutzregeln – Material der Ursprungsnachricht.

Eine DSN gehört zu genau einer Ursprungsnachricht, darf aber mehrere Empfängerblöcke enthalten. Action unterscheidet failed, delayed, delivered, relayed und expanded; Status trägt einen strukturierten Code. Teilzustellung wird dadurch nicht zu einem pauschalen Fehlschlag. Ein Listenbetreiber kann nur einen dauerhaft gescheiterten Teilnehmer behandeln, während ein anderer Empfänger weiterhin im Wiederholungszustand bleibt.

Mehr Struktur schafft zugleich Datenschutzrisiken. Empfänger, geheime Weiterleitungsadressen und Teile der Ursprungsnachricht können sichtbar werden, weshalb Felder an Vertraulichkeitsgrenzen ausgelassen werden dürfen. Außerdem kann eine DSN gefälscht werden. Die Felder liefern einen präzisen Betriebsbericht, aber keine Nichtabstreitbarkeit.

Auch Abwesenheitsroboter brauchen einen Endzustand

Automatische Zustellberichte sind nicht die einzigen Nachrichten, die einander auslösen können. Abwesenheitsantworten, Gruppendienste, Helpdesks und Inhaltsprozessoren können gegenseitig reagieren. RFC 3834 verallgemeinert deshalb die Regel: Ein Automat darf keine Antwort erzeugen, deren Ziel eine Nulladresse wäre, und sollte normalerweise den Umschlag-Return-Path statt eines aus From oder Reply-To erratenen Ziels verwenden.

Soll auf eine automatische Antwort keine weitere Automatik reagieren, kann sie MAIL FROM:<> nutzen; bei verfügbarer DSN-Erweiterung ist NOTIFY=NEVER sinnvoll. Schleifenfreiheit ist jedoch keine Autorisierung. Rückadressen lassen sich fälschen. Ein Dienst, der große Antworten oder Nebenwirkungen auslöst, braucht zusätzlich einen Grund anzunehmen, dass der Betroffene die Anfrage veranlasst hat.

Für die Submission stellt RFC 6409 klar, dass ein Nullpfad allein kein Ablehnungsgrund ist. Legitime Mailprogramme erzeugen solche Nachrichten, darunter bestimmte Disposition Notifications. Authentisierung, Berechtigung, Rate- und Inhaltsprüfung bleiben möglich. Der reservierte Zustand ist weder pauschal böse noch pauschal vertrauenswürdig.

Ohne Absender-Mailbox bleibt der Host prüfbar

SPF bewertet gewöhnlich die MAIL-FROM-Domäne. RFC 7208 legt für einen Nullpfad fest, die MAIL-FROM-Identität als postmaster an der HELO-Identität zu konstruieren. So bleibt eine Autorisierungsoberfläche für sendenden Host und Domäne erhalten.

Das Ergebnis beweist weder den Inhalt einer DSN noch die gemeldete Störung oder eine menschliche Identität. Ein autorisierter Host kann einen falschen Bericht erzeugen; eine echte Meldung kann an Fehlkonfiguration scheitern. Null bedeutet lediglich nicht, dass jede Prüfung entfällt.

Auch Null MX ist etwas anderes. Null MX erklärt im DNS, dass eine Domäne keine Mail annimmt. Der Null-Reverse-Path gehört zu einer konkreten Nachricht, die gerade übertragen wird, und beendet nur deren Rückmeldeast. Das eine schließt ein Ziel, das andere die Fehlerrekursion.

Quellen und Beweisgrenzen

Die ursprüngliche Unzustellbarkeitsmeldung und MAIL FROM:<> als Schleifenbremse stehen in RFC 821: https://www.rfc-editor.org/rfc/rfc821.html

Verbindliche Unterstützung des leeren Pfads und das Verbot einer Meldung an Null stehen in RFC 1123: https://www.rfc-editor.org/rfc/rfc1123.html

DSN-Umschlagparameter, Nullabsender-Behandlung und NOTIFY=NEVER stehen in RFC 3461: https://www.rfc-editor.org/rfc/rfc3461.html

Das strukturierte Multipart-Format, Felder je Nachricht und Empfänger sowie Datenschutzgrenzen stehen in RFC 3464: https://www.rfc-editor.org/rfc/rfc3464.html

Regeln für Abwesenheits-, Gruppen- und Dienstantworten stehen in RFC 3834: https://www.rfc-editor.org/rfc/rfc3834.html

Die heutige SMTP-Verantwortungsübergabe, Nullabsender-Klassen und lokale Postmaster-Route stehen in RFC 5321: https://www.rfc-editor.org/rfc/rfc5321.html

Legitime Nullabsender bei der Submission stehen in RFC 6409: https://www.rfc-editor.org/rfc/rfc6409.html

Die HELO-basierte SPF-Identität bei nullem Reverse-Path steht in RFC 7208: https://www.rfc-editor.org/rfc/rfc7208.html

Diese RFCs belegen Protokollpflichten, nicht die Echtheit einer einzelnen DSN oder aktuelle Providerpraxis. Der Artikel behauptet keine gegenwärtigen Bounce-, Spam-, Ablehnungs- oder Einführungsraten.