DMARC - Aggregatberichte verstehen

8

TL; DR
Ich erhalte viele DMARC-Rückmeldungen von Konten / Websites, mit denen ich keinen Kontakt habe, und möchte Klarheit darüber, ob ich Maßnahmen ergreifen sollte oder ob diese Rückmeldungen über schwerwiegende Probleme informieren.

Ich betreibe einen WHM-Server und verwende SPF und DKIM (und _DMARC). Alle E-Mails werden vom gleichen Domänenserver gesendet.

Ein Beispiel für ein DNS-Setup für mein _DMARC (und DKIM und 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"

und soweit ich das beurteilen kann, ist dies eingerichtet und funktioniert wie erwartet.

Ich erhalte jedoch einige automatische Nachrichten von verschiedenen Domains im World Wide Web, die nichts mit meiner Domain zu tun haben. Ich bin die einzige Person, die E-Mails von meiner Domain verwendet. Niemand anderes sendet E-Mails von meiner Domain.

Zum Beispiel habe ich heute Morgen einen DMARC-Gesamtbericht von Comcast erhalten, der besagt:

<?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>

Nein. Abgesehen von meiner Domain erkenne ich keine der hier aufgeführten Details. Die angegebene IP-Adresse <source_ip>ist nicht meine IP-Adresse, und mir ist überhaupt kein Kontakt mit Comcast bekannt.

Grundsätzlich bekomme ich ziemlich viele dieser Mitteilungen und kann kein Feedback finden, das mir sagt, ob sie nur informativ sind und vergessen werden können (in welchem ​​Fall ist der Sinn von ihnen?) Oder ob ich etwas tun kann mit meinem Server, um die Fehler zu verbessern, über die mich der Hinweis informiert.

DAMIT:

  • Können diese Berichte bearbeitet werden?
  • Wie sollen DMARC-Berichte wie diese an meinem Ende bearbeitet werden?
  • Sind diese Berichte Indikatoren für jede Form von Kontokompromittierung?
  • Kann / spiegelt die Anzahl dieser Berichte [möglicherweise] meinen Domainnamen im Rest des Webs schlecht wider?

Es mag erwähnenswert sein, dass ich vermute, dass die Antwort auf die letzten beiden Kugeln "Nein" lautet, aber ich bin kein Experte in diesen Fragen.


Ich habe diesen Beitrag sowie die DMARC-FAQ und dieses Thema bereits gelesen , aber es gibt nicht viele Informationen. darüber, wie wir auf aggregierte Berichte reagieren sollen. Ich bin mir bewusst, dass "fehlgeschlagene" DMARC-Berichte durch Mail-Weiterleitungsprogramme verursacht werden können, obwohl ich hoffe, diese Möglichkeit mit meinem SPF zu negieren ~all.

Insgesamt denke ich , ich sollte mir keine Sorgen um diese Berichte machen müssen, aber ich hätte gerne eine zweite Meinung, da ich dies als Regelmäßigkeit und ( ich denke ) als relativ bedeutende Anzahl von aggregierten Berichten empfinde, die ich erhalte.

Martin
quelle

Antworten:

6

Können diese Berichte bearbeitet werden?

Ja, aber die meisten Informationen bestätigen hoffentlich, dass Ihre Konfiguration in Ordnung ist.

Wie sollen DMARC-Berichte wie diese an meinem Ende bearbeitet werden?

Normalerweise werden diese Berichte von einem automatisierten System verarbeitet, das diese Daten in hübsche Berichte mit Grafiken, Statistiken und Problemen umwandelt, die Aufmerksamkeit erfordern. Wenn Sie diese Art von System noch nicht gesehen haben, sollten Sie sich vielleicht bei dmarcian.com umsehen , das einen kostenlosen Basisdienst bietet, der Ihnen den Einstieg erleichtert und Ihnen hilft, zu verstehen, was Sie tun und was nicht. Damit dies funktioniert, müssten Sie eine E-Mail-Adresse verwenden, die Sie in Ihrem DMARC-Datensatz angegeben haben.

Sind diese Berichte Indikatoren für irgendeine Form von Kontokompromittierung?

Nein, es handelt sich lediglich um Berichte über alle Aktivitäten von DMARC-fähigen Servern, die Nachrichten verarbeitet haben, die angeblich von Ihrem Domain-Namen stammen, und die Ihnen im Wesentlichen mitteilen, dass sie eine Nachricht erhalten haben, woher sie stammt und was sie damit gemacht haben und warum.

Kann / spiegelt die Anzahl dieser Berichte [möglicherweise] meinen Domainnamen im Rest des Webs schlecht wider?

Nein, diese Berichte werden nur an die im DMARC-Datensatz angegebene E-Mail-Adresse gesendet und nicht im Internet veröffentlicht. Das einzige wirkliche Potenzial für negative Auswirkungen besteht darin, dass Sie Ihren SPF und / oder DKIM falsch eingerichtet haben und am Ende viele Nachrichten abgelehnt / blockiert werden, aber zumindest mit DMARC würden Sie davon erfahren.

Richhallstoke
quelle
Vielen Dank für die Bestätigung dort. Ich habe seitdem ein (kostenloses) Konto eingerichtet dmarcian.com, war mir aber nicht sofort sicher, warum dies als solches von Vorteil ist, aber ich denke, es fasst die Feedback-Daten zusammen, die mir die Berichte geben.
Martin
1
Es ist nur einfacher für die Augen, insbesondere wenn die Datenmenge in den Berichten sowie die Häufigkeit des Empfangs erheblich sein können. DMARC-Berichte sind für die Verarbeitung durch Computer konzipiert. Die Schnittstelle von dmarcian.com wurde für das Lesen durch Menschen entwickelt. Sie können jederzeit eine eigene automatische Verarbeitungslösung entwickeln, wenn Sie kein Fan der Benutzeroberfläche von dmarcian.com sind. Es gibt auch andere, die Sie erkunden könnten, aber dies ist die einzige freie, die ich kenne. Hoffe das hilft.
Richhallstoke
2

Als Antwort auf Ihr Beispiel: Viele DMARC-Fehler lassen sich auf Weiterleitungs- und Mailinglisten zurückführen, beispielsweise bei Google Groups for Business. In dem Bericht wird jedoch angezeigt, dass die E-Mail von einem Host gesendet wurde, der Teil von secureserver.net ist. Der SPF wurde auf dem Rückweg von überprüft bounce.secureserver.netund übergeben.

Höchstwahrscheinlich war dies eine Bounce-Nachricht von Ihrem Anti-SPAM- oder eingehenden SMTP-Dienst, die an den ursprünglichen E-Mail-Absender zurückgesendet wurde und versucht hat, Ihnen eine E-Mail zu senden. Der Bounce wird in Ihrem Namen mit einem geänderten Rückweg gesendet. SecureServer.net ist Teil von GoDaddy. Hosten Sie mit GoDaddy oder einem Partner?

Als Antwort auf Ihre Aussage:

Ich bin mir bewusst, dass "fehlgeschlagene" DMARC-Berichte durch Mail-Weiterleitungsprogramme verursacht werden können, obwohl ich hoffe, diese Möglichkeit mit meinem SPF zu negieren ~all.

DMARC wird nur dann als bestanden ausgewertet, wenn SPF- oder DKIM-Prüfungen zu einem Bestehen führen, das mit Ihrer FromAdressdomäne übereinstimmt. Ich bin mir also nicht sicher, was du damit meinst, was ~alldas Problem negiert.

Weiterleitungen schreiben die return-pathAdresse normalerweise an ihre eigene Absprungadresse um, sodass die Ausrichtung mit der Ursprungsdomäne fehlschlägt. Das ARC- Protokoll befindet sich noch im Entwurf, sollte jedoch dieses Weiterleitungsproblem für die SPF-Ausrichtung mit DMARC für vertrauenswürdige Weiterleitungen beseitigen. Außerdem bleiben DKIM-Signaturen meistens im Takt, es sei denn, signierte Felder werden vom Spediteur geändert. DMARC kann also weiterhin basierend auf DKIM bestehen.

Eine letzte Sache:

In Ihrer DMARC-Richtlinie veröffentlichen Sie eine sp=noneRichtlinie für alle Subdomänen, die andernfalls die p=quarantineRichtlinie erben würden . Dies führt dazu, dass jeder, der Ihre Domain fälschen möchte, einfach eine beliebige Subdomain auswählen kann app.mydomain.co.uk. Vielleicht ist dies ein gewünschtes Setup, aber ich wollte nur darauf hinweisen.

Reinto
quelle