Zusammenfassung

  • RFC4865 verlagert das Warten vor der Freigabe einer Mail vom Endgerät zum Submission-Server. Das Verbot einer vorzeitigen Freigabe ist weder eine Zusage sekundengenauer Ausführung noch ein Nachweis der Zustellung.
  • Bei gemeinsamer Verwendung mit DELIVERBY muss der Client die Zustellfrist strikt nach der Freigabe ansetzen. Für den Server formuliert die Norm eine eigene Ablehnungsbedingung. Auch zulässige Anfragen benötigen ein Speicherbudget, eine belastbare Zeitbasis und getrennte Ausführungsnachweise.

Eine gefüllte Warteschlange besteht nicht nur aus Arbeit, die ein Betreiber noch nicht geschafft hat. Ein Teil kann aus Arbeit bestehen, die er noch gar nicht ausführen darf. Für einen zeitgesteuerten Maildienst ist diese Unterscheidung grundlegend: Leerlauf kann eine erfüllte Verpflichtung sein, und eine verweigerte Annahme kann einen unlösbaren Auftrag verhindern.

Das zeigt ein ausdrücklich hypothetischer Fall. Eine Nachricht wird morgens eingereicht, darf erst um zwölf Uhr freigegeben werden und soll nach elf Uhr nicht mehr zugestellt werden. Hier wird kein beobachteter Vorfall beschrieben. Die beiden Vorgaben passen bereits logisch nicht zusammen. Zusätzliche Bandbreite, schnellere Datenträger oder eine leere Ausgangswarteschlange ändern daran nichts.

Nimmt ein System die Nachricht dennoch an und streicht still eine Bedingung, hat es nicht dieselbe Leistung besser erbracht. Es hat entschieden, welche Absicht des Absenders weniger wichtig sei. Ein hoher Annahmeanteil kann dann gerade verbergen, dass die versprochene Leistung unklar geworden ist.

RFC4865 bietet eine andere Perspektive. Das im Mai2007 veröffentlichte Dokument definiert Future Message Release für SMTP-Submission. Ein Client kann eine Nachricht beim Server speichern lassen, bis ihre spätere Freigabe erlaubt ist. Er muss dazu weder selbst dauerhaft verbunden bleiben noch die gesamte Wartezeit mit lokalem Speicher überbrücken.

Der Nutzen ist konkret. Die Last wird aber verlagert, nicht abgeschafft. Ein Server übernimmt Inhalt, Speicherverbrauch und einen künftigen Ausführungsschritt. Diese Übernahme macht ihn nicht zum Eigentümer aller späteren Zustellentscheidungen.

Ein Auftrag beginnt mit seinen Grenzen

Der Server kündigt FUTURERELEASE in der EHLO-Antwort an. Dazu gehören eine maximale Wartezeit und ein spätestes zulässiges Freigabedatum. Der Client prüft zunächst die Unterstützung und verwendet dann genau einen Halteparameter im MAIL-Befehl.

HOLDFOR beschreibt eine Dauer, HOLDUNTIL einen Zeitpunkt. Die gewählte Angabe muss innerhalb des jeweils angekündigten Maximums liegen. Ein fehlender Parameter ist keine stillschweigende Auswahl einer Standardwartezeit. Die Fähigkeit des Servers und der konkrete Auftrag bleiben verschiedene Sachverhalte.

Die zwei Darstellungen berücksichtigen unterschiedliche Möglichkeiten der Endgeräte. Ein Client kann eine brauchbare Ortszeit kennen, ohne seine Zeitzone hinreichend bestimmen zu können. Ein anderer verfügt möglicherweise nicht über eine ausreichend genaue Uhr. Die Norm hält beide Formen aus praktischen Gründen für sinnvoll.

Nach Annahme einer Nachricht mit einem gültigen Auftrag darf der Server sie nicht freigeben, bevor die Dauer abgelaufen beziehungsweise der Zeitpunkt erreicht ist. Die Aussage betrifft eine Untergrenze: vorher nicht. Sie verspricht nicht, dass die Freigabe genau mit dem Erreichen dieser Grenze erfolgt.

Noch weiter entfernt ist die Behauptung, die Nachricht werde dann beim Empfänger liegen oder gelesen. Zwischen Freigabeberechtigung, tatsächlicher Ausführung, Annahme durch den nächsten Transportabschnitt und endgültiger Zustellung liegen weiterhin einzelne Ereignisse. Ein Kalenderfeld kann diese Ereignisse nicht zu einem einzigen machen.

Auch eine relative Dauer liefert keine Garantie gegen Zeitfehler. RFC4865 warnt ausdrücklich, dass ungenaue oder veränderte Serveruhren bei beiden Verfahren zu früher oder verspäteter Freigabe führen können. Die Wahl einer für den Client geeigneten Darstellung ersetzt keine belastbare Zeitbasis beim Betreiber.

Die zweite Vorgabe regelt etwas anderes

DELIVERBY stammt aus RFC2852. Die Erweiterung erlaubt eine Zustellzeitvorgabe zusammen mit dem gewünschten Verhalten, wenn die Nachricht nicht rechtzeitig zugestellt werden kann. Sie verlangt keine bevorzugte Verarbeitung. Ein Server kann eine höhere Priorität vergeben, muss dies wegen DELIVERBY aber nicht tun.

Ebenso wenig ist DELIVERBY ein Auftrag, bis zu einem späteren Zeitpunkt zu warten. Die Zustellfrist verlängert auch nicht die übliche Aufbewahrungsdauer für unzustellbare Nachrichten. Zwei passende Zeitangaben sind daher keine Reservierung einer durchgängigen Transportleistung.

Mit Future Message Release entsteht ein mögliches Fenster zwischen erlaubter Freigabe und Zustellfrist. Dieses Fenster ist zunächst nur widerspruchsfrei. Ob die Warteschlange, der Ausgang und die folgenden Systeme die Arbeit innerhalb dieses Fensters bewältigen, muss gesondert beurteilt werden.

Genau hier setzt Abschnitt5.2 von RFC4865 an. Für einen Client, der beide Erweiterungen gemeinsam verwendet, verlangt Abschnitt5.2.1 eine Zustellfrist strikt nach der ausdrücklich genannten oder aus der Dauer abgeleiteten Freigabezeit. Zwei beliebige Werte in der Zukunft reichen nicht.

Abschnitt5.2.2 beschreibt die Pflicht des Servers anders: Unterstützt er beide Erweiterungen und stellt fest, dass die Freigabezeit später als die Zustellfrist liegt, muss er MAIL zurückweisen. Als Antwort werden501 und der erweiterte Status5.5.4 empfohlen.

Diese Sätze dürfen nicht zu einer vermeintlich einheitlichen Vergleichsregel zusammengezogen werden. Die ausdrücklich formulierte Ablehnungsbedingung des Servers lautet nicht „später oder gleich“. Daraus entsteht jedoch keine Erlaubnis für den Client, gleiche Zeitpunkte zu verwenden. Er wäre weiterhin an seine strengere Reihenfolge gebunden.

Für die Praxis bedeutet das: Eine Client-Prüfung muss dessen strikte Vorgabe testen. Ein Test des Servers muss seine tatsächliche Reaktion auf Randwerte gesondert festhalten. Wenn das Verhalten bei Gleichheit entscheidend ist, braucht es einen beobachteten Implementierungsbefund. Dieser Artikel behauptet keinen solchen Versuch.

Im klaren Widerspruchsfall bewahrt die Ablehnung eine Entscheidung beim Absender. Nur dieser kann festlegen, ob eine Veröffentlichung vor dem geplanten Zeitpunkt oder eine Zustellung nach dem Nutzungsfenster eher vertretbar ist. Eine Infrastrukturkomponente sollte das nicht unbemerkt zugunsten besserer Erfolgszahlen entscheiden.

Abgelaufen ist kein vollständiger Zustand

RFC2852 unterscheidet die Modi Return und Notify. Wenn im Return-Modus bis zur Frist weder die betreffende Zustellung noch Weiterleitung erfolgt ist, dürfen weitere Zustellversuche nicht fortgesetzt werden. Für Empfänger, deren Benachrichtigungsbedingungen es verlangen, ist die entsprechende Fehlermeldung zu erzeugen.

Im Notify-Modus soll die Verarbeitung nach Erreichen der Frist dagegen entsprechend der örtlichen Regelung fortgesetzt werden. Hinzu kommt die vorgesehene Verzögerungsbenachrichtigung für die betroffenen Empfänger. Der gleiche Zeitpunkt hat also je nach Auftrag unterschiedliche Handlungsfolgen.

Ein Statusfeld „abgelaufen“ kann für eine Übersicht genügen, nicht aber als alleinige Grundlage einer Wiederholungs- oder Abbruchentscheidung. Wer alles weiter versucht, verletzt unter Umständen Return. Wer alles stoppt, beendet unter Umständen Arbeit, die unter Notify weitergehen sollte.

Auch auf dem nächsten Abschnitt unterscheiden sich die Bedingungen. Eine Return-Nachricht darf nicht an einen Server ohne DELIVERBY-Unterstützung weitergeleitet werden. Dessen feste Mindestzeit darf außerdem nicht größer sein als die verbleibende Zeit. Notify kann eine nicht unterstützende Station passieren, mit den in RFC2852 festgelegten Folgen für Benachrichtigungen.

Die bloße Übergabe ist damit kein Beleg, dass jede Verpflichtung erhalten geblieben ist. Die Fähigkeit des nächsten Abschnitts gehört zum Auftrag. Sie muss zusammen mit Modus und Restzeit betrachtet werden.

Eine weitere Grenze betrifft die Kenntnis des Ergebnisses. Die Benachrichtigung über einen Fehler muss nicht beschleunigt zurücktransportiert werden. RFC2852 weist ausdrücklich darauf hin. Ein knapper Zustellauftrag begrenzt deshalb nicht automatisch die Zeit, nach der der Absender sicher von einem Scheitern erfährt. Ausbleibende Nachricht bleibt fehlende Beobachtung, nicht nachgewiesener Erfolg.

Die Protokollphase muss ebenfalls erhalten bleiben. Eine positive MAIL-Antwort ist keine abgeschlossene Zustellung und nicht zwingend das Ende der erfolgreichen Einreichung. Laut RFC2852 kann eine Unmöglichkeit erst bei der Empfängerprüfung oder nach der Datenübertragung erkennbar werden. Ein einzelner Zähler für „angenommen“ würde verschiedene Stufen vermischen.

Zukunftsarbeit braucht heutige Budgets

Ein Submission-Server hält unter Umständen Inhalte, die erst viel später den Ausgang belasten dürfen. Die Berechtigung eines Absenders beantwortet dabei nicht die Frage nach der Menge. Auch ein ordnungsgemäß autorisierter Nutzer kann den Speicher mit zukünftiger Arbeit erschöpfen.

RFC4865 empfiehlt eine benutzerbezogene Quote für Nachrichten mit späterer Freigabe. Wenn der Server diese Quote anwendet und erkennt, dass eine neue Nachricht sie überschreiten würde, muss er MAIL ablehnen. Die Empfehlung zur Einführung der Quote und die Pflicht bei erkanntem Überschreiten einer angewandten Quote haben unterschiedliche Voraussetzungen.

Es wäre falsch, daraus einen identischen Reservierungsmechanismus für alle Implementierungen abzuleiten. Die Norm beschreibt die Verpflichtung, nicht die konkrete interne Speicherbuchhaltung jedes Produkts. Wer für die eigene Kapazitätsplanung mehr wissen muss, benötigt Implementierungs- und Betriebsnachweise.

Die Statuswerte trennen zudem die Benutzerquote von der Systemquote: X.7.16 steht für unzureichenden Spielraum des Nutzers, X.7.17 für den des Systems. Im ersten Fall kann das Abfließen einer einzelnen Warteschlange relevant sein, im zweiten die Entlastung des gemeinsamen Budgets. Ein pauschaler Wiederholungsabstand würde die unterschiedliche Ursache verdecken.

Selbst eingehaltene Einzelgrenzen sichern keine gleichmäßige Zukunftslast. Viele Nachrichten können gleichzeitig zur Freigabe berechtigt werden. Das ist eine aus dem Mechanismus abgeleitete Prüfsituation, kein hier gemessener Ausfall. Sie zeigt, wie ein Engpass von gespeicherten Bytes zu Freigabeverarbeitung und Ausgangskapazität wandern kann.

Die angegebene maximale Wartezeit ist daher keine Prognose freien Durchsatzes am späteren Tag. Ein Produkt kann einen langen Horizont anbieten, während die konkrete Verteilung bereits angenommener Verpflichtungen eine andere Belastung erzeugt. Kalenderreichweite und Kapazitätsvorsorge sollten in derselben unternehmerischen Entscheidung zusammenkommen.

Lu Heng beschreibt in Note32 ein Agency-Problem, wenn Entscheidungsmacht und wirtschaftliche Folgen auseinanderfallen. Auf diesen Fall angewandt lautet die Frage: Wer darf einen künftigen Auftrag versprechen, und wer finanziert und verantwortet die Warteschlange? Diese Perspektive belegt keine unlauteren Motive eines Anbieters. Note36 über BTW.Media fordert gerade, Strukturen zu beschreiben, statt einen Beteiligten zum Helden oder Gegner zu machen.

Die ursprüngliche Anweisung darf nicht verschwinden

Erzeugt der Submission-Server eine DSN zu einer Nachricht mit Future-Message-Release-Anforderung, verlangt RFC4865 die Felder Arrival-Date und Future-Release-Request im maschinenlesbaren Teil. Der zweite Eintrag hält den ursprünglichen Haltewert in der festgelegten Form fest.

Das hilft, absichtlich angeordnete Wartezeit von ungewollter Transportverzögerung zu unterscheiden. Es beweist aber nicht den Zeitpunkt der tatsächlichen Freigabe. Ebenso wenig belegt es die Annahme durch einen folgenden Server oder die Zustellung. Auftrag und Ausführung müssen getrennt gespeichert und anschließend zusammengeführt werden können.

Für eine DSN oder eine MDN, die der Client beim Submission-Server einreicht, darf er die spätere Freigabe nicht anfordern. Eine Meldung über Verarbeitung soll nicht über diese Erweiterung selbst zur absichtlich vertagten Meldung werden. Dass solche Nachrichten trotzdem auf Transportwegen warten können, wird damit nicht ausgeschlossen.

Auch Date im Nachrichtenkopf ist kein Ersatz für die Ereignishistorie. RFC4865 beschreibt, dass die Kopfdaten insbesondere Date nach der Einreichung unverändert bleiben; der Client kann ein künftiges Datum wählen, und der Transport soll nicht durch veränderte Spuren die Wartezeit verbergen müssen. Davon zu unterscheiden ist die begrenzte Ergänzung oder syntaktische Korrektur einer Date-Angabe bei der Einreichung, die RFC6409 erlaubt.

RFC6409 ersetzt RFC4409 und trennt Submission von Relay. Üblicherweise nutzt Submission Port587. Die dort allgemein erlaubte Zuordnung bestimmter Dienste auf25 zur Submission hebt den eigenen Anwendungsbereich von FUTURERELEASE nicht auf. Ein gewöhnlicher Relay-Dienst erhält dadurch keine allgemeine Berechtigung, diese Erweiterung anzukündigen.

Präzision endet nicht beim Haupttext

Das verifizierte redaktionelle Erratum2040 zu RFC4865 behebt eine nicht definierte Datumsproduktion durch den Verweis auf date-time aus RFC3339. Die Begleitbemerkung des Meldenden über seinen funktionierenden Server stammt aus2010. Sie ist eine zugeordnete historische Aussage, keine aktuelle Erhebung zur Verbreitung.

Das redaktionelle Erratum2300 zu RFC2852 ist für eine spätere Dokumentaktualisierung vorgemerkt. Es betrifft fehlende Leerzeichen in der Grammatik und ändert keine Fristsemantik. Der Status einer Korrektur ist Teil der Beweislage, nicht austauschbare Randinformation.

Für diese Analyse wurden weder SMTP-Tests ausgeführt noch Serveruhren verändert oder Produktionswarteschlangen untersucht. Die Quellen legen Pflichten und Grenzen offen. Ob ein konkretes System diese einhält, bleibt eine eigene Beobachtungsaufgabe.

Der entscheidende Nutzen liegt darin, unmögliche Verpflichtungen vor ihrer stillen Übernahme sichtbar zu machen. Ein Betreiber muss warten können, wo Warten beauftragt ist. Er muss aber auch zurückweisen können, wo kein zulässiger Zeitpunkt mehr existiert, um den Auftrag überhaupt beginnen zu lassen.

Quellen