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. 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:
- Blocken von Mails anhand der vorhandenen SPF-Records. Der Check wird nur für Ihre eigenen Domains durchgeführt, nicht für fremde.
- 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:
| Hit | Score | Bedeutung |
|---|---|---|
| SPF_NONE | 0.01 | Die Domain veröffentlicht keinen SPF-Record. |
| SPF_PASS | -0.01 | Die Mail stammt aus einer der angegebenen Quellen und ist damit vertrauenswürdig. |
| SPF_FAIL | 0.5 | Die Mail stammt nicht aus einer der angegebenen Quellen und die Domain setzt -all. Die Quelle wird als nicht vertrauenswürdig eingestuft. |
| SPF_SOFTFAIL | 0.01 | Die Mail stammt nicht aus einer der angegebenen Quellen und die Domain setzt ~all. Der Vertrauensstatus der Quelle ist unbekannt. |
| SPF_NEUTRAL | 0.01 | 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. Dies passiert dann, wenn die Absenderadresse leer ist, also bei Bounces, DSNs usw.
| Hit | Score | Bedeutung |
|---|---|---|
| SPF_HELO_NONE | 0.01 | Die Domain veröffentlicht keinen SPF-Record. |
| SPF_HELO_PASS | -0.01 | Die Mail stammt aus einer der angegebenen Quellen und ist damit vertrauenswürdig. |
| SPF_HELO_FAIL | 0.2 | Die Mail stammt nicht aus einer der angegebenen Quellen und die Domain setzt -all. Die Quelle wird als nicht vertrauenswürdig eingestuft. |
| SPF_HELO_SOFTFAIL | 0.01 | Die Mail stammt nicht aus einer der angegebenen Quellen und die Domain setzt ~all. Der Vertrauensstatus der Quelle ist unbekannt. |
| SPF_HELO_NEUTRAL | 0.01 | Die Domains hat ?all gesetzt. Die Mails sollen so behandelt werden, als ob kein SPF-Record existieren würde. |
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 Nutzung von SPF-DNS-Records
Da SPF-Records mit -all 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.