Zusammenfassung

  • Die positive Abschlussantwort auf den finalen DATA-Terminator bedeutet, dass der SMTP-Empfänger die Nachricht angenommen und die Verantwortung für Zustellung oder Weiterleitung übernommen hat. Sie quittiert Verwahrung, nicht das Ziel.
  • 250 ist nur zusammen mit Befehl und Protokollzustand beweiskräftig. Nach EHLO, MAIL, RCPT, RSET oder NOOP bezeichnet derselbe Code andere abgeschlossene Aktionen.
  • Ein belastbarer Nachweis verbindet Envelope, Empfängerantworten, DATA-Abschluss, dauerhafte Queue, jeden Folge-Hop und die lokale Übergabe. Platzierung, Filter und menschliches Lesen bleiben eigene Tatsachen.

Der Code braucht seinen Satz

In einem Log steht 250 OK. Ohne den beantworteten Befehl ist das wie ein „erledigt“ ohne Aufgabe.

EHLO kann mit 250 den Anfangszustand und Erweiterungen bestätigen. MAIL FROM erhält den Code, wenn der Reverse Path akzeptiert wird. RCPT TO erhält ihn für einen einzelnen Forward Path. RSET wird nach dem Verwerfen des Transaktionszustands positiv beantwortet, NOOP sogar ohne Zustandsänderung.

Erst nach dem Inhalt entsteht die hier untersuchte Verpflichtung. Der Server hat zunächst mit 354 das Senden zugelassen. Der Client überträgt Nachricht und Endemarkierung. Nun verarbeitet der Empfänger Reverse Path, angenommene Empfänger und gespeicherte Daten. Nimmt er die Transaktion für die Zustellung an, antwortet er positiv; andernfalls muss er ablehnen. Das Basismodell kennt an dieser Grenze keine teilweise Annahme.

Die positive Abschlussantwort verschiebt die Verantwortung. Der Sender darf seine Kopie löschen, weil der Empfänger verspricht, die Nachricht zuzustellen, weiterzuleiten oder einen später erkannten Fehler ordnungsgemäß zu behandeln. Er hat nicht die Mailbox beobachtet.

Ein Monitoring, das nur drei Ziffern speichert, zerstört diese Zuständigkeitsgrenze. Es braucht Connection und Transaction, konkreten Befehl, MAIL FROM, alle RCPT-Ergebnisse, DATA-Ende, Zeit, beobachtete Serveridentität und Queue-Handle.

John Klensins Rolle bleibt ebenso begrenzt. Das offizielle IETF-Profil bezeichnet ihn als Dr. John C. Klensin und listete bei der Recherche 60 RFCs. RFC 5321 nennt ihn als Autor. Das belegt Mitarbeit an einem kollektiven Standard, nicht die Kontrolle über einen laufenden Maildienst oder die Konformität eines Produkts.

Dauerhaftigkeit liegt vor der Zusage

Die Bedeutung der Antwort legt eine sichere Reihenfolge nahe. Ein Server muss die lokal versprochene Dauerhaftigkeit erreichen, bevor die positive Antwort ihn verlässt. Wer zuerst bestätigt und danach speichert, schafft eine Lücke: Der Sender hat seine Kopie rechtmäßig freigegeben, während beim Empfänger noch keine wiederherstellbare Kopie existiert.

RFC 5321 verlangt, eine angenommene Nachricht nicht aus leichtfertigen Gründen zu verlieren — etwa durch einen späteren Absturz oder vorhersehbare Ressourcenknappheit. Der Standard schreibt weder Datenbank noch Replikationsverfahren vor. Journal, Transaktion oder Spiegelung bleiben lokale Architekturentscheidungen.

Darum beweist der RFC-Text keinen konkreten fsync. Ein Dienst, der „Antwort erst nach Replikation“ verspricht, muss Queue-ID, Durability-Stufe, Konfigurationsepoche und Reply-Zeit verbinden können. Die Nachricht selbst muss dafür nicht dauerhaft im Audit stehen.

Heng Lus Running-Code-Perspektive verhindert geliehene Gewissheit. Der Standard definiert die Verantwortungsgrammatik. Die Implementierung ordnet die Schreibschritte. Der Operator wählt Storage und Retry. Der Autorenname signiert keinen Laufzeitzustand.

Relay-Annahme ist keine Mailbox

Der Empfänger übernimmt die Verantwortung für Zustellung oder Weiterleitung. Ein Relay kann mehrere Hops vom Ziel entfernt sein. Nach der Annahme wird es selbst SMTP-Client und sucht in einer neuen Transaktion einen neuen Verantwortlichen. Jede positive Abschlussantwort eröffnet eine weitere Verwahrungsepoche.

Received-Zeilen helfen, die behaupteten Hops zu rekonstruieren. Sie nennen Sender, Empfänger und Zeitpunkt. Sie sind aber kein Ende-zu-Ende-Zertifikat. Sie belegen weder die Haltbarkeit der Folge-Queue noch korrekte Alias-Erweiterung, Gateway-Verarbeitung oder Sichtbarkeit für den Benutzer.

Selbst „final delivery“ besitzt SMTP-Scope: Die Nachricht verlässt die SMTP-Umgebung. Meist erreicht sie den Benutzer oder ein zugehöriges Mail Drop; manchmal verarbeitet ein anderes Mailsystem sie weiter. Das Ende eines Transportprotokolls ist nicht automatisch das Ende der Benutzerwirkung.

Ehrliche Zustände lauten deshalb: an diesem Hop angenommen, lokal persistiert, am nächsten Hop angenommen, an Local Delivery übergeben, in Mailbox geschrieben, quarantänisiert, per Policy verworfen, Benutzersicht unbekannt. Eine nicht sichtbare Stufe darf nicht den Erfolg des vorherigen Hops erben.

Kein Bounce ist kein positiver Beleg

Wird ein Fehler erst nach der Annahme erkannt, soll der verantwortliche Server normalerweise eine Nachricht an den Envelope-Reverse-Path erzeugen. Diese Benachrichtigung verwendet selbst einen leeren Reverse Path, damit ihr Scheitern keine Schleife erzeugt.

Der negative Kanal kann fehlen. Bei ursprünglich leerem Reverse Path darf keine SMTP-Fehlernachricht zurückgehen. Relay, Mailingliste, Alias oder temporärer DNS-Fehler verhindern eine sofortige Empfängerprüfung. Unter heutigen Missbrauchsbedingungen kann auch stilles Verwerfen unerwünschter Mail zulässig sein, um keinen Backscatter an eine gefälschte Absenderadresse zu senden.

„Kein Bounce“ kann daher Zustellung, wartenden Bericht, fehlende Rückadresse, Statusverlust am Gateway, stille Policy oder Beobachtungslücke bedeuten.

RFC 3461, 3463 und 3464 schaffen mit DSN einen anderen Beleg. Pro Empfänger können failed, delayed, delivered, relayed oder expanded gemeldet werden. Eine Anforderung garantiert keinen Bericht. relayed behauptet keine finale Mailbox; delivered belegt kein Lesen. Auch die DSN muss selbst transportiert werden.

Das finale DATA-250 bestimmt den neuen Verantwortungsträger. Eine spätere DSN beschreibt einen Folgezustand. Wer beide in „zugestellt“ verschmilzt, verliert Träger und Ergebnis.

Eine verlorene Antwort lässt zwei Kopien zurück

Der Empfänger speichert korrekt und sendet 250, doch die Verbindung bricht ab, bevor der Client die Antwort sieht. Beim Empfänger liegt eine gültige Kopie. Der Sender kann die Annahme nicht beweisen, behält seine Kopie und versucht erneut. Doppelte Zustellung ist möglich.

RFC 5321 erlaubt für das DATA-Ende eine lange Wartezeit, weil Verarbeitung nötig sein kann, und fordert zugleich eine möglichst schnelle Antwort. Das senkt die Zahl unklarer Übergaben, beseitigt sie aber nicht.

„Finale Antwort nicht gesehen“ ist keine Ablehnung. Es ist ein mehrdeutiger Zustand mit Duplikatrisiko. Original-Handle, Disconnect, Retry-Entscheidung und spätere Korrelationswerte gehören zusammen. Eine Erfolgsquote aus positiven Replies zählt bestätigte Handoffs, nicht Mailboxen, und muss Retries getrennt ausweisen.

LMTP liefert eine andere Kardinalität

SMTP beantwortet RCPT vor dem Inhalt einzeln, gibt nach DATA jedoch einen Abschluss für die angenommene Transaktion als Ganzes.

LMTP ändert dies bei lokaler Übergabe. RFC 2033 verlangt nach dem finalen Punkt für jeden zuvor erfolgreichen RCPT eine Antwort in derselben Reihenfolge. Eine positive Antwort übernimmt Verantwortung für den zugehörigen Empfänger.

Der Collector muss Protokoll, RCPT-Reihenfolge und Zahl der Antworten erhalten. Ein einzelnes SMTP-250 in mehrere finale Empfängererfolge zu zerlegen erfindet Präzision. Eine LMTP-Sequenz zu einem Status zu verdichten kann den falschen Empfänger markieren.

Das minimale Verwahrungsbuch

Der erste Block hält Connection, Transaction und beobachtete Endpunkte fest; TLS-Kontext bleibt von Nachrichtenannahme getrennt. MAIL FROM, jeder RCPT samt Reply, 354, DATA-Abschluss, Zeit und Queue-ID folgen.

Nach der Übergabe protokolliert der neue Verantwortliche Persistenz, Versuche, Next Hop, dessen Antwort und unklare Disconnects. Local Delivery ergänzt Agent- oder LMTP-Ergebnisse. Eine DSN ergänzt Action und Status pro Empfänger sowie den Nachweis ihres eigenen Handoffs. Spam, proprietäre Gateways und Lesen bleiben ohne unabhängige Quelle unbekannt.

Das ist eine Minimum Initial Specification, kein gemeinsamer Software-Stack. Queue-Engine, Retry, Datenschutz und Aufbewahrung bleiben lokal. Gemeinsam gilt: Reply nicht vom Befehl trennen, Verwahrung nicht Zustellung nennen, Gewissheit nicht über Hops vererben.

Der belastbare Satz lautet: Dieser Server nahm dieses Envelope und diese Nachricht am DATA-Ende an; die Verantwortung wechselte; folgende Relay- oder Local-Delivery-Zustände wurden beobachtet; übrige Empfänger- und Benutzerresultate sind unbekannt.

Quellen