SPF - Sender Policy Framework

SPF ist ein Versuch, die Verwendung der eigenen Domains als Absender-Adresse zu kontrollieren. Hierzu trägt man für die Domains im DNS TXT-Records im SPF-Format ein. Diese enthalten eine Liste der Hosts, IP-Adressen oder IP-Netze, die Mails mit dieser Domain in der Absender-Adresse verschicken dürfen. Näheres siehe https://en.wikipedia.org/wiki/Sender_Policy_Framework . Einschränkend wirkt, dass SPF nur auf die Absender-Adresse im Envelope angewendet wird, nicht dagegen auf den Inhalt der From:-Header-Zeile.

Pro:

  • Mails mit der eigenen Domain im Envelope-From von nicht-autorisierten Hosts können abgelehnt werden. Dies sind:
  • Phishing-Mails, die über Provider versendet werden, die die Verwendung von fremden Absender-Adressen nicht unterbinden. Alle großen Provider lassen dies nicht mehr zu, nur kleinere Provider/Einrichtungen mit unzureichender Mailserver-Konfiguration achten noch nicht darauf.
  • Bounces auf Spam-Mails, die von beliebigen Quellen aber mit der eigenen Domain im Absender an Dritte gesendet werden, deren Mailserver diese Mails zuerst annehmen aber dann in einem späteren Schritt zurückschicken (bouncen). Diese Bounces waren der Hauptgrund für die großen Mailprovider, SPF zu entwickeln und einzusetzen.

Kontra:

  • Moderne Phishing-Mails fälschen heutzutage nur noch den Header-From:, da der Empfänger nur diesen von seinem Mailclienten angezeigt bekommt. Der Envelope-From ist hierbei egal.
  • Einfache Weiterleitungen von Mails (Forwards,Bounces) werden größtenteils unterbunden, da Mails nur noch direkt von den Einrichtungs-Mailservern angenommen werden, nicht mehr von Zwischen-Hops (Freemailer, einfache Mailverteiler). Aus diesem Grund werden E-Mails wegen SPF-Checks fast nirgends sofort abgelehnt, da fast alle großen Provider auf Druck ihrer Nutzer Forwards erlauben müssen. Die SPF-Checks werden eher für Reputationszwecke benutzt und gehen abgeschwächt in die Spam-Bewertung ein.
  • Mailinglisten funktionieren nur noch, wenn Sie den Original-Absender ersetzen oder umschreiben, z.B. mit SRS. Damit haben einige Mailinglisten noch Probleme.

Wenn Sie SPF in Ihrer Einrichtung einführen wollen, so benötigen Sie folgende Regeln in Ihrer Mail-Policy:

  • Mails dürfen nur über die Einrichtungs-Mailserver versendet werden, nicht über Server von anderen Providern. Dies betrifft vor allem Nutzer, die remote bzw. im Homeoffice arbeiten. Ein VPN-Zugang bzw. ein weltweit erreichbarer Mailserver ist hierzu notwendig.
  • Weiterleitungen von dienstlichen Mails auf private Konten bei dritten Providern sind nicht gestattet (bzw. SPF bei diesen Providern unterbindet dies).

Wenn Sie sich für den Einsatz von SPF entscheiden, so können wir folgende Szenarien anbieten:

  1. Blocken von Mails anhand der vorhandenen SPF-Records. Der Check wird nur für Ihre eigenen Domains durchgeführt, nicht für fremde.
  2. Dasselbe, wobei anstelle nicht vorhandener SPF-Records eine von Hand gepflegten Liste der Mailserver direkt in der postfix-Konfiguration gehalten wird.

Durch die fehlenden SPF-Records im zweiten Fall vermeiden Sie SPF-bedingte Rejects durch dritte Provider, d.h. der größte Teil der Weiterleitungen wird weiterhin funktionieren.

DNS-Konfiguration:

 Setzen Sie SPF-Records für Ihre Domains, so müssen Sie eines der folgenden Partikel in die SPF-Records aufnehmen:

include:_spf.oXXX.mx.srv.dfn.de Alle Services ihrer Einrichtung
include:_spf.sXXXY.mx.srv.dfn.de Ein bestimmter Service
mx Wenn wir nur eingehend für Sie filtern und ihre MX-Records auf den eingehenden Service zeigen.

XXX ersetzen Sie durch ihre dreistellige Einrichtungsnummer und Y durch die laufende Nummer des Services. Ein weicher SPF-Record, der Weiterleitungen nicht unterbinden sollte, würde dann zum Beispiel so aussehen:

example.org TXT "v=spf1 include:_spf.o100.mx.srv.dfn.de ~all"

Und ein harter SPF-Record, der Weiterleitungen unterbindet, so:

example.org TXT "v=spf1 include:_spf.o100.mx.srv.dfn.de -all"

Beachten Sie noch bitte die DNS-Lookup-Limits bei der Verarbeitung des SPF-Records: Es dürfen in der Summe maximal  10 Partikel der Typen: mx, a, ptr, include, exists, redirect auftauchen, die Anzahl der Partikel all, ip4, ip6, exp ist dagegen nicht begrenzt.

Validierung von DNS-SPF-Records

Sie können ihre SPF-Records durch diverse Validatoren überprüfen lassen, hier eine Auswahl:

 

Checks und Markierung innerhalb des MailSupports

Der Spamassassin führt bei jeder Mail SPF-Checks sowohl auf die Domain der Absenderadresse als auch auf die Domain in der HELO-Angabe des SMTP-Protokolls durch. Das Ergebnis landet im X-Spam-Status:-Header in Form von Hits, deren Namen mit dem Prefix SPF_ beginnen.  Die wichtigsten sind:

  • SPF_NONE Die Domain veröffentlicht keinen SPF-Record.
  • SPF_PASS Die Mail stammt aus einer der angegebenen Quellen und ist damit vertrauenswürdig.
  • SPF_FAIL Die Mail stammt nicht aus einer der angegebenen Quellen und die Domain setzt -all. Die Quelle wird als nicht vertrauenswürdig eingestuft.
  • SPF_SOFTFAIL Die Mail stammt nicht aus einer der angegebenen Quellen und die Domain setzt ~all. Der Vertrauensstatus der Quelle ist unbekannt.
  • SPF_NEUTRAL Die Domains hat ?all gesetzt. Die Mails sollen so behandelt werden, als ob kein SPF-Record existieren würde.

Diese Checks gibt es noch in der Variante mit //SPF_HELO_//-Prefix anstelle des //SPF-//. Hierbei wird anstelle der Domain aus der Absenderadresse der Name aus dem HELO/EHLO-SMTP-Kommando für den Check herangezogen.

Zusätzliche optionale Konfigurationen

1. harter SPF-Check auf beliebige Domains

a. postfix: Sämtliche eingehenden Mails werden dem SPF-Check unterworfen. Mails, deren Domains -all konfiguriert haben, und die aus nicht aufgeführten Quellen stammen, werden abgelehnt. Verwendet wird die Komponente postfix-policyd-spf-perl.

b. spamassassin:Die Scores für die SPF_*-Hits können individuell angepasst werden. Je nach erreichtem Gesamtscore und der individuellen Spam-Konfiguration werden diese Mails als Spam abgelehnt oder markiert und weitergeleitet.

2. SPF-Check nur auf die eigenen Domains

Sie setzen für ihre Domains SPF-DNS-Records auf, die wir auswerten. Die Auswertung geschieht über die Komponente postfix-policyd-spf-perl. Bei der Verwendung von -all werden Mails von nicht aufgeführten Quellen abgelehnt. Die Liste der Domains, für die dieser Check durchgeführt werden soll, muss über unsere Hotline konfiguriert werden.

3. SPF-analoger Check nur auf die eigenen Domains ohne SPF-DNS-Records

a. Envelope-From: Da SPF-Records unangenehme Folgen nach sich ziehen, wie z.B. unterbundene Weiterleitungen, bieten wir eine Alternative an. Bei dieser wird statt des SPF-DNS-Records eine Liste der erlaubten Mailquellen in der whitelist_sender_client_cidr geführt, die über das Portal selbst gepflegt werden kann. Wie unter Punkt 2 muss allerdings die Liste der Domains, für die dieser Check durchgeführt werden soll, über unsere Hotline konfiguriert werden.

b. Header-From: SPF ist nur für den Envelope-From definiert, den der Empfänger in seinem Mailclient in der Regel nicht sieht. Daher bieten wir einen weiteren Check an, bei dem die Verwendung der eigenen Domains im Header-From kontrolliert werden kann. Hierbei wird die Mail abgelehnt, wenn eine der eigenen Domains im From:-Header verwendet wird. Ein Whitelisting kann hierbei über die amavis_whitelist_spam_*-Listen erfolgen.