Le indicazioni riportate in questo articolo “DMARC per Proteggere Il Nostro Dominio” sono frutto di un approfondimento pratico e personale del problema e delle possibili soluzioni adottate. L’articolo non vuole essere una trattazione esaustiva dell’argomento, ma solo uno spunto per evidenziare il tema e promuovere ulteriori approfondimenti. I riferimenti citati in calce sono solo alcuni dei molti reperibili in Internet e sono stati inclusi solo per comodità del lettore. NSC s.r.l. non è associata con aziende o enti citati nel testo o nelle referenze in calce al testo.

DMARC per Proteggere Il Nostro Dominio

1. Introduzione

… ci sono giorni che ….

sono più i messaggi EMail finiti nel cestino taggati come ***SPAM*** che quelli rimasti da leggere nella nostra Inbox… , o no?

Ma il vero terrore di tutti noi responsabili di uno o più domini Internet è ricevere una comunicazione del tono “no, non abbiamo ricevuto la vostra email con la presentazione / offerta / ecc. perché è finita nello SPAM… o perché è stata respinta dal nostro server di posta elettronica…”

Beh, prima di cospargerci il capo di cenere e preparare le spalle alla sicura fustigazione imposta dal nostro Direttore Commerciale … cerchiamo di anticipare il nemico e di correre ai ripari!

Lo SPAM, ovvero la mole di messaggi indesiderati inviati da mittenti contraffatti, è un problema: per la noia nell’eliminare i messaggi, per il rischio che sia un veicolo di distribuzione di software maligno, e anche per la reputazione del nostro sito, e quindi per la certezza che le nostre normali EMail vengano recapitate e lette dai destinatari senza prima essere cestinate anch’esse… proprio come SPAM!
Non basta infatti il ‘mass mailing’ legale, ma comunque non richiesto ed indesiderato: lo SPAM, se fatto da terzi utilizzando come indirizzi mittenti quelli associabili al nostro dominio (es. info@nesecon.com), può portare a fare scattare le difese dei server di posta contro tutto quello che proviene dal nostro dominio, finendo con il danneggiare il flusso di EMail da noi inviate, singole, o ‘massive’ che siano.

Rimando ai riferimenti citati in calce per approfondimenti ulteriori e passo ad indicare come ci si può proteggere dallo SPAM, e soprattutto come si può proteggere la reputazione del proprio dominio di posta elettronica.

2. Come nasce lo SPAM.

Inizialmente l’unico che potesse bloccare lo SPAM era proprio il destinatario del messaggio: esaminando il mittente, il soggetto, il contenuto del messaggio si può valutare innanzitutto se il messaggio può interessarci, e quindi se è una frode oppure no.
Anche oggi acquisire questa pratica è importante per ognuno di noi, e per fortuna alcuni Client di Posta Elettronica incorporano meccanismi più o meno flessibili per marcare come ***SPAM*** i messaggi sospetti, lasciando comunque all’utente l’ultima parola.

Con il diffondersi dei servizi di EMail gestiti dagli ISP, questi ultimi hanno cercato di inventare dei meccanismi in grado di riconoscere lo SPAM direttamente sui server utilizzati per la gestione della posta elettronica in arrivo. Questi meccanismi possono agire in diversi modi:

• verificando su appositi servizi di BlackList se l’indirizzo EMail mittente o il server di posta usato per l’invio, sono stati denunciati come possibile sorgente di SPAM
• verificando la coerenza dei dati di invio del messaggio
• verificando l’autenticità del messaggio

Quindi alcuni dei meccanismi necessari ad uno SPAM per sperare di avere un po’ di successo, visti i meccanismi anti-SPAM usati dai provider, sono:

• un elenco di indirizzi destinatari da usare come bersaglio dello SPAM. …Beh, penso che tra clear e dark web non sia veramente difficile per un male intenzionato trovare database più o meno qualificati con migliaia di indirizzi email…
• un indirizzo mittente appartenente ad un dominio esistente dietro cui mascherarsi. Può essere anche una casella non esistente (es. pinco.pallo@nesecon.com), ma il dominio, la parte dopo la ‘@’ deve essere registrato,
• un server di posta a cui consegnare le email per l’invio, anch’esso riconosciuto come valido dalla rete. L’ideale sarebbe usare il server di posta registrato come associato al dominio che si usa come mittente (record MX della zona DNS del dominio). Ma se il nostro MAIL Server è opportunamente protetto con filtri e con autenticazione del mittente, beh si possono usare altri server pubblici…

Qui descriveremo come far si che il nostro dominio non venga riconosciuto come sorgente di SPAM, e quindi come proteggere la posta elettronica che inviamo.

3. Difendiamo la reputazione del nostro dominio.

3.1. Proteggiamo il nostro Server di Posta Elettronica.

La prima difesa è far sì che il server di Posta Elettronica che usiamo per l’invio delle email sia riconosciuto da Internet e possa essere usato solo da utenti autorizzati:

• deve avere un indirizzo IP referenziato in un dominio DNS, in maniera da potere identificare l’ente responsabile dell’uso di quell’indirizzo IP
• deve accettare solo messaggi inviati da Client di posta conosciuti, per mezzo del loro indirizzo IP o meglio per mezzo di una identificazione con credenziali
• personali, in modo da potere a richiesta fornire una traccia fino al client mittente del messaggio.

Nel caso si utilizzino i server EMAIL del proprio provider, allora sarà quest’ultimo a curare la protezione dei propri server.

3.2. Seguiamo le raccomandazioni SPF.

SPF (Sender Policy Framework) è un Internet Standard definito dalla RFC 7208.

Implementando SPF il server del dominio di posta destinatario verifica la coerenza del server di posta mittente con i dati dichiarati per il dominio mittente.

Esempio:
Il record SPF del dominio ‘nesecon.com’: è simile a questo:[nesecon.com. TXT 900 “v=spf1 ip4:x.x.x.x ip4:x.x.x.x include:mail.foo.net ~all” ]

Traduzione:
Le email inviate da utenti nnnn@nesecon.com possono essere inviate solo da SMTP server aventi:

• gli indirizzi IP dei server SMTP in uscita gestiti direttamente da NSC s.r.l.
• gli indirizzi dichiarati dalla policy SPF del dominio “mail.foo.net” usato dall’ISP fornitore di servizi Internet usato da NSC s.r.l.

In tutti gli altri casi le email verranno comunque passate e taggate come “SPAM” (~all)

SPF richiede solo la compilazione del record SPF nel DNS del dominio mittente.
Il record SPF non può richiedere più di 10 query DNS per la sua elaborazione, contando anche quelle generate dalle eventuali clausole INCLUDE, A, MX, EXISTS.
L’ISP usato da NSC s.r.l. usa ha una propria SPF policy, e questa deve essere referenziata nel record SPF del dominio ‘nesecon.com’ (vedi referenze)

ATTENZIONE!!!

SPF esegue i controlli sulla base dell’ header “Mail From:” dell’envelope, che può essere diverso dal campo “From:” della mail stessa, e che viene di solito visualizzato dai client di posta. Quindi uno spammer può inviare da un mail-address di un dominio terzo (Header “Mail From:”) una mail di spam contraffacendo il campo “From:” della mail stessa. Il controllo SPF dell’envelope verrà superato, e l’utente vedrà il mittente contraffatto e non quello reale. Questo problema viene risolto da DMARC, che richiede l’allineamento dei due campi mittente.

3.3. Seguiamo le raccomandazioni DKIM.

DKIM (DomainKeys Identified Mail) è un Internet Standard definito dalla RFC 6376, del Settembre 2011, aggiornata dalle RFC 8301 e RFC 8463.
Implementando DKIM il server del dominio di posta destinatario verifica l’integrità e la validità del messaggio sulla base di una firma digitale di alcuni campi (header) del messaggio ritenuti essenziali, quali mittente, destinatario, soggetto, data, ecc. , apposta da un ente considerato affidabile, quali:

• il mittente
• il Mail Submission Agent (server SMTP in uscita)
• un server SMTP di transito incaricato dal mittente dell’apposizione della firma digitale

La verifica viene fatta dal SMTP server di arrivo, sulla base della presenza degli header “DKIM-Signature” presenti nel messaggio, usando la chiave pubblica del firmatario, specificata in un apposito record DNS del dominio mittente.

DKIM quindi richiede:

• la generazione di una firma elettronica, in proprio o tramite un service terzo
• la configurazione del punto di firma, in proprio sul client di posta mittente, o sul server di posta mittente, o tramite un service terzo
• l’apposizione della firma a protezione dei campi selezionati, obbligatori e facoltativi, fatta sul punto di firma
• la configurazione di un record DKIM sul DNS del dominio mittente, contenente la policy e la PubKey per la validazione della firma un dominio può usare più chiavi, o per differenti servizi, o per rotazione, o perché fornite da diversi service firmatari esterni: ogni chiave è identificata negli header e nel DNS da un apposito ‘selector’.

ATTENZIONE!!!

• DKIM non esegue la crittografia del messaggio, ma certifica con la firma solo l’integrità del messaggio
• DKIM firma solo alcuni degli header del messaggio, a discrezione della policy del firmatario, e quindi non garantisce l’integrità di tutto il messaggio
• in particolare DKIM non può gestire le parti MIME del messaggio, ovvero qualsiasi corpo di messaggio che non sia scritto in normali caratteri ASCII, o formattato, o compresso, o incluso, o attached, ecc.
• la chiave di firma può essere soggetta a “spoofing” e quindi uno ‘spammer’ può inviare il messaggio dall’interno della organizzazione, recuperarlo con gli header di firma corretti e da qui costruire altri messaggi e fare spam e phishing.

DKIM richiede una collaborazione con l’ISP di riferimento, e l’uso di un servizio di firma sulla posta inviata.

3.4. Seguiamo le raccomandazioni DMARC.

DMARC (Domain-based Message Authentication, Reporting & Conformance) è un Internet Standard definito nella RFC 7489.

DMARC è una procedura di verifica avanzata dell’autenticità una email e del trattamento delle EMail su un Server SMTP incaricato della gestione della Posta in Arrivo (MX) al fine di ridurre le possibilità di email spoofing e di spam.

DMARC unisce e migliora l’azione delle specifiche SPF e DKIM: se un flusso di SPAM supera i controlli DMARC, allora si potrà restringere la ricerca della sorgente di SPAM ai soli utenti effettivamente autorizzati ad usare gli indirizzi email usati nello SPAM.

DMARC, se correttamente implementato sul proprio server SMTP di ricezione della posta, riduce il rischio che gli utenti del proprio dominio siano oggetti di SPAM o di mailing malevolo, restringendo la ricezione alle sole email che abbiano passato i check DMARC secondo le policy DMARC.

E’il dominio a cui appartengono i mittenti della email che impone le azioni da prendere in caso di check falliti:

• None: la mail passa, e viene solo referenziata nei report DMARC inviati ai domini mittenti e destinatari
• Quarantine: la mail viene messa in quarantena e poi rifiutata, e segnalata nei report
• Reject: la mail viene respinta e segnalata nei report.

E’ consigliabile paritre dalla policy ‘None’, per verificare il funzionamento dell’intero meccanismo e risolvere i problemi di compliance con i destinatari che esigono che il mittente specifichi una policy DMARC.

Successivamente si potrà passare alla policy ‘Quarantine’ ed osservare attentamente i report, al fine di verificare che non ci siano problemi di ricezione email (in alcuni casi abbiamo rilevato che servizi in cloud di SMTP in uscita applicavano autonomamente un drop in caso di azionamento della policy ‘quarantine’, tranciando di fatto flussi di email lecite ….)

Se i passi precedenti avrenno avuto un esito positivo, e soprattutto se non avranno causato problemi alle email inviate lecitamente dal nostro dominio, allora si potrà passare alla policy ‘Reject’, sempre sorvegliando i report e i flussi di email.

La corrispondenza tra “Mail From:” header (envelope Mail From) e il campo “From:” della email viene rafforzata da DMARC con la funzione di “Identifier Allignment”, per evitare spoofing del campo “From”, che è quello che viene poi effettivamente visualizzato dai Mail Client.

Inoltre DMARC utilizza i risultati delle verifiche fatte da SPF e/o da DKIM, integrandoli con i controlli di allineamento tra gli header “Mail From:” e “From:” (SFP) e tra il dominio usato per l’autenticazione della firma e il “From:” header (DKIM), al fine di valutare la veridicità del mittente della email, migliorando quindi l’efficacia di SPF e di DKIM

A differenza di SPF e di DKIM, l’oggetto principale di verifica di DMARC è l’header “From:” del messaggio, e non l’header “Mail from:” dell’envelope. Per validare l’EMail è sufficiente che il controllo di allineamento abbia successo per uno dei protocolli SPF / DKIM utilizzati.

Esempio:
Il record SPF del dominio ‘nesecon.com’: è simile a questo:[_dmarc.nesecon.com. TXT 900 “v=DMARC1; p=none; rua=mailto:xxxxxx@nesecon.com; ruf=mailto:xxxxx@nesecon.com; sp=none; ri=86400”]

Traduzione:

• le email inviate da utenti ‘nnnn@nesecon.com’ o da sottodomini di ‘nesecon.com’ possono essere sottoposte dai server SMTP di destinazione alle verifiche DMARC versione 1 e SPF e DKIM, se sono presenti nella zona DNS del dominio “nesecon.com” i relativi record;
• in caso di fallimento delle verifiche la mail verrà riportata nei report e comunque consegnata al destinatario;
• i report relativi alle statistiche dei controlli DMARC (‘rua=’)e quelli relativi ai dettagli delle singole EMail email non conformi (‘ruf=’) verranno inviati come email all’indirizzo ‘xxxxxx@nesecon.com’.

4. I rapporti DMARC.

Un’altra novità introdotta da DMARC è la possibilità di ricevere dai server SMTP che eseguono la procedura di controllo dei report sull’esito dei controlli DMARC. Questi rapporti vengono inviati come allegati email agli indirizzi indicati nel campo ‘rua=’ del record DMARC, sotto forma di file XML compressi con zip o con gzip.

Essendo file XML la loro lettura non è pratica, ma esistono diversi siti in rete che mettono a disposizione strumenti di formattazione anche sofisticata dei risultati, sia gratuiti che a pagamento.

Per gli avventurosi sono disponibili dei tool open source che permettono di creare un microservizio locale di ricezione, analisi, archiviazione e consultazione statistica dei report.

In abbiamo adottato in via sperimentale “dmarc-viewer’, installato come applicazione Docker-Composer su una Virtual Machine Linux Ubuntu.
Grazie ad uno script Python di supporto il microserver si connette alla mailbox indicata nel record DMARC del dominio per ricevere i messaggi contenenti i report, ne estrae gli allegati, li decomprime e quindi lancia il comando di analisi e importazione dei report nel database. Un microserver WWW permette la consultazione dei dati statistici dei report, integrando una gradevole esposizione grafica della geolocalizzazione dei mittenti.

5. Riferimenti

Per finire alcuni riferimenti per approfondire il tema:

– Introduzione allo SPAM
Da Wikipedia, l’enciclopedia libera: Spam

– DMARC, SPF, DKIM
How to Implement DMARC/DKIM/SPF to Stop Email Spoofing/Phishing: The Definitive Guide

– SPF: Sender Policy Framework
Da Wikipedia, l’enciclopedia libera: Sender Policy Framework
Da Register.it: Impostare il record SPF per fare mailmarketing

– DKIM: DomainKeys Identified Mail
Da Wikipedia, l’enciclopedia libera: DomainKeys Identified Mail
DKIM.org
Da Google Workspace: Impedire lo spoofing e lo spam con DKIM
DKIM: How to Explain to you grandmother

– DMARC: Domain-based Message Authentication, Reporting & Conformance
Da Wikipedia, l’enciclopedia libera: DMARC

Free Tools:

– DMARC checker:
ddmarcanalyzer.com: DMARC Record Check
easydmarc.com: DMARC Record Checker
dmarcly.com: SPF/DKIM/DMARC Tools
dmarcly.com: SPF Record Checker – Check SPF Record – SPF Record Lookup

easydmarc.com: DMARC XML Report Analyzer

– OpenSource DMARC Report Analyzer:
github.com: docker-dmarc-report
github.com: dmarc-viewer

Analyze and Visualize DMARC Results Using Open-Source Tools