Wenn wir von „E-Mail-Authentifizierung“ sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Sicherheit bieten soll, dass die Nachricht tatsächlich von der angegebenen Quelle stammt.
Business in a box.
Entdecken Sie unsere Lösungen.
Sprechen Sie mit unserem Vertriebsteam
Wenn wir von „Email Authentication“ sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Sicherheit bieten soll, dass die Nachricht tatsächlich von der angegebenen Quelle der Nachricht stammt. Die Idee ist, ein gewisses Maß an Schutz gegen betrügerische E-Mails wie Phishing und Spoofing zu erreichen, die das Vertrauen eines Empfängers in den Empfang von E-Mails untergraben könnten. Das Versenden authentifizierter E-Mails bedeutet jedoch nicht, dass es sich um gute oder gewünschte E-Mails handelt; es bedeutet nur, dass die E-Mail so ist, dass ein Ruf für die authentifizierte Partei zuverlässig aufgebaut und in Entscheidungen über E-Mail-Akzeptanz und Platzierung verwendet werden kann.
Es gibt heute zwei Hauptformen der E-Mail-Authentifizierung—Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM). In diesem Blog-Beitrag werde ich erklären, was SPF ist und wie es funktioniert.
SPF Übersicht
Sender Policy Framework (SPF), um RFC 7208 zu paraphrasieren, ist ein Protokoll, das einer Organisation nicht nur erlaubt, Hosts und Netzwerke zu autorisieren, ihre Domainnamen beim Versenden von E-Mails zu verwenden, sondern auch eine Möglichkeit bietet, wie ein empfangender Host diese Autorisierung überprüfen kann.
Wenn Sie diesen Beitrag fertig gelesen haben, hoffe ich, dass Sie Folgendes gelernt haben:
SPF ist ein „pfadbasiertes“ Authentifizierungssystem.
SPF-Richtlinien werden in DNS TXT-Einträgen deklariert.
Die Validierung ist an die Return-Path-Domain (was wir hier bei SparkPost die „Bounce-Domain“ nennen) oder die HELO-Domain gebunden.
Die Validierung kann früh in der SMTP-Transaktion durchgeführt werden, daher ist es eine gute Überprüfung, um nicht authentifizierte Mails schnell abzulehnen.
Es ist anfällig für einen relativ hohen Prozentsatz an falschen Negativen.
“Pfadbasierte” Authentication
Deklaration einer SPF-Richtlinie
Ein SPF-Politik-Datensatz einer Domäne ist einfach ein speziell formatiertes DNS-TXT-Datensatz, das normalerweise einen oder mehrere der folgenden „Mechanismen“ enthält:
v=spf1 – Erforderliches erstes Token, um anzuzeigen, dass der TXT-Datensatz ein SPF-Datensatz ist (eine Domäne kann mehrere TXT-Datensätze haben)
ipv4, ipv6 – Wird verwendet, um IP-Adressen und Netzwerke anzugeben, die berechtigt sind, E-Mails für die Domäne zu senden
a – Wenn die sendende Domäne einen DNS-„A“-Datensatz hat, der zur sendenden IP führt, ist die IP berechtigt
mx – Wenn die sendende IP auch einer der MX-Datensätze der sendenden Domäne ist, ist die IP berechtigt
all – Erforderliches letztes Token, immer modifiziert:
-all – Nur das Aufgelistete kann passieren; Fehler ablehnen.
~all – Dinge, die nicht hier sind, sollten softfail sein; akzeptiere es, aber vermerke es.
?all – Nicht sicher, ob Dinge, die nicht hier sind, passieren sollten.
+all – Wir denken, dass SPF nutzlos ist; alles zulassen.
Andere weniger häufige, aber noch immer weit verbreitete Mechanismen sind:
include – Wird verwendet, wenn eine Domäne nicht nur ihre eigenen Server hat, sondern auch die Server eines anderen verwendet. Muss sorgfältig eingesetzt werden. Jedes include ist eine weitere DNS-Abfrage, und SPF-Datensätze dürfen nicht mehr als zehn DNS-Abfragen zur Auflösung erfordern.
redirect – Wenn Domäne A und Domäne B vom selben Unternehmen betrieben werden und dieselbe Infrastruktur verwenden. Die Besitzer möchten normalerweise nur eine Kopie des SPF-Datensatzes für beide beibehalten und B so konfigurieren, dass Anfragen zu A umgeleitet werden.
exists – Wenn eine Domäne viele kleine, nicht zusammenhängende Netzblöcke hat, kann sie diesen Mechanismus verwenden, um ihren SPF-Datensatz anzugeben, anstatt sie alle aufzulisten. Nützlich, um innerhalb der Größenbeschränkung (512 Bytes) für die DNS-Antwort zu bleiben.
Eine Anmerkung zum „ptr“-Mechanismus
Ein letzter Mechanismus, „ptr“, existierte in der ursprünglichen Spezifikation für SPF, wurde jedoch in der aktuellen Spezifikation als „nicht verwenden“ deklariert. Der ptr-Mechanismus wurde verwendet, um anzugeben, dass, wenn die sendende IP-Adresse einen DNS-PTR-Datensatz hat, der auf den fraglichen Domänennamen verweist, dann diese IP-Adresse berechtigt war, E-Mails für die Domäne zu senden.
Der aktuelle Status dieses Mechanismus ist, dass er nicht verwendet werden sollte. Dennoch müssen Seiten, die SPF-Validierung durchführen, ihn als gültig akzeptieren.
Einige Beispiel SPF Records
Hier sind einige Beispielaufzeichnungen und deren Bedeutungen. Dieses Beispiel zeigt RFC 1918-Adressen, aber ich erkenne, dass solche Adressen niemals in echten SPF-Einträgen erscheinen werden.
MX-Eintrag, eine IP-Adresse, ein IP-Netzwerk, Softfail für alles andere:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A-Eintrag, zwei IP-Netzwerke, alles andere ablehnen:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Wir senden keine E-Mails:
“v=spf1 -all”
Wir halten SPF für dumm:
“v=spf1 +all”
Der SPF-Eintrag für die Domain sparkpostmail.com (Redirect-Mechanismus verwendet)
“v=spf1 redirect=_spf.sparkpostmail.com”
Der SPF-Eintrag für _spf.sparkpostmail.com (exists- und ptr-Mechanismen verwendet):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Bei SparkPost verwenden wir derzeit den ptr-Mechanismus in unserem SPF-Eintrag. Wir haben festgestellt, dass dies aufgrund fehlender universeller Unterstützung zur Validierung des exists-Mechanismus erforderlich ist. Und bisher haben wir keine SPF-Fehler festgestellt, die durch die Verwendung des ptr-Mechanismus entstehen.
Wie funktioniert SPF Authentication?
So sieht ein typischer SMTP-Transaktion aus, wenn SPF im Spiel ist:
Der sendende Server (Client) verbindet sich mit dem empfangenden Server
Der empfangende Server notiert die IP-Adresse des verbindenden Clients
Sie tauschen Begrüßungen aus, einschließlich des HELO-Hostnamens des Clients
Der Client gibt den SMTP MAIL FROM-Befehl aus
Der empfangende Server kann nun den SPF-Eintrag entweder für die MAIL FROM-Domain oder den HELO-Hostnamen abfragen, um festzustellen, ob die verbindende IP berechtigt ist, E-Mails für die Domain zu senden, und entscheiden, ob die Nachricht akzeptiert wird oder nicht.
MAIL FROM oder HELO – Welches sollte geprüft werden?
Die SPF-Spezifikation legt fest, dass empfangende Sites SPF für die MAIL FROM-Domain überprüfen MÜSSEN und EMPFIEHLEN, sie für den HELO-Hostname zu überprüfen. In der Praxis erfolgt die Überprüfung nur auf der MAIL FROM-Domain, außer vielleicht in den Fällen, in denen die MAIL FROM-Adresse der NULL-Absender (d.h. „<>“) ist, in welchem Fall der HELO-Hostname die einzige verfügbare Identität ist.
SPF ist nicht narrensicher
Obwohl es ein relativ unkomplizierter Weg zu sein scheint, E-Mails zu authentifizieren, ist SPF anfällig für Ausfälle in Form von Fehlalarmen. Diese Ausfälle können häufiger auftreten, als es vielen recht ist.
Hier sind zwei gängige Szenarien, in denen vollkommen legitime E-Mails die SPF-Validierung nicht bestehen und daher als betrügerisch erscheinen können:
Automatisches Weiterleiten, bei dem eine Nachricht, die an jsmith@alumni.university.edu gesendet wurde, an ein Postfach weitergeleitet wird, das so eingestellt ist, dass alle E-Mails automatisch an jsmith@isp.com weitergeleitet werden
Mailinglisten, bei denen E-Mails, die an talk-about-stuff@listserv.foo.com gesendet werden, „explodiert“ und an jeden Abonnenten gesendet werden
In beiden Fällen, wenn der Return-Path unverändert von seinem Original bleibt, könnten die E-Mails die SPF-Prüfung nicht bestehen (abhängig von dem Modifikator, der mit dem ‚all‘-Mechanismus verwendet wird). Dies liegt daran, dass sie von einem Zwischenserver an ihr endgültiges Ziel gelangen, nicht von dem ursprünglichen, und dieser Zwischenserver wahrscheinlich nicht im SPF-Eintrag der Domäne enthalten ist. Eine Technik namens „Sender Rewriting Scheme“ oder „SRS“ kann dieses Risiko mindern, und einige größere Seiten haben es eingeführt, aber es ist nicht universell.
Abschluss
Das ist also die SPF-Authentifizierung, wie sie funktioniert, wie man eine SPF-Richtlinie erklärt und welche Fallstricke es bei der Verwendung von SPF gibt. SPF war das erste E-Mail-Authentifizierungsschema, das weit verbreitet angenommen wurde, aber es ist nicht das einzige, das es gibt. Die SPF-Authentifizierung ist am effektivsten, wenn sie in Kombination mit anderen Anti-Betrugs-Techniken eingesetzt wird.
