Résumé

  • La révision DKIM2 du 1er novembre ajoute un enregistrement de politique du domaine, absent de la version du 27 octobre. Le parent peut publier strict pour empêcher ses sous-domaines de rendre son From « Authentic ».
  • Sans cet enregistrement, ou sans le drapeau strict, la correspondance ascendante du projet autorise le sous-domaine. Le silence du parent joue donc en faveur de la délégation.
  • La politique se publie à _domainkey du domaine parent concerné. Elle ne se transmet ni aux domaines enfants ni aux domaines au-dessus ; une panne DNS temporaire donne TEMPERROR.

Louer une annexe et découvrir qu’elle ouvre l’entrée

Une entreprise délègue mail.example.com à un prestataire d’envoi. Celui-ci contrôle les clés de son sous-domaine. Avec la révision 09 du projet, sa signature peut aussi contribuer à rendre « Authentic » l’adresse example.com affichée dans From. Les auteurs disent préserver une pratique de DKIM1 pour éviter de casser les délégations existantes. La révision 08 ne contenait pas cette nouvelle politique ni le contrôle correspondant.

Le domaine parent peut retirer cette capacité. La section 3.8 prévoit un enregistrement TXT à _domainkey.example.com. Il commence par v=DKIM1 ; une liste facultative f= peut porter le drapeau strict. Ce drapeau refuse qu’un sous-domaine signataire rende authentique un From portant example.com. Si strict manque, ou si le parent ne publie aucun enregistrement, le projet laisse cette possibilité ouverte. La règle concerne le résultat DKIM2 « Authentic » proposé, pas l’état actuel des messages déjà livrés par DKIM1.

Le mécanisme est précis. La section 7 compare d’abord le domaine du From avec le d= de la signature pertinente. En l’absence de correspondance, elle inverse l’ordre. Ce second trajet peut remonter d’un sous-domaine signataire au parent visible ; c’est là que strict arrête la correspondance. Une signature du parent exact n’emprunte pas ce détour. La politique du parent ne s’hérite pas : chaque domaine décide au niveau DNS qui porte son propre nom.

Deux défauts ne doivent pas se déguiser en autorisation. Plusieurs enregistrements valides donnent PERMERROR. Une panne DNS temporaire au moment de lire la politique donne TEMPERROR. La fiche IETF décrit encore un Internet-Draft de groupe de travail, à l’état I-D Exists. Les sources consultées ne montrent pas de déploiement interopérable de ce nouveau verrou.