Zusammenfassung

  • DELIVERBY ließ einen SMTP-Client eine Frist in Sekunden und die Folge ihres Ablaufs erklären: Return beendete weitere Versuche, Notify meldete Verspätung und ließ die lokale Zustellpolitik weiterarbeiten.
  • Ein unterstützendes Relay musste verbrauchte Zeit abziehen und nur den Rest weitergeben. Die Erweiterung versprach weder Vorrang noch fristgerechte Zustellung, längere Aufbewahrung oder eine ebenso schnelle DSN.

Die wichtigste Zahl stand zunächst nicht in der Nachricht, sondern in der EHLO-Antwort des Servers. Hinter DELIVERBY konnte ein fester Mindestwert folgen. Er sagte: Kürzere Return-Fristen kann dieses System nicht glaubwürdig übernehmen.

Damit begann die Architektur beim Recht, Nein zu sagen. Ein Betreiber musste eine fremde Dringlichkeit nicht in die eigene Queue aufnehmen. Er konnte seine reale Untergrenze offenlegen. Erst wenn die angebotene Restzeit dazu passte, entstand eine Verpflichtung.

RFC 2852 veröffentlichte diese Deliver By SMTP Service Extension im Juni 2000. Das praktische Beispiel war eine Nachricht, die vor 17 Uhr einen Pager auslösen durfte, danach aber nicht mehr. Normales SMTP verstand temporäre Fehler und Wiederholungen; es kannte den außerhalb des Mailsystems liegenden Bedeutungsverlust nicht.

Eine Untergrenze war ehrlicher als eine Fast Lane

Der Client entdeckt die Fähigkeit über DELIVERBY und ergänzt MAIL FROM um BY. Ein neuer SMTP-Befehl war nicht nötig. Ebenso wenig entstand eine Pflicht, die Nachricht vor anderen zu bearbeiten.

Der Betreiber durfte seine Prioritätsregeln, Ressourcenverteilung und Retry-Intervalle behalten. Eine angenommene Frist bestimmte, was beim Ablauf geschehen musste, nicht wie die Queue jede Sekunde davor zu planen hatte. RFC 2852 warnt sogar davor, eine beschleunigte Verarbeitung zu erwarten.

Das trennt zwei Autoritäten. Der Absender weiß, wann der Inhalt seinen Zweck verliert. Der MTA weiß, welche Laufzeit und Last er tragen kann. Der eine erklärt die Ablaufwirkung, der andere veröffentlicht Grenzen und entscheidet über Annahme. Keiner beherrscht allein beide Seiten.

Auch die Annahme blieb stufenweise. Ein Server kann MAIL FROM bestätigen und erst bei RCPT TO, DATA oder Datenende erkennen, dass er die Bedingung nicht erfüllt. Empfänger und Inhalt sind beim ersten Schritt noch nicht vollständig bekannt. Ein frühes 250 ist deshalb kein End-to-End-Zertifikat.

Der Wert war eine Differenz, keine gemeinsame Uhr

BY enthält eine vorzeichenbehaftete Dezimalzahl von Sekunden, R oder N und optional T für Trace. Der größte Betrag ist neunhundertneunundneunzig Millionen neunhundertneunundneunzigtausend neunhundertneunundneunzig Sekunden und kann negativ oder positiv sein.

Der empfangende MTA addiert die Differenz zu seiner lokalen Zeit und erhält einen lokalen deliver-by-time. Kurz vor dem nächsten MAIL FROM berechnet er daraus die verbliebenen Sekunden.

So müssen zwei Verwaltungsdomänen ihre Uhren nicht exakt synchronisieren. Vollständig verschwindet Zeitunsicherheit nicht. Die Übertragung des Befehls dauert; RFC 2852 beschreibt eine leichte effektive Verlängerung, die sich über mehrere Hops summiert. Die Spezifikation erhält ein schrumpfendes Budget, keine perfekte Weltzeit.

Die Differenz ist auch kein deliver-after. Sie verbietet keine frühe Zustellung, sondern setzt eine Obergrenze. Und sie verlängert keine normale Queue-Retention. Eine lokale Politik darf eine aussichtslose Nachricht schon vor der angeforderten Frist zurückgeben.

Zwei Modi ordneten die Verantwortung am Ablaufpunkt

Bei R für Return sind null und negative Werte unzulässig. Wird die Nachricht bis zum deliver-by-time weder zugestellt noch weitergereicht, dürfen keine weiteren Versuche erfolgen. Für betroffene Empfänger folgt eine failed DSN mit 5.4.7, delivery time expired.

Bei N für Notify bleibt die Zustellberechtigung bestehen. Die Queue arbeitet nach lokaler Politik weiter und erzeugt für passende Empfänger eine delayed DSN mit 4.4.7. Null und negative Werte sind erlaubt, weil ein bereits überschrittener Termin weiterhin als Information mitreisen kann.

Diese Trennung verhindert, dass das Wort dringend den Geschäftsfall ersetzt. Eine abgelaufene Anweisung soll möglicherweise verschwinden. Ein verspäteter Bericht soll möglicherweise trotzdem ankommen. Return verändert die zulässige Aktion. Notify verändert die erforderliche Beobachtung.

Permanente Fehler müssen nicht bis zur Frist warten. Temporäre Fehler bleiben vor der Frist wiederholbar. Eine kürzere lokale Retention gilt weiter. DELIVERBY fügt einen kontrollierten Entscheidungspunkt hinzu, ohne SMTPs übrige Fehlerlogik zu verdrängen.

Das nachfolgende Relay bekam nur das Guthaben

Unterstützt der nächste Server DELIVERBY, muss das Relay den Modus erhalten und einen neuen BY-Wert mit der Restzeit senden. Das Beispiel der Spezifikation macht aus 120 Sekunden nach 22 Sekunden Aufenthalt noch 98. Verbrachte Zeit wird an keiner administrativen Grenze neu geschaffen.

Return verlangt eine lückenlose Fähigkeitskette. Eine R-Nachricht darf weder an einen inkompatiblen Server noch an einen Server gehen, dessen Mindestwert größer als der Rest ist. Ein anderer legitimer Weg kann geprüft werden. Fehlt er, ist die Nachricht unzustellbar; eine stille Weitergabe ohne Frist wäre semantisch eine andere Nachricht.

Notify darf eine inkompatible Grenze überschreiten, weil Versuche nach dem Termin weiterhin erlaubt sind. Das Relay muss den Verlust jedoch durch eine relayed DSN für die betroffenen Empfänger offenlegen und die Delay-Anforderung soweit möglich in DSN fortführen.

Hier zeigt sich minimale Koordination. Der Standard vereinheitlicht keine Queues. Er verlangt nur wahrheitsgemäßen gemeinsamen Zustand: Restzeit, Ablaufmodus und einen sichtbaren Punkt, an dem die Semantik nicht mehr weitergegeben werden kann.

Der Bericht lief nicht auf derselben Frist

DELIVERBY verwendet DSN für failed, delayed und relayed und ergänzt Deliver-By-Date. Mit T können nichtterminale Relay-Berichte angefordert werden, auch wenn kein ausdrücklicher Erfolgsbericht verlangt wurde.

DSN strukturiert den Nachweis einer Aktion. DELIVERBY bestimmt die Aktion, die am Termin fällig wird. Bei R verliert die Queue das Recht weiterzumachen; bei N behält sie es und muss Verzögerung anzeigen. Darin liegt die Abgrenzung zur Geschichte des Zustellbelegs.

Die Rückmeldung ist eine neue Mail mit eigener Route. Ein BY=60;R kann nach sechzig Sekunden fehlschlagen, ohne dass der Absender die DSN binnen sechzig Sekunden erhält. Selbst der Bericht bekommt keinen automatischen Vorrang. Eine begrenzte Vorwärtsverpflichtung erzeugt keine allumfassende zeitliche Kontrolle.

Kurze Fristen konnten die Infrastruktur vermessen

Trace-Berichte machen Übergaben sichtbar. Auch eine Serie mit wachsenden kurzen Zeiten kann über unterschiedliche Ablehnungen und Ergebnisse grobe Schwellen oder Latenzen verraten. RFC 2852 nennt diese Möglichkeit in den Sicherheitsbetrachtungen.

Ein solcher Befund bleibt begrenzt. Ein negativer Notify-Wert benennt keinen verursachenden Hop. 5.4.7 beweist keine Nachlässigkeit. relayed bestätigt eine Übergabe, nicht die finale Mailbox. Zeit ist ein Signal, kein automatisches Urteil.

Das aktuelle IANA-Register führt DELIVERBY weiterhin mit RFC 2852 und Requirement Level MAY. Das belegt die Registrierung, nicht heutige Verbreitung.

Die eigentliche Leistung bestand darin, eine zeitliche Bedingung zwischen unabhängigen Betreibern transportierbar zu machen. Der Absender durfte den Bedeutungsverlust benennen. Jeder Betreiber durfte die Bedingung ablehnen. Wer sie annahm, musste verbrauchte Sekunden sichtbar verbraucht lassen. Wo die Fähigkeit endete, musste auch der Anspruch auf semantische Kontinuität enden.

Kein Relay durfte die Frist zurücksetzen, weil die Frist nicht bloß eine Zahl war. Sie war der verbliebene Teil einer bereits angenommenen Verantwortung.

Quellen