DMARC - comprensione dei report aggregati


8

TL; DR
Ricevo molti feedback DMARC da account / siti Web con i quali non ho contatti e desidero chiarire se dovrei intraprendere un'azione o se questi rapporti di feedback sono informativi di problemi gravi?

Gestisco un server WHM e utilizzo SPF e DKIM (e _DMARC), tutte le e-mail vengono inviate dallo stesso server di dominio.

Un esempio di configurazione DNS per il mio _DMARC (e DKIM e 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:me@mydomain.co.uk!90m; 
                                ruf=mailto:me@mydomain.co.uk; 
                                rf=afrf; pct=100; ri=86400"

e per quanto posso dire questo è impostato e funziona come previsto.

tuttavia, ricevo molti messaggi automatici da vari domini nel World Wide Web, che non hanno nulla a che fare con il mio dominio. Sono l'unica persona che utilizza le e-mail dal mio dominio, nessun altro sta inviando e-mail dal mio dominio.

Ad esempio, questa mattina ho ricevuto un rapporto aggregato DMARC da Comcast in cui si afferma:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
    <version>1.0</version>
    <report_metadata>
        <org_name>comcast.net</org_name>
        <email>dmarc-admin@alerts.comcast.net</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>

No, non riconosco nessuno dei dettagli indicati qui a parte il mio dominio, l'indirizzo IP fornito <source_ip>non è il mio indirizzo IP e non sono a conoscenza di alcun contatto con Comcast.

Fondamentalmente, ricevo un sacco di questi avvisi e non riesco a trovare alcun feedback per dirmi se sono solo informativi e possono essere dimenticati (nel qual caso che senso hanno?) O se posso fare qualcosa con il mio server per migliorare i guasti di cui la comunicazione mi informa.

COSÌ:

  • Questi rapporti sono qualcosa su cui si può agire?
  • In che modo i rapporti DMARC come questi devono essere gestiti alla mia fine?
  • Questi rapporti sono indicatori di qualsiasi forma di compromissione dell'account
  • può / il numero di questi rapporti [potenzialmente] riflettere male sul mio nome di dominio sul resto del web?

Vale la pena notare che sospetto che la risposta agli ultimi due proiettili sia "No", ma non sono un esperto di questi.


Ho già letto questo post , le FAQ DMARC e questo argomento , ma non ci sono molte informazioni. su come intendiamo reagire ai rapporti aggregati. Sono consapevole che i rapporti DMARC "non riusciti" possono essere causati dai programmi di inoltro della posta, anche se spero di annullare questa possibilità con il mio SPF ~all.

Nel complesso penso che non dovrei preoccuparmi di questi rapporti, ma vorrei una seconda opinione a causa di ciò che percepisco come regolarità e ( penso ) un numero relativamente significativo di rapporti aggregati che sto ricevendo.

Risposte:


6

Questi rapporti sono qualcosa su cui si può agire?

Sì, ma la maggior parte delle informazioni si spera confermeranno che tutto è OK con la tua configurazione.

In che modo i rapporti DMARC come questi devono essere gestiti alla mia fine?

In genere questi rapporti vengono elaborati da un sistema automatizzato che trasforma questi dati in graziosi rapporti con grafici, statistiche e problemi che richiedono attenzione. Se non hai visto questo tipo di sistema, forse dovresti dare un'occhiata a dmarcian.com che fornisce un servizio di base gratuito che ti aiuterà a iniziare e capire cosa puoi e non puoi fare o vedere. Perché questo funzioni, dovresti usare un indirizzo e-mail che ti forniscono nel tuo record DMARC.

Questi rapporti segnalano qualsiasi forma di account compromessa?

No, sono solo rapporti di tutte le attività dei server compatibili con DMARC che hanno elaborato messaggi che affermano di provenire dal tuo nome di dominio, in sostanza ti dicono che hanno ricevuto un messaggio, da dove proviene e cosa hanno fatto con esso e perché.

Il numero di questi rapporti può [potenzialmente] riflettersi male sul mio nome di dominio sul resto del Web?

No, questi rapporti vengono inviati solo all'indirizzo e-mail fornito nel record DMARC e non pubblicati sul Web. L'unico vero potenziale per un impatto negativo è se si imposta erroneamente il proprio SPF e / o DKIM e si finisce per ottenere molti messaggi rifiutati / bloccati, ma almeno con DMARC lo si saprebbe.


Grazie per la rassicurazione lì. Da allora ho creato un account (gratuito) dmarcian.comma non sono stato immediatamente sicuro del motivo per cui sarebbe utile in quanto tale, ma suppongo che riassuma i dati di feedback che i rapporti mi danno.
Martin

1
È solo più facile per gli occhi, soprattutto quando la quantità di dati nei report e la frequenza di riceverli possono essere significativi. I report DMARC sono progettati per essere elaborati da computer, l'interfaccia di dmarcian.com è stata progettata per essere letta dagli umani. Potresti sempre trovare la tua soluzione di elaborazione automatica se non sei un fan dell'interfaccia di dmarcian.com. Ne esistono anche altri che potresti esplorare, ma questo è l'unico gratuito che conosco. Spero che sia di aiuto.
richhallstoke,

2

Come risposta al tuo esempio: molti errori DMARC possono essere ricondotti a liste di inoltro e mailing, ad esempio con Google Groups for Business. Tuttavia, nel rapporto ci mostra che l'e-mail è stata inviata da un host, parte di secureserver.net. L'SPF è stato verificato sul percorso di ritorno bounce.secureserver.nete passato.

Molto probabilmente si trattava di un messaggio di rimbalzo dal tuo servizio anti-SPAM o SMTP in entrata, rispedito al mittente dell'e-mail originale, che cercava di inviarti un'e-mail. Il rimbalzo verrà inviato per tuo conto con un percorso di ritorno modificato. SecureServer.net fa parte di GoDaddy, stai ospitando con GoDaddy o affiliato?

Come risposta alla tua dichiarazione:

Sono consapevole che i rapporti DMARC "non riusciti" possono essere causati dai programmi di inoltro della posta, anche se spero di annullare questa possibilità con il mio SPF ~all.

DMARC valuterà il passaggio solo se i controlli SPF o DKIM generano un passaggio, in linea con il Fromdominio dell'indirizzo. Quindi non sono sicuro di cosa tu voglia dire che ~allnega il problema.

Gli spedizionieri di solito riscrivono il return-pathproprio indirizzo di rimbalzo, impedendo l'allineamento con il dominio di origine. Il protocollo ARC è ancora in bozza, ma dovrebbe annullare questo problema di inoltro per l'allineamento di SPF con DMARC per spedizionieri fidati. Inoltre, le firme DKIM rimangono spesso intatte, a meno che i campi firmati non vengano modificati dallo spedizioniere. Quindi DMARC può ancora passare in base a DKIM.

Un'ultima cosa:

Nella tua politica DMARC, pubblichi una sp=nonepolitica per tutti i sottodomini, che altrimenti erediterebbero la p=quarantinepolitica. Ciò si traduce nel fatto che chiunque abbia la possibilità di falsificare il proprio dominio può semplicemente scegliere qualsiasi sottodominio da utilizzare, ad esempio app.mydomain.co.uk. Forse questa è una configurazione desiderata, ma volevo solo sottolinearlo.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.