Mit Hilfe von SPF¹⁾ 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 MTA²⁾ 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 6652³⁾ 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.

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.

Neben der Befragung von Black-/White-Listen, dem Nutzen von Greylisting oder policyd-weight, können wir auch SPF bei der Bewertung von eingehenden Sendungen heranziehen.

Als laden wir uns das aktuelle RPM auf unseren Server.

 # cd /usr/local/src/packages

 # wget http://repository.nausch.org/public/x86_64/smf-spf-2.0.4-1.el6.x86_64.rpm

Dann installieren wir das Paket.

 # yum localinstall smf-spf-2.0.4-1.el6.x86_64.rpm

Altenativ können wir das Paket natürlich auch direkt von Djangos Repository aus installieren.

 # yum localinstall http://repository.nausch.org/public/x86_64/smf-spf-2.0.4-1.el6.x86_64.rpm

Ein Update des Paketes geht entsprechend der Installation.

 # yum localupdate http://repository.nausch.org/public/x86_64/smf-spf-2.0.4-1.el6.x86_64.rpm

Was uns das Paket alles mitbringt, zeigt uns wie immer der Aufruf von rpm -qil <paketname>

 # rpm -qil smf-spf

Name        : smf-spf                      Relocations: (not relocatable)
Version     : 2.0.4                             Vendor: django
Release     : 1.el6                         Build Date: Tue 01 Apr 2014 10:39:14 PM CEST
Install Date: Tue 01 Apr 2014 10:41:43 PM CEST      Build Host: vml010039.intra.nausch.org
Group       : System Environment/Daemons    Source RPM: smf-spf-2.0.4-1.el6.src.rpm
Size        : 50591                            License: GPLv2+
Signature   : (none)
Packager    : Django <django@nausch.org>
URL         : http://smfs.sourceforge.net/smf-spf.html
Summary     : Mail filter for Sender Policy Framework verification
Description :
smf-spf is a lightweight, fast and reliable Sendmail milter that implements the
Sender Policy Framework technology with the help of the libspf2 library. It
checks SPF records to make sure that e-mail messages are authorized by the
domain that it is coming from. It's an alternative for the spfmilter,
spf-milter, and milter-spiff milters.
/etc/mail/smfs
/etc/mail/smfs/smf-spf.conf
/etc/rc.d/init.d/smf-spf
/usr/sbin/smf-spf
/usr/share/doc/smf-spf-2.0.4
/usr/share/doc/smf-spf-2.0.4/COPYING
/usr/share/doc/smf-spf-2.0.4/ChangeLog
/usr/share/doc/smf-spf-2.0.4/README.md
/var/run/smfs
/var/run/smfs/smf-spf.sock

Die Konfiguration des smf-spf-Daemons gestaltet sich vergleichsweise einfach und erfolgt lediglich mit Hilfe Der Datei /etc/mail/smfs/smf-spf.conf. In der Default-Konfiguration wird der Daemon über einen UNIX-Datei-Socket angesprochen. Diesen Parameter Socket weisen wir einem localen Port zu, über den wir später von Postfix aus, den SPF-Milter ansprechen wollen.

Mit unserem Editor der Wahl, z.B. vim bearbeiten wir diese Konfigurationsdatei.

 # vim /etc/mail/smfs/smf-spf.conf

/etc/mail/smfs/smf-spf.conf

# /etc/mail/smfs/smf-spf.conf
#
# smf-spf configuration file v2.0.2 (it's read at start)
#
 
# Whitelist by a sender IP address
#
# The syntax is an IP address followed by a slash
# and a CIDR netmask (if the netmask is omitted, /32 is assumed)
#
WhitelistIP	127.0.0.0/8
WhitelistIP	10.0.0.0/8
# Django : 2014-02-26
# nicht benutzte (private) Netzbereiche entfernt
# WhitelistIP	172.16.0.0/12
# WhitelistIP	192.168.0.0/16
 
# Whitelist by a sender PTR record (reverse DNS record)
#
# Performs a case insensitive substring match
#
#WhitelistPTR	.friendlydomain.tld
#WhitelistPTR	friendlyhost.friendlydomain.tld
 
# Whitelist by an envelope sender e-Mail address
#
# Performs a case insensitive substring match
#
#WhitelistFrom	friend@
#WhitelistFrom	@friendlydomain.tld
#WhitelistFrom	friend@friendlydomain.tld
 
# Whitelist by an envelope recipient e-Mail address
#
# Performs a case insensitive substring match
#
#WhitelistTo	postmaster@
#WhitelistTo	@yourspamloverdomain.tld
#WhitelistTo	spamlover@yourdomain.tld
 
# Refuse e-Mail messages at SPF Fail results (RFC-4408)
#
# Default: on
#
#RefuseFail	on	# (on|off)
#RefuseFail	off
 
 
# Subject tagging of e-Mail messages at SPF SoftFail
# and Fail (if RefuseFail set to off) results
#
# Default: on
#
#TagSubject	on	# (on|off)
 
# Subject tagging string
#
# Default: [SPF:fail]
#
#Tag		[SPF:fail]
 
# Build a standard Received-SPF: header
#
# Default: on
#
#AddHeader	on	# (on|off)
 
# Quarantine of e-Mail messages at SPF SoftFail
# and Fail (if RefuseFail set to off) results
#
# Default: off
#
#Quarantine	off	# (on|off)
 
# Quarantine mailbox
#
# Default: postmaster
#
#QuarantineBox	postmaster
#QuarantineBox	spambox@yourdomain.tld
 
# In-memory cache engine TTL settings
#
# The time is given in seconds, except if a unit is given:
# m for minutes, h for hours, and d for days
# Specify zero to disable caching
#
# Default: 1h
#
#TTL		1h
 
# Run as a selected user (smf-spf must be started by root)
#
# Default: smfs
#
#User		smfs
 
# Socket used to communicate with Sendmail daemon
#
# Default: unix:/var/run/smfs/smf-spf.sock
#
#Socket		unix:/var/run/smfs/smf-spf.sock
# Django : 2014-03-25
Socket inet:10010@127.0.0.1
 
# Facility for logging via Syslog daemon
#
# Default: mail
#
#Syslog		mail	# (daemon|mail|local0...local7)

In der Konfigurationsdatei main.cf unseres Postfix-Mailserver tragen wir nun noch am Ende nachfolgende Zeilen ein.

 # vim /etc/postfix/main.cf

/etc/postfix/main.cf

...
 
# Django : 2014-03-16
# SPF-Check via SMF-SPF-Milter einbinden.
smtpd_milters = inet:127.0.0.1:10010
 
...

Nun können wir das erste mal den Daemon anstarten.

 # service smf-spf start

Starting smf-spf:                                          [  OK  ]

In der Prozessliste finden wir nun unseren Prozess smf-spf, der mit den Rechten des Users smf läuft:

 # ps auxw | grep smf-spf

smfs     28462  0.0  0.1 179240   948 ?        Ssl  14:43   0:00 smf-spf

Mittels lsof können wir nun noch überprüfen, welcher Port von Daemon verwendet wird.

 # lsof -i :10010

COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
smf-spf 28462 smfs    4u  IPv4 2597844      0t0  TCP localhost:rxapi (LISTEN)

Damit der smf-spf-Daemon automatisch bei jedem Systemstart startet, denn ohne laufenden smf-spf-daemon verweigert nun unser postfix die Annahme der Nachrichten, kann die Einrichtung des Start-Scripte über folgenden Befehle erreicht werden:

 # chkconfig smf-spf on

Die Überprüfungung ob der Dienst (Daemon) smf-spfwirklich bei jedem Systemstart automatisch mit gestartet wird, kann durch folgenden Befehle erreicht werden:

 # chkconfig --list | grep smf-spf*

smf-spf        	0:off	1:off	2:on	3:on	4:on	5:on	6:off

Wichtig sind jeweils die Schalter on bei den Runleveln - 2 3 4 5.

Anschließend starten wir unseren Postfix-Mailserver einmal durch, damit unsere zuvor eingetragene Konfigurationsänderung aktiv werden kann.

 # service postfix condrestart

Shutting down postfix:                                     [  OK  ]
Starting postfix:                                          [  OK  ]

Zum Testen schicken wir uns von einem fremden Mailserver aus, der einen gültigen SPF-Record vorweisen kann eine eMail an unseren Mailserver und beobachten unser Maillog.

 # less /var/log/maillog

Mar 26 14:27:32 vml000080 smf-spf[26416]: SPF pass: 200.46.208.138, lists.horde.org, lists.horde.org, <horde-bounces@lists.horde.org>

Damit nicht bei jeder Anfrage, der SPF-Record beim DNS abgerufen werden muss, cacht der Daemon auch entsprechend den SPF-Record. Wir sehen dann bei der Nutzung dieser gecachten Daten im maillog.

Mar 26 14:40:18 vml000080 smf-spf[26416]: SPF none (cached): 72.26.200.202, mail.centos.org, mail.centos.org, <centos-bounces@centos.org>

Natürlich wird ein Fehler beim Überprüfen des SPF-records auch im maillog vermerkt.

Dec 15 14:39:49 vml000080 smf-spf[1501]: SPF fail: ip=88.217.171.167, fqdn=mx1.tachtler.net, helo=mx1.tachtler.net, from=<newsletter@aktuell.erwinmueller.de>

Im Mailheader der empfangenen eMail findet sich dann auch die entsprechenden Einträge:

Authentication-Results: mx01.nausch.org; spf=fail smtp.mailfrom=<newsletter@aktuell.erwinmueller.de> smtp.helo=mx1.tachtler.net

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

• Weiter zum Kapitel >>SRS - Sender Rewriting Scheme unter CentOS 6<<
• Zurück zum Kapitel >>Mailserverinstallation unter CentOS 6<<
• Zurück zu >>Projekte und Themenkapitel<<
• Zurück zur Startseite