Quando parliamo di “Autenticazione Email”, ci riferiamo a una tecnica che ha lo scopo di fornire al destinatario di un messaggio un certo livello di certezza che il messaggio provenga effettivamente dalla fonte dichiarata del messaggio.
Business in a box.
Scopri le nostre soluzioni.
Parla con il nostro team di vendita
When we speak of “Email Authentication”, we’re referring to a technique that is meant to provide to the recipient of a message some level of certainty that the message actually originated with the claimed source of the message. The idea is to achieve some level of defense against fraudulent email, such as phishing and spoofing, that could erode a recipient’s trust in receiving email. That said, the act of sending authenticated email does not, in and of itself, assert that the email is good or wanted email; it only means that the mail is such that a reputation for the authenticated party can be reliably established and used in email acceptance and placement decisions.
There are two primary forms of email authentication in use today—Sender Policy Framework (SPF) and DomainKeys Identifed Mail (DKIM). In this blog post, I’ll explain what SPF is, and how it works.
SPF Panoramica
Sender Policy Framework (SPF), to paraphrase RFC 7208, is a protocol that not only allows an organization to authorize hosts and networks to use its domain names when sending email, but also provides a way that a receiving host can check that authorization.
When you’re done reading this post, I hope you’ll have learned the following:
SPF is a “path-based” authentication system.
SPF policies are declared in DNS TXT records.
Validation is keyed to the Return-Path domain (what we here at SparkPost call the “bounce domain”) or the HELO domain.
Validation can be done early in the SMTP transaction, so it’s a good check to use to quickly reject unauthenticated mail.
It is prone to a relatively high percentage of false negatives.
“Path-Based” Authentication
SPF è considerato un sistema di autenticazione basato sul percorso perché è legato esclusivamente al percorso che il messaggio ha seguito per giungere dalla sua origine alla sua destinazione. Quando un server mittente avvia una transazione SMTP con un server ricevente, il server ricevente determinerà se il server mittente è autorizzato a inviare quel messaggio in base alla policy SPF del dominio. È esclusivamente una decisione basata sulla provenienza del messaggio, senza alcun riferimento al contenuto del messaggio.
Dichiarare una SPF Policy
Il record di policy SPF di un dominio è solo un record DNS TXT formattato specificamente, comunemente contenente uno o più dei seguenti “meccanismi”:
v=spf1 – Primo token richiesto per indicare che il record TXT è un record SPF (un dominio può avere più record TXT)
ipv4, ipv6 – Utilizzati per specificare indirizzi IP e reti autorizzate ad inviare mail per il dominio
a – Se il dominio mittente ha un record DNS “A” che si risolve con l'IP mittente, l'IP è autorizzato
mx – Se l'IP mittente è anche uno dei record MX per il dominio mittente, l'IP è autorizzato
all – Ultimo token richiesto, sempre modificato:
-all – Solo quanto elencato qui può passare; rifiuta i fallimenti.
~all – Cose che non sono qui dovrebbero fallire, accettele ma prendere nota.
?all – Non è sicuro se le cose che non sono qui dovrebbero passare.
+all – Pensiamo che SPF sia inutile; passa tutto.
Altri meccanismi meno comuni che sono ancora ampiamente utilizzati sono:
include – Usato quando un dominio non ha solo i propri server, ma utilizza anche server di qualcun altro. Deve essere usato con giudizio. Ogni include è un'altra query DNS, e i record SPF non possono richiedere più di dieci query DNS per risolversi.
redirect – Quando il dominio A e il dominio B sono di proprietà della stessa entità e utilizzano la stessa infrastruttura. I proprietari tipicamente vogliono mantenere solo una copia del record SPF per entrambi, e configurano B per reindirizzare le query ad A.
exists – Se un dominio ha molti piccoli blocchi di rete non contigui, può usare questo meccanismo per specificare il proprio record SPF, invece di elencarli tutti. Utile per rimanere entro il limite di dimensione (512 byte) per la risposta DNS.
Una nota sul meccanismo “ptr”
Un ultimo meccanismo, “ptr” esisteva nella specifica originale per SPF, ma è stato dichiarato “non usare” nella specifica attuale. Il meccanismo ptr veniva utilizzato per dichiarare che se l'indirizzo IP mittente aveva un record DNS PTR che si risolveva nel nome del dominio in questione, allora quell'indirizzo IP era autorizzato a inviare mail per il dominio.
Lo stato attuale di questo meccanismo è che non dovrebbe essere usato. Tuttavia, i siti che effettuano la validazione SPF devono accettarlo come valido.
Alcuni Esempi di Record SPF
Ecco alcuni record di esempio e i loro significati. Questo esempio mostra indirizzi RFC 1918, ma riconosco che tali indirizzi non appariranno mai nei veri record SPF.
Record MX, un indirizzo IP, una rete IP, softfail tutto il resto:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Un record, due reti IP, rifiuta tutto il resto:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Non inviamo posta:
“v=spf1 -all”
Pensiamo che SPF sia stupido:
“v=spf1 +all”
Il record SPF per il dominio sparkpostmail.com (meccanismo di redirect utilizzato)
“v=spf1 redirect=_spf.sparkpostmail.com”
Il record SPF per _spf.sparkpostmail.com (meccanismi di exists e ptr utilizzati):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
In SparkPost, attualmente stiamo utilizzando il meccanismo ptr nel nostro record SPF. Abbiamo trovato necessario farlo a causa di una mancanza di supporto universale per la validazione del meccanismo exists. E fino ad oggi, non abbiamo riscontrato fallimenti SPF a causa dell'uso del meccanismo ptr.
How Does SPF Authentication Work?
Ecco come appare una tipica transazione SMTP quando è coinvolto SPF:
Il server di invio (client) si connette al server ricevente
Il server ricevente annota l'indirizzo IP del client che si connette
Si scambiano i saluti, incluso l'hostname HELO del client
Il client emette il comando SMTP MAIL FROM
Il server ricevente può ora cercare il record SPF per il dominio MAIL FROM o l'hostname HELO per determinare se l'IP connesso è autorizzato a inviare posta per il dominio e decidere se accettare o meno il messaggio.
MAIL FROM o HELO – Quale controllare?
La specifica SPF stabilisce che i siti riceventi DEVONO controllare SPF per il dominio MAIL FROM, e RACCOMANDANO di controllarlo per l'hostname HELO. In pratica, il controllo avviene solo sul dominio MAIL FROM, tranne forse per quei casi in cui l'indirizzo MAIL FROM è il mittente NULL (cioè, “<>”), nel qual caso l'hostname HELO è l'unica identità disponibile.
SPF Non È Infallibile
Sebbene sembri un modo relativamente semplice per autenticare l'email, l'SPF è vulnerabile al fallimento sotto forma di falsi negativi. Questi fallimenti possono verificarsi più frequentemente di quanto molti si sentano a proprio agio.
Ecco due scenari comuni in cui la posta perfettamente legittima può fallire la convalida SPF e quindi sembrare fraudolenta:
Inoltro automatico, dove un messaggio inviato a jsmith@alumni.university.edu, una casella di posta impostata per inoltrare automaticamente tutta la posta a jsmith@isp.com
Mailing list, dove la posta inviata a talk-about-stuff@listserv.foo.com viene "esplosa" e inviata a ciascun iscritto
In entrambi questi casi, se il Return-Path rimane invariato dal suo originale, la posta potrebbe non superare i controlli SPF (a seconda del modificatore utilizzato con il meccanismo 'all'). Questo perché arriva alla sua destinazione finale da un server intermedio, non da quello originale, e quel server intermedio non è probabilmente presente nel record SPF del dominio. Una tecnica chiamata "Sender Rewriting Scheme" o "SRS" può mitigare questo rischio, e alcuni siti più grandi l'hanno adottata, ma non è universale.
Concludere
Quindi questa è l'autenticazione SPF, come funziona, come dichiarare una policy SPF e quali sono le insidie nell'utilizzo di SPF. SPF è stato il primo schema di autenticazione email a ottenere un'ampia adozione, ma non è l'unico disponibile. L'autenticazione SPF è più efficace quando viene implementata in combinazione con altre tecniche anti-frode.
