Qu’est-ce que DMARC et comment lire son premier rapport ?

Dessin d'une enveloppe

Source : wallhaven.cc

Je me suis récemment lancé dans l’aventure de l’auto-hébergement de ma messagerie électronique, et j’ai mis en place un certain nombre de mécanismes afin de lutter contre le spam et l’usurpation d’identité. Parmi ces mécanismes il y en a un qui s’appelle DMARC.

Et aujourd’hui, j’ai reçu mon tout premier rapport de la part de Google. DMARC ne vous dit rien ? Voyons ce que c’est, à quoi ça sert et comment le mettre en place !

Qu’est-ce que DMARC ?

DMARC, pour Domain-based Message Authentication, Reporting & Conformance est un moyen mis en place par les grands fournisseurs de messagerie mondiaux pour authentifier précisément l’expéditeur d’un email et lutter contre l’usurpation d’identité.

Il repose notamment sur deux autres mécanismes bien connus en matière de messagerie, DKIM (Domain Key Identified Mail) et SPF (Sender Policy Framework) pour s’assurer qu’un message donné provient bien de l’expéditeur duquel il prétend provenir.

À quoi ça ressemble ?

DMARC se présente sous la forme d’un enregistrement DNS de type TXT comme celui-ci :

$ dig TXT _dmarc.guillaume-leduc.fr +short
"v=DMARC1;p=reject;rua=mailto:admin@guillaume-leduc.fr;ruf=mailto:admin@guillaume-leduc.fr;adkim=s;aspf=s;pct=100;rf=afrf;sp=reject"

Qu’est-ce que ça signifie ?

Nous remarquons que l’enregistrement possède un certains nombre de « tags », ou clés-valeur, séparés par des points-virgule. Il y a deux tags obligatoires, les autres sont optionnels.

  • v : pour Version. Il est obligatoire et permet d’indiquer que cet enregistrement DNS de type TXT est bien un enregistrement DMARC. Il est donc utile aux fournisseurs de messagerie, doit contenir la valeur DMARC1 et être placé au tout début de l’enregistrement, sans quoi tout le reste ne sera pas valide.
  • p : pour Policy. Obligatoire lui aussi, il permet d’indiquer aux serveurs recevant les messages envoyés de votre domaine ce qu’ils doivent faire si jamais le test DMARC échoue. La politique s’applique au domaine, ainsi qu’à tous les sous-domaines par défaut, bien qu’il soit possible de préciser les actions à réaliser pour chaque sous domaine. Il peut prendre trois valeurs :
    1. p=none : le propriétaire du domaine n’indique aucune action spécifique en cas d’échec
    2. p=quarantine : le propriétaire du domaine indique qu’il faut mettre l’email en quarantaine, ou spam en cas d’échec du test
    3. p=reject : vous l’aurez deviné, le propriétaire demande le rejet de l’email si les tests ne sont pas passés avec succès. Ce rejet doit être effectué durant la phase de transaction SMTP, et c’est le plus haut niveau de protection que vous pouvez fournir.
  • rua : indique l’adresse à laquelle les rapports DMARC aggrégés doivent être envoyés
  • ruf : indique l’adresse à laquelle les rapports DMARC forensic doivent être envoyés
  • adkim : indique si le test DKIM doit être strict ou tolérant (relaxed en anglais)
  • aspf : idem que le tag précédent, mais avec SPF
  • pct : indique le pourcentage de messages auquel le test DMARC devrait être appliqué
  • rf : spécifie le format des messages contenant les rapports d’erreurs, par défaut afrf. Ces rapports vous sont envoyés par les destinataires de vos email
  • sp : politique à appliquer sur les sous-domaines
  • ri : le nombre de secondes a respecter entre deux envois de rapport, par défaut à 86400, soit 24h
  • fo : qui permet d’indiquer dans quel cas un rapport de vulnérabilité doit être envoyé

Vous voyez que je suis plutôt strict sur mon domaine (normal il n’y a que moi qui l’utilise pour envoyer des messages, normalement). Et donc pour faire simple, DMARC permet d’indiquer aux fournisseurs de messagerie comme Outlook, Gmail et consorts que faire lorsqu’ils reçoivent un email de votre part et que les tests relatifs à SPF ET DKIM sont mauvais.

Je n’ai toujours pas compris l’intérêt…

Exemple concret

Bob est un geek comme moi qui possède son propre serveur de messagerie ayant l’adresse xxx.xxx.xxx.xxx, et le domaine associé bob.com. Comme il fait les choses bien il a ajouté un enregistrement SPF a la zone DNS de son domaine qui contient l’adresse xxx.xxx.xxx.xxx pour indiquer au monde entier que tous les mail envoyés par @bob.com ne peuvent être envoyés que par son serveur. Il a poussé le vice plus loin en ajoutant un enregistrement DKIM qui contient une clé publique permettant à ses destinataires de vérifier qu’un mail provenant de @bob.com a bien été envoyé par xxx.xxx.xxx.xxx (serveur qui possède la clé privé et qui peut donc signer correctement les messages).

Maintenant si Bob envoie un message à Alice, qui fait confiance à Google pour gérer sa messagerie. Disons un mail de perso@bob.com vers alice@gmail.com. Lorsque les serveurs de Google recevront le message de perso@bob.com, il sauront que faire si jamais le test DKIM ou SPF échoue.

Ça serait le cas si Eve, qui a elle aussi son propre serveur de messagerie, essayait de se faire passer pour bob en envoyant des mails dont l’expéditeur est perso@bob.com.

Google saurait qu’il faut rejeter ces messages ou les placer en quarantaine.

D’ailleurs, Google envoie aussi des rapports réguliers à l’adresse que Bob a indiqué dans son enregistrement DMARC.

Comment lire un rapport DMARC ?

Déjà à quoi ça ressemble ? J’ai reçu un mail de la part de noreply-dmarc-support@google.com contenant une pièce jointe : une fichier xml dans une archive zip.

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>4188915360573353081</report_id>
    <date_range>
      <begin>1479427200</begin>
      <end>1479513599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>guillaume-leduc.fr</domain>
    <adkim>s</adkim>
    <aspf>s</aspf>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>151.80.171.221</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>guillaume-leduc.fr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>guillaume-leduc.fr</domain>
        <result>pass</result>
        <selector>mail</selector>
      </dkim>
      <spf>
        <domain>guillaume-leduc.fr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

La première section (report_metadata) contient des informations sur le fournisseur de messagerie qui vous envoie le rapport. La deuxième (policy_published) un résumé de l’enregistrement DNS DMARC que vous avez publié. Ici ça correspond bien à l’enregistrement que j’ai mis un peu plus haut.
Ensuite, dans la section record, nous avons un résumé des tests effectués avec notamment :

  • L’adresse ip source du mail frauduleux ou non qui a été testé (ici c’est bien mon serveur de mail, ainsi que le nombre d’adresses identifiées s’il y en a plusieurs
  • La décision qui a été prise par Google par rapport à l’email testé (disposition). Ici none indique que le mail est passé et n’a pas été rejeté ou mis en quarantaine. Logique puisqu’on voit juste en dessous que les tests DKIM et SPF ont été validés
  • Et enfin le résultat des tests DKIM et SPF

Finalement c’est du XML qui fait peur mais ça reste très lisible et compréhensible non ?

Si vous avez des questions ou si vous voyez une erreur n’hésitez pas. Je débute en la matière et j’apprends en même temps. Si j’ai décidé d’héberger moi-même mes messages électroniques c’est pour en finir avec le spam dans ma boîte perso alors j’espère que tous les outils mis en place par mes soins seront efficaces !

À bientôt 🙂

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email