Come leggere un report DMARC aggregato.

di Giulio di Bari :: 10 marzo 2020

DMARC è un protocollo, il cui sviluppo è partito nel 2012 per iniziativa di PayPal, e che serve a tutelare gli utenti dalle truffe via email consentendo ai mittenti di negare il recapito dei messaggio quando non sono realmente stati inviati da loro.

In passato (ma anche oggi.... ), chiunque volesse inviare un messaggio email con mittente, ad esempio, "@paypal.com", per tentare una truffa, poteva farlo senza troppi problemi, il protocollo SMTP infatti non prevede nativamente un sistema di verifica sul campo “From:”. Dovranno essere i sistemi antispam a capire se il messaggio è realmente proveniente da PayPal oppure no.

Nel corso degli anni sono stati implementati metodi quali SPF e DKIM i quali hanno consentito di risalire alla vera identità del mittente del messaggio ma nessuno di questi è stato realmente risolutivo per limitare gli abusi. Abbiamo già dedicato vari articoli su questi argomenti, e su come creare un record DMARC. Questo articolo è particolarmente complesso, per cui ti consigliamo un buon ripasso degli argomenti già trattati (i link sono a fondo articolo).

Con DMARC è possibile richiedere che il provider che riceve una email si comporti in un determinato modo nel caso in cui la stessa email che non superi i controlli SPF (provenienza IP) e DKIM (firma), e quel modo è definito dal mittente stesso nel record DMARC. In precedenza, invece, era il provider ricevente a decidere cosa fare di un messaggio e quindi, nel caso, a considerarlo spam.

Ecco un esempio di record DMARC: il titolare del dominio "miosito.it" pubblica un record DNS dove dice che se i messaggi con mittente @miosito.it non arrivano esattamente dai loro indirizzi IP (definiti nel record SPF) e non sono firmati da una chiave DKIM emessa da loro stessi (quindi con d=miosito.it) devono essere respinti:

v=DMARC1; p=reject; rua=mailto:log@miosito.it; ruf=mailto:log@miosito.it

Il server MX che riceve un messaggio da un indirizzo @miosito.it, e che supporta DMARC, deve applicare alla lettera queste indicazioni.

Implementare DMARC, a livello di mittente, è semplice: "basta" che per il vostro dominio, a livello DNS, sia creato un record SPF, una record DKIM, ed un record DMARC.

Abbastanza più complesso è invece implementarlo a livello di server ricevente. Non tutti i server riceventi infatti implementano il DMARC, ma il suo utilizzo si sta diffondendo. Ad esempio è implementato su Gmail, Yahoo, Hotmail...

La creazione del record DMARC determina, da parte dei provider riceventi che implementano il DMARC, l'invio di report: i report aggregati (all'indirizzo definito nel paramentre rua) e i report forensi (all'indirizzo definito nel paramentre ruf), tuttavia i report forensi non sono ancora implementai da molti provider.

Oggi ci occupiamo dei report aggregati.

I report aggregati DMARC

I rapporti aggregati DMARC forniscono informazioni su quali e-mail si stanno autenticando con SPF (Sender Policy Framework) e DKIM (DomainKeys Identified Mail), e quali no.

I report aggregati forniscano informazioni aggregate, e quindi sintentiche. Non contengono invece informazioni sul contenuto effettivo dei messaggi di posta elettronica, come ad esempio alcuni header dei messaggi come “To” , “From” ed il "corpo" del messaggio, informazioni invece contenute nei report forensi.

Per ricevere un rapporto aggregato, nel record DMARC, dobbiamo indicare "rua=mailto:dominio@esempio.com" dove al posto di dominio@esempio.com dobbiamo indicare la casella email nella quale vogliamo ricevere il report.

Una volta configurato il record DMARC, i server destinatari che utilizzano il sistema DMARC invieranno rapporti aggregati giornalieri alla destinazione definita nel tag rua.

Esempio di report aggregato

Vediamo assieme un esempio pratico.

Abbiamo un dominio, ed un sito web, "www.miosito.it", hostato presso Aruba.it.

Dal sito invieremo agli utenti email, come ad esempio nel caso di risposte automatiche nel caso di compilazione di modulo di richieste informazioni, o email con le quali effettuiamo un controllo email a seguito di registrazione al sito. Le mail vengono inviate utilizzando l'smtp di aruba, con IP 62.146.153.51 (in realtà essendo in hosting gli ip di invio possono essere vari, ma ipotizziamo che sia solo questo).

Abbiamo inoltre anche un server dedicato, con un solo IP dedicato 94.112.124.63, ed un dominio associato, ad esempio "mail.miosito.it", che utilizziamo con Postfix per l'invio di newsletter agli stessi utentie: qui l'smtp siamo noi.

Sul server dedicato abbiamo:

definito il RESERVE DNS: cioè all'ip 94.112.124.63 risponde il dominio mail.miosito.it e viceversa
installato OpenDkim e creato la coppia chiave privata e chiave pubblica, utilizzando il parametro "-d miosito.it". In questo modo tutti i messaggi in uscita con il dominio "miosito.it" avranno apposta la firma DKIM. Abbiamo copiato la chiave pubblica e creato il record DNS DKIM.
```
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg.....
```
Abbiamo inoltre creato un record DNS SPF, in cui abbiamo autorizzato come mittente autorizzato questo IP, ed anche l'altro del sito.
```
v=spf1 mx ip4:94.112.124.63 ip4:62.146.153.51 ~all
```
Infine abbiamo creato questo record DMARC per il nostro dominio: indichiamo ai server che ricevono le email, indirizzate dal nostro dominio, di inviare una email giornaliera aggregata, con il risultato dei controlli SPF e DKIM, all'indirizzo "log@miosito.it".
```
v=DMARC1; p=none; rua=mailto:log@miosito.it
```

Dal nostro sito, e dal server, inviamo email agli utenti del sito. Tra questi ci sono utenti con indirizzi email di Yahoo e, come detto, Yahoo implementa il controllo DMARC.

Ecco un report aggregato inviato da Yahoo, che riceviamo contenuto all'interno di un file zip (tutti i report aggregati arrivano zippati):

<?xml version="1.0"?>	
<feedback>	

  <report_metadata>	
    <org_name>Yahoo! Inc.</org_name>	
    <email>postmaster@dmarc.yahoo.com</email>	
    <report_id>1583385951.825954</report_id>	
    <date_range>	
      <begin>1583280000</begin>	
      <end>1583366399</end>	
    </date_range>	
  </report_metadata>
	
  <policy_published>	
    <domain>miosito.it</domain>	
    <adkim>r</adkim>	
    <aspf>r</aspf>	
    <p>none</p>	
    <pct>100</pct>	
  </policy_published>
	
  <record>	
    <row>	
      <source_ip>62.146.153.51</source_ip>	
      <count>13</count>	
      <policy_evaluated>	
        <disposition>none</disposition>	
        <dkim>fail</dkim>	
        <spf>pass</spf>	
      </policy_evaluated>	
    </row>	
    <identifiers>	
      <header_from>miosito.it</header_from>	
    </identifiers>	
    <auth_results>	
      <dkim>	
        <domain>aruba.it</domain>	
        <result>pass</result>	
      </dkim>	
      <spf>	
        <domain>miosito.it</domain>	
        <result>pass</result>	
      </spf>	
    </auth_results>	
  </record>
	
  <record>	
    <row>	
      <source_ip>94.112.124.63</source_ip>	
      <count>153</count>	
      <policy_evaluated>	
        <disposition>none</disposition>	
        <dkim>pass</dkim>	
        <spf>pass</spf>	
      </policy_evaluated>	
    </row>	
    <identifiers>	
      <header_from>miosito.it</header_from>	
    </identifiers>	
    <auth_results>	
      <dkim>	
        <domain>miosito.it</domain>	
        <result>pass</result>	
      </dkim>	
      <spf>	
        <domain>miosito.it</domain>	
        <result>pass</result>	
      </spf>	
    </auth_results>	
  </record>	

</feedback>

Analizziamo il contenuto del report aggregato

<report_metadata>

Un primo blocco di informazioni, racchiuso nel tag <report_metadata>, è relativo al server destinatario che utilizzza il sistema DMARC, tra cui

<org_name>: Nome del provider che invia il report
<emai>: L’indirizzo email usato dal provider per inviare il report
<report_id>: ID del report
<date_range>: Inizio e fine dell’intervallo di analisi considerato (dal ... al ), rappresentato in formato Unix Timestamp (cioè in secondi a partire dal 1 gennaio 1970)

<policy_published>

Un secondo blocco di informazioni, racchiuso nel tag <policy_published>, contiene informazioni relative alle regole DMARC da noi impostate nel record DNS

<domain>: è il dominio per il quale stiamo effettuando il controllo
<adkim>: è la "modalità di allineamento per DKIM" (vedi l'articolo dedicato a DKIM!). Non lo abbiamo definito nel record DMARC per cui vale il valore di default "r" cioè "relaxed"
<aspf>: è la "modalità di allineamento per SPF" (vedi l'articolo dedicato a DKIM!). Non lo abbiamo definito nel record DMARC per cui vale il valore di default "r" cioè "relaxed"
<p>: la politica da utilizzare nel caso in cui DKIM e SFP non siano verificati. Nel nostro caso è "none", cioè non facciamo nulla (quindi accettiamo le email sempre).
<pct> Percentuale di messaggi a cui applicare la politica DMARC. Anche questo non lo abbiamo definito nel record DMARC per cui vale il valore di default cioè 100.

<record>

Segue la parte più interessante, cioè il riepilogo dei risultati di autenticazione: ogni IP avrà un blocco di informazioni identificate dal tag <record>.

Nel nostro esempio, inviamo email da due IP, per cui mi aspetto almeno due blocchi <record>: il primo <record> è relativo all'ip del sito web, il secondo all'ip del server ("almeno" perchè potrebbero esserci più di 2 record, se qualcuno inviasse in modo fraudolento email con il nostro mittente da un altro server).

Ogni blocco <record> contiene queste informazioni

<source_ip>: l'ip da cui arriva la "nostra" email
<count>: numero di email ricevute dall'ip sopra indicato
<policy_evaluated>: la politica DMARC applicata
<auth_results>: il risultato dei controlli DKIM e SPF

Adesso spieghiamo il contenuto di <auth_results> e <policy_evaluated>, con riferimento al primo <record>

<auth_results>

Analizziamo il primo <record>, cioè quello relativo all'IP del sito 62.146.153.51.

In <auth_results> troviamo i seguenti tag:

<dkim> è il risultato dell’autenticazione DKIM.
Viene verificata se il dominio "d=" nella firma DKIM contenuta nella email, ed il dominio "d=" presente nel record DNS DKIM, combaciano. Il risultato è pass" se il controllo è superato, "fail" se non superato.
<spf> è il risultato dell'autenticazione SPF.
Viene verificato che l'IP del dominio contenuto nell'header "Return-PATH" della email è autorizzato dal record SPF. Il risultato è "pass" se superato, cioè se inviato da un IP autorizzato, "fail" se non superato.

Nel nostro esempio non passiamo il controllo DKIM, mentre passiamo il controllo SPF.

Per capirne il motivo analizziamo un estratto degli header di una email inviata dal sito

Return-Path: <info@miosito.it>
.......
Received: by webxc247s04.ad.aruba.it (Postfix, from userid 19207147)
	id 912881536001; Fri,  6 Mar 2020 13:21:05 +0100 (CET)
.......
From: MioSito <info@miosito.it>
.......
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1;
	t=1583497265; .....

Analizziamo questi header:

Il mittente ("From") della mail siamo noi "info@miosito.it"
La email è spedita usando l'smtp di aruba, per cui negli header vedremo che provengono dal dominio aruba.it (Received: by webxc247s04.ad.aruba.it)
La firma DKIM presente nella mail è una firma di Aruba, non generata da noi, per cui fa riferimento al dominio aruba.it.

Il controllo DKIM non passa, perchè la firma è del dominio "d=aruba.it", mentre il record DKIM che abbiamo pubblicato nel DNS fa riferimento al dominio "d=miosito.it": non c'è corrispondenza quindi il risultato è "fail"!

<dkim>	
  <domain>aruba.it</domain>	
  <result>fail</result>	
</dkim>

Il controllo SPF invece passa perchè avevamo autorizzato l'IP 62.146.153.51 nel record SFP. L'ip che viene verificato è quello del dominio contenuto nell'header "Return-PATH" del messaggio. L'ip di miosito.it è 62.146.153.51 per cui c'è corrispondenza.

<spf>	
  <domain>miosito.it</domain>	
  <result>pass</result>	
</spf>

<policy_evaluated>

Adesso vediamo il blocco <policy_evaluated>.

Nel record DMARC abbiamo indicato come comportarci di fronte a mancate verifiche di SFP e DKIM, definendo nelle regole tra cui "adkim" e "aspf".

Abbiamo fatto la verifica sia DKIM sia SPF, adesso ci aspettiamo da DMARC il responso finale, e quindi la politica da applicare.

<disposition>none</disposition>	
<dkim>fail</dkim>	
<spf>pass</spf>

Va letto in questo modo.

<policy_evaluated><spf>: indica l' "allineamento SPF" ("SPF alignment") cioè verifica la corrispondenza tra il dominio del mittente indicato nel campo "From" del messaggio e quello del "Return-PATH".
E non va confuso con il <auth_results><sfp><result> che invece, come abbiamo detto, verifica la corrispodenza tra IP del "Return-PATH" e IP autorizzato nel record SPF.

<policy_evaluated><dkim>: indica l' "allineamento DKIM" ("DKIM alignment") cioè verifica che il dominio del mittente indicato nel campo "From" ed il dominio contenuto nel parametro "d=" della firma coincidono.
E non va confuso con il <auth_results><sfp><dkim> che invece, come abbiamo detto, verifica la corrispodenza tra il dominio "d=" contenuto nella firma apposta alla mail e il dominio "d=" presente nel record DKIM.

Questi "allineamenti" sono stati definiti nei parametri "adkim" e "aspf", ed in entrambi i casi abbiamo definito la regola "r" ("relaxed").

<policy_evaluated><disposition>: è la "politica" da applicare al messaggio ed è il risultato dei due controlli precedenti: "none", come avevamo impostato nel paramtro "p"

Tutto chiaro ... o no? :-)

Capisco, non è immediato, ma col tempo ci prenderete la mano.

Analizziamo adesso il secondo record.

In <auth_results> entrambi i controlli passano, perchè la firma apposta nella mail, viene apposta da OpenDkim del nostro server, ed il dominio presente sarà "d=miosito.it" che combiacia con il dominio contenuto nel record DKIM. L'ip era stato autorizzato dal record SPF. Per cui i controlli sono entrambi "pass".

<dkim>	
  <domain>miosito.it</domain>	
  <result>pass</result>	
</dkim>	
<spf>	
  <domain>miosito.it</domain>	
  <result>pass</result>	
</spf>

E la <policy_evaluated> sarà:

<policy_evaluated>	
   <disposition>none</disposition>	
   <dkim>pass</dkim>	
   <spf>pass</spf>	
</policy_evaluated>

Per oggi ci fermiamo qui.

Certamente, leggere questi report a uno a uno è una vera impresa. Ma se siete un minimo programmatori potreste raggruppare tutti i report in un folder ed elaborarli con uno script, ad esempio in PHP, per ottenere un risultato riepilogativo come questo esempio che ho scaricato dalla rete.

In un report aggregato, come abbiamo visto, sono riportate informazioni sintetiche, non il dettaglio delle mail (estratti degli header) che non hanno superato i controlli. Queste informazioni sono invece presenti nel report "failure" chiamato anche "forensic" cioè "forense" a cui dedicheremo prossimamente un articolo.

Stay tuned!

Approfondimenti

Sito ufficiale DMARC