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
Quando parliamo di “Email Authentication”, ci riferiamo a una tecnica destinata a fornire al destinatario di un messaggio un certo livello di certezza che il messaggio sia effettivamente originato dalla fonte dichiarata. L'idea è di raggiungere un certo livello di difesa contro email fraudolente, come phishing e spoofing, che potrebbero erodere la fiducia del destinatario nel ricevere email. Detto ciò, l'atto di inviare email autenticate non afferma, di per sé, che l'email sia buona o desiderata; significa solo che l'email è tale che una reputazione per la parte autenticata può essere stabilita in modo affidabile e utilizzata nelle decisioni di accettazione e collocamento delle email.
Ci sono due forme principali di autenticazione email in uso oggi—Sender Policy Framework (SPF) e DomainKeys Identified Mail (DKIM). In questo post del blog, spiegherò cosa è SPF e come funziona.
SPF Panoramica
Sender Policy Framework (SPF), per parafrasare RFC 7208, è un protocollo che non solo consente a un'organizzazione di autorizzare host e reti a utilizzare i suoi nomi di dominio quando invia email, ma fornisce anche un modo in cui un host ricevente può verificare tale autorizzazione.
Quando avrai finito di leggere questo post, spero che avrai appreso quanto segue:
SPF è un sistema di autenticazione basato su "percorso".
Le politiche SPF sono dichiarate nei record TXT DNS.
La convalida è associata al dominio Return-Path (quello che qui a SparkPost chiamiamo il “dominio di ritorno”) o al dominio HELO.
La convalida può essere effettuata all'inizio della transazione SMTP, quindi è un buon controllo da utilizzare per rifiutare rapidamente la posta non autenticata.
È soggetto a una percentuale relativamente alta di falsi negativi.
“Path-Based” Authentication
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 viene coinvolto SPF:
Il server mittente (client) si connette al server ricevente
Il server ricevente annota l'indirizzo IP di connessione del client
Si scambiano saluti, incluso il nome host HELO del client
Il client emette il comando SMTP MAIL FROM
Il server ricevente può ora verificare il record SPF del dominio MAIL FROM o del nome host HELO per determinare se l'IP di connessione è 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.
