Wanneer we het hebben over "E-mailverificatie", verwijzen we naar een techniek die bedoeld is om de ontvanger van een bericht een mate van zekerheid te bieden dat het bericht daadwerkelijk afkomstig is van de vermeende bron van het bericht.
Business in a box.
Ontdek onze oplossingen.
Praat met ons verkoopteam
Wanneer we spreken van “Email Authentication”, verwijzen we naar een techniek die bedoeld is om de ontvanger van een bericht een bepaald niveau van zekerheid te bieden dat het bericht daadwerkelijk afkomstig is van de geclaimde bron van het bericht. Het idee is om een bepaald niveau van verdediging te bereiken tegen frauduleuze e-mail, zoals phishing en spoofing, die het vertrouwen van een ontvanger in het ontvangen van e-mail zouden kunnen aantasten. Dat gezegd zijnde, betekent het verzenden van geauthenticeerde e-mail op zichzelf niet dat de e-mail goed of gewenst is; het betekent alleen dat de e-mail zodanig is dat een reputatie voor de geauthenticeerde partij betrouwbaar kan worden vastgesteld en gebruikt bij beslissingen over e-mailacceptatie en -plaatsing.
Er zijn tegenwoordig twee primaire vormen van e-mailauthenticatie in gebruik—Sender Policy Framework (SPF) en DomainKeys Identifed Mail (DKIM). In deze blogpost zal ik uitleggen wat SPF is en hoe het werkt.
SPF Overzicht
Sender Policy Framework (SPF), om RFC 7208 te parafraseren, is een protocol dat niet alleen een organisatie toestaat om hosts en netwerken te autoriseren om zijn domeinnamen te gebruiken bij het verzenden van e-mail, maar ook een manier biedt waarop een ontvangende host die autorisatie kan controleren.
Wanneer je deze post hebt gelezen, hoop ik dat je het volgende hebt geleerd:
SPF is een "pad-gebaseerd" authenticatiesysteem.
SPF-beleid wordt gedeclareerd in DNS TXT-records.
Validatie is gekoppeld aan het Return-Path domein (wat wij hier bij SparkPost de “bounce domain” noemen) of het HELO-domein.
Validatie kan vroeg in de SMTP-transactie worden uitgevoerd, dus het is een goede controle om niet-geauthenticeerde e-mail snel te weigeren.
Het is gevoelig voor een relatief hoog percentage van valse negatieven.
“Path-Based” Authenticatie
SPF wordt beschouwd als een pad-gebaseerd authenticatiesysteem omdat het uitsluitend is gekoppeld aan het pad dat het bericht volgde van zijn oorsprong naar zijn bestemming. Wanneer een verzendende server een SMTP-transactie initieert met een ontvangende server, zal de ontvangende server bepalen of de verzendende server gemachtigd is om dat bericht te verzenden op basis van het SPF-beleid van het domein. Het is uitsluitend een beslissing op basis van waar het bericht vandaan komt, zonder enige betrekking op de inhoud van het bericht.
Een SPF-beleid verklaren
Het SPF-beleid van een domein is gewoon een specifiek geformatteerd DNS TXT-record, dat gewoonlijk een of meer van de volgende “mechanismen” bevat:
v=spf1 – Vereist eerste token om aan te geven dat het TXT-record een SPF-record is (een domein kan meerdere TXT-records hebben)
ipv4, ipv6 – Gebruikt om IP-adressen en netwerken op te geven die bevoegd zijn om mail voor het domein te verzenden
a – Als het verzendende domein een DNS “A”-record heeft dat wordt opgelost naar het verzendende IP, is het IP toegestaan
mx – Als het verzendende IP ook een van de MX-records is voor het verzendende domein, is het IP toegestaan
all – Vereist laatste token, altijd gewijzigd:
-all – Alleen wat hier is vermeld kan slagen; mislukkingen afwijzen.
~all – Dingen die hier niet zijn moeten softfailen; accepteer het maar merk het op.
?all – Niet zeker of dingen die hier niet zijn zouden moeten slagen.
+all – We denken dat SPF nutteloos is; laat alles door.
Andere minder gebruikelijke mechanismen die nog steeds veel worden gebruikt zijn:
include – Wordt gebruikt wanneer een domein niet alleen zijn eigen servers heeft, maar ook de servers van iemand anders gebruikt. Moet zorgvuldig worden gebruikt. Elke include is een andere DNS-query en SPF-records kunnen niet meer dan tien DNS-queries vereisen om op te lossen.
redirect – Wanneer domein A en domein B eigendom zijn van dezelfde entiteit en dezelfde infrastructuur gebruiken. De eigenaren willen meestal slechts één kopie van het SPF-record voor beide beheren en B configureren om queries door te sturen naar A.
exists – Als een domein veel kleine, niet-aaneengesloten netwerkblokken heeft, kan het deze mechanisme gebruiken om zijn SPF-record op te geven, in plaats van ze allemaal op te sommen. Handig om binnen de groottebeperking (512 bytes) voor DNS-respons te blijven.
Een opmerking over het “ptr” Mechanisme
Een laatste mechanisme, “ptr” bestond in de oorspronkelijke specificatie voor SPF, maar is verklaard als “niet gebruiken” in de huidige specificatie. Het ptr-mechanisme werd gebruikt om aan te geven dat als het verzendende IP-adres een DNS PTR-record had dat oploste naar de domeinnaam in kwestie, dat IP-adres gemachtigd was om mail voor het domein te verzenden.
De huidige status van dit mechanisme is dat het niet gebruikt mag worden. Echter, sites die SPF-validatie uitvoeren moeten het accepteren als geldig.
Enkele Voorbeeld SPF Records
Hier zijn enkele voorbeeldrecords en hun betekenissen. Dit voorbeeld toont RFC 1918-adressen, maar ik erken dat dergelijke adressen nooit in echte SPF-records zullen voorkomen.
MX-record, één IP-adres, één IP-netwerk, softfail alles behalve:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A-record, twee IP-netwerken, weiger alles behalve:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
We sturen geen mail:
“v=spf1 -all”
We vinden SPF stom:
“v=spf1 +all”
Het SPF-record voor het domein sparkpostmail.com (redirect mechanisme gebruikt)
“v=spf1 redirect=_spf.sparkpostmail.com”
Het SPF-record voor _spf.sparkpostmail.com (exists- en ptr-mechanismen gebruikt):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Bij SparkPost gebruiken we momenteel het ptr-mechanisme in ons SPF-record. We hebben het noodzakelijk geacht vanwege een gebrek aan universele ondersteuning voor het valideren van het exists-mechanisme. En tot nu toe hebben we geen SPF-fouten gezien als gevolg van het gebruik van het ptr-mechanisme.
Hoe werkt SPF-authenticatie?
Hier is hoe een typische SMTP-transactie eruitziet wanneer SPF erbij betrokken is:
De verzendende server (client) maakt verbinding met de ontvangende server
De ontvangende server noteert het verbindende IP-adres van de client
Ze wisselen begroetingen uit, inclusief de HELO-hostnaam van de client
Client geeft SMTP MAIL FROM-commando
De ontvangende server kan nu het SPF-record opzoeken voor het MAIL FROM-domein of de HELO-hostnaam om te bepalen of het verbindende IP geautoriseerd is om mail voor het domein te verzenden, en beslissen of het bericht geaccepteerd wordt.
MAIL FROM of HELO – Welke te controleren?
De SPF-specificatie bepaalt dat ontvangende sites SPF MOETEN controleren voor het MAIL FROM-domein, en AANBEVOLEN wordt om het te controleren voor de HELO-hostnaam. In de praktijk vindt de controle alleen plaats op het MAIL FROM-domein, behalve misschien voor die keren dat het MAIL FROM-adres de NULL-afzender is (d.w.z. "<>"), in welk geval de HELO-hostnaam de enige beschikbare identiteit is.
SPF Is Niet Waterdicht
Hoewel het een relatief eenvoudige manier lijkt om e-mail te verifiëren, is SPF kwetsbaar voor fouten in de vorm van valse negatieven. Deze fouten kunnen vaker voorkomen dan velen prettig vinden.
Hier zijn twee veelvoorkomende scenario's waarin volkomen legitieme e-mail kan falen bij SPF-validatie en dus frauduleus kan lijken:
Geautomatiseerd doorsturen, waarbij een bericht verzonden naar jsmith@alumni.university.edu, een mailbox die is ingesteld om alle mail automatisch door te sturen naar jsmith@isp.com
Mailinglijsten, waarbij mail verzonden naar talk-about-stuff@listserv.foo.com wordt 'ontploft' en naar elke abonnee gestuurd
In beide gevallen, als het Return-Path ongewijzigd blijft sinds het origineel, kan de e-mail SPF-controles niet doorstaan (afhankelijk van de modifier die is gebruikt met het ‘all’ mechanisme). Dit komt omdat het op zijn uiteindelijke bestemming aankomt van een tussenliggende server, niet de oorspronkelijke, en die tussenliggende server zal waarschijnlijk niet in het SPF-record van het domein staan. Een techniek genaamd “Sender Rewriting Scheme” of “SRS” kan dit risico verminderen, en sommige grotere sites hebben het geadopteerd, maar het is niet universeel.
Afronden
Dus dat is SPF-authenticatie, hoe het werkt, hoe een SPF-beleid te declareren en wat de valkuilen zijn bij het gebruik van SPF. SPF was het eerste e-mailauthenticatieschema dat op grote schaal werd geaccepteerd, maar het is niet de enige die er is. SPF-authenticatie is het meest effectief wanneer het wordt ingezet in combinatie met andere anti-fraude technieken.
