Dies ist eine alte Version des Dokuments!
SPF - Sender Policy Framework unter CentOS 7.x
Mit Hilfe von SPF1) kann definiert werden, welche Mailserver für welche Domains eMails verschickt werden (können), oder nicht, oder anders ausgedrückt, soll das Fälschen von Absender-Angaben mit Hilfe von SPF erschwert werden. Genauer gesagt schreibt das SPF fest, welcher MTA2) abgehend für den Versandt von e-Mails einer Domain zugelassen ist. Wichtige Hinweise zu SPF findet man bei Bedarf in der überarbeiteten Version RFC 66523) oder auch auf der Webseite von openspf.org.
Dieses here Ziel wirft bei genauerer Betrachtung viele Fragen auf und erzeugt bei manchen Mailserver-Betreibern nicht gerade viel Begeisterungsstürme. Probleme tauchen mit unter bei Mailumleitungen, Mailinglisten und/oder WebFormularen auf. Auch wird bei sehr konservativen SPF-Definition die Möglichkeit verhindert, eMails mit eigener Absender-eMail-Adresse über einen dritten Rechner zu versenden. Es wäre also nur möglich eMails auch über den Mail-Server zu versenden, auf dem auch das Postfach liegt! Speziell auch Beim Versand über ein z.B. WebFormular, oder eine Web-Grußkarte über einen Drittanbieter wäre dann kein Versand mehr möglich!
Beim SPF wird ein TXT-Record in der Zonendatei im DNS der betreffenden (Mail)Domain eingetragen. Dort wird definiert, welche SMTP-Server berechtigt sind, Nachrichten der (Mail)Domain zu verschicken. Mailserver können dann bei der Annahme der eMails abfragen, ob der sendende Mailserver überhaupt berechtigt ist, diese Nachricht zu verschicken. So soll bzw. kann mit Hilfe von SPF versucht werden, Absenderadressfälschungen - eine Form des eMail-Identitätsbetrugs - zu verhindern. SPAM kann aber mit Hilfe des Sender Policy Framework nicht direkt bekämpft werden!
Nachfolgende Skizze zeigt exemplarisch auf, wo genau SPF beim Verarbeiten einer eMail beim Kommunikationsaufbau und -ablauf zweier MTA4) kann ein Mailserver die eMail-Adresse im Envelop umschreiben und anpassen. Eine genauere Beschreibung zu SRS ist im Kapitel SRS - Sender Rewriting Scheme zu finden. ====== Links ====== * ⇐ Zurück zum Kapitel "SPAM- und Virenschutz Mechanismen unter CentOS 7" * ⇒ Weiter zum Kapitel "SRS - Sender Rewriting Scheme unter CentOS 7.x" * Zurück zum Kapitel >>Mailserverinstallation unter CentOS 7<< * Zurück zu >>Projekte und Themenkapitel<< * Zurück zur Startseite**
v
oder redirect
, ein Typ wie a
bzw. mx
oder auch eine Include-Aweisung include
sein. Der erste Wert gibt an, welche SPF-Version genutzt wird, aktuell SPF-Version „v=spf1“. Anschliessend können mehrere IPv4- und/oder IPv6-Adressen, auf den MX-Record verweisen werden oder auch weitere SPF-Definitionen inkludiert werden, die entweder berechtigt oder vom Mailversand ausgeschlossen sein sollen. Diese Berechtigung wird dabei über einen Qualifier definiert.
Der erste Wert gibt an, welche SPF-Version genutzt wird, aktuell SPF-Version „v=spf1“.
Folgendes Format wird hierbei verwendet:
[Präfix][Mechanismus][:Wert]
=== Präfix ===
Das Präfix bestimmt das SPF-Validierungsergebnis, welches der Empfänger auf die Nachricht anwenden soll, sofern der Absender mit der Angabe/Begriff übereinstimmt. Es stehen folgende Werte zur Verfügung:
* + : positiv Die nachfolgende IP-Adresse ist als legitimer Sender definiert. Wird jeweils kein Qualifer angegeben, wird automatisch der Wert + herangezogen (Defaulteinstellung).
* - : negativ Die nachfolgende IP-Adresse definiert ein nicht autorisiertes Sendesystem. Die Direktive Fail definiert nicht autorisierte Sender.
* ? : neutral Über die Rechtmässigkeit des Sendesystems kann nichts ausgesagt werden; Der Sender muss daher akzeptiert werden.
* ~ : soft-fail Die nachfolgende IP-Adresse definiert ein nicht autorisiertes Sendesystem. Das Empfangssystem soll jedoch die Annahme der Nachricht dennoch annehmen (Test-Qualifier).
=== Mechanismus ===
Der Mechanismus bestimmt, wie eine IP-Adresse mit dem Begriff abgeglichen werden soll. Unterstützte Werte sind hier:
* a
: definiert einen A-Record der Domäne
* ipv4
: Angabe einer IPv4-Adresse
* ipv6
: Angabe einer IPv6-Adresse
* mx
: definiert eine IP-Adresse, die im MX-Record der Domäne definiert wurde.
* ptr
: Dieser Mechanismus prüft, ob das DNS-Reverse-Mapping für <ip> existiert und korrekt auf einen Domänennamen innerhalb einer bestimmten Domäne verweist. Dieser Mechanismus SOLLTE NICHT veröffentlicht werden.
* include
: Einbinden einer weiteren SPF-Abfrage.
* exists
: Dieser Mechanismus wird verwendet, um einen beliebigen Domänennamen zu konstruieren, der für eine DNS-A-Eintragsabfrage verwendet wird. Er erlaubt komplizierte Schemata die beliebige Teile des mail envelops einbeziehen, um zu bestimmen, was erlaubt ist.
* all
: Alle anderen IP-Adressen, die explizit nicht bis jetzt genannt wurden, also der Rest der weiten Welt.
==== Beispiele ====
=== einfach „mx“-Definition ===
Im ersten Konfigurationsbeispiel, welches vermutlich einen Großteil von vielen MTA abedcken wird, treffen wir folgende Definition: eMails werden normalerweise immer von den IP-Adressen des zuständigen Mailserver versandt, können aber auch von anderen Servern verschickt werden. Ein Emfangendes System soll auf jeden Fall die Nachricht annahmen, diese aber entsprechend kennzeichnen. Als resultierender SPF-Record ergibt das dann z.B. v=spf1 mx ~all
im Falle des Mailservers mx01.nausch.org. Den Präfix +
beim Mechanismus mx
können wir weglassen, da dies die Defaulteinstellung ist.
Wir tragen also bei unserem zuständigen DNS im Zonenfile entsprechend die richtigen Daten ein.
nausch.org IN TXT „v=spf1 mx ~all“
Ändert sich die Anzahl der MX-Records bei unserer Domäne werden automatisch die zutreffenden Hosts bei einer SPF-Anfage honoriert, ohne dass wir extra den SPF-TXT-Record anfassen müssen. Sehr wohl ist jedoch anzumerken, dass für die vollständige Ermittlung der sendeberechtigten Systeme zusätzliche DNS-Abfragen notwendig werden, was mit unter zu Problemen führen kann, sofer die max. Anzahl von 10 DNS-Abfragen überschrittenwerden wird. Wie wir damit besser umgehen und diese Herausforderung meistern können, betrachten wir im Abschnitt XXXYYYZZZ dann noch extra genauer!
=== Erweiterungen um weitere Mechanismen ===
Im zweiten Beispiel nehmen wir an, dass neben dem MX der Domäne auch noch eine Webanwendung cloud.nausch.org
direkt Nachrichten versenden wird. Wir ergänzen also unseren Standard-mx-Eintrag um den Mechanismus a
.
nausch.org IN TXT „v=spf1 mx a:cloud.nausch.org ~all“
Da wir statt der IP-Adresse den Namen cloud.nausch.org angegeben haben, wird auch hier eine weitere DNS-Abfrage notwendig werden, wenn der vollständige SPF-Definition ermittelt werden soll. Alternativ kann man hier natürlich mit den ipv4
und ipv6
Mechanismen arbeiten.
nausch.org IN TXT „v=spf1 mx a:cloud.nausch.org ipv4:127.0.0.1 ipv6:::1 ~all“
Zu bedenken ist hier natürlich, dass keinenfals die maximale Länge von 255 Zeichen eines TXT-Records keinenfalls überschritten werden darf!
==== zusätzliche Hinweise ====
Will man neben dem SPF-Record in Form eines TXT-Records auch noch einem google-site-verification TXT-Record anlegen, dann kann man nicht zwei TXT-Records für die Domain im DNS hinterlegen. Um dennoch beide Funktionenn nutzen zu können, trägt man beide Werte in einem TXT-Record ein. So z.B.
@ 300 IN TXT "v=spf1 ip4:217.92.13.131/32 mx ?all " "google-site-verification=oghnZ6HahxTGKkknsap_i-iX8nMi9iz0n6ArEvxuLFA"
Auf den ersten Blick erscheint der Postfix Poliyd-Daemon pypolicyd-spf aus dem EPEL-Repository eine leicht zu installierende und vielversprechende Möglichkeit zu sein. Betrachtet man SPF alleine, stimmt dies auch.Möchte man aber hingegen später DMARC bei der Bewertung von SPF und DKIM einsetzen, so weicht man besser auf den SPF-Milter smf-spf aus Djangos Repository mailserver.guru aus.
