Zusammenfassung

  • RSET machte eine unfertige Nachricht zur verwerfbaren Transaktion innerhalb einer längeren SMTP-Sitzung: Absender, Empfänger und Daten verschwinden, die Verbindung bleibt bestehen.
  • Die positive Antwort bestätigt diese Bereinigung. Sie widerruft keine abgeschlossene Nachricht, löscht nicht den Sicherheitskontext und belegt keine Zustellung.

Der gültige Rest eines ungültigen Umschlags

Ein Client sendet MAIL FROM und danach zwei RCPT TO. Der Server akzeptiert den ersten Empfänger und weist den zweiten zurück. Für die Anwendung gilt jedoch: beide oder keiner.

Die spätere Ablehnung hebt die frühere Annahme nicht auf. Im Server können weiterhin Rückweg und ein gültiger Zielweg gespeichert sein. DATA würde eine Nachricht fortsetzen, die der Client inhaltlich aufgegeben hat. Ein neues MAIL träfe auf eine offene Transaktion. Ein TCP-Abbruch räumte zwar auf, vernichtete aber auch eine gesunde Sitzung.

RSET formuliert die kleinere Absicht: Verwirf diese Mailtransaktion. Erst das 250 OK des Servers liefert gemeinsame Gewissheit, dass der nächste Umschlag nichts vom alten erbt.

Das Vergessen gehörte schon zum SMTP von 1982

RFC 821 definierte RSET von Anfang an. Gespeicherter Absender, Empfänger und Maildaten mussten verworfen, Puffer und Zustandstabellen gelöscht und die Aktion positiv beantwortet werden. Zugleich konnte eine Sitzung null oder mehrere Mailtransaktionen enthalten.

Mehrere Nachrichten auf einer Verbindung sind nur dann sicher, wenn genau eine unfertige Nachricht beendet werden kann. Ein Neuaufbau nach jedem Fehler beseitigte den Nutzen der Wiederverwendung; ein verbleibender Umschlag beseitigte ihre Sicherheit. Der Reset war deshalb kein spätes Reparaturstück, sondern Voraussetzung des Sitzungsmodells.

RFC 821 verlangte außerdem, den Übertragungskanal nicht bloß wegen einer vorherigen Fehlerantwort zu schließen. Bei vorzeitigem Verbindungsverlust wurde die offene Transaktion abgebrochen, bereits abgeschlossene Transaktionen blieben jedoch unangetastet. Kanal, aktueller Versuch und historische Ergebnisse waren verschiedene Zustände.

Lokales Löschen beweist keinen entfernten Zustand

Der Client kann seinen eigenen Puffer leeren. Was der Server noch hält, sieht er nicht. Sichere Wiederverwendung beginnt deshalb erst mit einer zugeordneten Antwort des Gegenübers.

RFC 5321 schreibt für ein argumentloses RSET 250 OK vor und erlaubt den Befehl jederzeit. Ohne offene Transaktion ist er nahezu wirkungslos. Mit offener Transaktion verschwinden Absender, Empfänger und Daten. Der Server darf wegen RSET nicht schließen; das Beenden des Kanals ist Aufgabe von QUIT.

Ein 250 erhält seine Bedeutung durch den beantworteten Befehl. Nach RSET bestätigt es die Zustandsbereinigung, nicht die vorige Nachricht. Es verspricht auch keine physische Vernichtung von Audit- oder Missbrauchsaufzeichnungen. Protokollseitig darf der alte Umschlag die nächste Transaktion nicht beeinflussen.

Was die Sitzung weiterhin wissen darf

Die Formulierung über alle Puffer und Zustandstabellen klingt umfassend. Die übrigen Regeln begrenzen sie auf die Mailtransaktion.

TCP bleibt offen. Der Server wiederholt seine Begrüßung nicht. Nur wegen eines verworfenen Umschlags müssen die per EHLO erlernten Erweiterungen nicht erneut abgefragt werden. TLS bleibt aktiv, eine authentifizierte Sitzung wird nicht anonym. Verschwinden müssen dagegen Absender, Empfänger und Teilinhalt dieser Transaktion.

Ein später akzeptiertes EHLO setzt den offenen Transaktionszustand laut RFC 5321 ebenfalls wie RSET zurück. Es führt jedoch zusätzliche Begrüßungs- und Fähigkeitsarbeit aus und ist daher meist teurer. Die formale Gleichheit gilt für den Abbruch der Transaktion, nicht für die vollständige Aufgabe beider Befehle.

STARTTLS zeigt eine breitere Grenze. RFC 3207 fordert nach erfolgreichem TLS-Handshake, vor TLS erworbenes Wissen zu verwerfen und ein neues EHLO zu senden. Der Sicherheitskontext hat sich geändert; deshalb werden auch Fähigkeiten neu festgestellt. Ein aufgegebener Umschlag braucht diesen großen Neustart nicht.

Abbruch ist kein Rückwärtslauf

Eine Mailtransaktion beginnt mit MAIL, enthält mindestens ein RCPT und endet mit der Inhaltsübertragung. RSET betrifft die noch offene Einheit. Nach erfolgreicher Annahme des letzten Inhalts ist eine Transaktion abgeschlossen. Ein späterer Reset bereitet die nächste vor, widerruft aber keine bereits übernommene Verantwortung.

Eine lange SMTP-Sitzung ist keine Datenbanktransaktion über alle darin gesendeten Nachrichten. Jede abgeschlossene Nachricht besitzt ihr eigenes Ergebnis. Fortdauer der Verbindung bedeutet nicht, dass frühere Annahmen gemeinsam zurückgerollt werden können.

Auch Metriken müssen den Befehl zum Code erhalten. 250 nach Empfänger, Inhalt und Reset sind drei Aussagen über drei verschiedene Gegenstände.

PIPELINING rückte Grenzen zusammen

RFC 2920 erlaubte, ausgewählte Befehle gruppiert zu senden, ohne jede Antwort abzuwarten. RSET, Absenderbefehle und RCPT TO können innerhalb einer Gruppe stehen. Sogar der letzte Inhalt einer Nachricht und Reset plus neuer Absender der nächsten dürfen in derselben TCP-Übertragung liegen.

Die zeitliche Nähe verschmilzt nichts. Alle Antworten bleiben in Reihenfolge zuzuordnen. Der alte Inhalt, die Reset-Bestätigung und der neue Absender haben getrennte Ergebnisse. Ein Erfolg darf den Fehler daneben nicht verdecken.

Je schneller die Befehle unterwegs sind, desto genauer muss das Zustandsbuch sein. Das Leeren eines lokalen Puffers beweist nicht, dass der Server dieselbe Grenze überschritten hat.

Bereinigung nach einem unbestimmten Blockzustand

RFC 3030 transportiert Inhalt über BDAT-Blöcke. Ein weiterer Block nach BDAT LAST, das Mischen von DATA und BDAT oder ein fehlgeschlagener Block mit unbestimmtem Transaktionszustand verlangen RSET, bevor weitere Mailbefehle folgen.

Der Reset entfernt die zur offenen Transaktion gehörenden Fragmente. Er löscht nicht Verbindung, TLS oder Betriebsprotokoll; er verhindert, dass teilweise Daten zur nächsten Nachricht werden.

RFC 4954 schützt eine andere Reichweite: AUTH ist während einer offenen Mailtransaktion verboten und wird mit 503 abgewiesen. Sitzungsidentität darf nicht zwischen Absender, Empfänger und Inhalt eingeschoben werden. Zuerst muss der Umschlag abgeschlossen oder verworfen sein.

Wiederherstellung mit benanntem Umfang

Nach einem Fehler können Systeme so tun, als seien beide Seiten noch synchron, oder die ganze Verbindung zerstören. RSET bietet den nützlichen Mittelweg: die betroffene Einheit benennen, den Kanal erhalten und den Übergang bestätigen lassen.

SMTP wurde nicht zustandslos. Es lernte, Zustand aufzuteilen. Eine unfertige Nachricht kann vergessen werden, ohne das Gespräch zu vergessen; das Gespräch kann weitergehen, ohne abgeschlossene Nachrichten umzuschreiben.

Quellen