Validazione DKIM: Una migliore pratica di autenticazione delle email
Uccello
8 apr 2017
1 min read
Conclusioni principali
DKIM (DomainKeys Identified Mail) è un metodo di autenticazione delle email basato sul contenuto che verifica se un messaggio è stato alterato dopo essere stato firmato.
A differenza di 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 i destinatari per convalidare le firme.
Una firma DKIM include hash sia delle intestazioni che del corpo, selettori, timestamp e campi di identità, tutti elementi che il destinatario deve riprodurre e verificare.
La convalida DKIM si basa sul ricevimento dell'intero messaggio, il che significa che i fallimenti possono verificarsi tardi nel processo.
Risolvere i problemi di convalida DKIM falliti è spesso difficile perché i mittenti e i destinatari non possono riprodurre i rispettivi ambienti di firma/verifica.
Anche quando DKIM fallisce, di solito non causa direttamente problemi di ricezione nella casella di posta a meno che non sia combinato con altri segnali di reputazione negativi.
Q&A Highlights
Che cosa fa effettivamente DKIM?
DKIM allega una firma crittografica a un'email, permettendo al server ricevente 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 posta per un dominio (basato su percorso).
DKIM convalida se il contenuto è integro (basato su contenuto).
Entrambi servono a scopi diversi e si completano a vicenda.
Cosa contiene un'intestazione DKIM-Signature?
I campi chiave includono:
v= version
a= algoritmo
c= regole di canonicalizzazione
d= dominio di firma
s= selettore
h= intestazioni incluse nella firma
bh= hash del corpo
b= dati effettivi della firma
Ogni parte contribuisce a come la firma viene convalidata.
Come fa un server ricevente a convalidare DKIM?
Estrae i valori d= e s=.
Cerca la chiave pubblica su:
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 supera DKIM.
Quali possono essere le cause del fallimento di DKIM?
Messaggio alterato durante il transito (anche cambiamenti di spaziatura se si usa la canonizzazione rigida)
Chiave pubblica errata o mancante 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 problemi 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 di “hash mismatch” 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 passa altri controlli (SPF, DMARC alignment, bassi tassi di reclamo), i fallimenti DKIM isolati tipicamente non influenzano Inboxing da soli.
Perché utilizzare DKIM del tutto?
Protegge l'integrità del messaggio
Costruisce la reputazione del dominio
Abilita l'allineamento DMARC
Aiuta i provider di caselle di posta a distinguere i mittenti legittimi dai falsi
DKIM è considerato una best practice per tutti i mittenti email seri.
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 sia effettivamente originato dalla fonte dichiarata del messaggio. L'idea alla base di tali tecniche è di ottenere un certo livello di difesa contro email fraudolente, come phishing e spoofing, mail che potrebbe erodere la fiducia di un destinatario nel ricevere email. Detto ciò, l'atto di inviare email autenticate non afferma che l'email sia buona o desiderata; significa solo che la mail è tale che una reputazione per la parte autenticata può essere stabilita e utilizzata in modo affidabile nelle decisioni di accettazione e posizionamento delle email.
Oggi sono in uso due forme di autenticazione email:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
Nel post di oggi, sto trattando cosa sia DKIM e come funziona.
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 sia effettivamente originato dalla fonte dichiarata del messaggio. L'idea alla base di tali tecniche è di ottenere un certo livello di difesa contro email fraudolente, come phishing e spoofing, mail che potrebbe erodere la fiducia di un destinatario nel ricevere email. Detto ciò, l'atto di inviare email autenticate non afferma che l'email sia buona o desiderata; significa solo che la mail è tale che una reputazione per la parte autenticata può essere stabilita e utilizzata in modo affidabile nelle decisioni di accettazione e posizionamento delle email.
Oggi sono in uso due forme di autenticazione email:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
Nel post di oggi, sto trattando cosa sia DKIM e come funziona.
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 sia effettivamente originato dalla fonte dichiarata del messaggio. L'idea alla base di tali tecniche è di ottenere un certo livello di difesa contro email fraudolente, come phishing e spoofing, mail che potrebbe erodere la fiducia di un destinatario nel ricevere email. Detto ciò, l'atto di inviare email autenticate non afferma che l'email sia buona o desiderata; significa solo che la mail è tale che una reputazione per la parte autenticata può essere stabilita e utilizzata in modo affidabile nelle decisioni di accettazione e posizionamento delle email.
Oggi sono in uso due forme di autenticazione email:
Sender Policy Framework (SPF)
Domain Keys Identifed 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.
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.
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 è definito come autenticazione "basata sul contenuto", piuttosto che "basata sul percorso", perché il passaggio della validazione DKIM da parte di un messaggio si basa esclusivamente sul 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", perché il passaggio della validazione DKIM da parte di un messaggio si basa esclusivamente sul 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", perché il passaggio della validazione DKIM da parte di un messaggio si basa esclusivamente sul fatto che il contenuto sia cambiato tra il momento in cui è stato firmato e il momento in cui è stata tentata la validazione.
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.
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.
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 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 più interessanti per il lettore rispetto ad altre, ma le descriverò tutte qui.
Per prima cosa, esaminiamo quelle che sono principalmente di interesse passeggero 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 sono chiamate "regole di canonizzazione" (da qui la chiave c) e i set di regole sono o "rilassato" o "rigoroso".
t=1454417737; – La data e ora in cui la firma è stata creata.
Queste tre parti dell'intestazione contengono le informazioni effettive della 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 maggiore interesse per il server ricevente che validerà la firma:
d=welcome.foo.com; – Questo identifica il dominio che ha firmato il messaggio
s=notices; – Il selettore; i domini possono avere selettori multipli che utilizzano per firmare i messaggi.
i=@welcome.foo.com; – Questa è l'identità per conto della quale il messaggio è stato firmato. Sintatticamente, questo assomiglierà a un indirizzo email e potrebbe anche esserlo; 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 per aiutare il destinatario a validare le firme.
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 più interessanti per il lettore rispetto ad altre, ma le descriverò tutte qui.
Per prima cosa, esaminiamo quelle che sono principalmente di interesse passeggero 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 sono chiamate "regole di canonizzazione" (da qui la chiave c) e i set di regole sono o "rilassato" o "rigoroso".
t=1454417737; – La data e ora in cui la firma è stata creata.
Queste tre parti dell'intestazione contengono le informazioni effettive della 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 maggiore interesse per il server ricevente che validerà la firma:
d=welcome.foo.com; – Questo identifica il dominio che ha firmato il messaggio
s=notices; – Il selettore; i domini possono avere selettori multipli che utilizzano per firmare i messaggi.
i=@welcome.foo.com; – Questa è l'identità per conto della quale il messaggio è stato firmato. Sintatticamente, questo assomiglierà a un indirizzo email e potrebbe anche esserlo; 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 per aiutare il destinatario a validare le firme.
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 più interessanti per il lettore rispetto ad altre, ma le descriverò tutte qui.
Per prima cosa, esaminiamo quelle che sono principalmente di interesse passeggero 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 sono chiamate "regole di canonizzazione" (da qui la chiave c) e i set di regole sono o "rilassato" o "rigoroso".
t=1454417737; – La data e ora in cui la firma è stata creata.
Queste tre parti dell'intestazione contengono le informazioni effettive della 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 maggiore interesse per il server ricevente che validerà la firma:
d=welcome.foo.com; – Questo identifica il dominio che ha firmato il messaggio
s=notices; – Il selettore; i domini possono avere selettori multipli che utilizzano per firmare i messaggi.
i=@welcome.foo.com; – Questa è l'identità per conto della quale il messaggio è stato firmato. Sintatticamente, questo assomiglierà a un indirizzo email e potrebbe anche esserlo; 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 per aiutare il destinatario a validare le firme.
DKIM Validation
Oltre al requisito menzionato che il dominio i= deve essere lo stesso di o un sottodominio del dominio d=, i bit d= e s= vengono utilizzati dal validatore per cercare la chiave pubblica DKIM del firmatario nel DNS. La chiave è un record TXT nel 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 pubblica DKIM si troverebbe nel DNS a notices._domainkey.welcome.foo.com e potrebbe apparire in questo modo:
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 set 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, da qualsiasi reputazione in atto per il firmatario del messaggio.
Oltre al requisito menzionato che il dominio i= deve essere lo stesso di o un sottodominio del dominio d=, i bit d= e s= vengono utilizzati dal validatore per cercare la chiave pubblica DKIM del firmatario nel DNS. La chiave è un record TXT nel 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 pubblica DKIM si troverebbe nel DNS a notices._domainkey.welcome.foo.com e potrebbe apparire in questo modo:
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 set 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, da qualsiasi reputazione in atto per il firmatario del messaggio.
Oltre al requisito menzionato che il dominio i= deve essere lo stesso di o un sottodominio del dominio d=, i bit d= e s= vengono utilizzati dal validatore per cercare la chiave pubblica DKIM del firmatario nel DNS. La chiave è un record TXT nel 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 pubblica DKIM si troverebbe nel DNS a notices._domainkey.welcome.foo.com e potrebbe apparire in questo modo:
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 set 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, da qualsiasi reputazione 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.
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.
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.
