Wenn wir von "E-Mail-Authentifizierung" sprechen, beziehen wir uns auf eine Technik, die dazu gedacht ist, dem Empfänger einer Nachricht ein gewisses Maß an Sicherheit zu geben, dass die Nachricht tatsächlich von der angegebenen Quelle stammt. Die Idee ist, ein gewisses Maß an Abwehr gegen betrügerische E-Mails, wie Phishing und Spoofing, zu erreichen, die das Vertrauen eines Empfängers in den Erhalt von E-Mails untergraben könnten. Das heißt, der Versand authentifizierter E-Mails behauptet nicht von sich aus, dass die E-Mail gut oder gewollt ist; es bedeutet nur, dass die E-Mail so ist, dass ein Ruf für die authentifizierte Partei zuverlässig etabliert und bei Entscheidungen über den E-Mail-Empfang und die Zustellung verwendet werden kann.
Es gibt zwei Hauptformen der E-Mail-Authentifizierung, die heute verwendet werden—Sender Policy Framework (SPF) und DomainKeys Identifed Mail (DKIM). In diesem Blogbeitrag erkläre ich, 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 einen Weg bietet, wie ein empfangender Host diese Autorisierung überprüfen kann.
Wenn Sie diesen Beitrag 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 erfolgt über die Return-Path-Domain (was wir hier bei SparkPost als „Bounce-Domain“ bezeichnen) oder die HELO-Domain.
Die Validierung kann früh im SMTP-Transaktionsprozess erfolgen, daher ist es eine gute Prüfung, um schnell nicht authentifizierte E-Mails abzulehnen.
Es ist anfällig für einen relativ hohen Prozentsatz an falschen Negativen.
„Pfadbasierte“ Authentifizierung
SPF wird als pfadbasiertes Authentifizierungssystem angesehen, weil es ausschließlich an den Weg gebunden ist, den die Nachricht von ihrem Ursprung zu ihrem Ziel genommen hat. Wenn ein sendender Server eine SMTP-Transaktion mit einem empfangenden Server initiiert, wird der empfangende Server feststellen, ob der sendende Server autorisiert ist, diese Nachricht basierend auf der SPF-Policy der Domain zu senden. Es ist ausschließlich eine Entscheidung, die darauf basiert, woher die Nachricht kommt, ohne irgendetwas mit dem Inhalt der Nachricht zu tun zu haben.
Eine SPF-Policy deklarieren
Der SPF-Policyeintrag einer Domain ist einfach ein speziell formatierter DNS TXT-Eintrag, der üblicherweise einen oder mehrere der folgenden „Mechanismen“ enthält:
v=spf1 – Erforderliches erstes Token, um anzuzeigen, dass der TXT-Eintrag ein SPF-Eintrag ist (eine Domain kann mehrere TXT-Einträge haben)
ipv4, ipv6 – Wird verwendet, um IP-Adressen und Netzwerke anzugeben, die berechtigt sind, E-Mails für die Domain zu senden
a – Wenn die sendende Domain einen DNS „A“-Eintrag hat, der auf die sendende IP auflöst, ist die IP berechtigt
mx – Wenn die sendende IP auch einer der MX-Einträge für die sendende Domain ist, ist die IP berechtigt
all – Erforderliches letztes Token, immer modifiziert:
-all – Nur was hier aufgeführt ist, kann bestehen; ablehnen bei Fehlschlägen.
~all – Dinge, die nicht hier stehen, sollten softfail; akzeptiere es, aber notiere es.
?all – Nicht sicher, ob Dinge, die nicht hier sind, bestehen sollten.
+all – Wir denken, SPF ist nutzlos; alles bestehen lassen.
Andere weniger gebräuchliche Mechanismen, die jedoch immer noch weit verbreitet sind:
include – Wird verwendet, wenn eine Domain nicht nur ihre eigenen Server hat, sondern auch die Server eines anderen verwendet. Muss mit Bedacht eingesetzt werden. Jede include ist eine weitere DNS-Abfrage, und SPF-Einträge können nicht mehr als zehn DNS-Abfragen zur Auflösung erfordern.
redirect – Wenn Domain A und Domain B derselben Entität gehören und dieselbe Infrastruktur verwenden. Die Eigentümer möchten in der Regel nur eine Kopie des SPF-Eintrags für beide beibehalten und konfigurieren B, um Abfragen an A umzuleiten.
exists – Wenn eine Domain viele kleine, nicht zusammenhängende Netzwerkblöcke hat, kann sie diesen Mechanismus verwenden, um ihren SPF-Eintrag anzugeben, anstatt sie alle aufzulisten. Nützlich, um innerhalb des Größenlimits (512 Bytes) für die DNS-Antwort zu bleiben.
Eine Anmerkung zum Mechanismus „ptr“
Ein letzter Mechanismus, „ptr“, existierte in der ursprünglichen Spezifikation für SPF, wurde aber in der aktuellen Spezifikation als „nicht verwenden“ deklariert. Der ptr-Mechanismus wurde verwendet, um zu erklären, dass, wenn die sendende IP-Adresse einen DNS PTR-Eintrag hatte, der auf den betreffenden Domainnamen auflöst, dann war diese IP-Adresse autorisiert, E-Mails für die Domain zu senden.
Der aktuelle Status dieses Mechanismus ist, dass er nicht verwendet werden sollte. Allerdings müssen Webseiten, die SPF-Validierungen durchführen, ihn als gültig akzeptieren.
Einige Beispiel-SPF-Einträge
Hier sind einige Beispiel-Einträge und ihre 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 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 denken, SPF ist 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 ihn als notwendig empfunden aufgrund eines Mangels an universeller Unterstützung bei der Validierung des exists-Mechanismus. Und bis heute haben wir keine SPF-Fehler gesehen, die durch die Verwendung des ptr-Mechanismus entstanden sind.
Wie funktioniert die SPF-Authentifizierung?
Hier ist, wie eine typische SMTP-Transaktion aussieht, wenn SPF beteiligt ist:
Der sendende Server (Client) verbindet sich mit dem empfangenden Server
Der empfangende Server notiert die IP-Adresse des verbundenen Clients
Sie tauschen Grüße 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 für entweder die MAIL FROM-Domain oder den HELO-Hostnamen nachschlagen, um zu bestimmen, ob die verbindende IP berechtigt ist, E-Mails für die Domain zu senden, und entscheiden, ob die Nachricht akzeptiert werden soll oder nicht.
MAIL FROM oder HELO – Was prüfen?
Die SPF-Spezifikation stipuliert, dass empfangende Seiten SPF für die MAIL FROM-Domain prüfen MÜSSEN und empfehlen, sie für den HELO-Hostnamen zu prüfen. In der Praxis geschieht die Überprüfung nur bei der MAIL FROM-Domain, außer vielleicht in den Fällen, in denen die MAIL FROM-Adresse der NULL-Absender (d.h. "<>") ist, in diesem Fall ist der HELO-Hostname die einzige verfügbare Identität.
SPF ist nicht narrensicher
Obwohl es relativ einfach erscheint, E-Mails zu authentifizieren, ist SPF anfällig für Fehler in Form von falschen Negativen. Diese Fehler können häufiger auftreten, als vielen lieb ist.
Hier sind zwei häufige Szenarien, in denen perfekt legitime E-Mails die SPF-Validierung nicht bestehen und daher betrügerisch erscheinen können:
Automatisches Weiterleiten, bei dem eine Nachricht an jsmith@alumni.university.edu, ein Postfach, das so konfiguriert ist, dass es alle E-Mails automatisch an jsmith@isp.com weiterleitet
Mailinglisten, bei denen E-Mails an talk-about-stuff@listserv.foo.com „explodiert“ werden und an jeden Abonnenten gesendet werden
In beiden Fällen, wenn der Return-Path unverändert von seinem Original ist, kann die E-Mail die SPF-Prüfungen nicht bestehen (abhängig von dem Modifizierer, der mit dem 'all'-Mechanismus verwendet wird). Dies liegt daran, dass sie an ihrem endgültigen Ziel von einem Zwischenserver ankommt, nicht vom ursprünglichen, und dieser Zwischenserver wahrscheinlich nicht im SPF-Eintrag der Domain aufgeführt ist. Eine Technik namens „Sender Rewriting Scheme“ oder „SRS“ kann dieses Risiko mindern, und einige größere Seiten haben sie übernommen, aber sie ist nicht universell.
Zusammenfassung
Das ist also die SPF-Authentifizierung, wie sie funktioniert, wie man eine SPF-Policy deklariert und welche Fallstricke bei der Verwendung von SPF zu beachten sind. SPF war das erste E-Mail-Authentifizierungssystem, das weit verbreitete Akzeptanz fand, aber es ist nicht das einzige, das es gibt. Die SPF-Authentifizierung ist am effektivsten, wenn sie in Kombination mit anderen Betrugsbekämpfungstechniken eingesetzt wird.