Mail/DNS: Sender Policy Framework

Bei dieser Technik wird bei der entsprechenden Domain im DNS eine
Liste der für den Versand erlaubten Hosts beziehungsweise IPs hinterlegt. Kommt eine E-Mail von einem
System, welches nicht in dieser Liste ist, kann die E-Mail je nach Regelung geblockt, stärker gefiltert
oder zugelassen werden. Bei dieser Prüfung werden sowohl die Adresse aus MAIL FROM als auch
die Adresse aus HELO herangezogen.

Beispiel:

Es wird eine E-Mail mit der Absender-Adresse info@no-uce.de von einem Mailserver versendet, der nicht
für no-uce.de zuständig ist. Bei der SPF Prüfung wird von
dem empfangenden Mailserver nun im DNS geprüft, welche Hosts
laut SPF-Record E-Mails von no-uce.de versenden dürfen:

jean@andor ~ $ host -t TXT no-uce.de
no-uce.de descriptive text v=spf1 a mx -all

In diesem Fall dürfen E-Mails von no-uce.de nur von den Adressen im A- und MX-Record der Domain versendet
werden. Alle anderen (all) haben durch das vorangestellte - keine Autorisierung,
E-Mails der Domain zu versenden. Der empfangende Mailserver bekommt die Anweisung diese E-Mail
abzulehnen.

Der Einsatz von SPF kann in zwei von einander unabhängige
Bereiche geteilt werden: Zunächst geht es um das Einrichten eines entsprechenden
DNS-Records
, damit andere Mailserver auswerten können, ob der Sender autorisiert ist. So wird
unautorisierter Versand von E-Mails mit der eigenen Domain unterbunden. Der zweite Teil ist die Auswertung von SPF-Records anderer Domains.

SPF-Records

Ein SPF-Record setzt sich aus Mechanismen
all ip4 ip6 a mx ptr exists include, Modifikatoren
redirect exp und Kennzeichen + - ~ ? zusammen:

Mechanismen

all
Wird meist am Ende genutzt, da es auf alles zutrifft und somit genutzt werden kann, um alles nicht
Zutreffende zu verbieten
ip4
Prüft, ob die Client-IP mit der hier angegebenen IPv4-Adresse oder dem IPv4-Bereich übereinstimmt
ip6
Wie ip4, aber für IPv6
a
Prüft, ob die Client-IP mit einem der A-Records der Domain übereinstimmt
mx
Wie a, allerdings wird hier auf die MX-Records geprüft
ptr
Prüft, ob der angegebene Hostname auf die IP des Clients zeigt
exists
Prüft, ob die Domain über einen A-Record verfügt
include
Kann genutzt werden, um SPF-Einträge einer anderen
Domain zu nutzen. include:_spf.google.com, wenn mit der Domain auch
E-Mails über Googlemail verschickt werden. Besondere Vorsicht ist bei include geboten, da es zu
einem PermError kommt, wenn die angegebene Domain _spf.google.com über
keinen SPF-Record verfügt!

Wird nicht durch einen Doppelpunkt ein Host, eine Domain oder eine andere Adresse angegeben, wird die
eigene Domain verwendet. Somit bezieht sich ein alleingestelltes a auf die Adresse im A-Record der
abgefragten Domain no-uce.de.

v=spf1 a mx -all
A-Record der eigenen Domain
v=spf1 a:example.com mx -all
A-Record von example.com

Kennzeichen

Jeder Mechanismus kann mit einem vorangestellten Kennzeichen verwendet werden:

Pass +
Der Absender gilt als autorisiert
Fail –
Der Absender gilt nicht als autorisiert
Softfail ~
Eigentlich ist der Host nicht autorisiert, dennoch zulassen
Neutral ?
Es kann keine Aussage über die Autorisierung getroffen werden, daher zulassen

Wird kein Zeichen vorangestellt, handelt es sich um Pass. Mithilfe dieser Kennzeichen
lassen sich dann Konstrukte wie
v=spf1 exists:example.com a mx ?include:_spf.google.com -all zusammenstellen.
Aufgeschlüsselt bedeutet dies:

v=spf1
SPF-Version 1
exists:example.com
Wenn example.com nicht auflösbar ist, wird die E-Mail abgelehnt (fail)
a
E-Mails, bei denen die Client-IP und der A-Record der Domain übereinstimmen, werden zugelassen
mx
E-Mails, bei denen die Client-IP und der MX-Record der Domain übereinstimmen, werden zugelassen
?include:_spf.google.com
E-Mails, bei denen die SPF-Regeln von
_spf.google.com einen Treffer erzeugen, werden neutral behandelt (also akzeptiert)
-all
Alle anderen E-Mails ablehnen (reject)

Modifikatoren

Die beiden Modifikatoren redirect und exp seien an dieser Stelle auch kurz erwähnt:

redirect
Kann genutzt werden, um den SPF-Record einer anderen Domain zu nutzen
exp
Kann genutzt werden, um eine Erklärung für den Reject zu geben

Genauere Erklärungen zu der Syntax finden sich auf der offiziellen Website: SPF-Record Syntax. Sobald der SPF-Record als
TXT Record im DNS hinterlegt worden ist, können empfangende
Mailserver diesen auswerten.

Einbindung

Um SPF-Records auszuwerten, beziehungsweise die entsprechende Prüfung zu implementieren, stehen mehrere
Möglichkeiten zur Verfügung: Zum Einen kann eine entsprechende Prüfung direkt in Postfix mittels eines
Policy Daemons integriert werden, zum Anderen kann die SPF-Prüfung auch in Erweiterungen wie
Spamassassin eingeschaltet werden, wodurch das Ergebnis in das Ranking beim Auswerten von E-Mails
einfliest.

Postfix

Auf der Website von OpenSPF sind drei Tools zur Einbindung von
SPF-Prüfungen vorhanden; in diesem Artikel
wird die Python-Variante beschrieben. Zunächst sollte dafür
postfix-policyd-spf-python installiert
werden. In Debian geschieht dies mittels apt-get install postfix-policyd-spf-python.

Anschliessend muss in der main.cf von Postfix der Eintrag
policy-spf_time_limit = 3600s, sowie in den recipient restrictions (nach
reject_unauth_destination) check_policy_service unix:private/policy-spf hinzugefügt werden.
In der master.cf von Postfix muss dann noch der folgende Eintrag ergänzt werden:

policy-spf  unix  -       n       n       -       -       spawn
     user=nobody argv=/usr/bin/policyd-spf

Die Standardeinstellungen von postfix-policyd-spf-python sollten für die meisten Mailserver-Betreiber
gut sein, es empfiehlt sich jedoch zunächst in
/etc/postfix-policyd-spf-python/policyd-spf.conf den Wert von defaultSeedOnly auf 0 zu
stellen und sich anzusehen, was abgelehnt werden würde (Adressen durch xx ersetzt):

jean@andor ~ $ grep policyd-spf /var/log/mail.info
policyd-spf[6110]: Fail; identity=mailfrom; client-ip=47.xx.xx.xx; helo=xx.airtel.net;
                         envelope-from=xx@airtel.net; receiver=xx@no-uce.de
policyd-spf[6197]: None; identity=helo; client-ip=209.xx.xx.xx; helo=xx.google.com;
                         envelope-from=xx@googlemail.com; receiver=xx@no-uce.de
policyd-spf[6197]: Pass; identity=mailfrom; client-ip=209.xx.xx.xx; helo=xx.google.com;
                         envelope-from=xx@googlemail.com; receiver=xx@no-uce.de

Fallstricke

Debugging

Wird SPF eingesetzt, sollten die eigenen Nutzer
unbedingt informiert werden. Anders als bei

DMARC
gibt es im Falle von
SPF keine Benachrichtigung, wenn bei einem externen System
eine E-Mail aufgrund der SPF-Records abgelehnt wird. Es ist für den Systemadministrator also nicht
ersichtlich, was und ob die eigenen SPF-Records etwas Unerwünschtes anrichten.

Versand

Nutzt ein Kunde z.B. einen eigenen Mailserver innerhalb der Firma für den Versand von E-Mails, würden
diese E-Mails von Mailservern, die mittels SPF filtern,
blockiert werden, da die entsprechende Autorisierung fehlt. In solchen Fällen sollte die IP oder entsprechend der
Hostname des beim Kunden gehosteten Mailservers mit in den SPF-Record aufgenommen werden.

Einige Universitäten blockieren die Nutzung externer Mailserver. Sendet ein Student nun von dem
Universitäts-Mailserver mit seiner privaten Adresse von GMX als Absender, wird diese von Mailservern, die
SPF auswerten, ebenfalls abgelehnt, da der GMX SPF-Record
den Mailserver der Universität nicht als erlaubten Sender definiert hat.

Weitere Möglichkeiten

SPF-Records für HELO Hostnamen

Dieser Punkt wird oftmals vergessen oder ist nicht jedem bekannt. Die Hostnamen, die in HELO
beziehungsweise EHLO genutzt werden, sollten ebenfalls über einen (seperaten) SPF-Record
verfügen:

no-uce.de. IN TXT "v=spf1 mx -all"
mail.no-uce.de. IN TXT "v=spf1 a -all"

Der erste Record bezieht sich auf alle E-Mails mit Absender *@no-uce.de, während die zweite Regel bei der
HELO/EHLO-Prüfung zum Einsatz kommt.

Null-SPF

Weiterer Schutz ist möglich, indem Subdomains und Domains, die keine E-Mails versenden einen Null-SPF-Record
bekommen: www.no-uce.de. IN TXT "v=spf1 -all" Wenn über die Subdomain www. keine E-Mails
verschickt werden (genauso wie z.B. über die Subdomain ftp.), sollte ein entsprechender Null-SPF-Record gesetzt werden.
Dabei wird mit -all ein Fail-Response zurückgegeben.

Makros

Bei einigen Modifikatoren und Mechanismen können Macros verwendet werden. Diese Macros
ermöglichen es, dass z.B bei der SPF-Prüfung eine
DNSBL herangezogen werden kann.

Angenommen, es wird eine eigene DNSBL (dnsbl.example.org) gepflegt,
in welche IPs eingetragen werden, die unautorisiert E-Mails von einer eigenen Domain versenden (was z.B.
in den DMARC Reports ersichtlich ist).

Es kommt eine unautorisierte E-Mail von 1.2.3.4:
v=spf1 -exists:%{ir}.dnsbl.example.org ?all In diesem Fall wird die E-Mail abgelehnt, wenn
die Prüfung von 4.3.2.1.dnsbl.example.org einen Treffer ergibt. Hier wird also explizit nur blockiert,
wenn es zu einem Treffer auf einer bestimmten DNSBL kommt. In allen
anderen Fällen wird ein neutrales Ergebnis zurückgegeben.
Weitere Informationen zu den Macros finden sich
hier
.

No Comments

Post a Comment