Zusammenfassung

  • RFC 3461 ließ SMTP-Clients Erfolg, Fehlschlag oder Verzögerung pro Empfänger melden und zwei Identitäten durch Relays tragen: die Einlieferungstransaktion und den ursprünglichen Empfänger. RFC 3464 strukturierte die Antwort maschinenlesbar.
  • Die Begriffe begrenzen ihre Aussage selbst. delivered heißt nicht gelesen, relayed kennzeichnet das Ende verlässlicher Erfolgsmeldung, und auch eine formal korrekte DSN kann gefälscht, verloren oder aus Vertraulichkeitsgründen abgeschnitten werden.

Der alte Rückläufer war meist eine weitere E-Mail mit freiem Fehlertext. Mal enthielt sie nur Kopfzeilen, mal den ganzen Inhalt, mal ein lokales Diagnoseprotokoll. Für einen einzelnen Absender konnte das genügen. Bei großen Verteilerlisten blieb häufig unklar, welcher Host, welcher Empfänger und welche Einlieferung betroffen waren. Menschen und Programme mussten aus uneinheitlicher Prosa eine Betriebslage rekonstruieren.

Das war mehr als ein Darstellungsproblem. Nimmt ein SMTP-Server einen Empfänger mit positiver RCPT-Antwort an, übernimmt er normalerweise Verantwortung: zustellen oder später einen Fehlschlag melden. Diese Regel sagt jedoch nicht, ob der Absender Erfolg, Scheitern, ungewöhnliche Verzögerung oder gar nichts erfahren möchte. Sie erhält auch nicht automatisch die ursprüngliche Adresse, wenn Weiterleitung den aktuellen Empfänger umschreibt.

Die im Januar 2003 veröffentlichten RFC 3461, 3463 und 3464 trennten Anforderung, Berichtsformat und Statussystem. Ihr Ziel war keine universelle Empfangsgarantie. Sie verteilten genauer, wer eine Spur bestellen, wer eine betriebliche Handlung erklären und wie weit diese Erklärung reichen konnte.

Vier Parameter hielten Wunsch und Ergebnis auseinander

Unterstützung erscheint als DSN im EHLO-Angebot. Neue SMTP-Verben waren nicht nötig. MAIL erhielt RET und ENVID, RCPT erhielt NOTIFY und ORCPT.

NOTIFY gilt je Empfänger. SUCCESS, FAILURE und DELAY lassen sich kombinieren; NEVER muss allein stehen. Fehlt der Parameter, darf der Server traditionell nur Fehlschläge oder zusätzlich Verzögerungen melden. Der Absender bestimmt, welche Nachweise er empfangen will, nicht den Ausgang.

Auch DELAY setzt keine Frist. Das MTA mit der wartenden Nachricht beurteilt, wann die Verzögerung ungewöhnlich wird. Der Endzustand ist dann noch offen. Dieselbe 4.x.x-Bedingung kann zunächst mit delayed erscheinen, solange Versuche laufen, und später mit failed, wenn die Warteschlange aufgibt.

RET=FULL fordert bei einem Fehlschlag die gesamte Ursprungsnachricht zurück, RET=HDRS nur ihre Kopfzeilen. Enthält der Bericht keinen fehlgeschlagenen Empfänger, sollen nur Kopfzeilen zurückkehren. Die Wahl berührt Diagnose und Datenschutz zugleich: Ein vollständiger Rücklauf erzeugt eine weitere Inhaltskopie auf einem anderen Weg.

Zwei Kennungen bewahrten zwei verschiedene Identitäten

ENVID bezeichnet die Umschlagtransaktion und kehrt gegebenenfalls als Original-Envelope-Id zurück. Das Mailsystem deutet den Wert nicht; seine Bedeutung liegt beim Absender oder dessen Programm. Er ist nicht mit der Message-Id im Nachrichtenkopf identisch. Diese bezeichnet Inhalt, jener eine konkrete Einlieferung. Derselbe Inhalt kann mehrfach versandt werden, während eine Transaktion mehrere Empfänger mit unterschiedlichen Ergebnissen enthält.

ORCPT erhält den vom Absender ursprünglich genannten Empfänger. Bei der ersten Einlieferung muss er RCPT TO entsprechen. Nach einer Weiterleitung darf sich die operative Adresse ändern, der ursprüngliche Wert reist weiter. So beantwortet die aktuelle Adresse den nächsten Zustellschritt, ORCPT dagegen die Zuordnung zum Auftrag des Absenders.

Beide Werte ermöglichen Abgleich, aber keine Authentisierung. Eine plausible ENVID beweist den Berichtsersteller nicht. Eine ORCPT-Adresse beweist keine Person. Es sind Korrelationsgriffe, deren Nutzen von ehrlicher Weitergabe und gesonderter Herkunftsprüfung abhängt.

Action beschrieb die Entscheidung, Status die Bedingung

RFC 3464 definiert eine DSN als multipart/report: zuerst eine menschenlesbare Erklärung, dann message/delivery-status mit nachrichtenweiten und empfängerbezogenen Feldern, optional gefolgt von Ursprungsnachricht oder Kopfzeilen.

Jeder Empfänger erhält eine von fünf Action-Angaben: failed, delayed, delivered, relayed oder expanded. Daneben steht ein Status nach RFC 3463. 2.x.x bezeichnet Erfolg, 4.x.x anhaltenden vorübergehenden Fehler, 5.x.x dauerhaften Fehler; weitere Teile grenzen Gegenstand und Detail ein.

Die Felder sind nicht redundant. Ein DNS-Zeitüberschreiten kann dieselbe 4.x.x-Klasse behalten, während die Aktion von delayed zu failed wechselt. Status beschreibt die Lage, Action die Entscheidung, weiterzuversuchen oder abzubrechen.

failed ist endgültig, delayed nicht. delivered beendet den Zustand für diesen Empfänger, kann aber die Übergabe an einen Listenverteiler meinen und sagt nie, dass ein Mensch gelesen hat. expanded bedeutet, dass ein Mehrfachempfänger-Alias angenommen und neue Ziele erzeugt hat; weitere Meldungen können folgen.

relayed ist die ehrlichste Grenze. Die Nachricht wurde an eine Umgebung übergeben, die keine Verantwortung für positive DSNs übernimmt. Das MTA belegt die Übergabe, nicht den endgültigen Posteingang. Der Standard nennt den Verlust an Beobachtbarkeit, statt ihn als Erfolg auszugeben.

Ein Bericht über Scheitern durfte keinen Berichtsnachwuchs erzeugen

Eine DSN ist selbst E-Mail und kann scheitern. Würde daraus die nächste DSN entstehen, könnten unerreichbare Systeme Endlosschleifen von Meldungen über Meldungen erzeugen. Per SMTP versandte DSNs verwenden deshalb den leeren Rückpfad MAIL FROM:<>. Ihr eigener Fehlschlag löst keine weitere Netzmeldung aus.

Stabilität gewinnt hier gegen rekursive Sichtbarkeit. Der Absender erfährt möglicherweise nie vom verlorenen Bericht. Diese begrenzte Unkenntnis ist sicherer als unbegrenzte Rückkopplung.

Zwischen DSN-fähigen Relays sollen Anforderungen und Kennungen weitergegeben werden. Beim Übergang in ein fremdes Nachrichtensystem bleibt nur bestmögliche Übersetzung. Vertrauliche Weiterleitung kann die Sicht zusätzlich bewusst verkürzen: entfernte Felder auslassen, positive Meldungen stoppen oder am Übergang relayed berichten. Vollständige Telemetrie und ein verborgenes Weiterleitungsziel passen nicht immer zusammen.

Struktur bedeutete nicht Echtheit

RFC 3464 warnt, dass DSNs so leicht fälschbar sind wie gewöhnliche Internetmail. Ein erfundener Erfolg kann Nachfassen beenden; ein falscher Fehlschlag Wiederholungen, Listenausschluss oder falsche Supportmaßnahmen auslösen. ENVID erleichtert Zuordnung, ist aber keine Signatur.

Auch zurückgesandter Inhalt schafft Risiken. FULL kopiert möglicherweise vertraulichen Text in neue Systeme, Protokolle und Postfächer. Kopfzeilen allein verraten bereits Beteiligte, Betreff und Weg. Die Auswahl steuert den Umfang, nicht jede spätere Speicherung.

Die historische Leistung von DSN ist daher eine Grammatik begrenzter Autorität. Der Absender wählt Anfrage und Kennungen. MTAs entscheiden über Annahme, Wiederholung und Abbruch und melden ihre eigene Handlung. Gateways übersetzen nur bis zu ihrer Grenze, vertrauliche Weiterleitung darf Offenlegung beenden, und menschliches Lesen liegt ganz außerhalb von SMTP.

IANA führt DSN weiterhin als SMTP-Diensterweiterung mit RFC 3461. Die Quittung wurde wertvoll, weil sie Transaktion, ursprünglichen Empfänger, meldendes System, Handlung und Diagnose präzisiert, ohne Posteingang oder Aufmerksamkeit zu versprechen. Ihre Grenze gehört zum Beleg.

Quellen