Résumé

  • La révision 01 de l’Internet-Draft individuel draft-chuang-dkim2-sender-policy, publiée le 12 septembre 2026, précise les preuves exigées lorsqu’un relais DKIM2 déclare un message unaligned.
  • Dans le mécanisme proposé, ce drapeau dispense la signature frontière du contrôle d’alignement DMARC, dont le résultat est néanmoins indiqué comme pass.
  • Le nouveau texte exige que le message entrant ait auparavant passé DKIM avec alignement DMARC et qu’un autre récepteur DKIM2 puisse vérifier cet état d’origine ; il recommande aussi des rapprochements entre destinataires signés et enveloppe SMTP.
  • Un journal exploitable doit distinguer alignement vérifié de dérogation acceptée, identifier le From retenu, la signature concernée, la preuve antérieure et l’autorité locale qui a décidé du traitement.

Le problème apparaît au moment de relire, pas au moment de livrer

Une équipe de messagerie reçoit une alerte plusieurs jours après la livraison. Son agrégat DMARC montre une réussite. Le détail disponible dit encore pass. Pourtant, ce mot ne révèle pas si le domaine auteur et l’identifiant DKIM ont effectivement été comparés, ou si un relais a demandé que l’alignement ne soit pas exigé. Les deux trajectoires peuvent être légitimes ; elles ne constituent pas la même preuve.

C’est cette ambiguïté que rend visible la révision 01 de DKIM2 Sender Policy. DKIM2 cherche à conserver une chaîne de signatures alors que des relais modifient le message. Le champ From visible à l’arrivée n’est donc pas nécessairement celui de l’état initial.

Le projet propose d’abord de récupérer, si possible, le From attaché à la signature i=1. Si toute la chaîne est validée, le récepteur retrouve ainsi le contexte de politique de l’expéditeur d’origine. Il peut aussi, selon sa politique locale, prendre le From apparent associé à la signature la plus récente. Le choix déplace le point auquel l’identité responsable et la politique DMARC sont recherchées.

Puis intervient unaligned. Posé sur la signature frontière, le drapeau indique que l’alignement DMARC n’est pas attendu ; le projet prévoit pourtant que le résultat d’alignement affiche pass. Ce verdict ne décrit alors plus seulement une comparaison positive. Il encode l’acceptation d’une exception.

Une condition nouvelle autour d’un drapeau déjà présent

La révision 00 contenait déjà unaligned et son résultat pass. Il serait donc faux d’attribuer l’invention du drapeau à la nouvelle version. L’apport substantiel ressort de la comparaison officielle : pour la première signature DKIM2, l’exception ne doit être déclarée que si le message reçu avait une signature DKIM valide et alignée selon DMARC, et si son état authentifié reste vérifiable par un autre récepteur DKIM2.

La révision ajoute une piste pour étayer cette continuité. Un relais qui introduit un message DKIM dans DKIM2 peut rapprocher une adresse To ou Cc signée d’une adresse RCPT TO de l’enveloppe SMTP. Il peut aussi comparer le domaine d’un destinataire signé au domaine d= de la signature DKIM2 initiale. Ce ne sont pas des preuves universelles de légitimité ; ce sont des observations proposées contre la réutilisation du message.

Une autre option consiste à réécrire From afin de retrouver l’alignement. Le texte en expose la conséquence institutionnelle : le relais prend alors la « propriété » du message et les récepteurs DKIM2 suivants ignorent l’authentification antérieure. Une modification de champ devient donc aussi un déplacement de responsabilité.

La version 01 améliore la dérogation en la rendant conditionnelle. Mais si le système ne conserve que pass, les conditions redeviennent invisibles dès que le verdict sort de son moteur. Il manque le lien entre résultat, exception et preuve.

Trois politiques se rencontrent dans une seule ligne

Le RFC 9989 permet au propriétaire d’un domaine de publier une politique DMARC. Le projet DKIM2 ajoute des contraintes par message à travers les drapeaux de signature. Enfin, le récepteur garde sa politique locale de confiance et de disposition. Ces trois plans ne doivent pas être confondus.

Le texte qualifie les drapeaux de demandes du signataire. Le récepteur devrait les respecter. S’il choisit de ne pas appliquer une contrainte, il ne doit pas relayer le message hors de son propre domaine de gestion administrative. En cas d’échec, l’application de la politique d’exécution reste également soumise au choix local. Le signataire décrit donc une condition ; il ne commande pas à distance l’infrastructure du destinataire.

Le RFC 5598 aide à séparer l’auteur, l’émetteur, les relais et le récepteur final. Le RFC 8601 rappelle qu’un champ Authentication-Results tient son autorité du domaine qui l’a calculé. Copier un résultat local ne le transforme pas en preuve signée transmissible. Dans le cas présent, même un résultat calculé par le bon récepteur reste incomplet si sa raison — test ou dispense — disparaît.

La portée institutionnelle doit rester modeste. Datatracker rattache le document au groupe actif Individual Submissions. L’API du document ne renseigne ni filière, ni Area Director responsable, ni niveau de standard visé, tandis que l’en-tête du fichier mentionne Independent Stream et Experimental. Ce n’est ni un RFC, ni une décision du groupe DKIM, ni une enquête de déploiement. La spécification DKIM2 et le projet de bonnes pratiques restent des travaux distincts.

Préserver la raison sans imposer le verdict

Le remède minimal n’est pas de décider une politique mondiale. Il consiste à conserver deux champs au lieu d’un : le résultat, puis l’état du contrôle. verified signifierait que l’alignement a été exécuté et satisfait. waived signifierait que le récepteur a accepté unaligned après vérification de ses préconditions.

Pour verified, le reçu doit nommer le From évalué, l’identifiant DKIM, la position de signature et le mode d’alignement. Pour waived, il doit nommer le signataire ayant posé unaligned, sa position, la preuve DKIM antérieure, l’état d’origine récupéré et les vérifications de destinataire éventuellement utilisées. Les deux chemins doivent conserver le domaine de politique DMARC, sa version observée, la règle locale, le domaine administratif décideur, un condensat de l’état du message ou de la chaîne, l’heure et la disposition.

Ce reçu est ma proposition éditoriale, pas un champ du projet. Il applique une intuition de The Policy Mirror : le contrôle réel réside dans la politique effectivement chargée et dans le chemin qui l’exécute. Une spécification initiale minimale peut normaliser la différence entre preuve et dérogation sans retirer au récepteur sa décision future. La méthode de BTW Media impose enfin de ne pas présenter un texte de travail comme une pratique observée.

Aucun incident ni déploiement n’est établi ici. La version 01 rend l’exception plus vérifiable. Il reste à empêcher que son motif soit effacé par le mot qui la résume.

Sources