DMARCbis vs. DMARC : Qu'est-ce qui change ?

La spécification DMARC a été publiée pour la première fois en 2012, et l'Internet Engineering Task Force (IETF) propose des modifications au contrôle basé sur le DNS dans DMARCbis, le titre de travail de la version mise à jour. Le groupe de travail DMARC de l'IETF a discuté des mises à jour de la spécification DMARC afin qu'elle soit plus flexible et plus facile à comprendre et à déployer.

Proposition de mise à jour de DMARCbis 

Bien que les mises à jour ne soient pas radicales et n'obligent pas les propriétaires de domaines à mettre à jour leurs enregistrements DMARC pour maintenir la fonctionnalité, les changements visent à améliorer la clarté, la sécurité et l'interopérabilité du contrôle. 

Classée comme norme proposée par le groupe de travail DMARC de l'IETF, voici un aperçu des changements suggérés :

• Le cahier des charges est réorganisé et réécrit avec des exemples améliorés pour le rendre plus facile à comprendre et à suivre.
  
• Pour aider à définir les meilleures pratiques, la section "Conformance Requirements for Full DMARC Participation" a été ajoutée pour décrire le mécanisme DMARC et résumer "les exigences pour une pleine participation à DMARC, soit par les propriétaires de domaines, soit par les destinataires de courrier".

Les balises DMARC ne sont plus utilisées :

• pct les balises sont utilisées pour indiquer que la politique DMARC ne s'applique qu'à un pourcentage particulier du courrier électronique entrant. L'IETF écrit que "l'expérience opérationnelle a montré que la balise pct n'était généralement pas appliquée avec précision, à moins que la valeur spécifiée ne soit 0 ou 100 (la valeur par défaut), et que les imprécisions avec d'autres valeurs variaient considérablement d'une implémentation à l'autre".
  
  Bien que toutes les parties prenantes ne soient pas d'accord avec cette décision, la balise pct est remplacée par la balise t (mode de test) pour créer un scénario tout (100 %) ou rien (0 %). Certaines personnes apprécient la balise pct pour son utilité dans l'avancement mesuré de la mise en œuvre de la politique de sécurité de l'UE. p=quarantine et de p=reject d'autres ont reconnu que la balise pct n'était pas calculée de manière cohérente et qu'une balise plus précise apporterait une clarté opérationnelle.
  
  
• Les balises rf (format de rapport agrégé) et ri (intervalle entre les rapports agrégés) sont supprimées afin de simplifier et de rationaliser le processus de déploiement de DMARC. Il convient de noter ici que les destinataires d'e-mails continueront à générer et à délivrer des rapports agrégés aux adresses e-mail spécifiées dans la balise RUA.

Ajout de balises DMARC : 

np (politique de sous-domaine inexistant ) - avec les mêmes valeurs de politique que p et sp la balise np proposée permet aux propriétaires de domaines d'appliquer une politique à un sous-domaine qui n'existe pas. Pourquoi un propriétaire de domaine définirait-il une politique pour un sous-domaine inexistant ? Pour contourner les contrôles DMARC, les cybercriminels essaient d'utiliser un sous-domaine inexistant d'un domaine existant pour envoyer des courriels douteux. La balise np avec une valeur d'application de quarantaine ou de rejet peut fournir la protection nécessaire pour arrêter les courriels frauduleux envoyés à partir d'un faux sous-domaine.

psd (public suffix domain) - utilisé pour indiquer que le domaine est un domaine à suffixe public (PSD) géré par un registre. La balise sera utilisée pour définir le domaine racine du domaine From et aura les valeurs suivantes :

• y - Les PSO (public suffix operator) incluent cette balise avec une valeur de y pour indiquer que le domaine est un PSD. Si un enregistrement contenant cette balise avec une valeur de y est trouvé lors de la découverte de la politique, cette information sera utilisée pour déterminer le domaine organisationnel et le domaine de la politique DMARC applicable au message en question.
• n - indique que l'enregistrement de politique DMARC est publié pour un domaine qui n'est pas un DSP, mais qui est le domaine organisationnel pour lui-même et ses sous-domaines.
• u - valeur par défaut indiquant que l'enregistrement de politique DMARC est publié pour un domaine qui n'est pas un DSP et qui peut ou non être un domaine organisationnel pour lui-même et ses sous-domaines. Dans ce cas, le processus d' arborescence DNS détermine le domaine organisationnel. L'arborescence DNS est le processus d'association d'un nom de domaine à une adresse IP en naviguant dans le système de noms de domaine.

t (mode test) - Remplace la balise pct et a ces valeurs binaires :

• y - indique que la politique DMARC publiée dans les balises p, sp et/ou np ne doit pas être appliquée et agit comme la valeur pct=0 .
• n - la valeur par défaut qui applique la politique DMARC publiée et équivaut à la valeur pct=100.

Mises à jour techniques supplémentaires

• Le mécanisme de la liste des suffixes publics est remplacé par l'algorithme de parcours de l'arbre DNS afin de mieux prendre en charge les domaines de suffixes publics (PSD). 

• Étant donné que les redirections d'e-mails et les listes de diffusion peuvent interférer avec l'authentification des e-mails, DMARCbis recommande de ne pas utiliser l'option p=reject avec les listes de diffusion.

• Le rapport agrégé fait l'objet de quelques modifications définies dans ce document de l'IETF. La mise à jour de la RUA ne modifie pas votre enregistrement de politique DMARC ni le lieu de livraison de vos rapports, mais uniquement la manière dont les expéditeurs de rapports structurent le XML contenu dans les rapports.

Comme pour la balise pct, tous les experts en la matière ne sont pas d'accord avec l'évaluation de l'IETF, y compris Ash Morin, notre directeur des services professionnels : "En examinant attentivement les données DMARC pour identifier les listes de diffusion avec lesquelles les utilisateurs s'engagent, il est tout à fait possible de passer à p=reject en toute sécurité. Les logiciels de listes modernes tels que Mailman et LSoft LISTSERV intègrent déjà des mesures d'atténuation DMARC, et je mets en garde contre le fait de considérer le fait de ne pas publier p=rejectcomme une meilleure pratique - ce n'est pas le cas.

Comment se préparer à DMARCbis

Les enregistrements v=DMARC1 existants restent valables et continueront d'être la norme lorsque les changements seront publiés. Cela dit, lorsque DMARCbis sera publié, les propriétaires de domaines devront revoir et mettre à jour leurs enregistrements DMARC pour profiter des changements. 

Lorsque les mises à jour de DMARCbis seront publiées, vous pourrez examiner vos enregistrements DMARC pour vous assurer qu'ils sont conformes à la spécification DMARC modifiée :

• Suppression des balises obsolètes pct (pourcentage), rf (format de rapport) et ri (intervalle de rapport). 
• Ajoutez les nouvelles balises np (non-existent policy), psd (Public Suffix Domains) et t (testing mode) décrites ci-dessus.

Les enregistrements DMARC actuels sont-ils toujours valables ?

Oui, vos enregistrements DMARC existants ne seront pas obsolètes et continueront à fonctionner lorsque DMARCbis sera publié. Mais l'intégration des mises à jour de DMARCbis permet d'aligner vos enregistrements DMARC sur la dernière version de la norme industrielle.

Quand DMARCbis sera-t-il publié ?

Au moment de la rédaction de cet article, DMARCbis se trouve actuellement dans la phase "Last Call" de l'IETF et devrait être publié en 2025.

dmarcian est là pour vous aider

Avec une équipe d'experts en sécurité du courrier électronique et une mission qui consiste à rendre le courrier électronique et l'Internet plus dignes de confiance grâce à la sécurité des domaines, dmarcian est là pour aider à évaluer le catalogue de domaines d'une organisation à la lumière des prochaines mises à jour DMARC. Nous pouvons vous aider à mettre en œuvre et à gérer DMARC sur le long terme.

---

Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian.