Summary

  • RFC 1845 beschrieb 1995 eine experimentelle SMTP-Erweiterung: CHECKPOINT kündigte die Funktion an, TRANSID bezeichnete eine einzelne Übertragung, und der Server hielt ihren Zustand auf nichtflüchtigem Speicher fest.
  • Im Musterlauf bedeutete 355 6135 einen gespeicherten Nachrichtenpräfix von 6135 Oktetten. Umschlagbefehle und durch SMTP-Dot-Stuffing hinzugefügte Oktette zählten nicht mit.

Der Preis einer schwachen Verbindung wurde bei großen Nachrichten besonders sichtbar. Im ursprünglichen SMTP konnte eine nach dem TCP-Abbruch unvollendete Übertragung nicht an ihrer alten Stelle fortgesetzt werden. Beim nächsten Versuch lief der Inhalt wieder von vorn. D. Crocker, N. Freed und A. Cargille stellten im September 1995 eine experimentelle Alternative vor: Der empfangende Server sollte den gespeicherten Teil belegen, der sendende nur den Rest liefern. Die 6135 Oktette sind eine Zahl aus dem Protokollbeispiel, kein gemessener Schadensfall.

Vor dem Abbruch musste der Client den Vertrag aushandeln. Auf EHLO antwortete ein fähiger Server mit CHECKPOINT. In MAIL FROM trug der Client dann TRANSID ein, eine Kennung für genau diese Übertragung; Groß- und Kleinschreibung machten einen Unterschied. Das Message-ID im Mailheader war dafür zu grob. Eine Nachricht konnte in mehrere Kopien auf verschiedenen Wegen zerfallen und dabei denselben Header behalten. Jede Kopie brauchte ihren eigenen Fortschrittsstand. Der Server sollte den Wert von TRANSID als undurchsichtige Zeichenfolge behandeln, statt Bedeutung aus seinem Aufbau herauszulesen.

Eine Kennung allein speichert keine Arbeit. RFC 1845 verlangte, den jüngsten Transaktionszustand zusammen mit ihr auf nichtflüchtigem Speicher zu halten. Für unterbrochene Vorgänge empfahl sie mindestens 48 Stunden Aufbewahrung, ohne eine feste Frist vorzuschreiben. Der Client wartete nach der Unterbrechung, bis die alte Verbindung freigegeben war, prüfte den DNS-Stand erneut und versuchte die ursprüngliche Adresse zuerst, sofern sie noch als Ziel in Frage kam. Danach waren andere zulässige Adressen an der Reihe. Konnte ein anderer Server den Vorgang nicht fortsetzen, musste der Client vollständig neu senden.

Auf den alten Server zu warten, war keine Lösung.

Der neue Kontakt begann mit demselben MAIL FROM und exakt demselben TRANSID. Die Antwort 355 6135 bezeichnete die Position des nächsten erwarteten Oktetts der Nachrichtendaten, von null an gezählt. Sie war zugleich die Anzahl erfolgreich gespeicherter Oktette. MAIL FROM und RCPT TO gehörten nicht dazu. Auch die zusätzlichen Zeichen, mit denen SMTP Zeilen mit führendem Punkt schützt, wurden abgezogen. Bei DATA musste die Wiederaufnahme außerdem am Zeilenanfang liegen. Ein einfacher Sprung an Byte 6135 einer beliebigen lokalen Datei konnte diesen Bezug nicht herstellen; gezählt wurde das kanonische SMTP-Datenformat.

Danach folgten DATA, der fehlende Rest und 250 OK. Die RFC erlaubte sogar, dass der Client den ganzen Datenstrom lokal neu erzeugt und nur dessen ersten Teil nicht erneut ausgibt. Weniger Netzverkehr war der Gewinn. Die Rechenregel durfte dafür nicht ungenauer werden.

Ein solcher Zähler ist keine Empfangsbestätigung eines Menschen. Er identifiziert auch nicht jede Kopie derselben Mail. Er quittiert einen gespeicherten Präfix einer bestimmten Übertragung. Gerade weil die Aussage so begrenzt ist, kann der Client aus ihr eine präzise Fortsetzung ableiten.