Dies ist eine alte Version des Dokuments!


Artikel befindet sich gerade in der Bearbeitung!

SPF - Sender Policy Framework unter CentOS 7.x

SPF Logo 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.

Mit SPF soll hauptsächlich Absenderadressfälschungen verhindert werden, nicht jedoch direkt Spam zu bekämpfen. 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 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.

<uml w=800>

title Mailversand einer eMail\n skin BlueModern participant „\n Mail-Server mx01.nausch.org \n 217.91.103.190 \n“ as links participant „\n Mail-Server mx1.tachtler.net \n 88.217.171.167 \n“ as mitte participant „\n DNS-Server von nausch.org \n“ as rechts

links → mitte : connect von mx01.nausch.org zu mx1.tachtler.net note left : \n Verbindungsaufbau \n vom Quell- zum \n Zielserver \n links ←- mitte : . 220 mx1.tachtler.net ESMTP Postfix links –> mitte : HELO mx01.nausch.org links ←- mitte : . 250 mx1.tachtler.net links –> mitte : MAIL FROM:django@nausch.org

mitte → rechts : host -t TXT nausch.org note right : \n Abfrage der \n SPF-Records \n mitte ← rechts : nausch.org descriptive text „v=spf1 ip4:217.91.103.190/32 mx ?all“ note left : \n Der Mailserver mit der \n IP 217.91.103.190 ist berechtigt \n eMails der Mail-Domain \n nausch.org zu versenden \n links ←- mitte : . 250 2.1.0 Ok

links –> mitte : RCPT TO:klaus@tachtler.net links ←- mitte : . 250 2.1.0 Ok

links –> mitte : Übermittlung der Nachricht links ←- mitte : 250 2.0.0 Ok: queued as 5950581 note left : \n Beenden der Verbindung \n

</uml>

Weitere Informationen rund um SPF findet man im übrigen auf der Wikipedia Seite oder im besagten RFC 6652.

Aus den eingangs genannten Gründen sollte eine Sender Policy Framework Definition so gewählt werden, das auch weiterhin Nachrichten umgeleitet, Mailinglisten oder bei Bedarf Webformulare genutzt werden können.

Ein SPF-Record beinhaltet mehrere Angaben, die jeweils von links nach rechts ausgewertet werden. Der erste Wert gibt an, welche SPF-Version genutzt wird, aktuell SPF-Version „v=spf1“. Anschließend können mehrere IPv4- und/oder IPv6-Adressen angegeben werden, die entweder berechtigt oder vom Mailversand ausgeschlossen sein sollen. Diese Berechtigung wird dabei über einen Qualifier definiert. Es stehen folgende Werte zur Verfügung:

  • + : positiv Die nachfolgende IP-Adresse ist als legitimer Sender definiert. Wird kein Qualifer angegeben, wird automatisch der Wert + herangezogen (Defaulteinstellung).
  • - : negativ Die nachfolgende IP-Adresse definiert ein nicht autorisiertes Sendesystem Fail die Direktive definiert nicht autorisierte Sender
  • ? : neutral Über die Rechtmäßigkeit des Sendesystems kann nichts ausgesagt werden; Der Sender muß 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).

Neben der IP-Adressangabe mittels ip4 bzw.ip6, gibt es noch vier weitere Parameter, die im SPF-Record Anwendung finden.

  • a definiert einen A-Record der Domäne
  • mx definiert eine IP-Adresse, die im MX-Record der Domäne definiert wurde.
  • all Alle anderen IP-Adressen, also den Rest der weiten Welt.
  • include Einbinden einer weiteren SPF-Abfrage.

In der Regel wird man bei der Definition folgenden Festlegung treffen: eMails werden normalerweise immer von den IP-Adressen des zuständigen Mailserver versandt, können aber auch von anderen Servern verschickt werden. Als SPF-Record ergibt das dann „v=spf1 mx ?all“ im Falle des Mailservers mx01.nausch.org.

Wir tragen also bei unserem zuständigen DNS entsprechend die richtigen Daten ein.

 nausch.org                              IN      TXT     "v=spf1 mx ?all"

Über die URL SPF Record Testing Tools kann man online bei Bedarf testen, ob der SPF-Eintrag soweit richtig ist.

FIXME

Zu Beginn dieses Artikels wurde bereits darauf hingewiesen, dass mit unter Probleme bei Mailumleitungen und/oder WebFormularen auftauchen können. Mit SRS4) 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.

FIXME


1)
Sender Policy Frameworks
2)
Mail Transport Agent
3)
RFC 6652 aktualisiert RFC 4408
4)
Sender Rewriting Scheme
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • centos/mail_c7/spam_10.1417683168.txt.gz
  • Zuletzt geändert: 04.12.2014 08:52.
  • von django