Absender-Adressen von E-Mails sind leicht zu fälschen. Insbesondere Spam kommt immer mit entweder gestohlenen oder frei erfundenen Adressen an. Das Sender Policy Framework (SPF) ist ein Versuch, solche Fälschungen einzudämmen.
Um dieses Ziel zu erreichen, soll der empfangende Mailserver überprüfen können, ob der sendende Server tatsächlich berechtigt ist, E-Mails für die im Absender angegebene Domain zu verschicken. Ein Beispiel:
Vom Mailserver 1.2.3.4 wird eine E-Mail mit der Absenderadresse "charly@kuehnast.com" verschickt. Der empfangende Server fragt nun den Name-Server, der für die Domain kuehnast.com zuständig ist, ob es einen SPF-Eintrag für diese Domain gibt. Verschiedene Antworten sind möglich:
1. Es gibt keinen SPF-Eintrag. In diesem Fall kann nicht überprüft werden, ob der Server 1.2.3.4 berechtigt ist, diese E-Mail zu versenden. Der empfangende Server wird die Mail annehmen und wahrscheinlich weiteren Prüfungen unterziehen.
2. Es gibt einen SPF-Eintrag, der besagt, dass der Server 1.2.3.4 zum Versand der E-Mail berechtigt ist. Der empfangende Server nimmt die Mail an (wird sie aber hoffentlich trotzdem noch dem Spamfilter zur Überprüfung geben, denn Vorsicht ist die Mutter der Porzellankiste)
3. Es gibt einen SPF-Eintrag, der besagt, dass der Server 1.2.3.4 nicht zum Versand von Mails für kuehnast.com berechtigt ist. In diesem Fall darf der empfangende Server den SMTP-Dialog beenden.
Diese drei Möglichkeiten sind in der Praxis relevant. Es sei aber erwähnt, dass die SPF-Spezifikation, RfC 4408, noch weitere Varianten zulässt. So kann ein Nameserver auf die Frage nach einem SPF-Eintrag auch antworten, dass es dem Domaininhaber völlig egal ist, welcher Server E-Mails mit seinem Domainnamen verschickt. Der DNS-Eintrag, der die Überprüfung möglich macht, sieht beispielhaft so aus:
kuehnast.com. IN TXT "v=spf1 +ip4:11.22.33.44 -all"
Anstelle des TXT gibt es auch den passenderen, extra dafür eingeführten SPF-Record, der ansonsten syntaktisch gleich lautet. Betreiber eines älteren Nameservers, der den SPF-Typ noch nicht kennt, müssen sich mit dem TXT-Eintrag begnügen. Im Fall von bind9 sind das die Versionen vor 9.4.0. Die Autoren des RfC schlagen vor, dass bei Nameservern, die den SPF-Typ bereits kennen, sowohl der SPF- wie auch der TXT-Eintrag in identischer Form vorgenommen werden sollen, um Abwärtskompatibilität auch auf der abfragenden Seite zu gewährleisten.
Der Inhalt des SPF-Eintrags beginnt immer der Versionsbezeichnung, derzeit also v=spf1. Obwohl es noch keine weitere Version gibt, darf dieser Teil nicht weggelassen werden.Darauf folgen ein oder mehrere "Mechanismen", wie es der RfC nennt. Es sind Prüfungsmechanismen, aus denen sich ergibt, welche Server autorisiert sind, für die Domain E-Mail zu versenden. Die wichtigsten sind:
ip4: Eine einzelne IPv4-Adresse oder ein Netz in der Schreibweise 1.2.3.4/24. Ist der sendende Server in diesem Bereich beheimatet, gilt die SPF-Prüfung als bestanden.
ip6: Analog für IPv6-Adressen. Auch hier können einzelne Hosts oder Netze angegeben werden.
a: Alle A-Einträge für die Domain werden darauf überprüft, ob sich die Adresse des sendenden Servers unter ihnen befindet. Auch hier kann mit einer Netzmaske gearbeitet werden, "a/24" bezieht alle Hosts, die sich im gleichen Subnetz wie die Server, deren A-Records ermittelt werden. Zusätzlich ist es möglich, andere Domains in die Prüfung mit einzubeziehen. In diesem Fall lautet die Syntax "a:colocation.kuehnast.com/24".
mx: Analog zu "a", auch syntaktisch, nur dass in diesem Falle die MX-Einträge zur Überprüfung herangezogen werden.
all: Dieser Mechanismus trifft immer zu. Er steht deshalb normalerweise, mit einem Minuszeichen versehen, am Ende des SPF-Eintrags.
Diese Plus- oder Minuszeichen, die den Mechanismen vorangestellt werden, heißen Modifikatoren. Ist ein Mechanismus nicht mit einem Modifikator versehen, gilt dies implizit als "+", ich hätte das Pluszeichen vor dem ip4-Mechnismus im Beispiel oben auch fortlassen können.
Die Prüfungsmechanismen werden der Reihe nach abgearbeitet, bis einer davon ein positives Ergebnis liefert, also eine IP-Adresse findet, die mit der des sendenden Servers übereinstimmt. Wird keine solche Adresse gefunden, greift der letzte Mechanismus in der Zeile, "-all". Damit wird definiert, dass die Anfrage endgültig negativ beantwortet wird.
Es ist nicht sinnvoll, das "-all" am Zeilenende wegzulassen! Falls die Prüfungen keine positive, aber auch keine eindeutig negative Antwort liefert, gilt die gesamte SPF-Überprüfung weder als "pass" noch als "fail", sondern als "neutral". Auf Basis dieses Ergebnisses kann der empfangende Mailserver keine eindeutige Entscheidung treffen und wird die eingehende Mail so behandeln müssen, als käme sie von einem Absender, der überhaupt keinen SPF-Eintrag besitzt.
SPF schützt nicht per se vor Spam. Diese Mail wird eindeutig als Spam erkannt, obwohl die SPF-Prüfung bestanden wurde.
Die oben kurz erwähnte kuriose Konfiguration für Domaininhaber, denen explizit egal ist, wer in ihrem Namen Mails verschickt, lautet demnach einfach "v=spf1 +all". SPF wird nach wie vor kontrovers diskutiert, und einige radikale Gegner der Spezifikation benutzen diese Konfiguration, um ihren Unmut auszudrücken.
Sinnvoll kann dagegen die gegenteilige Konfiguration sein: "v=spf1 -all". Sie ist geeignet für Domains, von denen der Inhaber weiß, dass sie niemals zum Mailversand benutzt werden. Alle SPF-Abfragen werden damit negativ beschieden, und ein Spammer hat bei der missbräuchlichen Nutzung des Domainnamens vielleicht etwas weniger Erfolg.
Im praktischen Einsatz stellt SPF den Benutzer schnell vor Schwierigkeiten. Drei Kritikpunkte werden besonders häufig ins Feld geführt:
- SPF setzt voraus, dass der annehmende Mailserver auch der Endpunkt der E-Mail-Kommunikation ist. Wird die Mail jedoch vom annehmenden Server an einen Dritten weitergeleitet, der wiederum ein SPF-Prüfung vornimmt, so wird diese oft fehlschlagen. Denn die IP-Adresse des weiterleitenden Servers wird im zuständigen SPF-Record häufig nicht enthalten sein, da Weiterleitungen in vielen Fällen temporäre, aus einer Notsituation geborene Konstrukte sind. Lösbar ist dieses Problem mit Hilfe des Sender Rewriting Scheme (SRS), das jedoch zusätzlichen Aufwand bedeutet und gerade bei temporären Umleitungen kaum angewandt wird.
- Nicht immer ist es möglich, beim E-Mail-Versand den "heimischen" Mailserver zu benutzen. Gerade Außendienst-Mitarbeiter müssen häufig auf den Mailserver des Kunden zurückgreifen, weil sie den eigenen Server aus dem Kunden-Netz heraus nicht erreichen können.
- Spammer benutzen "Wegwerf-Domains" und können damit eigene, gültige SPF-Einträge anlegen. Außerdem kommen enorme Mengen Spam aus Botnetzen. Die Rechner eines Botnetzes sind gekaperte, mittels Trojanern ferngesteuerte Drohnen. Sie benutzen den standardmäßig eingerichteten SMTP-Transport zum Versand von Spam, eine SPF-Prüfung wird immer positiv ausfallen.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
