Inhaltsverzeichnis

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 7208 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-Grusskarte ü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 MTA3) das SPF zum Tragen kommt. Sobald eine eMail von einem Mailserver empfangen wird, benutzt dieses das SPF um festzustellen, ob das sendende System (MTA) dazu berechtigt ist. Besteht der Absender die SPF-Prüfung nicht, wird die Annahme der Nachricht je nach Konfiguration abgelehnt, zugestellt und|oder ggf. als Spam bzw. Betrug gekennzeichnet.

Mailversand einer eMailMailversand einer eMail  Mail-Server mx01.nausch.org217.91.103.190  Mail-Server mx01.nausch.org217.91.103.190  Mail-Server mx1.tachtler.net88.217.171.167  Mail-Server mx1.tachtler.net88.217.171.167  DNS-Server von nausch.org  DNS-Server von nausch.org connect von mx01.nausch.org zu mx1.tachtler.net Verbindungsaufbauvom Quell- zumZielserver . 220 mx1.tachtler.net ESMTP PostfixHELO mx01.nausch.org. 250 mx1.tachtler.netMAIL FROM:<django@nausch.org>host -t TXT nausch.org Abfrage derSPF-Records nausch.org descriptive text "v=spf1 ip4:217.91.103.190/32 mx ?all" Der Mailserver mit derIP 217.91.103.190 ist berechtigteMails der Mail-Domainnausch.org zu versenden . 250 2.1.0 OkRCPT TO:<klaus@tachtler.net>. 250 2.1.0 OkÜbermittlung der Nachricht250 2.0.0 Ok: queued as 5950581 Beenden der Verbindung 

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

Definition unseres SPF-Records

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.

Format der SPF-Richtlinie

Ein SPF-Record beinhaltet mehrere durch Leerzeichen getrennte Angaben, die jeweils der Reihe nach von links nach rechts ausgewertet werden. Eine solche Angabe kann ein Modifikator wie z.B. v oder redirect, ein Typ wie a bzw. mx oder auch eine Include-Anweisung 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.

Jede SPF-Definition im Zonenfile unseres DNS beginnt mit der sogenannten Versions-Section und wird auf die derzeit aktuelle SPF-Version v=spf1 gesetzt.

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:

Mechanismus

Der Mechanismus bestimmt, wie eine IP-Adresse mit dem Begriff abgeglichen werden soll. Unterstützte Werte sind hier:

Modifikator

Modifikatoren sind Name/Wert-Paare, mit denen zusätzliche Informationen im SPF-Record geliefert werden können. Die Modifikatoren sollen nach allen Mechanismen am Ende eines Datensatzes erscheinen, obwohl diese syntaktisch theoretisch an jeder beliebigen Stelle des Datensatzes stehen können.

Beispiele

einfach "mx"-Definition

Im ersten Konfigurationsbeispiel, welches vermutlich einen Großteil von vielen MTA abdecken 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 empfangendes System soll auf jeden Fall die Nachricht annehmen, 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, sofern die max. Anzahl von 10 DNS-Abfragen überschritten werden wird. Wie wir damit besser umgehen und diese Herausforderung meistern können, betrachten wir im Abschnitt DNS Lookup Limitierung 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 ip4:24.134.171.249/32 ip6:2001:678:e68:102:566e:2177:15b3:57fe/128 ~all"

Zu beachten ist hier natürlich, dass die maximale Länge von 255 Zeichen eines TXT-Records keinenfalls überschritten werden darf!

Hat man viele versendende Systeme und/oder viele IPv6-Adressen, wird man sehr schnell an diese Grenze stossen. Hier greifen wir nun auf den Mechanismus include zurück. 

nausch.org                      IN      TXT     "v=spf1 mx a:cloud.nausch.org  include:_spf.blk1.nausch.org include:_spf.blk2.nausch.org include:_spf.blk3.nausch.org ~all"

_spf.blk1.nausch.org    3600    IN      TXT     "v=spf1 ip6:2001:678:e68:102:1ae8:29ff:fec6:c8dd/128 ip6:2001:678:ed0:102:1ae8:29ff:fec6:c8dd/128 ip6:2001:678:e68:102:dea6:32ff:fe22:f0f2/128 ip6:2001:678:ed0:102:dea6:32ff:fe22:f0f2/128"
_spf.blk2.nausch.org    3600    IN      TXT     "v=spf1 ip6:2001:678:e68:102:1ae8:29ff:fea9:22ed/128 ip6:2001:678:ed0:102:1ae8:29ff:fea9:22ed/128 ip6:2001:678:e68:102:1ae8:29ff:fec6:c8eb/128 ip6:2001:678:ed0:102:1ae8:29ff:fec6:c8eb/128"
_spf.blk3.nausch.org    3600    IN      TXT     "v=spf1 ip4:81.169.212.137/32 ip4:24.134.171.249/32"

Wichtig ist hierbei, dass bei Nutzung des Mechanismus mx dieser im führenden SPF-Record aufgeführt wird und nicht in einem der inkludierten zusätzlichen ergänzenden Records! Weiterhin ist zu beachten, dass pro MX-Eintrag im DNS dann zusätzliche DNS-Anfragen nach sich ziehen, siehe Abschnitt DNS Lookup Limitierung.

zusätzliche Hinweise

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"

DNS Lookup Limitierung

Abhängig von den verwendeten Mechanismen oder auch Modifikatoren müssen in aller Regel zur Evaluierung der Bewertung der IP-Adresee des einliefernden SMTP-Clients weitere DNS-Anfragen durchgeführt werden. Im RFC 7208 finden sich ausführliche Hinweise zu den Limitierungen beim DNS-Lookup im Bezug auf unsere SPF-Definitionen.

Haben wir wie in diesem Beispiel den Mechanismus a verwendet, muss bei einer Prüfung der verwendete Daemon nicht nur einen TXT-Record im DNS erfragen, sondern zusätzlich noch eine A- (oder AAAA-) DNS-Abfrage für die Domäne durchführen. Beim Mechanismus mx können das, ja nach Anzahl der im MX-Record hinterlegten MX-Einträge dann einen oder auch mehrere zusätzliche A- (oder AAAA-) DNS-Abfrage nach sich ziehen. Im Falle z.B. von mailbox.org mit den hinterlegten 4 Mailservern wären das dann vier zusätzliche DNS-Anfragen.

Doch wie viele DNS-Anfragen werden nun im Zweifelsfall zusätzlich benötigt? Eine Antwort auf diese Frage bietet nachfolgende Tabelle.

Mechanismus lookups Modifikator lookups
a 1 v 0
all 0 exp 0
exists 1 redirect 1
include ≥ 1
ip4 0
ip6 0
include ≥ 1
mx ≥ 1
ptr ≥ 1

Sehen wir uns nun den SPF-Record lists.nausch.org genauer an und gehen detailliert auf die einzelnen Werte ein. 

 $ dig TXT lists.nausch.org +short
v=spf1 mx include:_spf.blk1.nausch.org include:_spf.blk2.nausch.org -all exp=explain._spf.%{d}
 $ dig TXT _spf.blk1.nausch.org +short
"v=spf1 ip6:2001:678:e68:102:1ae8:29ff:fec6:c8dd/128 ip6:2001:678:ed0:102:1ae8:29ff:fec6:c8dd/128 ip6:2001:678:e68:102:dea6:32ff:fe22:f0f2/128 ip6:2001:678:ed0:102:dea6:32ff:fe22:f0f2/128"
 $ dig TXT _spf.blk2.nausch.org +short
"v=spf1 ip6:2001:678:e68:102:1ae8:29ff:fea9:22ed/128 ip6:2001:678:ed0:102:1ae8:29ff:fea9:22ed/128 ip6:2001:678:e68:102:1ae8:29ff:fec6:c8eb/128 ip6:2001:678:ed0:102:1ae8:29ff:fec6:c8eb/128"
 $ dig TXT explain._spf.nausch.org +short
"Emails from lists.nausch.org may only be sent from your own authorized mail servers. Further instructions and explanations can be found here: https://dokuwiki.nausch.org/doku.php/centos:mail_c7:spam_10"

Zur vollständigen Bewertung eines anliefernden SMTP-Clients (IP-Adresse) sind also noch weitere DNS-Anfragen notwendig…

  1. einen MX-Lookup je Host im MX-Record einen Lookup (in unserem Fall 1 für den Host mx1.nausch.org)
  2. zwei TXT-Lookups für die inkludierten Blöcke _spf.blk1 und _spf.blk2

… in Summe also drei DNS-Anfagen. Hätte der MX-Record hingegen vier eingetragene Mailserver, wären dies schon in Summe sechs DNS-Anfragen!

Aus diesem Grund ist es ratsam, statt dem mx-Mechanismus die betreffenden Mailserver einzeln in einem include-Abschnitt aufzuführen! Natürlich müssen bei Änderungen am MX-Record dann zusätzlich auch die IP-Adressen im include Abschnitt gepflegt werden, so dass in einem SPF-Record nur aktuell verwendete Systeme gelistet werden sollen, versteht sich von selbst und sollte so erst gar nicht einer Erwähnung benötigen.

Der SPF-Standard RFC7208 schreibt vor, dass eine SPF-Richtlinie nicht mehr als 10 zusätzliche DNS-Lookups zur vollständigen Auswertung benötigen darf. Wenn ein Empfänger mehr als 10 Suchvorgänge durchführen muss, um die SPF-Richtlinie zu bewerten, schlägt beim Zustellversuch der eMail-Nachricht die SPF-Validierung mit einem Permerror-Status fehl, was die Zustellung der E-Mail-Nachricht verhindern kann.

Testing-Tools

Zum Testen auf Validität unseres SPF-Records stehen uns im WEB unter anderem folgende Dienste (SPF Record Testing Tools) zur Verfügung. Die Ergebnisse können helfen auf Mängel in den Records hinzuweisen, so dass wir zur besseren Reputation bei der Mailannahmen bei den Empfängern doch auch entscheidend Einfluss nehmen können.

SPF-Bewertung bei der Mailannahme

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


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 nausch.org aus.

Installation

Die einfachste und schnellste Variante bei der Installation ist die aus dem Repository nausch.org. Hier reicht ein einfacher Aufruf von yum und alles wird automatisch installiert inkl. der Paketabhängigkeiten. 

 # yum install smf-spf

Will oder kann man nicht auf das Repository nausch.org zurückgreifen, steht immer noch der Installation per Hand nichts im Wege. 

 # yum localinstall http://repo7.nausch.org/7/x86_64/libspf2-1.2.10-1.el7.centos.x86_64.rpm \ 
                    http://repo7.nausch.org/7/x86_64/smf-spf-2.0.4-1.el7.centos.x86_64.rpm

Was das RPM alle mitbrachte zeigt ein Blick in die RPM-Datenbank. 

 # rpm -qil smf-spf
Name        : smf-spf
Version     : 2.0.4
Release     : 1.el7.centos
Architecture: x86_64
Install Date: Wed 17 Dec 2014 02:01:33 PM CET
Group       : System Environment/Daemons
Size        : 26876
License     : GPLv2+
Signature   : RSA/SHA1, Wed 17 Dec 2014 02:00:24 PM CET, Key ID 60ecfb9e8195aea0
Source RPM  : smf-spf-2.0.4-1.el7.centos.src.rpm
Build Date  : Wed 17 Dec 2014 02:00:16 PM CET
Build Host  : vml000200.dmz.nausch.org
Relocations : (not relocatable)
Packager    : Django <django@nausch.org>
Vendor      : django
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
/run/smfs
/run/smfs/smf-spf.sock
/usr/lib/systemd/system/smf-spf.service
/usr/lib/tmpfiles.d/smfs.conf
/usr/sbin/smf-spf

Konfiguration

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 lokalen 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-12-17
# 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-12-17
Socket inet:8890@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 definieren wir uns nun eine eigene Variable, die wir dann in der Datei /etc/postfix/master.cf dann verwenden wollen. Wir tragen also nun in der Section MILTER nachfolgende Zeilen ein. 

 # vim /etc/postfix/main.cf
/etc/postfix/main.cf
...
 
################################################################################
## MILTER
# Django : 2014-11-18
# DMARC Test
spf_milter       = inet:127.0.0.1:8890
#opendkim_milter  = inet:127.0.0.1:8891
#opendmarc_milter = inet:127.0.0.1:8892
amavisd_milter   = inet:10.0.0.67:8899
...

In der Konfigurationsdatei /etc/postfix/master.cf legen wir nun fest, dass bei der Annahme auf Port 25 unser gerade definierte smf-spf-milter verwendet werden soll. 

 # vim /etc/postfix/master.cf
...

smtp      inet  n       -       n       -       1       postscreen
smtpd     pass  -       -       n       -       -       smtpd
  -o smtpd_sasl_auth_enable=no
  -o smtpd_milters=${spf_milter},${amavisd_milter}
dnsblog   unix  -       -       n       -       0       dnsblog
tlsproxy  unix  -       -       n       -       0       tlspr

Programmstart

Das Starten des Daemon erfolgt über folgenden Aufruf. 

 # systemctl start smf-spf

Den erfolgreichen Start bzw. den Status des smf-spf-Daemon können wir bei Bedarf mit folgendem Aufruf abfragen. 

 # systemctl status smf-spf

● smf-spf.service - Sender Policy Framework milter
   Loaded: loaded (/usr/lib/systemd/system/smf-spf.service; disabled)
   Active: active (running)since Wed 2014-12-17 14:05:12 CET; 40min ago
  Process: 19140 ExecStart=/usr/sbin/smf-spf (code=exited, status=0/SUCCESS)
 Main PID: 19141 (smf-spf)
   CGroup: /system.slice/smf-spf.service
           └─19141 /usr/sbin/smf-spf

Dec 17 14:05:12 vml000087.dmz.nausch.org systemd[1]: Started Sender Policy Framework milter

Im Maillog wird der Start des Daemon entsprechend dokumentiert. 

 # less /var/log/maillog
 Dec 17 14:05:12 vml000087 smf-spf[19140]: starting smf-spf 2.0.2 listening on inet:8890@127.0.0.1
 Dec 17 14:05:12 vml000087 smf-spf[19140]: running as uid: 993, gid: 99

Mit Hilfe von netstat können wir überprüfen, ob der Port 8890 geöffnet wurde. 

 # netstat -tulpen
#Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      0          114172     19358/master        
tcp        0      0 127.0.0.1:8890          0.0.0.0:*               LISTEN      993        112487     19141/smf-spf

Gleiches können wir natürlich auch mit dem Befehl lsof erreichen. 

 # lsof -i:8890
 COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
 smf-spf 19141 smfs    4u  IPv4 112487      0t0  TCP localhost:rxapi (LISTEN)

Damit der Daemon automatisch beim Hochfahren des Servers gestartet wird, nutzen wir folgenden Aufruf. 

 # systemctl enable smf-spf.service
 ln -s '/usr/lib/systemd/system/smf-spf.service' '/etc/systemd/system/multi-user.target.wants/smf-spf.service'

Wollen wir überprüfen ob der Dienst automatisch startet, verwenden wir folgenden Aufruf. 

 # systemctl is-enabled smf-spf.service
 enabled

Die Rückmeldung enabled zeigt an, dass der Dienst automatisch startet; ein disabled zeigt entsprechend an, dass der Dienst nicht automatisch startet.

Tests und Logging

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

Zum Testen des SPF-Records kann man auch auf Dienste im WWW zurückgreifen.

SRS - Sender Rewriting Scheme

Zu Beginn dieses Artikels wurde bereits darauf hingewiesen, dass mit unter Probleme bei Mailumleitungen und/oder Web-Formularen 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.

Links

1)
Sender Policy Frameworks
2) , 3)
Mail Transport Agent
4)
Sender Rewriting Scheme