DMARC

DMARC è un protocollo, il cui sviluppo è partito nel 2012 per iniziativa di PayPal, che serve a tutelare gli utenti dalle truffe via email consentendo ai mittenti di negare il recapito dei messaggio che non sono realmente inviati da loro.
Al momento chiunque voglia inviare un messaggio email con mittente @paypal.com, per tentare una truffa, può farlo senza troppi problemi, il protocollo SMTP infatti non prevede nativamente un sistema di verifica sul campo “From:”. Sta poi ai sistemi antispam 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.

Con DMARC è possibile richiedere esplicitamente per il titolare di un dominio cosa fare dei messaggi email che hanno come mittente il suo dominio stesso ma non rispettano certi criteri di provenienza IP (definiti via SPF) e di autenticazione (firma DKIM) in modo tale che il server ricevente non sia lui a dover decidere cosa fare del messaggio ma segua alla lettera quanto specificato nel record DNS DMARC.

In pratica PayPal (che qui usiamo come esempio) pubblica un record DNS dove dice che se i messaggi con mittente @paypal.com 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=paypal.com) devono essere respinti:
v=DMARC1; p=reject; rua=mailto:; ruf=mailto:,mailto:

Il server MX che riceve un messaggio da un indirizzo @paypal.com è che supporta DMARC deve applicare alla lettera questa “volontà”.
Il vantaggio di DMARC è quindi che rende possibile definire per i mittenti come i server riceventi devono trattare i messaggi provenienti dai loro domini, mentre in precedenza era l’antispam del destinatario a decidere in proprio se quel messaggio era realmente chi diceva di essere oppure no.

Implementare DMARC, a livello di mittente, è molto semplice e richiede solo che per il vostro dominio sia già definito un record SPF ed una firma DKIM, mediante dei Wizard DMARC è poi possibile creare il proprio record da inserire nel DNS.
Ma attenzione, nel caso la vostra policy sia di tipo “reject” tutti i messaggi che non rispettano esattamente questi criteri non verranno consegnati ai destinatari, quindi consigliamo di andare cauti con la sua implementazione partendo prima di tutto con una policy “none”.

Abbastanza più complesso è invece implementarlo a livello di server ricevente. Al momento una piena implementazione è presente su Gmail, Yahoo, Hotmail/Outlook.com e pochi altri.
In Fattispazio abbiamo iniziato da qualche settimana la sperimentazione dell’applicazione di DMARC (anche per far fronte alle forti ondate di spam provenienti da caselle email @libero.it).

Recentemente Yahoo e Libero.it hanno pubblicato la loro policy DMARC con reject/quarantine rispettivamente, il che vuol dire che se avete un indirizzo email con questi due provider ma non inviate email dai loro SMTP i vostri messaggi quasi certamente non arriveranno ai destinatari. Questo ha causato non pochi problemi agli utenti che erano abituati ad inviare email con SMTP di altri provider.

Ci sono tantissimi altri aspetti di DMARC di cui volutamente qui non abbiamo parlato, ad esempio il server ricevente ogni giorni deve inviare un report sulle email che non hanno rispettato gli standard definiti dal mittente ad uno specifico indirizzo email indicato nel record DNS di DMARC.
Maggiori informazioni nel sito dedicato dmarc.org
Pin It

© 2019 Progetti&Eventi srl, All Rights Reserved