Validazione DKIM: Una Best Practice per l'Autenticazione delle Email
Uccello
8 apr 2017
1 min read
Punti Chiave
DKIM (DomainKeys Identified Mail) è un metodo di autenticazione email basato sul contenuto che verifica se un messaggio è stato modificato dopo essere stato firmato.
Contrariamente a SPF, che valida il percorso di invio, DKIM valida il contenuto del messaggio stesso utilizzando firme crittografiche.
DKIM utilizza due chiavi: una chiave privata per firmare i messaggi in uscita e una chiave pubblica pubblicata nel DNS per consentire ai destinatari di convalidare le firme.
Una firma DKIM include hash di sia degli header che del corpo, selettori, timestamp e campi di identità — tutti elementi che il destinatario deve riprodurre e verificare.
La validazione DKIM si basa sul ricevere prima l'intero messaggio, il che significa che possono verificarsi errori in ritardo nel processo.
La risoluzione dei problemi di validazione DKIM non riuscita è spesso difficile perché mittenti e destinatari non possono riprodurre gli ambienti di firma/verifica reciproci.
Anche quando DKIM fallisce, tipicamente non causa direttamente problemi di consegna nella casella di posta da solo a meno che non sia combinato con altri segnali di reputazione negativa.
Punti salienti del Q&A
Cosa fa realmente DKIM?
DKIM allega una firma crittografica a un'email, consentendo al server di ricezione di confermare se il contenuto del messaggio è stato modificato dopo l'invio.
In che modo DKIM è diverso da SPF?
SPF convalida chi è autorizzato a inviare email per un dominio (basato su percorso).
DKIM convalida se il contenuto è integro (basato sul contenuto).
Entrambi servono a scopi diversi e si integrano a vicenda.
Cosa c'è all'interno di un'intestazione DKIM-Signature?
I campi chiave includono:
v= versione
a= algoritmo
c= regole di canonicalizzazione
d= dominio di firma
s= selettore
h= intestazioni incluse nella firma
bh= hash del corpo
b= dati della firma effettiva
Ogni parte contribuisce a come viene convalidata la firma.
Come convalida un server di ricezione il DKIM?
Estrae i valori di d= e s=.
Cerca la chiave pubblica presso:
selector._domainkey.domain
Rigenera gli hash dell'intestazione e del corpo.
Li confronta con i valori bh= e b= nell'email.
Se corrispondono, il messaggio passa DKIM.
Cosa causa il fallimento di DKIM?
Messaggio alterato in transito (anche le modifiche degli spazi bianchi se si utilizza la canonicalizzazione rigorosa)
Chiave pubblica mancante o errata nel DNS
Errori di formattazione DNS
Selettore rimosso o ruotato in modo errato
Identità non corrispondenti (i= deve essere lo stesso dominio o sottodominio di d=)
Perché i fallimenti di DKIM possono essere difficili da risolvere?
Poiché il firmatario e il validatore operano in ambienti completamente diversi, nessuna delle due parti può ricostruire le condizioni di hashing o lo stato della firma dell'altra.
Ciò rende i fallimenti opachi per "mismatch di hash" i più frustranti da diagnosticare.
Un fallimento DKIM significa che l'email finirà nello spam?
Non necessariamente.
DKIM è solo un segnale. Se il dominio ha una forte reputazione e supera altri controlli (allineamento SPF, DMARC, tassi di reclamo bassi), i fallimenti DKIM isolati di solito non influiscono sull'inserimento nella posta in arrivo da soli.
Perché usare DKIM?
Protegge l'integrità dei messaggi
Costruisce la reputazione del dominio
Abilita l'allineamento DMARC
Aiuta i fornitori di caselle di posta a distinguere i mittenti legittimi dagli impostori
DKIM è considerato una prassi consigliata per tutti i mittenti di email seri.
Quando parliamo di “Autenticazione Email”, ci riferiamo a una tecnica che fornisce al destinatario di un messaggio un certo livello di certezza che il messaggio provenga realmente dalla sorgente dichiarata del messaggio. L'idea dietro tali tecniche è di raggiungere un certo 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 ciò, l'atto di inviare email authenticate non afferma 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 di autenticazione email in uso oggi:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Nel post di oggi, parlerò di cosa sia DKIM e di come funzioni.
Quando parliamo di “Autenticazione Email”, ci riferiamo a una tecnica che fornisce al destinatario di un messaggio un certo livello di certezza che il messaggio provenga realmente dalla sorgente dichiarata del messaggio. L'idea dietro tali tecniche è di raggiungere un certo 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 ciò, l'atto di inviare email authenticate non afferma 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 di autenticazione email in uso oggi:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Nel post di oggi, parlerò di cosa sia DKIM e di come funzioni.
Quando parliamo di “Autenticazione Email”, ci riferiamo a una tecnica che fornisce al destinatario di un messaggio un certo livello di certezza che il messaggio provenga realmente dalla sorgente dichiarata del messaggio. L'idea dietro tali tecniche è di raggiungere un certo 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 ciò, l'atto di inviare email authenticate non afferma 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 di autenticazione email in uso oggi:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Nel post di oggi, parlerò di cosa sia DKIM e di come funzioni.
Panoramica di DKIM
Contrariamente al suo controparte di autenticazione SPF, che fornisce un modo per un dominio di autorizzare un host a inviare email per conto suo, 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à mittente siano le stesse, o almeno strettamente correlate, con DKIM non c'è alcun requisito che ciò sia così.
I miei obiettivi per te con questo post sono che tu impari e comprenda i seguenti concetti su DKIM:
DKIM è un'autenticazione “basata sul contenuto”, a differenza dello SPF “basato sul percorso”.
L'entità responsabile afferma la propria responsabilità “firmando” il messaggio con una coppia di hash crittografici inseriti nell'intestazione di un messaggio.
La validazione DKIM viene eseguita dal dominio ricevente che tenta di generare gli stessi due hash.
La validazione DKIM non può essere completata in molti casi fino a quando l'intero messaggio non è stato trasmesso dal server di invio.
Le anomalie nella validazione possono essere difficili da risolvere.
Contrariamente al suo controparte di autenticazione SPF, che fornisce un modo per un dominio di autorizzare un host a inviare email per conto suo, 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à mittente siano le stesse, o almeno strettamente correlate, con DKIM non c'è alcun requisito che ciò sia così.
I miei obiettivi per te con questo post sono che tu impari e comprenda i seguenti concetti su DKIM:
DKIM è un'autenticazione “basata sul contenuto”, a differenza dello SPF “basato sul percorso”.
L'entità responsabile afferma la propria responsabilità “firmando” il messaggio con una coppia di hash crittografici inseriti nell'intestazione di un messaggio.
La validazione DKIM viene eseguita dal dominio ricevente che tenta di generare gli stessi due hash.
La validazione DKIM non può essere completata in molti casi fino a quando l'intero messaggio non è stato trasmesso dal server di invio.
Le anomalie nella validazione possono essere difficili da risolvere.
Contrariamente al suo controparte di autenticazione SPF, che fornisce un modo per un dominio di autorizzare un host a inviare email per conto suo, 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à mittente siano le stesse, o almeno strettamente correlate, con DKIM non c'è alcun requisito che ciò sia così.
I miei obiettivi per te con questo post sono che tu impari e comprenda i seguenti concetti su DKIM:
DKIM è un'autenticazione “basata sul contenuto”, a differenza dello SPF “basato sul percorso”.
L'entità responsabile afferma la propria responsabilità “firmando” il messaggio con una coppia di hash crittografici inseriti nell'intestazione di un messaggio.
La validazione DKIM viene eseguita dal dominio ricevente che tenta di generare gli stessi due hash.
La validazione DKIM non può essere completata in molti casi fino a quando l'intero messaggio non è stato trasmesso dal server di invio.
Le anomalie nella validazione possono essere difficili da risolvere.
Autenticazione basata sul contenuto
DKIM è definito come autenticazione “basata sul contenuto”, piuttosto che “basata sul percorso”, poiché se un messaggio passa o meno la validazione DKIM dipende esclusivamente dal fatto che il contenuto sia cambiato tra il momento in cui è stato firmato e il momento in cui è stata tentata la validazione.
DKIM è definito come autenticazione “basata sul contenuto”, piuttosto che “basata sul percorso”, poiché se un messaggio passa o meno la validazione DKIM dipende esclusivamente dal fatto che il contenuto sia cambiato tra il momento in cui è stato firmato e il momento in cui è stata tentata la validazione.
DKIM è definito come autenticazione “basata sul contenuto”, piuttosto che “basata sul percorso”, poiché se un messaggio passa o meno la validazione DKIM dipende esclusivamente dal fatto che il contenuto sia cambiato tra il momento in cui è stato firmato e il momento in cui è stata tentata la validazione.
Firma e Validazione DKIM
Le organizzazioni che desiderano firmare le email con DKIM genereranno prima due chiavi crittografiche. Una delle chiavi deve rimanere privata e disponibile per il server di invio per la firma delle email, e l'altra deve essere resa pubblica nel DNS per l'uso da parte dei domini riceventi nei tentativi di convalida della 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 DKIM pubblica.
Le organizzazioni che desiderano firmare le email con DKIM genereranno prima due chiavi crittografiche. Una delle chiavi deve rimanere privata e disponibile per il server di invio per la firma delle email, e l'altra deve essere resa pubblica nel DNS per l'uso da parte dei domini riceventi nei tentativi di convalida della 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 DKIM pubblica.
Le organizzazioni che desiderano firmare le email con DKIM genereranno prima due chiavi crittografiche. Una delle chiavi deve rimanere privata e disponibile per il server di invio per la firma delle email, e l'altra deve essere resa pubblica nel DNS per l'uso da parte dei domini riceventi nei tentativi di convalida della 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 DKIM pubblica.
L'intestazione DKIM-Signature
Per iniziare la nostra comprensione di DKIM, guardiamo prima 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 di maggior interesse per il lettore rispetto ad altre, ma descriverò tutte qui.
Per prima cosa, daremo un'occhiata a quelle che sono principalmente di interesse passante per il lettore:
v=1; – Specifica la versione DKIM (1 è l'unico valore valido)
a=rsa-sha256; – L'algoritmo usato 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 quando si creano gli hash in una firma DKIM; queste regole sono chiamate “regole di canonicalizzazione” (da cui la chiave c) e i set di regole sono “relaxed” o “strict”.
t=1454417737; – Il timestamp di quando la firma è stata creata.
Queste tre parti dell'intestazione contengono le informazioni sulla firma:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Questo è l'hash del corpo del messaggio.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Questo è un elenco delle intestazioni utilizzate per creare i dati della firma mostrati di seguito.
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 quando firmano i messaggi.
i=@welcome.foo.com; – Questa è l'identità per conto della quale il messaggio è stato firmato. Syntatticamente, questo avrà l'aspetto di un indirizzo email, e potrebbe anche essere uno; la parte locale dell'indirizzo email può essere vuota, come in questo esempio, e la parte del 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 ad aiutare il ricevente a convalidare le firme.
Campo | Significato | Come lo utilizzano i ricevitori |
|---|---|---|
v= | Versione DKIM (sempre 1) | Conferma il formato della firma |
a= | Algoritmo di hashing + firma (es. rsa-sha256) | Assicura che il validatore riproduca correttamente la firma |
c= | Regole di canonicalizzazione (intestazione/corpo) | Normalizza gli spazi bianchi prima dell'hashing |
t= | Timestamp della creazione della firma | Utilizzato per controlli di freschezza e prevenzione delle ripetizioni |
bh= | Hash del corpo | Il ricevitore rigenera questo per confermare l'integrità del corpo del messaggio |
h= | Elenco delle intestazioni firmate | Assicura che le intestazioni usate nella firma siano disponibili e non modificate |
b= | Firma DKIM effettiva | Il ricevitore verifica questa firma contro la chiave pubblica |
d= | Dominio di firma | Utilizzato per localizzare la chiave pubblica DNS del firmatario |
s= | Selettore | Combinato con il dominio per formare: selector._domainkey.domain |
i= | Identità di firma | Deve essere uguale o un sottodominio di d=, identifica l'entità firmataria |
Per iniziare la nostra comprensione di DKIM, guardiamo prima 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 di maggior interesse per il lettore rispetto ad altre, ma descriverò tutte qui.
Per prima cosa, daremo un'occhiata a quelle che sono principalmente di interesse passante per il lettore:
v=1; – Specifica la versione DKIM (1 è l'unico valore valido)
a=rsa-sha256; – L'algoritmo usato 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 quando si creano gli hash in una firma DKIM; queste regole sono chiamate “regole di canonicalizzazione” (da cui la chiave c) e i set di regole sono “relaxed” o “strict”.
t=1454417737; – Il timestamp di quando la firma è stata creata.
Queste tre parti dell'intestazione contengono le informazioni sulla firma:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Questo è l'hash del corpo del messaggio.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Questo è un elenco delle intestazioni utilizzate per creare i dati della firma mostrati di seguito.
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 quando firmano i messaggi.
i=@welcome.foo.com; – Questa è l'identità per conto della quale il messaggio è stato firmato. Syntatticamente, questo avrà l'aspetto di un indirizzo email, e potrebbe anche essere uno; la parte locale dell'indirizzo email può essere vuota, come in questo esempio, e la parte del 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 ad aiutare il ricevente a convalidare le firme.
Campo | Significato | Come lo utilizzano i ricevitori |
|---|---|---|
v= | Versione DKIM (sempre 1) | Conferma il formato della firma |
a= | Algoritmo di hashing + firma (es. rsa-sha256) | Assicura che il validatore riproduca correttamente la firma |
c= | Regole di canonicalizzazione (intestazione/corpo) | Normalizza gli spazi bianchi prima dell'hashing |
t= | Timestamp della creazione della firma | Utilizzato per controlli di freschezza e prevenzione delle ripetizioni |
bh= | Hash del corpo | Il ricevitore rigenera questo per confermare l'integrità del corpo del messaggio |
h= | Elenco delle intestazioni firmate | Assicura che le intestazioni usate nella firma siano disponibili e non modificate |
b= | Firma DKIM effettiva | Il ricevitore verifica questa firma contro la chiave pubblica |
d= | Dominio di firma | Utilizzato per localizzare la chiave pubblica DNS del firmatario |
s= | Selettore | Combinato con il dominio per formare: selector._domainkey.domain |
i= | Identità di firma | Deve essere uguale o un sottodominio di d=, identifica l'entità firmataria |
Per iniziare la nostra comprensione di DKIM, guardiamo prima 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 di maggior interesse per il lettore rispetto ad altre, ma descriverò tutte qui.
Per prima cosa, daremo un'occhiata a quelle che sono principalmente di interesse passante per il lettore:
v=1; – Specifica la versione DKIM (1 è l'unico valore valido)
a=rsa-sha256; – L'algoritmo usato 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 quando si creano gli hash in una firma DKIM; queste regole sono chiamate “regole di canonicalizzazione” (da cui la chiave c) e i set di regole sono “relaxed” o “strict”.
t=1454417737; – Il timestamp di quando la firma è stata creata.
Queste tre parti dell'intestazione contengono le informazioni sulla firma:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Questo è l'hash del corpo del messaggio.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Questo è un elenco delle intestazioni utilizzate per creare i dati della firma mostrati di seguito.
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 quando firmano i messaggi.
i=@welcome.foo.com; – Questa è l'identità per conto della quale il messaggio è stato firmato. Syntatticamente, questo avrà l'aspetto di un indirizzo email, e potrebbe anche essere uno; la parte locale dell'indirizzo email può essere vuota, come in questo esempio, e la parte del 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 ad aiutare il ricevente a convalidare le firme.
Campo | Significato | Come lo utilizzano i ricevitori |
|---|---|---|
v= | Versione DKIM (sempre 1) | Conferma il formato della firma |
a= | Algoritmo di hashing + firma (es. rsa-sha256) | Assicura che il validatore riproduca correttamente la firma |
c= | Regole di canonicalizzazione (intestazione/corpo) | Normalizza gli spazi bianchi prima dell'hashing |
t= | Timestamp della creazione della firma | Utilizzato per controlli di freschezza e prevenzione delle ripetizioni |
bh= | Hash del corpo | Il ricevitore rigenera questo per confermare l'integrità del corpo del messaggio |
h= | Elenco delle intestazioni firmate | Assicura che le intestazioni usate nella firma siano disponibili e non modificate |
b= | Firma DKIM effettiva | Il ricevitore verifica questa firma contro la chiave pubblica |
d= | Dominio di firma | Utilizzato per localizzare la chiave pubblica DNS del firmatario |
s= | Selettore | Combinato con il dominio per formare: selector._domainkey.domain |
i= | Identità di firma | Deve essere uguale o un sottodominio di d=, identifica l'entità firmataria |
Validazione DKIM
Oltre al requisito menzionato che il dominio i= deve essere lo stesso o un sottodominio del dominio d=, le parti d= e s= vengono utilizzate dal validatore per cercare la chiave DKIM pubblica del firmatario in DNS. La chiave è un record TXT in DNS e si trova sempre nella posizione selector._domainkey.domain. Quindi, nel nostro esempio qui, con s=notices e d=welcome.foo.com, la chiave DKIM pubblica sarebbe trovata in DNS presso notices._domainkey.welcome.foo.com, e potrebbe apparire qualcosa del genere:
notices._domainkey.welcome.foo.com. descriptive text "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 insieme di hash del messaggio; se quegli hash corrispondono, allora il messaggio non è stato alterato durante il transito, e quindi il messaggio può contribuire e forse beneficiare di qualsiasi reputazione sia in atto per il firmatario del messaggio.
Oltre al requisito menzionato che il dominio i= deve essere lo stesso o un sottodominio del dominio d=, le parti d= e s= vengono utilizzate dal validatore per cercare la chiave DKIM pubblica del firmatario in DNS. La chiave è un record TXT in DNS e si trova sempre nella posizione selector._domainkey.domain. Quindi, nel nostro esempio qui, con s=notices e d=welcome.foo.com, la chiave DKIM pubblica sarebbe trovata in DNS presso notices._domainkey.welcome.foo.com, e potrebbe apparire qualcosa del genere:
notices._domainkey.welcome.foo.com. descriptive text "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 insieme di hash del messaggio; se quegli hash corrispondono, allora il messaggio non è stato alterato durante il transito, e quindi il messaggio può contribuire e forse beneficiare di qualsiasi reputazione sia in atto per il firmatario del messaggio.
Oltre al requisito menzionato che il dominio i= deve essere lo stesso o un sottodominio del dominio d=, le parti d= e s= vengono utilizzate dal validatore per cercare la chiave DKIM pubblica del firmatario in DNS. La chiave è un record TXT in DNS e si trova sempre nella posizione selector._domainkey.domain. Quindi, nel nostro esempio qui, con s=notices e d=welcome.foo.com, la chiave DKIM pubblica sarebbe trovata in DNS presso notices._domainkey.welcome.foo.com, e potrebbe apparire qualcosa del genere:
notices._domainkey.welcome.foo.com. descriptive text "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 insieme di hash del messaggio; se quegli hash corrispondono, allora il messaggio non è stato alterato durante il transito, e quindi il messaggio può contribuire e forse beneficiare di qualsiasi reputazione sia in atto per il firmatario del messaggio.
Errore di convalida e risoluzione dei problemi
Ho menzionato sopra che i fallimenti di DKIM possono essere difficili da risolvere, e spiegherò perché è così qui.
Alcuni fallimenti di convalida DKIM hanno cause ovvie, come il messaggio non firmato, la chiave pubblica del dominio di firma non trovata nel DNS o non sintatticamente corretta, o forse il messaggio è stato ovviamente alterato durante il transito. Quando si verificano quel tipo di fallimenti, è facile capire il problema e raccomandare una soluzione. Quelli difficili, però, e quelli che portano alla parte di supporto più frustrante, sono i casi in cui il messaggio è stato firmato, la chiave pubblica esiste nel DNS, e il messaggio non è stato ovviamente alterato, ma il validatore riporta che la firma non è riuscita a convalidare.
Il motivo per cui questi sono difficili da risolvere è che non c'è un vero modo per nessuna delle due parti di riprodurre le condizioni sotto le quali il messaggio è stato firmato e convalidato. Il messaggio ha nel suo'intestazione DKIM-Signature gli hash che sono stati generati dal firmatario al momento della firma, ma il validatore probabilmente non ha accesso all'infrastruttura del firmatario e quindi non può provare a riprodurre la firma nelle condizioni del firmatario. Allo stesso modo, il firmatario probabilmente non ha accesso all'infrastruttura del validatore e quindi non ha modo di provare a convalidare il messaggio nel modo in cui lo ha fatto il validatore.
Fallimenti come quelli che sto descrivendo qui sono eventi rari, e i fallimenti di convalida DKIM da soli di solito non hanno un impatto sul posizionamento della consegna. Mentre DKIM gestisce l'autenticazione dei messaggi, l'implementazione di tecniche di convalida e-mail complete assicura che stai inviando a indirizzi legittimi che possono effettivamente ricevere e autenticare i tuoi messaggi. È stata la mia esperienza che tali fallimenti generano più ticket di supporto rispetto a qualsiasi altro tipo di problema DKIM.
Ho menzionato sopra che i fallimenti di DKIM possono essere difficili da risolvere, e spiegherò perché è così qui.
Alcuni fallimenti di convalida DKIM hanno cause ovvie, come il messaggio non firmato, la chiave pubblica del dominio di firma non trovata nel DNS o non sintatticamente corretta, o forse il messaggio è stato ovviamente alterato durante il transito. Quando si verificano quel tipo di fallimenti, è facile capire il problema e raccomandare una soluzione. Quelli difficili, però, e quelli che portano alla parte di supporto più frustrante, sono i casi in cui il messaggio è stato firmato, la chiave pubblica esiste nel DNS, e il messaggio non è stato ovviamente alterato, ma il validatore riporta che la firma non è riuscita a convalidare.
Il motivo per cui questi sono difficili da risolvere è che non c'è un vero modo per nessuna delle due parti di riprodurre le condizioni sotto le quali il messaggio è stato firmato e convalidato. Il messaggio ha nel suo'intestazione DKIM-Signature gli hash che sono stati generati dal firmatario al momento della firma, ma il validatore probabilmente non ha accesso all'infrastruttura del firmatario e quindi non può provare a riprodurre la firma nelle condizioni del firmatario. Allo stesso modo, il firmatario probabilmente non ha accesso all'infrastruttura del validatore e quindi non ha modo di provare a convalidare il messaggio nel modo in cui lo ha fatto il validatore.
Fallimenti come quelli che sto descrivendo qui sono eventi rari, e i fallimenti di convalida DKIM da soli di solito non hanno un impatto sul posizionamento della consegna. Mentre DKIM gestisce l'autenticazione dei messaggi, l'implementazione di tecniche di convalida e-mail complete assicura che stai inviando a indirizzi legittimi che possono effettivamente ricevere e autenticare i tuoi messaggi. È stata la mia esperienza che tali fallimenti generano più ticket di supporto rispetto a qualsiasi altro tipo di problema DKIM.
Ho menzionato sopra che i fallimenti di DKIM possono essere difficili da risolvere, e spiegherò perché è così qui.
Alcuni fallimenti di convalida DKIM hanno cause ovvie, come il messaggio non firmato, la chiave pubblica del dominio di firma non trovata nel DNS o non sintatticamente corretta, o forse il messaggio è stato ovviamente alterato durante il transito. Quando si verificano quel tipo di fallimenti, è facile capire il problema e raccomandare una soluzione. Quelli difficili, però, e quelli che portano alla parte di supporto più frustrante, sono i casi in cui il messaggio è stato firmato, la chiave pubblica esiste nel DNS, e il messaggio non è stato ovviamente alterato, ma il validatore riporta che la firma non è riuscita a convalidare.
Il motivo per cui questi sono difficili da risolvere è che non c'è un vero modo per nessuna delle due parti di riprodurre le condizioni sotto le quali il messaggio è stato firmato e convalidato. Il messaggio ha nel suo'intestazione DKIM-Signature gli hash che sono stati generati dal firmatario al momento della firma, ma il validatore probabilmente non ha accesso all'infrastruttura del firmatario e quindi non può provare a riprodurre la firma nelle condizioni del firmatario. Allo stesso modo, il firmatario probabilmente non ha accesso all'infrastruttura del validatore e quindi non ha modo di provare a convalidare il messaggio nel modo in cui lo ha fatto il validatore.
Fallimenti come quelli che sto descrivendo qui sono eventi rari, e i fallimenti di convalida DKIM da soli di solito non hanno un impatto sul posizionamento della consegna. Mentre DKIM gestisce l'autenticazione dei messaggi, l'implementazione di tecniche di convalida e-mail complete assicura che stai inviando a indirizzi legittimi che possono effettivamente ricevere e autenticare i tuoi messaggi. È stata la mia esperienza che tali fallimenti generano più ticket di supporto rispetto a qualsiasi altro tipo di problema DKIM.
