Résumé

  • draft-gondwana-dkim2-debug-header-01 donne une forme commune aux traces X-DKIM2-Info utilisées pendant les premiers essais DKIM2 ; il ne crée pas un nouveau résultat de vérification.
  • Le champ est exclu des condensats et des signatures. Il peut orienter un humain vers les bonnes pièces, mais ne prouve ni l’émetteur, ni l’action, ni l’instantané, ni l’exhaustivité du récit.

Le message semble avoir apporté son propre dossier d’incident. Une ligne nomme la révision DKIM2 du filtre d’entrée, son dépôt et son programme. Une autre affirme que le logiciel de liste a créé la Message-Instance m=2, énumère les en-têtes condensés et désigne l’instantané antérieur. Plus loin, le filtre de sortie explique qu’il n’a pas signé parce que la chaîne était rompue.

Pour l’ingénieur d’astreinte, cette histoire est autrement plus utile qu’un simple « échec ». Pourtant, rien dans cette histoire n’oblige le message à dire vrai. On peut insérer, déplacer, réécrire ou supprimer chacune de ces lignes sans faire échouer les parties protégées par DKIM2.

C’est la frontière assumée par A Diagnostic Header Field for DKIM2 Implementations. Sa révision 01 a été enregistrée le 30 septembre 2026 en heure du Pacifique, soit déjà le 1er octobre à Shanghai et en UTC. Il s’agit d’un Internet-Draft individuel, de statut prévu Informational et classé I-D Exists. Ce n’est ni un document adopté par le groupe DKIM, ni un RFC, ni une inscription IANA, ni une dépendance normative de DKIM2. Les auteurs le présentent comme un outil pour les premiers tests, probablement sans vocation à publication.

Un vocabulaire commun pour comparer les pannes

DKIM2 cherche à maintenir une chaîne vérifiable malgré les transformations que subit un courrier, notamment dans une liste de diffusion. Les champs Message-Instance portent des condensats et des Recipes permettant de reconstruire un état antérieur ; les champs DKIM2-Signature relient ces états protégés. Lorsqu’un prototype accepte un message et qu’un autre le refuse, le verdict final ne dit pas toujours où leurs comportements ont divergé.

X-DKIM2-Info place alors les indices au même endroit. Chaque occurrence contient, dans l’ordre, cinq étiquettes obligatoires : draft, repo, date, sw et action. La première désigne la révision DKIM2 mise en œuvre. Le dépôt et le programme distinguent un composant ou une bifurcation. La date doit évoluer lorsque le comportement DKIM2 de cet émetteur change. Une occurrence décrit une action ; plusieurs actions produisent plusieurs occurrences.

Le vocabulaire couvre la vérification, l’ajout d’une Message-Instance, la signature et le refus de signer. verify=pass ou verify=fail peut être suivi d’une explication libre. mi-m=<N> peut fournir le nombre et l’ordre des en-têtes condensés, ainsi que l’identifiant de l’instantané lu et celui de l’instantané conservé. sign indique le domaine et l’algorithme. not-signed donne une raison choisie par l’implémentation, par exemple broken-mi-chain.

La révision 01 élimine aussi quelques écarts artificiels entre prototypes : elle reprend exactement la grammaire des extensions DKIM2, impose un point-virgule après chaque étiquette et remplace mi-m<N> par mi-m=<N>. C’est une amélioration d’interopérabilité syntaxique, pas un renforcement de la preuve.

La souplesse vient précisément de l’absence de protection

Le brouillon DKIM2 sous-jacent écarte du condensat Message-Instance les noms d’en-tête commençant par X-. Le brouillon de diagnostic interdit en plus à l’émetteur d’inclure X-DKIM2-Info dans ce qu’il signe ou condense. Un intermédiaire peut donc placer son commentaire juste au-dessus du champ concerné sans changer la Message-Instance ni invalider une signature DKIM2.

Cette propriété retire au commentaire toute capacité de s’authentifier. Le texte répète qu’il ne s’agit pas d’un résultat de vérification, lequel doit être consigné dans Authentication-Results. Il ne représente que ce que l’émetteur prétend avoir fait, et un logiciel ne doit prendre aucune décision sur le message à partir de ce champ. N’importe quel intermédiaire peut ajouter, modifier ou retirer une occurrence sans détection.

La distinction avec l’article BTW déjà consacré à Authentication-Results est donc nette. Celui-ci analysait la confiance locale accordée à un authserv-id dans un domaine administratif et une transaction SMTP déterminés. X-DKIM2-Info se situe en dessous de cette couche de verdict local : il est explicitement impropre à toute décision automatisée. Il aide une personne à formuler l’étape suivante de l’enquête.

La proximité visuelle n’établit pas la causalité

Le projet demande d’ajouter d’abord le champ opérationnel ou protégé, puis de placer immédiatement au-dessus le champ de débogage qui le décrit. Il demande aussi à un émetteur conforme de ne pas altérer les occurrences existantes. On obtient ainsi une chronologie lisible dans le bloc d’en-têtes.

Mais une position voisine n’est pas une signature causale. Un relais ultérieur peut préfixer un action=sign convaincant, rapprocher une ligne d’une autre Message-Instance ou effacer celle qui aurait expliqué l’échec. Le chemin de dépôt et le nom du programme sont des auto-déclarations, non une attestation du binaire. La date de comportement n’est pas un condensat de commit. Aucun identifiant d’événement, aucune clé d’instance, aucun numéro de séquence, aucun accusé de réception et aucune déclaration d’exhaustivité ne transforme les lignes séparées en journal inviolable.

Le silence est tout aussi ambigu. Si l’émetteur constate que la dernière Message-Instance correspond encore et n’ajoute rien, aucune action n’est enregistrée. L’absence de mi-m=<N> ne démontre donc ni qu’un contrôle a eu lieu, ni qu’aucune transformation n’est survenue, ni que la trace est complète.

Un pointeur vers un instantané n’est pas l’instantané

Les étiquettes les plus utiles au support rendent cette limite concrète. snapf désigne la copie antérieure utilisée pour calculer une Recipe ; snaps désigne la copie actuelle gardée pour une comparaison future. Le texte précise que ces identifiants n’ont de sens que pour l’émetteur qui les a écrits. Un exemple ressemble même à une clé de base de données ou à un chemin.

Le jeton raccourcit la conversation avec l’opérateur concerné : il permet de demander les octets, les journaux et la politique de rétention correspondants. Hors de ce système, il ne prouve ni le contenu, ni la garde, ni la durée de conservation, ni même la disponibilité de l’instantané. Sans condensat de contenu et reçu de récupération distincts, le pointeur copié n’est pas un objet de preuve transportable.

La trace peut par ailleurs divulguer le dépôt source, le programme, la version de brouillon, une partie de l’organisation du stockage et l’inventaire des en-têtes. Une explication libre peut révéler le comportement du parseur. Une organisation peut supprimer les champs à sa frontière sortante sans affecter la vérification DKIM2. Elle réduit ainsi l’exposition, mais prive le testeur distant du même indice : rétention interne et divulgation externe doivent être conçues ensemble.

Une subtilité de parsing demeure. RFC 5322 autorise le point-virgule dans un nom de champ d’en-tête, tandis que le format s’en sert comme séparateur sans mécanisme de citation. Le brouillon demande d’omettre de hn les noms dangereux, de limiter sa longueur et de remplacer ou supprimer les points-virgules dans les valeurs. Ces précautions réduisent l’ambiguïté ; elles ne démontrent pas que tous les prototypes les appliquent de manière identique.

RFC 6648 rappelle enfin pourquoi les noms X- peuvent devenir des interfaces de fait après avoir quitté leur usage privé. Ici, le préfixe matérialise un compromis volontaire : il maintient l’information hors de la sémantique et de la couverture cryptographique DKIM2. La direction ne doit pas confondre une frontière de protocole propre avec un confinement opérationnel garanti.

Se servir de l’indice pour retrouver le reçu

Une enquête robuste sépare le logiciel déclaré, l’action déclarée, le champ effectivement reçu, la frontière qui l’a conservé ou supprimé, la vérification DKIM2 réelle, le verdict local dans Authentication-Results, le build et les journaux, les instantanés, le diagnostic de cause, la correction et le résultat de distribution observé. Chaque niveau répond à une question différente.

La doctrine de spécification minimale de Heng Lu va dans ce sens : un format partagé doit faciliter les essais indépendants sans se substituer à la vérité d’exécution locale. La primauté du code en fonctionnement demande ensuite si le build, les octets, les journaux et le résultat après correction peuvent être observés et reproduits.

X-DKIM2-Info est précieux parce qu’il laisse des empreintes lisibles au voisinage d’une panne. Il devient dangereux au moment où l’on transforme cette commodité de support en provenance, en règle de sécurité ou en verdict. La bonne automatisation n’agit pas sur l’indice ; elle s’en sert pour récupérer les éléments que l’on peut vérifier.

Sources