Table des matières

Vérifier les rapports DMARC

Préambule

A Savoir:

DMARC vérifie, entre autres la concordance des domaines trouvés par SPF et DKIM avec le domaine de l’en-tête From:. En particulier, DMARC vérifie que le nom de domaine de la machine ayant été autorisée à envoyer le mail (SPF) correspond à l’adresse de l’émetteur (From:) et que le domaine de la clé ayant signé le mail (DKIM) correspond au header From:.

Note:

C’est la politique DMARC, publiée comme enregistrement DNS, qui indique quoi faire en cas d’erreur, par exemple

Dans notre enregistrement DNS, on trouve une adresse mail de reporting : tech@picasoft.net. L’idée est de demander à tous les fournisseurs de mail qui vérifient la politique DMARC de nous envoyer un rapport hebdomadaire, qui donne le statut de la vérification des e-mails.

Attention:

La vaste majorité des fournisseurs mails ne vérifient pas la politique DMARC, et moins encore envoient un rapport. Aujourd’hui, nous recevons des rapports quasiment exclusivement en provenance de Google.

Récupération des rapports

Il suffit de se connecter à n’importe quel client mail sur le serveur de Picasoft, avec :

Thunderbird trouve automatiquement la configuration. Sinon, on utilisera mail.picasoft.net, port 587 pour SMTP, port 143 pour IMAP, avec STARTTLS.

Les rapports XML reçus par mail peuvent être rendus plus lisibles grâce à cet outil.

Question:

Comment interpréter les tableaux générés ?

Les mails sont séparés en quatre catégories (« quelle origine a ce mail ? »). Pour nous, si tout va bien, il n’y en aura toujours que 2 :

Important:

La présence d’une autre catégorie devrait attirer l’attention et être élucidée.

La section Compliance indique DMARC est “validé”.

A Savoir:

DMARC est validé si l’alignement SPF ou l’alignement DKIM est respecté, car il existe des cas légitimes où l’alignement SPF ne peut pas être respecté (voir plus bas).

Ci-dessous, on trouve un exemple de résultat.

DMARC Capable

Tout est au vert, la Compliance est de 100%.

L’alignement DKIM est respecté, c’est-à-dire que tous les mails envoyés depuis le serveur mail de Picasoft ont été signés avec une clé dont le domaine de validité (ici picasoft.net) correspond au header From:, qui se termine en @picasoft.net. Le sélecteur de la clé DKIM est ici janv2021.

L’alignement SPF est respecté, c’est-à-dire que le header From: provient du même domaine que l’enveloppe d’en-tête (indiquée avec la commande SMTP MAIL FROM). En effet, SPF vérifie seulement que l’IP du serveur de MAIL FROM est autorisée à envoyer des e-mails pour le domaine picasoft.net. Mais elle ne prévient pas la falsification du header From:. Avec cette vérification d’alignement, on empêche l’expéditeur de falsifier une adresse, en faisant croire que le mail est envoyé depuis un autre domaine.

Forwarders

C’est une autre histoire :

Déjà, on constate que l’alignement SPF est systématiquement cassé.

Note:

C’est totalement normal ! SPF ou l’alignement DMARC seront toujours l’un ou l’autre cassé dans le cas d’un relai.

Question:

Pourquoi ?

Pour que SPF fonctionne, il faut que l’IP du serveur qui envoie le mail soit autorisée pour le domaine du MAIL FROM. Or, si le serveur de relai (par exemple, utc.fr) ne change pas le MAIL FROM, alors le serveur de destination pourra constater que l’IP de 195.83.155.132 (mxo-out5.utc.fr) n’est pas autorisée à émettre pour le domaine picasoft.net (en effet, seuls les serveurs des champs DNS MX le peuvent, pour nous, mail.picasoft.net).

Donc, il faut que le MAIL FROM soit changé par le relai, pour finir en @utc.fr. Dans ce cas, SPF passera.

Par contre, l’alignement sera cassé, car le header From: finit en @picasoft.net et l’enveloppe en @utc.fr.

A Savoir:

D’ailleurs, cette technique pose un problème : si le mail est rejeté par le destinataire, comment notifier l’émetteur originel du mail ? Des techniques comme Sender Rewriting Scheme permettent de ré-écrire l’enveloppe, sans casser SPF, et en conservant l’émetteur originel.

DKIM est préservé pour les adresses mail en utc.fr ayant demandé de relayer les mails, ce qui suffit à valider la conformité à la politique DMARC :

En revanche, DKIM est cassé pour univ-amu.fr. La Compliance est à 0%.

Note:

En général, ceci indique que le relai modifie le corps du mail ou ses en-têtes avant de relayer le mail. Ainsi, la signature calculée à l’arrivée du mail sera différente de celle indiquée dans ses en-têtes.

On constate que ni l’alignement SPF, ni SPF lui-même ne passent.

Dans ce genre de cas, soit le serveur mail de relai est très, très mal configuré, soit il a un but malveillant d’usurpation/falsification. En ce qui nous concerne, ça sera bien souvent le premier cas.

Important:

Dans tous les cas, même si notre politique DMARC demande de ne rien faire en cas de non-conformité, le fait que SPF et DKIM soient simultanément cassés risque de provoquer une alerte sur le client mail de l’utilisateur, de finir en spam, ou autre chose. Il est donc souhaitable de régler le problème.

Note:

La seule chose que l’on puisse faire, c’est de contacter les administrateurs du serveur mail de relai, et de leur donner des détails.