Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:internal_serv:mail:maintenance:dmarc_reports [2021/01/31 14:49] – qduchemi
+++ technique:adminsys:mail:maintenance:dmarc_reports [2021/11/22 22:29] – ↷ Liens modifiés en raison d'un déplacement. qduchemi
@@ Ligne 7: / Ligne 7: @@
 <bootnote learn>[[technique:etudes:mail:protocoles:smtp:limites#dmarc|DMARC]] vérifie, entre autres la concordance des domaines trouvés par [[technique:etudes:mail:protocoles:smtp:limites#spf|SPF]] et [[technique: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:`.</bootnote>
-<bootnote>C'est la [[technique:internal_serv:mail:config:dmarc|politique DMARC]], publiée comme enregistrement DNS, qui indique quoi faire en cas d'erreur, par exemple</bootnote>
+<bootnote>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</bootnote>
-Dans [[technique:internal_serv: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.
+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.
 <bootnote warning>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.</bootnote>
@@ Ligne 32: / Ligne 32: @@
 <bootnote critical>La présence d'une autre catégorie devrait attirer l'attention et être élucidée.</bootnote>
+La section `Compliance` indique DMARC est "validé".
+<bootnote learn>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).</bootnote>
 Ci-dessous, on trouve un exemple de résultat.
@@ Ligne 37: / Ligne 41: @@
 #### DMARC Capable
-{{ :technique:internal_serv:mail:maintenance:dmarc_capable.png |}}
+{{ technique:adminsys:mail:maintenance:dmarc_capable.png |}}
+Tout est au vert, la `Compliance` est de 100%.
-Tout est au vert :
+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`.
-* 41 messages ont été envoyés ce jour-ci
+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.
-* 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:internal_serv: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
@@ Ligne 49: / Ligne 53: @@
 C'est une autre histoire :
-{{ :technique:internal_serv:mail:maintenance:dmarc_forwarders.png |}}
+{{ technique:adminsys:mail:maintenance:dmarc_forwarders.png |}}
 Déjà, on constate que l'alignement SPF est systématiquement cassé.
-<bootnote>C'est totalement normal ! SPF **ou** l'alignement DMARC seront **toujours l'un ou l'autre cassé** dans le cas d'un relai.</boonote>
+<bootnote>C'est totalement normal ! SPF **ou** l'alignement DMARC seront **toujours l'un ou l'autre cassé** dans le cas d'un relai.</bootnote>
 <bootnote question>Pourquoi ?</bootnote>
@@ Ligne 63: / Ligne 67: @@
 Par contre, l'**alignement sera cassé**, car le header `From:` finit en `@picasoft.net` et l'enveloppe en `@utc.fr`.
-<bootnote learn>Cette dernière 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.</bootnote>
+<bootnote learn>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.</bootnote>
 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:internal_serv:mail:maintenance:dmarc_compliant.png |}}
+{{ technique:adminsys:mail:maintenance:dmarc_compliant.png |}}
-En revanche, DKIM est cassé pour `univ-amu.fr`.
+En revanche, DKIM est cassé pour `univ-amu.fr`. La `Compliance` est à 0%.
 <bootnote>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.</bootnote>