{{indexmenu_n>15}} ## Vérifier les rapports DMARC ### Préambule [[technique:old:etudes:mail:protocoles:smtp:limites#dmarc|DMARC]] vérifie, entre autres la concordance des domaines trouvés par [[technique:old:etudes:mail:protocoles:smtp:limites#spf|SPF]] et [[technique:old:etudes:mail:protocoles:smtp:limites#dkim|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:`. C'est la [[technique:adminsys:mail:config:dmarc|politique DMARC]], publiée comme enregistrement DNS, qui indique quoi faire en cas d'erreur, par exemple Dans [[technique:adminsys:mail:config:dmarc|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. 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 : * Identifiant : `tech@picasoft.net` * Mot de passe : [[asso:tuto:vaultwarden|sur le vaultwarden]] 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](https://us.dmarcian.com/xml-to-human-converter/). 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 : * `DMARC Capable` : nos serveurs mails, qui ont une politique DMARC * `Forwarders` : des relais, par exemple le serveur de l'UTC qui renvoie vers une adresse perso. La présence d'une autre catégorie devrait attirer l'attention et être élucidée. La section `Compliance` indique DMARC est "validé". 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 {{ technique:adminsys:mail:maintenance:dmarc_capable.png |}} 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 [[technique:adminsys:mail:config:dkim|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 : {{ technique:adminsys:mail:maintenance:dmarc_forwarders.png |}} Déjà, on constate que l'alignement SPF est systématiquement cassé. C'est totalement normal ! SPF **ou** l'alignement DMARC seront **toujours l'un ou l'autre cassé** dans le cas d'un relai. 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`. 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](https://en.wikipedia.org/wiki/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 : {{ technique:adminsys:mail:maintenance:dmarc_compliant.png |}} En revanche, DKIM est cassé pour `univ-amu.fr`. La `Compliance` est à 0%. 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. 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. 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.