CUSTOMIZE 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 réellement de la source prétendue du message.
Lorsque nous parlons de « 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 réellement de la source revendiquée du message. L'idée derrière ces techniques est d'obtenir un certain niveau de défense contre les emails frauduleux, tels que le phishing et le spoofing, courrier qui pourrait éroder la confiance d'un destinataire dans la réception d'un email. 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 le billet d'aujourd'hui, je couvre ce qu'est DKIM et comment il 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.
Authentification « Content-Based »
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.
L'en-tête DKIM-Signature
Pour commencer notre compréhension de DKIM, regardons 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 plus intéressantes pour le lecteur que d'autres, mais je vais toutes les décrire ici.
Tout d'abord, examinons celles qui sont principalement d'intérêt secondaire 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 empreintes cryptographiques
c=relaxed/relaxed; – Il existe deux ensembles de règles concernant la suppression des espaces blancs dans les en-têtes et le corps du message qui peuvent être appliqués lors de la création des empreintes 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 « relâchés » soit « stricts ».
t=1454417737; – L'horodatage de la 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 de l'empreinte du corps du message.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Voici une liste des en-têtes utilisés pour créer les données de signature montrées ci-dessous.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Il s'agit des données de signature DKIM réelles
Ces trois parties sont les plus intéressantes 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 lors de la signature des messages.
i=@welcome.foo.com; – C'est 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 le même que ou un sous-domaine du domaine d=, les bits d= et s= sont utilisés par le validateur pour chercher la clé publique DKIM du signataire dans le DNS. La clé est un enregistrement TXT dans le DNS, et elle est toujours trouvée à l'emplacement selector._domainkey.domain. Donc, dans notre exemple ici, avec s=notices et d=welcome.foo.com, la clé publique DKIM serait trouvée dans le DNS à notices._domainkey.welcome.foo.com, et elle pourrait ressembler à ceci :
notices._domainkey.welcome.foo.com. texte descriptif "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, alors le message n'a pas été altéré durant le transit, et ainsi 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.
