Mailserver: Sender Policy Framework
Die Bearbeitung von Spammails ist heutzutage leider die Hauptbeschäftigung von praktisch jedem Mailserver. Verschiedene Mechanismen werden bei der Spamprüfung hintereinander geschaltet, um beim Durchlauf einer jeden E-Mail zu entscheiden, ob sie zugestellt werden sollte oder nicht. Das Sender Policy Framework (SPF) kann den Servern die Arbeit etwas erleichtern.
Geschichte
Mit der Arbeit an SPF wurde 2003 begonnen und der finale experimentelle Status wurde 2006 mit RFC4408 erreicht. Dieser Standard wird heutzutage bereits von einigen Mailservern unterstützt.
Im April diesen Jahres wurde SPFv1 mit RFC7208 offiziell von der Internet Engineering Task Force als Standard verabschiedet.
Motivation
E-Mails von meinem Mailserver an einen Google-Mailaccount wurden, wenn sie recht kurz waren, öfters als möglicher Spam ohne Zustellung zurückgewiesen. Ich mache Google keinen Vorwurf. Viel mehr als das Ergebnis vom Bayes-Filter und einer Übereinstimmung von SMTP-Banner und Reverse-DNS-Eintrag mit hatte es zur Klassifizierung schließlich nicht greifbar. Weiter schlägt bei Google so viel Spam auf, dass sie es sich einfach nicht leisten können, dort Ressourcen zu verbraten.
Nach etwas Recherche habe ich herausgefunden, dass SPF mein Problem lösen könnte.
Funktionsweise
Dieser Mechanismus verhindert, dass jemand E-Mails mit falschem Absender
versenden kann, insofern der empfangende Mailserver das prüft bzw.
prüfen kann. Es wird beim versendenden Mailserver ein SPF-Record im DNS gesetzt, welcher beschreibt, welche Rechner E-Mails für die benutzte Domain versenden dürfen. Ein empfangender Mailserver kann nach Abfrage des SPF-Records entscheiden, ob die IP des Mailservers, von dem er die Mail bekommt, der Regel des Records entspricht.
Einrichtung
Alles hängt am SPF-Record, der in jedem Fall korrekt sein muss. Falls man sich vertut und empfangende Mailserver ein SPF-Fail feststellen, kann das die Zustellungen um ein Vielfaches unwahrscheinlicher machen.
Senderichtung
Abhängig vom Setup kann es beliebig kompliziert sein, die passende SPF-Regel herauszufinden. Mir hat es geholfen, die RFC zu lesen. Letztendlich war die Regel aber für mein Setup mit einem Mailserver und einer mailsendenden Domain ziemlich einfach.
$ host -t txt gnuheidix.de gnuheidix.de descriptive text "v=spf1 mx -all"
Diese Regel sagt nicht mehr aus, als dass die im MX-Record hinterlegten Rechner Mails senden dürfen und kein anderer. Es gibt übrigens auch einen Tester vom Schreiber der RFC.
Empfangsrichtung
Es kann sein, dass beim eigenen Mailserver bereits SPF geprüft wird. OpenSPF hat eine Liste der Implementierungen zusammengestellt.
Man kann die eigene Unterstützung testen, indem man in den Header einer E-Mail, die man von außerhalb des eigenen Mailservers empfangen hat, schaut. Folgender Header zeigt beispielhaft, dass gegen SPF erfolgreich geprüft wurde.
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=199.59.150.99; helo=spruce-goose-bd.twitter.com; envelope-from=bbbbbbbbbb2baaa=gnuheiix.de@bounce.twitter.com; receiver=baaa@gnuheiix.de
Um die SPF-Prüfung bei meinem Postfix an den Start zu bringen, habe ich das Package postfix-policyd-spf-python installiert und die Einrichtungsschritte der Manpage befolgt. Das ist nach 15 Minuten erledigt.
Fazit
Diese weitere Komplexitätsstufe kann den entscheidenden Unterschied bei der Spamklassifizierung machen.
X-Spam-Status: No, tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.552, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
Probiert es doch mal aus.
Nachtrag
29.05.2014: Es gibt auch ein Plugin für Munin.
Kommentare