Quando parliamo di “Autenticazione Email”, ci riferiamo a una tecnica volta a fornire al destinatario di un messaggio un certo livello di certezza che il messaggio provenga effettivamente dalla fonte dichiarata. L'idea è di raggiungere un certo livello di difesa contro le email fraudolente, come il phishing e lo spoofing, che potrebbero minare la fiducia del destinatario nel ricevere email. Detto ciò, l'atto di inviare email autenticate non implica, di per sé, che l'email sia buona o desiderata; significa solo che la posta è tale che una reputazione per la parte autenticata può essere stabilita e utilizzata in decisioni di accettazione e posizionamento delle email.
Ci sono due forme principali di autenticazione email in uso oggi—Sender Policy Framework (SPF) e DomainKeys Identifed Mail (DKIM). In questo post del blog, spiegherò cosa è lo SPF e come funziona.
Panoramica su SPF
Il Sender Policy Framework (SPF), per parafrasare RFC 7208, è un protocollo che consente a un'organizzazione non solo di autorizzare host e reti a utilizzare i propri nomi di dominio quando inviano email, ma fornisce anche un modo per un host ricevente di verificare quella autorizzazione.
Quando hai finito di leggere questo post, spero che tu abbia appreso quanto segue:
Lo SPF è un sistema di autenticazione “basato su percorso”.
Le politiche SPF sono dichiarate nei record DNS TXT.
La convalida è riferita al dominio Return-Path (quello che noi di SparkPost chiamiamo il “dominio di rimbalzo”) o il dominio HELO.
La convalida può essere effettuata precocemente nella transazione SMTP, quindi è un buon controllo da utilizzare per rifiutare rapidamente la posta non autenticata.
È soggetta a una percentuale relativamente alta di falsi negativi.
Autenticazione “Basata su Percorso”
Lo SPF è considerato un sistema di autenticazione basato su percorso perché è legato esclusivamente al percorso che il messaggio ha seguito per arrivare dalla sua origine alla sua destinazione. Quando un server di invio avvia una transazione SMTP con un server ricevente, il server ricevente determinerà se il server di invio è autorizzato o meno a inviare quel messaggio in base alla politica SPF del dominio. È una decisione basata esclusivamente su dove proviene il messaggio, senza alcun legame con il contenuto del messaggio.
Dichiarare una Politica SPF
Il record della politica SPF di un dominio è semplicemente un record DNS TXT formattato specificamente, che contiene comunemente uno o più dei seguenti “meccanismi”:
v=spf1 – Token obbligatorio 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 autorizzati a inviare posta per il dominio
a – Se il dominio di invio ha un record DNS “A” che risolve all'IP di invio, l'IP è autorizzato
mx – Se l'IP di invio è anche uno dei record MX per il dominio di invio, l'IP è autorizzato
all – Token finale obbligatorio, sempre modificato:
-all – Solo ciò che è elencato qui può passare; rifiuta i fallimenti.
~all – Le cose che non sono qui dovrebbero fallire dolcemente; accettale ma annotale.
?all – Non sono sicuro se le cose che non sono qui dovrebbero passare.
+all – Pensiamo che l'SPF sia inutile; accetta tutto.
Altri meccanismi meno comuni ma comunque di larga diffusione sono:
include – Utilizzato quando un dominio non solo ha i propri server, ma utilizza anche server di qualcun altro. Deve essere usato con cautela. Ogni inclusione è un'altra query DNS, e i record SPF non possono richiedere più di dieci query DNS per essere risolti.
redirect – Quando il dominio A e il dominio B sono posseduti dalla stessa entità e utilizzano la stessa infrastruttura. I proprietari desiderano tipicamente mantenere una sola copia del record SPF per entrambi e configurare B per reindirizzare le query ad A.
exists – Se un dominio ha molti piccoli blocchi di rete non contigui, può utilizzare 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 meccanismo finale, “ptr”, esisteva nella specifica originale per lo SPF, ma è stato dichiarato “non usare” nella specifica attuale. Il meccanismo ptr era utilizzato per dichiarare che se l'indirizzo IP di invio aveva un record DNS PTR che si risolveva nel nome di dominio in questione, allora quell'indirizzo IP era autorizzato a inviare posta 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 esempi di record e i loro significati. Questo esempio mostra indirizzi RFC 1918, ma riconosco che tali indirizzi non appariranno mai in veri record SPF.
Record MX, un indirizzo IP, una rete IP, fallisci dolcemente tutto il resto:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Record A, due reti IP, rifiuta tutto il resto:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Noi non inviamo email:
“v=spf1 -all”
Pensiamo che l'SPF sia stupido:
“v=spf1 +all”
Il record SPF per il dominio sparkpostmail.com (meccanismo di reindirizzamento usato)
“v=spf1 redirect=_spf.sparkpostmail.com”
Il record SPF per _spf.sparkpostmail.com (meccanismi exists e ptr utilizzati):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Noi di SparkPost stiamo attualmente utilizzando il meccanismo ptr nel nostro record SPF. Lo abbiamo trovato necessario a causa della mancanza di supporto universale per la validazione del meccanismo exists. E fino ad oggi, non abbiamo visto fallimenti SPF a causa dell'uso del meccanismo ptr.
Come Funziona l'Autenticazione SPF?
Ecco come appare una tipica transazione SMTP quando è coinvolto lo SPF:
Il server di invio (client) si connette al server ricevente
Il server ricevente annota l'indirizzo IP di connessione del client
Scambiano saluti, incluso il nome host 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 il 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 lo SPF per il dominio MAIL FROM e CONSIGLIARE di controllarlo per il nome host HELO. In pratica, il controllo avviene solo sul dominio MAIL FROM, eccetto forse per quei casi in cui l'indirizzo MAIL FROM è il mittente NULL (cioè, “<>”), nel qual caso il nome host HELO è l'unica identità disponibile.
Lo SPF Non È Impeccabile
Pur sembrando un modo relativamente semplice per autenticare le email, lo SPF è vulnerabile a fallimenti sotto forma di falsi negativi. Questi fallimenti possono verificarsi più frequentemente di quanto molti siano a loro agio.
Ecco due scenari comuni in cui email perfettamente legittime possono fallire la convalida SPF e quindi apparire fraudolente:
Inoltro automatico, in cui un messaggio inviato a jsmith@alumni.university.edu, una casella di posta impostata per inoltrare automaticamente tutta la posta a jsmith@isp.com
Liste di distribuzione, in cui la posta inviata a talk-about-stuff@listserv.foo.com viene “esplosa” e inviata a ciascun abbonato
In entrambi i casi, se il Return-Path rimane invariato rispetto all'originale, la posta potrebbe fallire i controlli SPF (a seconda del modificatore utilizzato con il meccanismo ‘all’). Questo perché arriva alla sua destinazione finale da un server intermedio, non dal server originale, e quel server intermedio è poco probabile che sia nel record SPF del dominio. Una tecnica chiamata “Schemi di Riscrittura del Mittente” o “SRS” può mitigare questo rischio e alcuni siti più grandi l'hanno adottata, ma non è universale.
In Conclusione
Quindi questa è l'autenticazione SPF, come funziona, come dichiarare una politica SPF e quali sono i problemi nell'utilizzare lo SPF. Lo SPF è stato il primo schema di autenticazione email a ottenere un'ampia adozione, ma non è l'unico là fuori. L'autenticazione SPF è più efficace quando viene implementata in combinazione con altre tecniche anti-frode.