Validation DKIM : une meilleure pratique d'authentification des emails
Oiseau
8 avr. 2017
1 min read
Points Clés
DKIM (DomainKeys Identified Mail) est une méthode d'authentification de courrier électronique basée sur le contenu qui vérifie si un message a été altéré après avoir été signé.
Contrairement à SPF, qui valide le chemin d'envoi, DKIM valide le contenu du message lui-même en utilisant des signatures cryptographiques.
DKIM utilise deux clés : une clé privée pour signer les messages sortants et une clé publique publiée dans DNS pour que les récepteurs puissent valider les signatures.
Une signature DKIM inclut des hachages à la fois des en-têtes et du corps, des sélecteurs, des horodatages et des champs d'identité — que le récepteur doit reproduire et vérifier.
La validation DKIM repose sur la réception de l'intégralité du message en premier, ce qui signifie que des échecs peuvent survenir tard dans le processus.
Le dépannage des validations DKIM échouées est souvent difficile car les expéditeurs et les récepteurs ne peuvent pas reproduire les environnements de signature/vérification des uns et des autres.
Même lorsque DKIM échoue, cela ne cause généralement pas directement de problèmes d'acheminement vers la boîte de réception à moins d'être combiné avec d'autres signaux de mauvaise réputation.
Points forts des Q&A
Que fait réellement DKIM ?
DKIM ajoute une signature cryptographique à un e-mail, permettant au serveur destinataire de confirmer si le contenu du message a été modifié après son envoi.
Comment DKIM est-il différent de SPF ?
SPF valide qui est autorisé à envoyer du courrier pour un domaine (basé sur le chemin).
DKIM valide si le contenu est intact (basé sur le contenu).
Les deux ont des objectifs différents et se complètent mutuellement.
Qu'est-ce qui se trouve dans un en-tête DKIM-Signature ?
Les champs clés incluent :
v= version
a= algorithme
c= règles de canonicalisation
d= domaine de signature
s= sélecteur
h= en-têtes inclus dans la signature
bh= hachage du corps
b= données de signature réelles
Chaque partie contribue à la façon dont la signature est validée.
Comment un serveur récepteur valide-t-il DKIM ?
Extrait les valeurs d= et s=.
Recherche la clé publique à :
selector._domainkey.domain
Régénère les hachages de l'en-tête et du corps.
Les compare aux valeurs bh= et b= dans l'e-mail.
S'ils correspondent, le message passe DKIM.
Quelles sont les causes de l'échec du DKIM ?
Message modifié en transit (même les changements d'espacement si vous utilisez une canonisation stricte)
Clé publique incorrecte ou manquante dans le DNS
Erreurs de formatage DNS
Sélecteur supprimé ou tourné incorrectement
Identités incompatibles (i= doit être le même domaine ou sous-domaine de d=)
Pourquoi les échecs DKIM peuvent-ils être difficiles à résoudre ?
Parce que le signataire et le validateur opèrent dans des environnements complètement différents — aucune des deux parties ne peut reconstruire les conditions de hachage ou l'état de signature de l'autre.
Cela rend les échecs opaques de "défaut de correspondance de hachage" les plus frustrants à diagnostiquer.
Un échec DKIM signifie-t-il que l'email ira dans les spams ?
Pas nécessairement.
DKIM est juste un signal. Si le domaine a une bonne réputation et passe d'autres vérifications (SPF, alignement DMARC, faibles taux de plaintes), les échecs de DKIM isolés n'ont généralement pas d'impact sur l'inboxing par eux-mêmes.
Pourquoi utiliser DKIM du tout?
Protège l'intégrité des messages
Construit la réputation de domaine
Permet l'alignement DMARC
Aide les fournisseurs de boîtes à distinguer les expéditeurs légitimes des usurpateurs
DKIM est considéré une bonne pratique pour tous les expéditeurs d'email sérieux.
Lorsque nous parlons d'« Email Authentication », nous faisons référence à une technique qui offre au destinataire d'un message un certain niveau de certitude que le message provient effectivement de la source revendiquée du message. L'idée derrière de telles techniques est d'atteindre un certain niveau de défense contre les emails frauduleux, tels que le phishing et l'usurpation, des courriels qui pourraient éroder la confiance du destinataire dans la réception des emails. Cela dit, l'envoi d'un email authentifié n'affirme pas que l'email est bon ou souhaité ; cela signifie seulement que le courrier est tel qu'une réputation pour la partie authentifiée peut être établie de manière fiable et utilisée dans les décisions d'acceptation et de placement des emails.
Il existe aujourd'hui deux formes d'authentification des emails :
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dans l'article d'aujourd'hui, je vais couvrir ce qu'est DKIM et comment cela fonctionne.
Lorsque nous parlons d'« Email Authentication », nous faisons référence à une technique qui offre au destinataire d'un message un certain niveau de certitude que le message provient effectivement de la source revendiquée du message. L'idée derrière de telles techniques est d'atteindre un certain niveau de défense contre les emails frauduleux, tels que le phishing et l'usurpation, des courriels qui pourraient éroder la confiance du destinataire dans la réception des emails. Cela dit, l'envoi d'un email authentifié n'affirme pas que l'email est bon ou souhaité ; cela signifie seulement que le courrier est tel qu'une réputation pour la partie authentifiée peut être établie de manière fiable et utilisée dans les décisions d'acceptation et de placement des emails.
Il existe aujourd'hui deux formes d'authentification des emails :
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dans l'article d'aujourd'hui, je vais couvrir ce qu'est DKIM et comment cela fonctionne.
Lorsque nous parlons d'« Email Authentication », nous faisons référence à une technique qui offre au destinataire d'un message un certain niveau de certitude que le message provient effectivement de la source revendiquée du message. L'idée derrière de telles techniques est d'atteindre un certain niveau de défense contre les emails frauduleux, tels que le phishing et l'usurpation, des courriels qui pourraient éroder la confiance du destinataire dans la réception des emails. Cela dit, l'envoi d'un email authentifié n'affirme pas que l'email est bon ou souhaité ; cela signifie seulement que le courrier est tel qu'une réputation pour la partie authentifiée peut être établie de manière fiable et utilisée dans les décisions d'acceptation et de placement des emails.
Il existe aujourd'hui deux formes d'authentification des emails :
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dans l'article d'aujourd'hui, je vais couvrir ce qu'est DKIM et comment cela fonctionne.
Aperçu de DKIM
Contrairement à son homologue d'authentification SPF, qui fournit un moyen pour un domaine d'autoriser un hôte à envoyer du courrier en son nom, DKIM offre un moyen pour une entité (domaine, organisation, personne, etc.) de prendre la responsabilité d'un message, indépendamment de l'entité qui a effectivement envoyé le message. Bien que dans de nombreux cas l'entité responsable et l'entité émettrice soient les mêmes, ou du moins étroitement liées, avec DKIM il n'y a aucune exigence pour que ce soit le cas.
Mes objectifs pour vous avec cet article sont que vous appreniez et compreniez les concepts suivants concernant DKIM :
DKIM est une authentification « basée sur le contenu », contrairement à SPF qui est « basé sur le chemin ».
L'entité responsable affirme sa responsabilité en « signant » le message avec une paire de hachages cryptographiques insérés dans un en-tête de message.
La validation DKIM est effectuée par le domaine récepteur qui tente de générer les deux mêmes hachages.
La validation DKIM ne peut pas être complétée dans de nombreux cas jusqu'à ce que le message complet ait été transmis par le serveur d'envoi.
Les échecs de validation peuvent être difficiles à dépanner.
Contrairement à son homologue d'authentification SPF, qui fournit un moyen pour un domaine d'autoriser un hôte à envoyer du courrier en son nom, DKIM offre un moyen pour une entité (domaine, organisation, personne, etc.) de prendre la responsabilité d'un message, indépendamment de l'entité qui a effectivement envoyé le message. Bien que dans de nombreux cas l'entité responsable et l'entité émettrice soient les mêmes, ou du moins étroitement liées, avec DKIM il n'y a aucune exigence pour que ce soit le cas.
Mes objectifs pour vous avec cet article sont que vous appreniez et compreniez les concepts suivants concernant DKIM :
DKIM est une authentification « basée sur le contenu », contrairement à SPF qui est « basé sur le chemin ».
L'entité responsable affirme sa responsabilité en « signant » le message avec une paire de hachages cryptographiques insérés dans un en-tête de message.
La validation DKIM est effectuée par le domaine récepteur qui tente de générer les deux mêmes hachages.
La validation DKIM ne peut pas être complétée dans de nombreux cas jusqu'à ce que le message complet ait été transmis par le serveur d'envoi.
Les échecs de validation peuvent être difficiles à dépanner.
Contrairement à son homologue d'authentification SPF, qui fournit un moyen pour un domaine d'autoriser un hôte à envoyer du courrier en son nom, DKIM offre un moyen pour une entité (domaine, organisation, personne, etc.) de prendre la responsabilité d'un message, indépendamment de l'entité qui a effectivement envoyé le message. Bien que dans de nombreux cas l'entité responsable et l'entité émettrice soient les mêmes, ou du moins étroitement liées, avec DKIM il n'y a aucune exigence pour que ce soit le cas.
Mes objectifs pour vous avec cet article sont que vous appreniez et compreniez les concepts suivants concernant DKIM :
DKIM est une authentification « basée sur le contenu », contrairement à SPF qui est « basé sur le chemin ».
L'entité responsable affirme sa responsabilité en « signant » le message avec une paire de hachages cryptographiques insérés dans un en-tête de message.
La validation DKIM est effectuée par le domaine récepteur qui tente de générer les deux mêmes hachages.
La validation DKIM ne peut pas être complétée dans de nombreux cas jusqu'à ce que le message complet ait été transmis par le serveur d'envoi.
Les échecs de validation peuvent être difficiles à dépanner.
Authentification « Content-Based »
DKIM est considéré comme une authentification « basée sur le contenu », plutôt que « basée sur le chemin », car le passage ou non d'un message à la validation DKIM dépend uniquement du fait que le contenu ait changé ou non entre le moment où il a été signé et le moment où la validation a été tentée.
DKIM est considéré comme une authentification « basée sur le contenu », plutôt que « basée sur le chemin », car le passage ou non d'un message à la validation DKIM dépend uniquement du fait que le contenu ait changé ou non entre le moment où il a été signé et le moment où la validation a été tentée.
DKIM est considéré comme une authentification « basée sur le contenu », plutôt que « basée sur le chemin », car le passage ou non d'un message à la validation DKIM dépend uniquement du fait que le contenu ait changé ou non entre le moment où il a été signé et le moment où la validation a été tentée.
DKIM Signing et Validation
Les organisations souhaitant signer des courriels avec DKIM généreront d'abord deux clés cryptographiques. L'une des clés est conservée privée et disponible pour le serveur d'envoi afin de signer les courriels, et l'autre doit être rendue publique dans le DNS pour être utilisée par les domaines récepteurs tentant de valider la signature. Les méthodes pour générer ces clés et les installer dépendent de la plateforme et dépassent le cadre de ce post, bien que plus tard je décrirai la publication dans le DNS de la clé publique DKIM.
Les organisations souhaitant signer des courriels avec DKIM généreront d'abord deux clés cryptographiques. L'une des clés est conservée privée et disponible pour le serveur d'envoi afin de signer les courriels, et l'autre doit être rendue publique dans le DNS pour être utilisée par les domaines récepteurs tentant de valider la signature. Les méthodes pour générer ces clés et les installer dépendent de la plateforme et dépassent le cadre de ce post, bien que plus tard je décrirai la publication dans le DNS de la clé publique DKIM.
Les organisations souhaitant signer des courriels avec DKIM généreront d'abord deux clés cryptographiques. L'une des clés est conservée privée et disponible pour le serveur d'envoi afin de signer les courriels, et l'autre doit être rendue publique dans le DNS pour être utilisée par les domaines récepteurs tentant de valider la signature. Les méthodes pour générer ces clés et les installer dépendent de la plateforme et dépassent le cadre de ce post, bien que plus tard je décrirai la publication dans le DNS de la clé publique DKIM.
L'en-tête DKIM-Signature
Pour commencer notre compréhension de DKIM, examinons d'abord un en-tête 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'en-tête DKIM-Signature est une série de paires clé-valeur, certaines étant plus intéressantes pour le lecteur que d'autres, mais je vais toutes les décrire ici.
Tout d'abord, nous allons examiner celles qui présentent un intérêt passager pour le lecteur :
v=1; – Spécifie la version DKIM (1 est la seule valeur valide)
a=rsa-sha256; – L'algorithme utilisé pour construire les hachages cryptographiques
c=relaxed/relaxed; – Il existe deux ensembles de règles concernant la suppression des espaces dans les en-têtes et le corps qui peuvent être appliqués lors de la création des hachages dans une signature DKIM ; ces règles sont appelées "règles de canonicalisation" (d'où la clé c) et les ensembles de règles sont soit « relaxés » soit « stricts ».
t=1454417737; – L'horodatage de création de la signature.
Ces trois parties de l'en-tête contiennent les informations de signature réelles :
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Il s'agit du hachage du corps du message.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Il s'agit d'une liste des en-têtes utilisés pour créer les données de signature affichées ci-dessous.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Il s'agit des données de signature DKIM réelles
Ces trois parties sont d'un grand intérêt pour le serveur récepteur qui validera la signature :
d=welcome.foo.com; – Cela identifie le domaine qui a signé le message
s=notices; – Le sélecteur ; les domaines peuvent avoir plusieurs sélecteurs qu'ils utilisent pour signer des messages.
i=@welcome.foo.com; – Il s'agit de l'identité pour le compte de laquelle le message a été signé. Syntaxiquement, cela ressemblera à une adresse e-mail, et pourrait même en être une ; la partie locale de l'adresse e-mail peut être vide, comme dans cet exemple, et la partie domaine doit être la même que, ou un sous-domaine de, le domaine dans la partie d= de la signature.
La raison pour laquelle ces parties intéressent le serveur récepteur est qu'elles fournissent les informations nécessaires pour aider le récepteur à valider les signatures.
Pour commencer notre compréhension de DKIM, examinons d'abord un en-tête 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'en-tête DKIM-Signature est une série de paires clé-valeur, certaines étant plus intéressantes pour le lecteur que d'autres, mais je vais toutes les décrire ici.
Tout d'abord, nous allons examiner celles qui présentent un intérêt passager pour le lecteur :
v=1; – Spécifie la version DKIM (1 est la seule valeur valide)
a=rsa-sha256; – L'algorithme utilisé pour construire les hachages cryptographiques
c=relaxed/relaxed; – Il existe deux ensembles de règles concernant la suppression des espaces dans les en-têtes et le corps qui peuvent être appliqués lors de la création des hachages dans une signature DKIM ; ces règles sont appelées "règles de canonicalisation" (d'où la clé c) et les ensembles de règles sont soit « relaxés » soit « stricts ».
t=1454417737; – L'horodatage de création de la signature.
Ces trois parties de l'en-tête contiennent les informations de signature réelles :
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Il s'agit du hachage du corps du message.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Il s'agit d'une liste des en-têtes utilisés pour créer les données de signature affichées ci-dessous.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Il s'agit des données de signature DKIM réelles
Ces trois parties sont d'un grand intérêt pour le serveur récepteur qui validera la signature :
d=welcome.foo.com; – Cela identifie le domaine qui a signé le message
s=notices; – Le sélecteur ; les domaines peuvent avoir plusieurs sélecteurs qu'ils utilisent pour signer des messages.
i=@welcome.foo.com; – Il s'agit de l'identité pour le compte de laquelle le message a été signé. Syntaxiquement, cela ressemblera à une adresse e-mail, et pourrait même en être une ; la partie locale de l'adresse e-mail peut être vide, comme dans cet exemple, et la partie domaine doit être la même que, ou un sous-domaine de, le domaine dans la partie d= de la signature.
La raison pour laquelle ces parties intéressent le serveur récepteur est qu'elles fournissent les informations nécessaires pour aider le récepteur à valider les signatures.
Pour commencer notre compréhension de DKIM, examinons d'abord un en-tête 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'en-tête DKIM-Signature est une série de paires clé-valeur, certaines étant plus intéressantes pour le lecteur que d'autres, mais je vais toutes les décrire ici.
Tout d'abord, nous allons examiner celles qui présentent un intérêt passager pour le lecteur :
v=1; – Spécifie la version DKIM (1 est la seule valeur valide)
a=rsa-sha256; – L'algorithme utilisé pour construire les hachages cryptographiques
c=relaxed/relaxed; – Il existe deux ensembles de règles concernant la suppression des espaces dans les en-têtes et le corps qui peuvent être appliqués lors de la création des hachages dans une signature DKIM ; ces règles sont appelées "règles de canonicalisation" (d'où la clé c) et les ensembles de règles sont soit « relaxés » soit « stricts ».
t=1454417737; – L'horodatage de création de la signature.
Ces trois parties de l'en-tête contiennent les informations de signature réelles :
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Il s'agit du hachage du corps du message.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Il s'agit d'une liste des en-têtes utilisés pour créer les données de signature affichées ci-dessous.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Il s'agit des données de signature DKIM réelles
Ces trois parties sont d'un grand intérêt pour le serveur récepteur qui validera la signature :
d=welcome.foo.com; – Cela identifie le domaine qui a signé le message
s=notices; – Le sélecteur ; les domaines peuvent avoir plusieurs sélecteurs qu'ils utilisent pour signer des messages.
i=@welcome.foo.com; – Il s'agit de l'identité pour le compte de laquelle le message a été signé. Syntaxiquement, cela ressemblera à une adresse e-mail, et pourrait même en être une ; la partie locale de l'adresse e-mail peut être vide, comme dans cet exemple, et la partie domaine doit être la même que, ou un sous-domaine de, le domaine dans la partie d= de la signature.
La raison pour laquelle ces parties intéressent le serveur récepteur est qu'elles fournissent les informations nécessaires pour aider le récepteur à valider les signatures.
DKIM Validation
En plus de l'exigence mentionnée selon laquelle le domaine i= doit être identique ou un sous-domaine du domaine d=, les bits d= et s= sont utilisés par le validateur pour rechercher la clé DKIM publique du signataire dans le DNS. La clé est un enregistrement TXT dans le DNS, et elle se trouve toujours à l'emplacement selector._domainkey.domain. Donc, dans notre exemple ici, avec s=notices et d=welcome.foo.com, la clé DKIM publique serait trouvée dans le DNS à notices._domainkey.welcome.foo.com, et elle pourrait ressembler à ceci :
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Le validateur utilise cette clé (les bits p=) pour produire son propre ensemble de hachages du message ; si ces hachages correspondent, cela signifie que le message n’a pas été altéré en transit, et donc le message peut contribuer à, et peut-être bénéficier de, la réputation en place pour le signataire du message.
En plus de l'exigence mentionnée selon laquelle le domaine i= doit être identique ou un sous-domaine du domaine d=, les bits d= et s= sont utilisés par le validateur pour rechercher la clé DKIM publique du signataire dans le DNS. La clé est un enregistrement TXT dans le DNS, et elle se trouve toujours à l'emplacement selector._domainkey.domain. Donc, dans notre exemple ici, avec s=notices et d=welcome.foo.com, la clé DKIM publique serait trouvée dans le DNS à notices._domainkey.welcome.foo.com, et elle pourrait ressembler à ceci :
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Le validateur utilise cette clé (les bits p=) pour produire son propre ensemble de hachages du message ; si ces hachages correspondent, cela signifie que le message n’a pas été altéré en transit, et donc le message peut contribuer à, et peut-être bénéficier de, la réputation en place pour le signataire du message.
En plus de l'exigence mentionnée selon laquelle le domaine i= doit être identique ou un sous-domaine du domaine d=, les bits d= et s= sont utilisés par le validateur pour rechercher la clé DKIM publique du signataire dans le DNS. La clé est un enregistrement TXT dans le DNS, et elle se trouve toujours à l'emplacement selector._domainkey.domain. Donc, dans notre exemple ici, avec s=notices et d=welcome.foo.com, la clé DKIM publique serait trouvée dans le DNS à notices._domainkey.welcome.foo.com, et elle pourrait ressembler à ceci :
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Le validateur utilise cette clé (les bits p=) pour produire son propre ensemble de hachages du message ; si ces hachages correspondent, cela signifie que le message n’a pas été altéré en transit, et donc le message peut contribuer à, et peut-être bénéficier de, la réputation en place pour le signataire du message.
Échec de validation et dépannage
J'ai mentionné plus haut que les échecs de DKIM peuvent être difficiles à dépanner, et je vais expliquer pourquoi c'est le cas ici.
Certains échecs de validation DKIM ont des causes évidentes, telles que le message n'étant pas signé, ou la clé publique du domaine de signature n'étant pas trouvée dans le DNS ou n'étant pas syntaxiquement correcte, ou peut-être que le message a été visiblement altéré pendant le transit. Lorsque ces types d'échecs se produisent, il est facile de déterminer le problème et de recommander une solution. Les plus difficiles, cependant, et ceux qui conduisent à l'expérience de support la plus frustrante, sont les cas où le message a été signé, la clé publique existe dans le DNS, et le message n'a pas été visiblement altéré, mais le validateur rapporte que la signature a échoué à valider.
La raison pour laquelle il est difficile de dépanner ces problèmes est qu'il n'y a pas de réelle façon pour chaque côté de reproduire les conditions sous lesquelles le message a été signé et validé. Le message a dans son en-tête DKIM-Signature les hachages qui ont été générés par le signataire au moment de la signature, mais le validateur n'a probablement pas accès à l'infrastructure du signataire et ne peut donc pas essayer de reproduire la signature dans les conditions du signataire. De même, le signataire n'a probablement pas accès à l'infrastructure du validateur et n'a donc aucun moyen d'essayer de valider le message de la manière dont le validateur l'a fait.
Les échecs comme ceux que je décris ici sont des occurrences rares, et les échecs de validation DKIM en eux-mêmes n’ont généralement pas d’impact sur le placement dans la livraison. Bien que DKIM gère l'authentification des messages, la mise en œuvre de techniques de validation de courriel complètes garantit que vous envoyez à des adresses légitimes qui peuvent réellement recevoir et authentifier vos messages. Il m'est apparu que ces échecs génèrent plus de tickets de support que tout autre type de problème DKIM.
J'ai mentionné plus haut que les échecs de DKIM peuvent être difficiles à dépanner, et je vais expliquer pourquoi c'est le cas ici.
Certains échecs de validation DKIM ont des causes évidentes, telles que le message n'étant pas signé, ou la clé publique du domaine de signature n'étant pas trouvée dans le DNS ou n'étant pas syntaxiquement correcte, ou peut-être que le message a été visiblement altéré pendant le transit. Lorsque ces types d'échecs se produisent, il est facile de déterminer le problème et de recommander une solution. Les plus difficiles, cependant, et ceux qui conduisent à l'expérience de support la plus frustrante, sont les cas où le message a été signé, la clé publique existe dans le DNS, et le message n'a pas été visiblement altéré, mais le validateur rapporte que la signature a échoué à valider.
La raison pour laquelle il est difficile de dépanner ces problèmes est qu'il n'y a pas de réelle façon pour chaque côté de reproduire les conditions sous lesquelles le message a été signé et validé. Le message a dans son en-tête DKIM-Signature les hachages qui ont été générés par le signataire au moment de la signature, mais le validateur n'a probablement pas accès à l'infrastructure du signataire et ne peut donc pas essayer de reproduire la signature dans les conditions du signataire. De même, le signataire n'a probablement pas accès à l'infrastructure du validateur et n'a donc aucun moyen d'essayer de valider le message de la manière dont le validateur l'a fait.
Les échecs comme ceux que je décris ici sont des occurrences rares, et les échecs de validation DKIM en eux-mêmes n’ont généralement pas d’impact sur le placement dans la livraison. Bien que DKIM gère l'authentification des messages, la mise en œuvre de techniques de validation de courriel complètes garantit que vous envoyez à des adresses légitimes qui peuvent réellement recevoir et authentifier vos messages. Il m'est apparu que ces échecs génèrent plus de tickets de support que tout autre type de problème DKIM.
J'ai mentionné plus haut que les échecs de DKIM peuvent être difficiles à dépanner, et je vais expliquer pourquoi c'est le cas ici.
Certains échecs de validation DKIM ont des causes évidentes, telles que le message n'étant pas signé, ou la clé publique du domaine de signature n'étant pas trouvée dans le DNS ou n'étant pas syntaxiquement correcte, ou peut-être que le message a été visiblement altéré pendant le transit. Lorsque ces types d'échecs se produisent, il est facile de déterminer le problème et de recommander une solution. Les plus difficiles, cependant, et ceux qui conduisent à l'expérience de support la plus frustrante, sont les cas où le message a été signé, la clé publique existe dans le DNS, et le message n'a pas été visiblement altéré, mais le validateur rapporte que la signature a échoué à valider.
La raison pour laquelle il est difficile de dépanner ces problèmes est qu'il n'y a pas de réelle façon pour chaque côté de reproduire les conditions sous lesquelles le message a été signé et validé. Le message a dans son en-tête DKIM-Signature les hachages qui ont été générés par le signataire au moment de la signature, mais le validateur n'a probablement pas accès à l'infrastructure du signataire et ne peut donc pas essayer de reproduire la signature dans les conditions du signataire. De même, le signataire n'a probablement pas accès à l'infrastructure du validateur et n'a donc aucun moyen d'essayer de valider le message de la manière dont le validateur l'a fait.
Les échecs comme ceux que je décris ici sont des occurrences rares, et les échecs de validation DKIM en eux-mêmes n’ont généralement pas d’impact sur le placement dans la livraison. Bien que DKIM gère l'authentification des messages, la mise en œuvre de techniques de validation de courriel complètes garantit que vous envoyez à des adresses légitimes qui peuvent réellement recevoir et authentifier vos messages. Il m'est apparu que ces échecs génèrent plus de tickets de support que tout autre type de problème DKIM.
