Zusammenfassung
- Das SMTP von 1982 sah vor, dass ein empfangender Server eine Nachricht an den nächsten Server weiterreichen und dafür selbst zum Absender werden konnte.
- RFC 2505 verlangte 1999 eine Sperre gegen unbefugtes Relaying. Selbst behauptete Namen in
HELOundMAIL FROMsollten dafür keine Berechtigung verleihen.
Ein Fremder betritt die Spedition und sagt: „Ich bin der Chef.“ Dann bestellt er einen Lastwagen quer durchs Land, Rechnung an die Firma. Im E-Mail-Verkehr brauchte man tatsächlich Speditionen zwischen verschiedenen Systemen. Was sich später als Open Relay rächte, war die freundliche Idee, dass der Auftraggeber seinen eigenen Berechtigungsschein ausfüllen dürfe.
Im SMTP-Standard RFC 821 vom August 1982 ist die Weiterleitung ein normaler Teil des Transportwegs. Ein empfangender Server kann eine Nachricht für einen anderen Server annehmen oder ablehnen. Nimmt er sie an, tritt er auf der nächsten Etappe als Sender auf. RFC 821 unterscheidet das endgültige Postfach vom Weg über mehrere Hosts. Das war für ein Netz aus unterschiedlichen Mailumgebungen nützlich: Die Nachricht musste nicht an der ersten Systemgrenze stehen bleiben.
Die teure Frage lautete, wer diese zusätzliche Fahrt bestellen darf. RFC 2505, im Februar 1999 als Best Current Practice 30 veröffentlicht, beschrieb unbefugte Nutzung eines Mail-Relays als Verbrauch fremder Ressourcen und als Gefahr für den Ruf seines Betreibers. Ein Mail Transfer Agent sollte solchen Verkehr steuern und ablehnen können. Aus der Transportfunktion wurde damit kein Fehler. Fehlerhaft war der Zutritt ohne Erlaubnis.
Vier Angaben einer SMTP-Sitzung hatten dabei sehr verschiedenes Gewicht. In HELO nennt der anrufende Rechner einen Namen; er kann ihn erfinden. Auch die Adresse in MAIL FROM stammt vom Anrufer und lässt sich fälschen. RCPT TO bezeichnet den Empfänger, und der Server sieht die Netzadresse der Verbindung. Wer aus den ersten beiden Selbstauskünften eine Relay-Erlaubnis ableitete, verwechselte eine Visitenkarte mit einem Auftrag der Geschäftsführung.
RFC 2505 verankerte die Entscheidung bei den eigenen Aufgaben des Servers. Er kann Nachrichten für Empfängerdomänen annehmen, die er bedient oder für die er vereinbarungsgemäß weiterleitet. Er kann Anrufer zum Relaying zulassen, deren Quelladresse autorisiert ist oder deren Hostname er nach eigener DNS-Politik vertraut. Andere Weiterleitungswünsche weist er zurück. Entscheidend ist nicht die Höflichkeit der Begrüßung, sondern wem der Betreiber einen Transport zugesagt hat.
Selbst die Zieladresse konnte sich verkleiden. RFC 2505 warnte vor Source-Routen wie @a,@b:, vor Prozent-Tricks und vor UUCP-Pfaden mit !. Eine hastige Prüfung konnte eine scheinbar örtliche Adresse genehmigen, obwohl die vollständige Auswertung eine weitere Fahrt verlangte. Zugleich nutzten legitime Gateways ungewöhnliche Schreibweisen. Betreiber sollten ihre tatsächlich verwendeten Routingwege kennen, bevor sie die Schranke einstellen. Eine Schranke, die nur den Anfang des Ziels liest, kontrolliert die falsche Straße.
Im Juni 1999 folgte RFC 2635 mit dem wenig diplomatischen Titel DON'T SPEW. Das Dokument wandte sich an Provider: keine offen weiterleitenden Mailserver, eine veröffentlichte Nutzungsordnung, Prüfung eines Missbrauchsvorwurfs vor Sanktionen und betreute Adressen abuse und postmaster. Der MTA konnte eine Sitzung stoppen. Beschwerden entgegennehmen, Kunden zuordnen und Fehlbeschuldigungen vermeiden musste weiterhin eine Organisation.
Der spätere SMTP-Standard RFC 5321 von Oktober 2008 hält eine zweite Spannung fest. Mail sollte traditionell zugestellt werden oder eine Fehlermeldung auslösen. Unerwünschte Massenpost machte Ablehnung und in bestimmten Lagen auch Verwerfen zu Betriebsentscheidungen; lautlos verschwundene Nachrichten beschädigen aber das Vertrauen in die Zustellung. Die Erlaubnis zur Weiterfahrt und das Schicksal einer bereits angenommenen Nachricht sind zwei verschiedene Schalter am selben Pult.
Der Server durfte weiter Post befördern. Er brauchte nur eine Antwort auf die Frage, für wen. Die Kosten und der Ruf gehörten dem Betreiber; das Wort „Hallo“ in HELO gehörte jedem, der eine Verbindung öffnen konnte. 1999 bekam diese ziemlich einfache Eigentumsfrage endlich ihren Platz im Fahrplan.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten





