Wanneer we spreken over “Email Authenticatie”, verwijzen we naar een techniek die bedoeld is om de ontvanger van een bericht een zekere mate van zekerheid te geven dat het bericht daadwerkelijk afkomstig is van de beweerde bron van het bericht. Het idee is om een zekere mate van verdediging te bereiken tegen frauduleuze e-mail, zoals phishing en spoofing, die het vertrouwen van een ontvanger in het ontvangen van e-mail kan ondermijnen. Dat gezegd hebbende, betekent de handeling van het verzenden van geauthenticeerde e-mail op zich 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 Identified 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 in staat stelt 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 klaar bent met het lezen van deze post, hoop ik dat je het volgende hebt geleerd:
SPF is een “pad-gebaseerd” authenticatiesysteem.
SPF-beleid wordt verklaard in DNS TXT-records.
Validatie is gekoppeld aan het Return-Path-domein (wat wij hier bij SparkPost het “bounce-domein” noemen) of het HELO-domein.
Validatie kan vroeg in de SMTP-transactie worden uitgevoerd, dus het is een goede controle om ongeauthenticeerde e-mail snel af te wijzen.
Het is gevoelig voor een relatief hoog percentage valse negatieven.
“Pad-gebaseerde” Authenticatie
SPF wordt beschouwd als een pad-gebaseerd authenticatiesysteem omdat het uitsluitend verbonden is met het pad dat het bericht heeft afgelegd om van zijn oorsprong naar zijn bestemming te komen. Wanneer een verzendende server een SMTP-transactie initieert met een ontvangende server, bepaalt de ontvangende server 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 die is gebaseerd op waar het bericht vandaan komt, zonder enig verband met de inhoud van het bericht.
Een SPF-beleid Verklaren
Het SPF-beleidsrecord van een domein is gewoon een specifiek geformatteerd DNS TXT-record, dat vaak een of meer van de volgende “mechanismen” bevat:
v=spf1 – Vereist eerste token om aan te geven dat TXT-record een SPF-record is (een domein kan meerdere TXT-records hebben)
ipv4, ipv6 – Gebruikt om IP-adressen en netwerken te specificeren die zijn toegestaan om mail voor het domein te verzenden
a – Als het verzendende domein een DNS “A” record heeft dat oplost naar het verzendende IP, is het IP toegestaan
mx – Als het verzendende IP ook een van de MX-records voor het verzendende domein is, is het IP toegestaan
all – Vereist laatste token, altijd aangepast:
-all – Alleen wat hier vermeld staat mag slagen; faalverzoeken worden afgewezen.
~all – Dingen die hier niet worden vermeld moeten softfail; accepteer het maar noteer het.
?all – Niet zeker of dingen die hier niet staan vermeld moeten slagen.
+all – We denken dat SPF nutteloos is; laat alles toe.
Andere minder gebruikelijke mechanismen die nog steeds wijdverspreid worden gebruikt zijn:
include – Gebruikt wanneer een domein niet alleen zijn eigen servers heeft, maar ook de servers van een ander gebruikt. Moet voorzichtig worden gebruikt. Elke include is een andere DNS-vraag en SPF-records mogen niet meer dan tien DNS-vragen vereisen om opgelost te worden.
redirect – Wanneer domein A en domein B in bezit zijn van dezelfde entiteit en dezelfde infrastructuur gebruiken. De eigenaren willen meestal slechts één kopie van het SPF-record voor beide onderhouden en configureren B om vragen naar A te verwijzen.
exists – Als een domein veel kleine, niet-aaneengesloten netwerkblokken heeft, kan het dit mechanisme gebruiken om zijn SPF-record te specificeren, in plaats van ze allemaal op te sommen. Handig om binnen de grootte limiet (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, dan dat IP-adres gemachtigd was om mail voor het domein te verzenden.
De huidige status van dit mechanisme is dat het niet gebruikt moet worden. Echter, sites die SPF-validering doen, moeten het accepteren als geldig.
Enkele Voorbeelden van 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 verschijnen.
MX-record, één IP-adres, één IP-netwerk, zacht falen van alles wat niet lukt:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A record, twee IP-netwerken, alles afwijzen wat niet lukt:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
We verzenden geen mail:
“v=spf1 -all”
We denken dat SPF dom is:
“v=spf1 +all”
Het SPF-record voor het domein sparkpostmail.com (gebruikte redirect-mechanisme)
“v=spf1 redirect=_spf.sparkpostmail.com”
Het SPF-record voor _spf.sparkpostmail.com (gebruikte exists en ptr mechanismen):
“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 gevonden vanwege een gebrek aan universele ondersteuning voor het valideren van het exists mechanisme. En tot op heden hebben we geen SPF-fouten gezien als gevolg van ons gebruik van het ptr mechanisme.
Hoe Werkt SPF-authenticatie?
Hier ziet een typische SMTP-transactie eruit wanneer SPF is betrokken:
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-opdracht uit
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 gemachtigd is om mail voor het domein te verzenden, en beslissen of het bericht moet worden geaccepteerd.
MAIL FROM of HELO – Welke te Controleren?
De SPF-specificatie bepaalt dat ontvangende sites MUST SPF moeten controleren voor het MAIL FROM-domein en dit RECOMMEND voor de HELO-hostnaam. In de praktijk gebeurt controle alleen op het MAIL FROM-domein, behalve misschien in die gevallen waarin het MAIL FROM-adres de NULL-zender 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 authenticeren, is SPF kwetsbaar voor falen in de vorm van valse negatieven. Deze fouten kunnen vaker voorkomen dan veel mensen comfortabel vinden.
Hier zijn twee veelvoorkomende scenario's waarbij volkomen legitieme mail SPF-validatie kan mislukken en dus frauduleus kan lijken:
Geautomatiseerde doorsturing, waarbij een bericht 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 “uitgesplitst” en naar elke abonnee verzonden wordt
In beide gevallen, als het Return-Path ongewijzigd blijft vanaf het origineel, kan de mail SPF-controles mislukken (afhankelijk van de modificator die met het ‘all’ mechanisme wordt gebruikt). Dit komt omdat het arriveert bij zijn eindbestemming vanaf een tussenliggende server, niet de oorspronkelijke, en die tussenliggende server is waarschijnlijk niet in het SPF-record van het domein. Een techniek genaamd “Sender Rewriting Scheme” of “SRS” kan dit risico beperken, en sommige grotere sites hebben het overgenomen, maar het is niet universeel.
Afsluiting
Dat is dus SPF authenticatie, hoe het werkt, hoe een SPF-beleid te verklaren, en wat de valkuilen zijn bij het gebruik van SPF. SPF was het eerste e-mail authenticatiesysteem dat wijdverspreide adoptie bereikte, 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.