Résumé

  • La révision 00 propose un seul résultat DKIM2 pour toute la chaîne du message, accompagné du domaine d’origine et, dans certains échecs, du numéro de la signature en cause.
  • Authentication-Results reste un mémo interne non protégé : il n’a de sens que dans l’ADMD qui l’a produit et ne doit pas être recopié vers le prochain relais.
  • Un header.d présent à côté d’un échec n’est pas forcément une identité authentifiée ; le commentaire par saut sert au diagnostic humain, non à l’automatisation.

Le piège apparaît au moment où tout semble fonctionner. Un premier opérateur vérifie la chaîne DKIM2, ajoute dkim2=pass, puis transmet le message à un second opérateur. Celui-ci voit le mot pass. S’il agit sans refaire la vérification, il ne s’appuie plus sur la chaîne cryptographique, mais sur une ligne de texte héritée d’une autre frontière.

Le projet initial, annoncé le 5 septembre 2026, est précisément construit autour de cette différence. DKIM2 documente une chaîne de prise en charge. Authentication-Results en donne un compte rendu local après le calcul. La preuve peut être revérifiée ; le compte rendu dépend de l’acteur qui l’a écrit et du chemin par lequel il parvient à son lecteur.

Il faut conserver la modestie institutionnelle du texte. La fiche API du Datatracker le classe comme Internet-Draft individuel, sans valeur d’approbation par l’IETF. La source XML fixe le contenu de la révision 00 ; l’annonce I-D fixe sa date et son auteur. L’objectif « Standards Track » indiqué dans le document est une intention, pas un statut acquis.

La proposition transforme les sorties du projet DKIM2 du groupe de travail en un vocabulaire compatible avec RFC 8601. Contrairement à DKIM1, où plusieurs signatures indépendantes peuvent recevoir plusieurs résultats, DKIM2 produit ici un résultat pour le message entier : la chaîne de conservation tient, ou elle ne tient pas. pass, fail, permerror et temperror décrivent une vérification tentée ; none signifie qu’aucune signature DKIM2 n’était présente et qu’aucune vérification n’a été entreprise. La métadonnée Datatracker du document de groupe ne doit pas être confondue avec celle du nouveau texte individuel.

Deux propriétés condensent l’enquête. header.d reprend le domaine signataire de la signature d’origine i=1. header.i désigne le numéro de la signature à laquelle l’échec est attribué. Ce dernier nom est trompeusement familier : pour DKIM1, header.i est un identifiant d’agent ou d’utilisateur ; pour DKIM2, c’est un index numérique. Un schéma de données qui supprime le nom de la méthode rend donc la valeur ambiguë.

Le vérificateur commence par la signature la plus récente et peut s’arrêter au premier échec. Les signatures plus anciennes apparaissent alors comme skipped dans le commentaire. Elles sont visibles, mais elles n’ont pas été validées. C’est pourquoi le projet autorise header.d à côté de n’importe quel résultat pour aider l’opérateur, tout en interdisant de l’utiliser pour la réputation ou la disposition du message si le résultat global n’est pas pass.

Ce détail impose une règle de provenance. Un champ ne devient pas une identité authentifiée par sa seule présence. Dans un cas de réussite il peut porter une identité validée ; dans un cas d’échec il peut n’être qu’une valeur extraite. L’entrepôt qui garde le domaine et jette le résultat transforme une observation de diagnostic en affirmation d’identité.

La frontière principale vient de RFC 8601. Authentication-Results relie des composants de validation et d’évaluation à l’intérieur d’un même domaine de gestion administrative, l’ADMD. Le champ ne possède souvent aucun mécanisme d’intégrité propre. Le MTA de bord doit retirer les occurrences étrangères qui prétendent provenir de ses propres services avant d’ajouter son résultat.

DKIM2 ne signe volontairement pas ce champ. Il est écrit après la vérification et il est couramment supprimé aux frontières. Ainsi, n’importe quel système manipulant le message peut ajouter, modifier ou effacer le compte rendu sans que DKIM2 le détecte. Un authserv-id ressemble à un nom d’émetteur, mais son autorité vient de la configuration et du chemin interne, pas de la chaîne cryptographique.

La transaction SMTP interdit aussi la simple copie d’un résultat honnête. La dernière signature DKIM2 est liée aux valeurs MAIL FROM et RCPT TO observées par le vérificateur. Son pass s’arrête donc à cette réception. Le relais suivant crée une nouvelle transaction. Pour documenter son action, il ajoute une nouvelle signature DKIM2 ; le destinataire suivant revérifie la chaîne et produit son propre compte rendu. Il ne reçoit pas l’autorité du premier verdict par héritage.

Le commentaire apporte la finesse humaine : numéros de saut, domaines, états et diagnostic. Mais le projet précise qu’un parseur conforme peut le supprimer. Sa structure recommandée cherche la lisibilité, pas la stabilité d’une API. Les outils doivent agir sur le résultat et les propriétés définies, non extraire une pseudo-structure du commentaire.

Cette prudence est aussi une mesure de sécurité. Les sélecteurs, domaines, MAIL FROM et RCPT TO peuvent être influencés par l’expéditeur ou les intermédiaires. Selon RFC 5322, parenthèses et barre oblique inverse modifient la grammaire des commentaires. Elles doivent être échappées ; la longueur doit être bornée ; l’affichage doit rester du texte non fiable. Sinon, une valeur hostile peut fermer le commentaire et fabriquer un nouveau résultat dans un champ que l’ADMD croit interne.

Le diagnostic peut également révéler les domaines traversés, une relation de transfert ou une adresse de destinataire. Le garder partout « pour l’audit » peut augmenter l’exposition au lieu d’améliorer la preuve.

Le choix rappelle ARC, qui sépare quelques propriétés actionnables du détail par instance. DKIM1 explique l’ancien sens des propriétés ; l’architecture du courrier Internet situe l’ADMD comme périmètre d’exploitation, non comme autorité globale.

Le registre IANA des paramètres d’authentification du courrier ne contenait pas dkim2 lors de cette vérification. La révision 00 demande l’ajout d’une méthode, de deux propriétés et de cinq résultats. Demander une inscription n’est pas l’avoir obtenue.

La spécification initiale minimale de Heng Lu éclaire ce découpage : un vocabulaire commun coordonne, mais la décision future reste chez l’opérateur qui en répond. Les couches de réalité empêchent le mot pass de se substituer au calcul, à la politique ou à l’effet. La primauté du code en fonctionnement exige de vérifier ce que le MTA a réellement retiré, contrôlé et transmis.

La force du projet n’est donc pas de rendre le verdict universel. Elle est d’expliquer exactement pourquoi il ne l’est pas.