CUSTOMIZE Quando parliamo di “Email Authentication”, ci riferiamo a una tecnica che fornisce al destinatario di un messaggio un certo livello di certezza che il messaggio provenga effettivamente dalla fonte dichiarata del messaggio.
Quando parliamo di "Email Authentication", ci riferiamo a una tecnica che fornisce al destinatario di un messaggio un certo livello di certezza che il messaggio provenga effettivamente dalla fonte dichiarata del messaggio. L'idea alla base di tali tecniche è di raggiungere un qualche livello di difesa contro le email fraudolente, come il phishing e lo spoofing, email che potrebbero erodere la fiducia di un destinatario nel ricevere email. Detto questo, l'atto di inviare email autenticate non afferma che l'email sia buona o desiderata; significa solo che l'email è tale che una reputazione per la parte autenticata possa essere stabilita in modo affidabile e utilizzata nelle decisioni di accettazione e posizionamento delle email.
Oggi ci sono due forme di autenticazione email in uso:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Nel post di oggi, sto trattando cosa sia DKIM e come funziona.
DKIM Panoramica
A differenza della sua controparte di autenticazione SPF, che fornisce un modo per un dominio di autorizzare un host a inviare posta per suo conto, DKIM fornisce un modo per un'entità (dominio, organizzazione, persona, ecc.) di assumersi la responsabilità di un messaggio, indipendentemente dall'entità che ha effettivamente inviato il messaggio. Sebbene in molti casi l'entità responsabile e l'entità che invia possano essere la stessa, o almeno strettamente correlate, con DKIM non è richiesto che questo sia così.
I miei obiettivi per te con questo post sono che tu apprenda e comprenda i seguenti concetti su DKIM:
DKIM è un'autenticazione "basata sul contenuto", a differenza della SPF "basata sul percorso".
L'entità responsabile dichiara la sua responsabilità "firmando" il messaggio con una coppia di hash crittografici inseriti nell'intestazione del messaggio.
La convalida DKIM viene eseguita dal dominio ricevente che tenta di generare gli stessi due hash.
La convalida DKIM non può essere completata in molti casi finché il messaggio completo non è stato trasmesso dal server di invio.
I fallimenti di convalida possono essere difficili da risolvere.
Autenticazione “Content-Based”
DKIM Signing e Validation
Le organizzazioni che desiderano firmare le email con DKIM genereranno prima due chiavi crittografiche. Una delle chiavi viene mantenuta privata e disponibile per il server di invio per firmare le email, mentre l'altra deve essere resa pubblica nel DNS affinché i domini riceventi possano tentare di convalidare la firma. I metodi per generare queste chiavi e installarle dipendono dalla piattaforma e sono al di là dell'ambito di questo post, anche se più avanti descriverò la pubblicazione nel DNS della chiave pubblica DKIM.
L'intestazione DKIM-Signature
Per iniziare a comprendere DKIM, diamo prima un'occhiata a un'intestazione DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
L'intestazione DKIM-Signature è una serie di coppie chiave-valore, alcune delle quali più interessanti per il lettore rispetto ad altre, ma qui le descriverò tutte.
Per prima cosa, esaminiamo quelle che sono per lo più d'interesse fugace per il lettore:
v=1; – Specifica la versione DKIM (1 è l'unico valore valido)
a=rsa-sha256; – L'algoritmo utilizzato per costruire gli hash crittografici
c=relaxed/relaxed; – Ci sono due insiemi di regole riguardanti la rimozione degli spazi bianchi nelle intestazioni e nel corpo che possono essere applicate durante la creazione degli hash in una firma DKIM; queste regole si chiamano “regole di canonizzazione” (da qui la chiave c) e gli insiemi di regole sono “rilassato” o “rigido”.
t=1454417737; – Il timestamp di quando è stata creata la firma.
Queste tre parti dell'intestazione contengono le informazioni di firma effettive:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Questo è l'hash del corpo del messaggio.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Questa è una lista delle intestazioni che sono state utilizzate per creare i dati della firma mostrati qui sotto.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Questi sono i dati effettivi della firma DKIM
Queste tre parti sono di maggior interesse per il server ricevente che convaliderà la firma:
d=welcome.foo.com; – Questo identifica il dominio che ha firmato il messaggio
s=notices; – Il selettore; i domini possono avere più selettori che utilizzano durante la firma dei messaggi.
i=@welcome.foo.com; – Questa è l'identità per conto della quale il messaggio è stato firmato. Sintatticamente, questo sembrerà un indirizzo email e potrebbe persino essere uno; la parte locale dell'indirizzo email può essere vuota, come in questo esempio, e la parte dominio deve essere la stessa o un sottodominio del dominio nella parte d= della firma.
Il motivo per cui queste parti sono di interesse per il server ricevente è che forniscono le informazioni necessarie per aiutare il ricevente a convalidare le firme.
DKIM Validation
Oltre al requisito menzionato che il dominio i= deve essere lo stesso o un sottodominio del dominio d=, i bit d= e s= sono utilizzati dal validatore per cercare la chiave pubblica DKIM del firmatario nel DNS. La chiave è un record TXT nel DNS, e si trova sempre alla posizione selector._domainkey.domain. Quindi, nel nostro esempio qui, con s=notices e d=welcome.foo.com, la chiave pubblica DKIM verrebbe trovata nel DNS a notices._domainkey.welcome.foo.com, e potrebbe apparire in questo modo:
notices._domainkey.welcome.foo.com. testo descrittivo "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Il validatore utilizza quella chiave (i bit p=) per produrre il proprio set di hash del messaggio; se questi hash corrispondono, allora il messaggio non è stato alterato durante il transito, e quindi il messaggio può contribuire a, e forse beneficiare di, qualunque reputazione sia in atto per il firmatario del messaggio.
Validation Failure e Risoluzione dei Problemi
Ho menzionato sopra che i fallimenti DKIM possono essere difficili da risolvere, e qui spiegherò il motivo.
Alcuni fallimenti nella validazione DKIM hanno cause ovvie, come il fatto che il messaggio non sia firmato, o la chiave pubblica del dominio firmante non sia trovata nel DNS o non sia sintatticamente corretta, o forse il messaggio è stato evidentemente alterato durante la trasmissione. Quando accadono questi tipi di fallimenti, è facile capire il problema e raccomandare una soluzione. Tuttavia, quelli difficili e quelli che portano all'esperienza di supporto più frustrante, sono i casi in cui il messaggio era firmato, la chiave pubblica esiste nel DNS e il messaggio non è stato evidentemente alterato, ma il validatore riporta che la firma non è stata validata.
Il motivo per cui questi casi sono difficili da risolvere è che non c'è un vero modo per nessuna delle parti di riprodurre le condizioni sotto le quali il messaggio è stato firmato e validato. Il messaggio ha nella sua intestazione DKIM-Signature gli hash generati dal firmatario al momento della firma, ma probabilmente il validatore non ha accesso all'infrastruttura del firmatario e quindi non può cercare di riprodurre la firma nelle condizioni del firmatario. Allo stesso modo, probabilmente il firmatario non ha accesso all'infrastruttura del validatore e quindi non ha modo di cercare di validare il messaggio nel modo in cui il validatore ha fatto.
I fallimenti come quelli che sto descrivendo qui sono eventi rari, e i fallimenti nella validazione DKIM di per sé di solito non hanno un impatto sulla consegna. Mentre DKIM gestisce l'autenticazione dei messaggi, l'implementazione di tecniche di validazione email complete garantisce che si stia inviando a indirizzi legittimi che possono effettivamente ricevere e autenticare i vostri messaggi. È stata la mia esperienza che tali fallimenti generano più ticket di supporto rispetto a qualsiasi altro tipo di problema DKIM.
