Zusammenfassung

  • RFC 1846 vom September 1995 behandelte spezialisierte Hosts, die nie E-Mail empfingen. Ohne SMTP-Server konnte der Absender einen misslungenen Verbindungsversuch als vorübergehend behandeln und die falsch adressierte Nachricht tagelang erneut zustellen wollen. Der experimentelle Code 521 ließ einen MX-Relay oder einen kleinen Ablehnungsserver früher eine endgültige Antwort geben.
  • Die Autoren beschrieben eine Falle: Manche bestehende Clients stellten die Nachricht nach 521 und sofortiger Trennung erneut an, gaben sie aber zurück, wenn der Server bis zum QUIT offen blieb. RFC 7504 von 2015 nahm 521 für niemals empfangende Hosts offiziell in SMTP auf und ergänzte 556 für Relays, die schon vorher wissen, dass eine Domain keine Mail annimmt.

Eine höfliche Warteschlange vor einer leeren Wand

Beim E-Mail-Versand ist Geduld normalerweise vernünftig. Fällt ein Empfänger für ein paar Stunden aus, kann die Nachricht nach seiner Rückkehr eintreffen. Aber manche Rechner haben von Anfang an keinen Empfangsdienst. Alain Durand und Francis Dupont beschrieben in ihrem experimentellen RFC von 1995 eine zunehmend arbeitsteilige Internetwelt: Maschinen für DNS, NTP und andere einzelne Aufgaben. An solche Hosts konnte trotzdem irrtümlich eine Mail adressiert werden.

Ohne SMTP-Dienst am Ziel hörte der Client des Absenders nur Stille. Daraus ließ sich nicht schließen, dass der Host niemals Mail annehmen würde; vielleicht würde morgen ein Server gestartet. Also musste das sendende System die Nachricht zwischenspeichern und die Verbindung erneut versuchen. Laut RFC blieb die fehlgeleitete Post mitunter tagelang liegen, bevor sie mit einer oft unverständlichen Fehlermeldung zurückkam. Der Betreiber des maillosen Hosts hielt kein Postfach bereit. Speicher, Verbindungsversuche und menschliche Wartezeit fielen auf der Absenderseite an.

Im SMTP-Modell von 1982 führten Sender und Empfänger ein Gespräch aus Befehlen und nummerierten Antworten. Eine Antwort konnte die nächste Handlung festlegen. Durand und Dupont wollten eine Aussage ergänzen, die ein gescheiterter Verbindungsaufbau nicht lieferte: Dieser Host empfängt grundsätzlich keine Mail. Die Kennzahl dafür war 521. Sie sollte keine Mailbox schaffen, sondern eine fruchtlose Suche nach einer Mailbox beenden.

Es gab zwei Orte für die Absage. Ein MX-Relay konnte beim Empfängerbefehl 521 für den maillosen Host zurückgeben. Oder der Host selbst betrieb einen äußerst kleinen SMTP-Server, der jeden Zustellversuch ablehnte. Im ersten Fall sprach ein Mail-Vermittler für ihn, im zweiten der betroffene Rechner selbst. Entscheidend war weniger, wo die Stimme saß, als dass ein Verantwortlicher das dauerhafte „hier nicht“ von einem bloßen Ausfall unterschied.

Die MX-Lösung verlangte eine einheitliche Auskunft. RFC 1846 empfahl, dass Relays mit niedrigerer Präferenz die Mail ebenfalls ablehnen, wenn ein anderer Relay sie im Namen dieses Hosts ablehnt. Sagt ein Eingang endgültig nein und der nächste verhält sich anders, hat der Sender weiterhin einen Anlass, einen alternativen Weg zu probieren. Eine Ablehnungsregel erfüllt ihren Zweck erst, wenn sie an den ausgeschilderten Wegen übereinstimmt.

Eine kurze Absage konnte wie eine kurze Störung wirken

Der Minimalserver durfte unmittelbar nach Verbindungsaufbau mit 521 grüßen und danach seinen offiziellen Hostnamen oder seine IP-Adresse nennen. Anschließend konnte er die Verbindung schließen. Er durfte aber auch Befehle annehmen, auf alles außer QUIT mit 521 antworten und das Ende des Gesprächs abwarten. Ein solcher Host durfte in keinem MX-Eintrag als Mailziel stehen. Wer den Empfang vollständig verweigert, darf nicht zugleich als Empfänger ausgewiesen werden.

Warum sollte er nach der Absage noch warten? Die Autoren hatten beobachtet, dass einige vorhandene SMTP-Clients eine sofortige Trennung nach 521 als vorübergehende Störung behandelten und die Mail wieder einreihten. Blieb der Server offen, schickten sie QUIT und gaben die Nachricht dem Absender zurück. Der Inhalt der Antwort war derselbe. Die Dauer des Gesprächs bestimmte, ob der sendende Rechner ihr glaubte. Ein korrekt gesendeter Code war noch kein korrekt beendeter Zustellversuch.

Damit bekam der Rechner ohne Mail eine kleine Mailaufgabe: erreichbar bleiben, den eigenen Namen nennen, fest ablehnen und bei Bedarf auf den Abschied des Clients warten. Nachrichten speichern oder verteilen musste er nicht. Gerade diese winzige Arbeit konnte verhindern, dass andere Systeme tagelang eine unmögliche Zustellung vorbereiteten. Ein Dienst, der nur verkündet, dass es keinen Dienst gibt, klingt nach Bürokratie. Im Netzwerk sparte er Bürokratie auf der anderen Seite.

1995 war 521 eine experimentelle Empfehlung und noch kein Internetstandard. Die Autoren baten um Berichte über Implementierungen. Ihre Beobachtung zu „einigen“ Clients war keine Statistik über betroffene Programme oder Nachrichten. Für die tatsächliche Größenordnung wären damalige Mail-Queue-Protokolle oder eine Erhebung der Implementierungen nötig. Der beschriebene Ablauf belegt aber die technische Grenze: Die Ablehnung des Servers und die Reaktion des Senders waren getrennte Ereignisse.

2015 wusste schon das DNS von der leeren Mailbox

RFC 7504 übernahm 521 im Juni 2015 offiziell in SMTP. Der Standardtext berichtete, der Code sei mittlerweile weit verbreitet, obwohl er bislang nicht formal in das Grundprotokoll aufgenommen worden war. Nun bezeichnete 521 am Beginn einer Verbindung einen Host, der unter keinen Umständen Mail annimmt. Das unterscheidet ihn vom breiter verwendbaren 554, mit dem ein Server auch einzelne Absender, Empfänger oder Situationen ablehnen kann. Die 2015er Fassung beendete das Experiment und gab dem Code einen engeren Platz.

Noch vor einer Verbindung konnte eine Domain inzwischen eine ähnliche Tatsache kundtun. RFC 7505 definierte einen Null-MX-Eintrag im DNS: Diese Domain empfängt keine Mail. Ohne MX kann der Sender auf eine A- oder AAAA-Adresse ausweichen und einen Rechner zu erreichen versuchen, der zwar Webseiten oder andere Dienste anbietet, aber keine Mail. Null MX verlegt die Absage in die Namensauskunft und erspart den Kontakt mit einem eigens ablehnenden SMTP-Server.

RFC 7504 führte außerdem 556 ein. Ein Zwischenserver, der etwa durch Null MX weiß, dass die Domain einer Weiterleitungsadresse keine Mail annimmt, kann dem vorgelagerten System antworten, ohne den Zielhost zu kontaktieren. 521 spricht der Host beim Öffnen der Verbindung. 556 spricht der Vermittler, der die Domainregel schon kennt. Die Nummern halten auseinander, wer die Entscheidung trifft und wann sie im Weg einer Nachricht wirksam wird.

1995 musste man bisweilen einen kleinen Server einschalten, damit eine Maschine ohne Postfach hörbar nein sagen konnte. 2015 konnte eine Domain diese Auskunft auch im DNS geben. In beiden Fällen war die Einsparung die gleiche: Wer die Wahrheit über den Zielort kennt, beendet die Raterei der anderen. Stille ließ fremde Warteschlangen wachsen. Eine eindeutige Absage ließ sie schrumpfen.