SPF ?  WTF is SPF ?

Der Sender Policy Framework erlaubt es dem Empfänger einer Email zu prüfen, ob die Email die er gerade bekommt, wirklich von den Mailservern des Absender stammt, oder ab der Absender Fake ist.

Damit das klappt, muß der Absender zwei, ja zwei, einer reicht nicht mehr, Einträge im DNS vornehmen.

Bis SPF standardisiert wurde, reichte es einen TXT Eintrag zu haben. Heutzutage gibt es einen eigenen DNS Type namens SPF für den SPF Eintrag, den sollte man also auch ausfüllen, weil TXT irgendwann nicht mehr geprüft wird.

Die beiden Einträge sind aber gleich aufgebaut, man muß also nichts neues lernen.

Ein Beispiel ( gekürzt auf das Wesentliche ) am Beispiel des TXT Eintrags ) :

$ dig TXT bloggt-in-braunschweig.de

; <<>> DiG 9.10.3-P4-RedHat-9.10.3-13.P4.fc23 <<>> TXT bloggt-in-braunschweig.de
…
;; ANSWER SECTION:
bloggt-in-braunschweig.de. 21599 IN    TXT    „v=spf1 mx -all“
…

Erklärung: „v=spf1 mx -all“

v=spf1 beschreibt den SPF Type, der Teil ist derzeit immer so, aber das könnte sich in Zukunft mal ändern.
mx       legt fest, daß die IP des Senders mit der IP des MX der Domain übereinstimmen muß.
-all       legt fest, daß es keinen Zweifel gibt, daß der SPF Eintrag vollständig ist und daher alle Mails die mit ihm nicht übereinstimmen, gelöscht werden können.

Diesen SPF kann man jetzt noch erweitern, hier ein Beispiel, wenn der Webserver nicht gleich dem Mailserver ist:

Erklärung: „v=spf1 a mx -all“

a          legt fest, daß die IP auch die des IN A zum Domainnamen sein darf.

Hat man mehrere IPs auf dem Server, wäre es clever auch diese einzutragen, weil man nie sicher sein kann, daß der Mailserver nicht mal eine andere IP davon benutzt:

Erklärung: „v=spf1 a mx ip4:5.4.3.5/24 -all“

ip4:ip/mask  legt also fest, aus welchen IP Bereich der Absender stammen darf. Das ist z.b. ganz wichtig für web.de oder gmx.de die einen ganzen Serverpark nutzen um Emails zu versenden. Die „ip4“ Anweisung kann man beliebig oft einsetzen, wenn man mehrere Netze hat.

Es gibt noch einige andere Anweisungen, z.b. kann man mit include ganze SPF Anweisungen von anderen Domains übernehmen. Z.b. wenn man bei xxx.domain als Hoster einen Service nutzt, könnte man den SPF von xxx.domain includen und wäre so sicher, auch immer alle Serverips freigegeben zu haben, die dieser Hoster nutzt.

Das Wirkprinzip nochmal in Detail

Der Domaininhaber legt pro Domain fest, von welcher IP eine Email gesendet werden darf.

Der Empfänger prüft, ob die zu ihm kommende IP vom SPF Eintrag gedeckt ist.

Daraus folgt, daß jeder Domaininhaber tätig werden muß.

SPF Fallen

Prinzipbedingte Fallen von SPF sind z.b. Weiterleitungen an andere Emailkonten auf anderen Servern.

Wenn ich auf Server A von Domain X eine Email bekomme, sehe ich als Server noch die IP des originalen Absenders. Wenn ich als Server die Email an Server B weiterleite, sieht der nur meine IP und kann auch nur die gegen den SPF prüfen. Wenn das nicht paßt, und das wird es in 99% der Fälle nicht, wird die Email korrekterweise abgelehnt. Hier gibt es nur eine Abhilfe, des Absender beim Weiterleiten umzuschreiben, so daß man den Originalabsender noch sieht, aber er nicht mehr für SPF Prüfungen in Frage kommt.

Um das zu machen, gibt es verschiedene Ansätze wie SRS , aber nichts was aus einer RFC kommt, AFAIK.

Links

Da dies nur eine kleine Einführung in die Welt von SPF sein kann, hier einige Links zum Thema:

Wikipedia: Sender Policy Framework
OpenSPF: www.openspf.org

Linuxhinweise

Mit Dig, daß auf allen Distros zu haben sein dürfte, kann man so die Records abfragen:

dig -t TXT domainname
dig -t SPF domainname

Da wir einen SPF vom Type SPF im DNS gesetzt haben, DIG aber nichts dafür ausgibt, weiß ich jetzt nicht, ob der DNS den Fehler macht, oder DIG.

Mit der Perlerweiterung Perl-Mail-SPF kann man den Eintrag checken:

/usr/share/doc/perl-Mail-SPF/bin/spfquery –scope mfrom –id someone@domainname –ip 8.9.34.31

Beispiel:

# /usr/share/doc/perl-Mail-SPF/bin/spfquery –scope mfrom –id someone@bloggt-in-braunschweig.de –ip 1.2.3.4
fail
Please see http://www.openspf.org/Why?s=mfrom;id=someone%40bloggt-in-braunschweig.de;ip=1.2.3.4;r=XXXXXXXX.XXXXXXXXXXX.XXXXX
bloggt-in-braunschweig.de: Sender is not authorized by default to use ’someone@bloggt-in-braunschweig.de‘ in ‚mfrom‘ identity (mechanism ‚-all‘ matched)
Received-SPF: fail (bloggt-in-braunschweig.de: Sender is not authorized by default to use ’someone@bloggt-in-braunschweig.de‘ in ‚mfrom‘ identity (mechanism ‚-all‘ matched)) receiver=s36.my-system.de; identity=mailfrom; envelope-from=“someone@bloggt-in-braunschweig.de“; client-ip=1.2.3.4

Wie man sieht, ist 1.2.3.4 nicht im SPF drin und darf deswegen im unserem Namen keine Emails verschicken.