DMARC, sigle de l'anglais Domain-based Message Authentication, Reporting, and Conformance, est une spécification technique créée par un groupe d'organisations qui souhaite aider à réduire l'usage abusif des courriels, tels que le spam, l'hameçonnage, en proposant une solution de déploiement et de surveillance des problèmes liés à leur authentification[1].

Cette technologie a été normalisée par l'Internet Engineering Task Force (IETF) dans la RFC 7489.

Principe modifier

DMARC standardise la façon dont les destinataires (au sens des MTA destinataires) réalisent l'authentification des courriels en utilisant les mécanismes de Sender Policy Framework et de DomainKeys Identified Mail. Cela signifie que l'expéditeur (au sens d'un MTA expéditeur) recevra les résultats de l'authentification de ses messages par tout destinataire qui implémente DMARC (AOL, Gmail, Outlook, Yahoo!, etc.).

Une politique DMARC autorise l'expéditeur à indiquer que ses courriels sont protégés par SPF et/ou DKIM et indique au destinataire ce qu'il doit faire si ces méthodes d'authentification échouent (ex. : rejeter tous les courriels sans DKIM et prévenir une adresse électronique). DMARC supprime les conjectures que le destinataire doit faire à propos de la façon de gérer ces messages en échec, limitant ou supprimant l'exposition de l'utilisateur aux messages potentiellement frauduleux ou dangereux. DMARC fournit également un moyen pour les destinataires de rendre compte à l'émetteur du message qu'il a réussi ou échoué l'évaluation DMARC.

DMARC est conçu pour s'intégrer dans le processus d'authentification des courriels entrants d'une organisation. La façon dont il fonctionne permet d'aider les destinataires à déterminer si le message est conforme à ce qu'il connait de l'expéditeur. Si ce n'est pas le cas, DMARC inclut des explications sur la façon de traiter les messages non conformes. DMARC ne détermine pas directement si un message est frauduleux ou non. DMARC nécessite que le message ait satisfait aux validations SPF et/ou DKIM et que les noms de domaines correspondent. Avec DMARC, un message peut donc échouer s'il passe les validations SPF et DKIM, mais que les domaines ne correspondent pas[2].

Les politiques DMARC sont publiées dans le DNS public du domaine comme enregistrement TXT et annoncent ce que le destinataire d'un courriel doit faire si ce dernier ne satisfait pas les mécaniques d'authentification SPF et/ou DKIM.

Spécifications modifier

Correspondance des noms de domaine modifier

DMARC va vérifier la cohérence (en mode strict et/ou relax) des trois noms de domaines suivants :

  • Le nom de domaine pour DMARC est celui du champ From: du courriel (après @).
  • Le nom de domaine pour DKIM est celui déclaré dans la signature (champ d=).
  • Le nom de domaine pour SPF est celui de la commande MAIL FROM du SMTP.

Domaines organisationnels modifier

Le protocole DMARC repose sur la constitution d'une liste des suffixes publics (exemple https://publicsuffix.org/), afin d'identifier le domaine organisationnel (Organizational Domain).

Par exemple si le FQDN est a.b.c.exemple.co.uk, le suffixe public est co.uk, donc le domaine organisationnel est exemple.co.uk.

Recherche d'un enregistrement DMARC modifier

La recherche d'un enregistrement DMARC est d'abord effectuée sur le FQDN, puis sur le domaine organisationnel (si le FQDN n'est pas déjà un domaine organisationnel).

Par exemple, si l'expéditeur (champ From: du courriel) est exemple@a.news.example.org :

  • On cherche un enregistrement TXT pour _dmarc.a.news.example.org (la valeur du paramètre p sera utilisée).
  • À défaut, on cherche un enregistrement TXT pour _dmarc.example.org (la valeur du paramètre sp sera utilisée).
  • Les niveaux intermédiaires sont toujours ignorés (ici : _dmarc.news.example.org)

Paramètres modifier

Paramètre Description[3],[4]
v [Obligatoire :] Version du protocole, qui doit avoir pour valeur DMARC1 et être le premier paramètre.
(Autrement dit, l'enregistrement TXT doit commencer par « v=DMARC1; ».)
pct Pourcentage de messages à filtrer (nombre entier entre 0 et 100), 100 par défaut.
adkim Mode de cohérence des noms de domaine pour DKIM :
  • s = mode strict (par FQDN).
    Le domaine de la signature DKIM doit correspondre exactement au domaine de l'expéditeur du message (champ From:).
  • r = mode relax (par domaine organisationnel), par défaut.
    Par ex. si l'expéditeur est exemple@news.example.org, il est possible de signer avec d=example.org ou d=a.b.c.example.org pour DKIM.
aspf Mode de cohérence des noms de domaine pour SPF (s ou r).
p [Obligatoire :] Procédure en cas d'échec avec le domaine principal :
  • none = Livrer le courriel normalement
  • quarantine = Traiter le courriel comme suspect (en modifiant son score de spam, en mettant un flag, ou autre…)
  • reject = Rejeter le courriel
sp Procédure en cas d'échec avec un sous-domaine (none, quarantine ou reject).
Si le paramètre sp est absent, la valeur de p est utilisée comme substitut.
Ce paramètre sera inutilisé sur un sous-domaine, donc il doit toujours être sur un domaine organisationnel.
ruf Destinataires des rapports d'échecs détaillés.
fo Conditions pour l'envoi d'un rapport détaillé :
  • 1 = en cas d'échec de DKIM et/ou de SPF
  • d = en cas d'échec de DKIM
  • s = en cas d'échec de SPF
  • 0 = en cas d'échec de DKIM et de SPF, par défaut
rua Destinataires des rapports agrégés.
Une taille limite peut être indiquée (en k, m, g ou t) sous la forme.
rf Format à utiliser pour les rapports d'échec, afrf par défaut (Authentication Failure Reporting Format)
ri Intervalle en secondes entre rapports agrégés, 86400 par défaut.

Exemple :

_dmarc.example.org 3600 IN TXT "v=DMARC1;pct=42;adkim=s;aspf=s;p=quarantine;sp=none;ruf=mailto:forensik@example.org;fo=1;rua=mailto:postmaster@example.org!50m"

Contributeurs fondateurs modifier

Les contributeurs fondateurs de DMARC étaient notamment[5] :

Références modifier

  1. Butcher, Mike. DMARC Promises A World Of Less Phishing. Tech Crunch. Jan 30, 2012
  2. Kucherawy, Murray. The Current DMARC draft specification. DMARC.org. Mar 30, 2012
  3. (en) « HOWTO - Define a DMARC Record », sur zytrax.com (consulté le ).
  4. (en) RFC 7489, section 6.3. : General Record Format
  5. Voir (en) https://dmarc.org/about/history/, ainsi que (en) RFC 7489, page 73 : Acknowledgements
  6. (en) « Participate – dmarc.org », sur dmarc.org (consulté le ).
  7. « Page d’accueil - Microsoft 365 Blog », sur Microsoft 365 Blog (consulté le ).
  8. Vincent Hermann, « Microsoft communique abondamment sur Outlook.com en ce moment pour annoncer des améliorations. Après... », sur pcinpact.com, Next INpact, (consulté le ).

Lien externe modifier