DMARC - comprendre les rapports agrégés

8

TL; DR
Je reçois beaucoup de commentaires DMARC de comptes / sites Web avec lesquels je n'ai pas de contact et je veux savoir si je devrais prendre des mesures ou si ces rapports de rétroaction sont informatifs de problèmes graves?

J'exécute un serveur WHM et j'utilise SPF et DKIM (et _DMARC), tous les e-mails sont envoyés à partir du même serveur de domaine.

Un exemple de configuration DNS pour mon _DMARC (et DKIM et SPF):

mydomain.co.uk     14400 IN TXT "v=spf1 mx a ip4:11.22.33.44 ip4:11.22.33.55 ~all"

default._domainkey 14400 IN TXT "v=DKIM1; k=rsa; p=<code>;

_dmarc             14400 IN TXT "v=DMARC1; p=quarantine; sp=none; 
                                rua=mailto:[email protected]!90m; 
                                ruf=mailto:[email protected]; 
                                rf=afrf; pct=100; ri=86400"

et pour autant que je sache, cela est configuré et fonctionne comme prévu.

cependant, je reçois pas mal de messages automatiques de divers domaines à travers le World Wide Web, qui n'ont rien à voir avec mon domaine. Je suis la seule personne à utiliser les e-mails de mon domaine, personne d'autre n'envoie d'e-mails depuis mon domaine.

Par exemple, ce matin, j'ai reçu un rapport global DMARC de Comcast indiquant:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
    <version>1.0</version>
    <report_metadata>
        <org_name>comcast.net</org_name>
        <email>[email protected]</email>
        <report_id>v1-1483425166-mydomain.co.uk</report_id>
        <date_range>
            <begin>1483315200</begin>
            <end>1483401600</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>mydomain.co.uk</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>quarantine</p>
        <sp>none</sp>
        <pct>100</pct>
        <fo>0</fo>
    </policy_published>
    <record>
        <row>
            <source_ip>72.167.218.164</source_ip>
            <count>1</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>fail</dkim>
                <spf>fail</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>mydomain.co.uk</header_from>
        </identifiers>
        <auth_results>
            <spf>
                <domain>bounce.secureserver.net</domain>
                <scope>mfrom</scope>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>
</feedback>

Non, je ne reconnais aucun des détails énoncés ici en dehors de mon domaine, l'adresse IP cédée <source_ip>n'est pas mon adresse IP et je ne suis pas au courant d'avoir un quelconque contact avec Comcast.

En gros, je reçois beaucoup de ces avis et je ne trouve aucun commentaire pour me dire s'ils sont juste informatifs et peuvent être oubliés (dans ce cas, quel est leur intérêt?) Ou si je peux faire quelque chose avec mon serveur pour améliorer les défaillances dont la notification m'informe.

DONC:

  • Ces rapports peuvent-ils être suivis d'effets?
  • Comment les rapports DMARC tels que ceux-ci devraient-ils être suivis de ma part?
  • Ces rapports sont-ils des indicateurs de toute forme de compromis de compte
  • le nombre de ces rapports peut-il / peut-il [potentiellement] avoir une mauvaise image de mon nom de domaine sur le reste du Web?

Il convient de noter que je soupçonne que la réponse aux deux dernières balles est "Non", mais je ne suis pas un expert en la matière.


J'ai déjà lu cet article ainsi que la FAQ DMARC et ce sujet , mais il n'y a pas beaucoup d'informations. sur la façon dont nous sommes censés réagir aux rapports agrégés. Je suis conscient que les rapports DMARC "ayant échoué" peuvent être causés par des programmes de transfert de courrier, bien que j'espère annuler cette possibilité avec mon SPF ~all.

Dans l'ensemble, je pense que je ne devrais pas avoir à me soucier de ces rapports, mais j'aimerais avoir un deuxième avis en raison de ce que je perçois comme la régularité et ( je pense ) le nombre relativement important de rapports agrégés que je reçois.

Martin
la source

Réponses:

6

Ces rapports peuvent-ils être suivis d'effets?

Oui, mais la plupart des informations confirmeront, espérons-le, que tout est OK avec votre configuration.

Comment les rapports DMARC tels que ceux-ci devraient-ils être suivis de ma part?

En règle générale, ces rapports sont traités par un système automatisé qui transforme ces données en de jolis rapports avec des graphiques, des statistiques et des problèmes nécessitant une attention particulière. Si vous n'avez pas vu ce type de système, vous devriez peut-être consulter dmarcian.com qui fournit un service de base gratuit qui vous aiderait à démarrer et à comprendre ce que vous pouvez et ne pouvez pas faire ou voir. Pour que cela fonctionne, vous devez utiliser une adresse e-mail qu'ils vous fournissent dans votre dossier DMARC.

Ces rapports sont-ils des indicateurs d'une forme quelconque de compromis de compte?

Non, ce ne sont que des rapports de toutes les activités des serveurs compatibles DMARC qui ont traité des messages prétendant provenir de votre nom de domaine, vous indiquant essentiellement qu'ils ont reçu un message, d'où il vient et ce qu'ils en ont fait et pourquoi.

Le nombre de ces rapports peut-il / peut-il [potentiellement] avoir un impact négatif sur mon nom de domaine sur le reste du Web?

Non, ces rapports sont uniquement envoyés à l'adresse e-mail fournie dans le dossier DMARC et non publiés sur le Web. Le seul réel potentiel d'impact négatif est que si vous configurez votre SPF et / ou DKIM de manière incorrecte et que vous finissez par recevoir de nombreux messages rejetés / bloqués, mais au moins avec DMARC, vous le saurez.

richhallstoke
la source
Merci pour le réconfort là-bas. J'ai depuis créé un compte (gratuit), dmarcian.commais je ne savais pas immédiatement pourquoi cela serait bénéfique en tant que tel, mais je suppose qu'il résume les données de retour que les rapports me donnent.
Martin
1
C'est tout simplement plus agréable pour les yeux, surtout lorsque la quantité de données dans les rapports ainsi que la fréquence de leur réception peuvent être importantes. Les rapports DMARC sont conçus pour être traités par des ordinateurs, l'interface dmarcian.com a été conçue pour être lue par les humains. Vous pouvez toujours trouver votre propre solution de traitement automatique si vous n'êtes pas un fan de l'interface dmarcian.com. D'autres existent aussi que vous pourriez explorer, mais c'est le seul gratuit que je connaisse. J'espère que cela t'aides.
richhallstoke
2

En réponse à votre exemple: de nombreux échecs DMARC peuvent être attribués à des listes de transfert et de diffusion, par exemple avec Google Groups for Business. Cependant, dans le rapport, il nous montre que l'e-mail a été envoyé par un hôte faisant partie de secureserver.net. Le SPF a été vérifié sur le chemin de retour de bounce.secureserver.netet passé.

Il s'agit très probablement d'un message de renvoi de votre service anti-SPAM ou SMTP entrant, renvoyé à l'expéditeur de l'e-mail d'origine, qui a tenté de vous envoyer un e-mail. Le rebond sera envoyé en votre nom avec un chemin de retour modifié. SecureServer.net fait partie de GoDaddy, hébergez-vous avec GoDaddy ou un affilié?

En réponse à votre déclaration:

Je suis conscient que les rapports DMARC "ayant échoué" peuvent être causés par des programmes de transfert de courrier, bien que j'espère annuler cette possibilité avec mon SPF ~all.

DMARC n'évaluera la réussite que si les vérifications SPF ou DKIM aboutissent à une réussite, conformément à votre Fromdomaine d'adresse. Je ne suis donc pas sûr de ce que vous voulez dire par là, cela ~allannule le problème.

Les redirecteurs réécrivent généralement le return-pathà leur propre adresse de rebond, ce qui fait échouer l'alignement avec le domaine d'origine. Le protocole ARC est toujours en projet, mais devrait annuler ce problème de transmission pour l'alignement SPF avec DMARC pour les redirecteurs de confiance. De plus, les signatures DKIM restent le plus souvent intactes, à moins que les champs signés ne soient modifiés par le transitaire. DMARC peut donc toujours passer sur la base de DKIM.

Une dernière chose:

Dans votre stratégie DMARC, vous publiez une sp=nonestratégie pour tous les sous-domaines, qui autrement hériterait de la p=quarantinestratégie. Cela signifie que quiconque souhaite usurper votre domaine peut simplement choisir n'importe quel sous-domaine à utiliser, par exemple app.mydomain.co.uk. C'est peut-être une configuration souhaitée, mais je voulais juste le souligner.

Reinto
la source