Wikipedia

DMARC

sistema di validazione dei messaggi di posta elettronica
Questa voce sugli argomenti sicurezza informatica e Internet è solo un abbozzo.
Contribuisci a migliorarla secondo le convenzioni di Wikipedia. Segui i suggerimenti del progetto di riferimento.

DMARC, acronimo di Domain-based Message Authentication, Reporting & Conformance, è un complesso sistema di validazione dei messaggi di posta elettronica[1][2]. È stato sviluppato principalmente per contrastare l'email spoofing, una tecnica di attacco informatico ampiamente utilizzata nello spam e nel phishing[3]. Le caratteristiche di DMARC sono state definite nella RFC 7489[4] del marzo 2015.

Storia

modifica

I protocolli base utilizzati per l'invio e la ricezione della posta elettronica non consentono di verificare l'autenticità del mittente. È quindi relativamente semplice fare in modo che una email appaia proveniente da un certo indirizzo anziché dal mittente reale. Questa debolezza del sistema è stata ampiamente utilizzata per l'invio di spam confezionando i messaggi in modo che appaiano inviati da aziende o da mittenti noti al destinatario. La stessa tecnica è utilizzata anche nel phishing in modo da conferire maggiore autorevolezza al messaggio. In entrambi i casi il tentativo di attacco informatico si concretizza attraverso l'alterazione di alcune parti dell'intestazione della email ed in particolare del campo del mittente From:[5].

Lo sviluppo del protocollo DMARC è partito[6] nel 2010 ed ha visto la collaborazione di diversi soggetti interessati ad offrire sistemi di validazione della posta elettronica. Allo sviluppo del protocollo hanno partecipato alcuni tra i maggiori fornitori di caselle di posta elettronica come AOL, GMail, Hotmail e Yahoo! Mail interessati a proteggere i propri utenti da spam e phishing. Al progetto hanno partecipato anche istituti bancari, servizi di pagamento come Paypal e servizi internet come Facebook e LinkedIn i cui domini sono spesso abusivamente utilizzati nell'email spoofing.

Le specifiche del protocollo DMARC sono state pubblicate per la prima volta il 30 gennaio 2012 e sotto forma di RFC il 18 marzo 2015. Il lavoro tecnico si è concentrato nel definire una serie di criteri condivisi per l'uso di due tecnologie già esistenti:

  • Sender Policy Framework (SPF): consente di verificare che una email inviata da un dato dominio arrivi effettivamente da uno degli host abilitati dai gestori del dominio stesso . Questo elenco viene reso pubblico attraverso un record DNS.
  • DomainKeys Identified Mail (DKIM): permette ai gestori di un dominio di aggiungere una firma digitale tramite chiave privata ai messaggi di posta elettronica. DKIM aggiunge quindi un ulteriore strumento per verificare la corrispondenza tra mittente e relativo dominio di appartenenza.

Combinando opportunamente questi due sistemi diventa possibile validare il mittente di una email, garantire cioè che il messaggio provenga realmente dal dominio e dall'utente specifico. Per simmetria la mancata validazione può consentire una immediata individuazione di messaggi di spam, di phishing o in cui comunque il mittente reale sia stato mascherato. Ovviamente perché la validazione tramite DMARC sia efficace è necessario che questo protocollo sia implementato sia sul server del destinatario che sul server del mittente.

Funzionamento

modifica

Le policy di DMARC vengono pubblicate attraverso un record DNS.

Per comprendere il funzionamento di DMARC poniamoci in una condizione semplificata in cui l'indirizzo mitt@example-mitt.com invii una email all'indirizzo dest@example-dest.org. Durante l'invio il server example-mitt.com aggiunge al messaggio l'intestazione (header) DKIM generata con un sistema di crittografia a doppia chiave. Quando l'email arriva sul server example-dest.org il protocollo DMARC consente di effettuare una serie di controlli di validità prima che il messaggio venga scaricato dal destinatario. Utilizzando la chiave pubblica DKIM di example-mitt.com il server example-dest.org procede anzitutto a verificare che il messaggio arrivi effettivamente dall'indirizzo dichiarato e che non sia stato alterato durante il suo percorso. Successivamente attraverso SPF il server verifica che l'host da cui è partito il messaggio sia tra quelli abilitati.

DMARC quindi, effettua il cosiddetto controllo dell'allineamento[7] su DKIM ed SPF: il dominio contenuto nel campo "From" dell'header deve combaciare esattamente col dominio di firma DKIM (in un allineamento strict) o essere un sottodominio dello stesso (allineamento relaxed)[8]. Analogamente deve sussistere l'allineamento del dominio anche per SPF tra "From" e "Mail From"[9]. In questo modo viene colmata la lacuna dell'identificazione sicura di un mittente che DKIM ed SPF da soli non riuscirebbero a garantire: una mail infatti può essere firmata da chiunque e riuscire a passare quindi un controllo DKIM, ed SPF effettua il controllo del dominio indicato su "HELO" o su "Mail From"[10] mentre invece il campo "From", ovvero il mittente visibile sulla mail, non è soggetto a controlli.

Una mail supera il check DMARC quando almeno uno dei due controlli supera l'allineamento[11]. E' consentito scegliere il comportamento che il destinatario dovrebbe applicare in caso di fallimento del check: un comportamento neutro (neutral), considerare la mail come sospetta (quarantine) oppure rifiutarla (reject). Il sistema del destinatario può offrirsi di inviare un report che contiene il server sorgente, il dominio di destinazione, il risultato dei controlli DKIM, SPF e relativi allineamenti. Detti report uniti ad una policy neutra permettono di testare la configurazione senza creare disagi. L'obiettivo di DMARC è quello di arrivare ad una policy di quarantine o reject.

DMARC offre quindi un enorme valore aggiunto rispetto al solo controllo SPF o DKIM.

Allineamento

modifica

DMARC funziona verificando che il dominio presente nel campo From: del messaggio (chiamato anche "RFC5322.From"[12]) sia "allineato" con altri nomi di dominio autenticati. Se uno dei controlli di allineamento SPF (specificato tramite il campo aspf) o DKIM (specificato tramite il campo adkim ) ha esito positivo, allora anche il test di allineamento DMARC ha esito positivo.

L'allineamento può essere specificato come rigoroso o rilassato. Per l'allineamento rigoroso, i nomi di dominio devono essere identici. Per l'allineamento rilassato, deve corrispondere il dominio organizzativo di primo livello. In precedenza, il dominio organizzativo veniva determinato controllando un elenco di suffissi pubblici DNS. La nuova specifica prevede invece un'analisi gerarchica (Tree Walk) dei domini superiori. Ad esempio, a.b.c.d.example.com.au ed example.com.au hanno lo stesso dominio organizzativo, perché _dmarc.example.com.au è l’unico record DMARC definito tra tutti i sottodomini coinvolti, incluso _dmarc.au. Poiché questo approccio consente ai proprietari dei domini di definire i ruoli dei vari sottodomini, viene considerato più preciso rispetto all’uso della Public Suffix List[13].

Come SPF e DKIM, DMARC utilizza il concetto di proprietario del dominio, ovvero l'entità (o le entità) autorizzata a modificare un determinato dominio DNS.

SPF verifica che l’indirizzo IP del server mittente sia autorizzato dal proprietario del dominio che appare nel comando MAIL FROM del protocollo SMTP. (L’indirizzo email nel campo MAIL FROM è anche chiamato bounce address, envelope-from o RFC5321.MailFrom). Oltre a richiedere che il controllo SPF abbia esito positivo, DMARC verifica che RFC5321.MailFrom sia allineato con RFC5322.From[14].

DKIM consente di firmare crittograficamente alcune parti di un messaggio email, e la firma deve includere il campo From. Nell’intestazione DKIM-Signature dell’email, i tag d= (dominio) e s= (selettore) specificano dove recuperare la chiave pubblica nel DNS. Una firma valida dimostra che il firmatario è il proprietario del dominio e che il campo From non è stato modificato dopo l'applicazione della firma. Un messaggio può contenere più firme DKIM; DMARC richiede almeno una firma valida in cui il dominio specificato nel tag d= sia allineato con il dominio del mittente indicato nel campo From:.

Record DNS

modifica

I record DMARC vengono pubblicati nel DNS con un'etichetta di sottodominio _dmarc, ad esempio: _dmarc.esempio.com. Questo si confronta con SPF (pubblicato su esempio.com) e DKIM (pubblicato su selettore._domainkey.esempio.com).

Il contenuto del record TXT consiste in coppie nome=valore, separate da punti e virgola, in modo simile a SPF e DKIM.

I tag disponibili sono:[12]

  • adkim, modalità di allineamento DKIM (predefinito r per relaxed, in alternativa s per strict)
  • aspf, modalità di allineamento SPF (predefinito r per relaxed, in alternativa s per strict)
  • fo, opzioni di report per i fallimenti (predefinito 0, alternativamente 1, d o s)
  • p, policy (vedi sotto)
  • pct, percentuale di email "non conformi" su cui applicare la policy (predefinito 100)
  • rf, formato dei report specifici per messaggio
  • ri, intervallo richiesto tra i report aggregati
  • rua, URI a cui inviare i report aggregati
  • ruf, URI a cui inviare i report di fallimento/forensi
  • sp, policy per i sottodomini (predefinita uguale a p)
  • v, versione

Ad esempio: 

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"

In questo esempio, l'entità che controlla il dominio esempio.com intende monitorare i tassi di fallimento SPF e/o DKIM e non prevede l'invio di email da sottodomini di esempio.com. Si noti che un sottodominio può pubblicare un proprio record DMARC; i destinatari devono controllare questo record prima di fare riferimento a quello del dominio organizzativo.

Adozione graduale

modifica

Il protocollo prevede diversi passaggi intermedi, o stati transitori, per consentire agli amministratori di posta elettronica di passare gradualmente da una situazione in cui DMARC non è implementato affatto fino a una configurazione completamente restrittiva.[15][16][17] Il concetto di adozione graduale presuppone che l'obiettivo finale di DMARC sia l'impostazione più rigorosa, anche se ciò non è sempre vero per tutti i domini. Indipendentemente dall’intento, questi meccanismi permettono una maggiore flessibilità.

Politica

modifica

Innanzitutto, esistono tre politiche principali:

  • none è la politica di base. Non richiede alcun trattamento particolare da parte dei destinatari, ma consente al dominio di ricevere rapporti di feedback.
  • quarantine chiede ai destinatari di trattare con sospetto i messaggi che non superano il controllo DMARC. I destinatari possono implementarla in modi diversi, ad esempio contrassegnando i messaggi o consegnandoli nella cartella dello spam.
  • reject richiede ai destinatari di rifiutare completamente i messaggi che non superano il controllo DMARC.

La politica pubblicata può essere mitigata applicandola solo a una percentuale dei messaggi che falliscono il controllo DMARC. Ai destinatari viene chiesto di selezionare la percentuale indicata dei messaggi tramite un semplice algoritmo di campionamento di Bernoulli. I messaggi rimanenti devono essere trattati secondo la politica meno restrittiva; ovvero, none se p=quarantine, quarantine se p=reject. Se non specificato, pct è predefinito al 100% dei messaggi. Il caso p=quarantine; pct=0; viene utilizzato per costringere i gestori di mailing list a riscrivere il campo From:, poiché alcuni non lo fanno quando p=none.[18]

Infine, la politica per i sottodomini sp= e la più recente politica per domini senza nome np= [19] consentono di modificare la politica per sottodomini specifici.

Note

modifica
  1. ^ (EN) Use DMARC to validate email, setup steps - Microsoft Defender for Office 365, su learn.microsoft.com. URL consultato il 21 luglio 2025.
  2. ^ Informazioni su Domain-based Message Authentication, Reporting & Conformance (DMARC), su docs.trendmicro.com. URL consultato il 21 luglio 2025.
  3. ^ (EN) What is DMARC - How Does DMARC Work?, su MxToolbox. URL consultato il 21 luglio 2025.
  4. ^ RFC 7489
  5. ^ Bob Radvanovsky, Analyzing Spoofed E-mail Headers, in Journal of Digital Forensic Practice, vol. 1, n. 3, 1º settembre 2006, pp. 231–243, DOI:10.1080/15567280601142178. URL consultato il 21 luglio 2025.
  6. ^ (EN) History – dmarc.org, su dmarc.org. URL consultato il 28 giugno 2017.
  7. ^ Murray Kucherawy e Elizabeth Zwicky, DMARC RFC 3.1. Identifier Alignment, RFC 7489, Internet Engineering Task Force, 2015-03. URL consultato il 16 ottobre 2021.
  8. ^ Murray Kucherawy e Elizabeth Zwicky, DMARC RFC 3.1.1. DKIM-Authenticated Identifiers, RFC 7489, Internet Engineering Task Force, 2015-03. URL consultato il 16 ottobre 2021.
  9. ^ Murray Kucherawy e Elizabeth Zwicky, DMARC RFC 3.1.2. SPF-Authenticated Identifiers, RFC 7489, Internet Engineering Task Force, 2015-03. URL consultato il 16 ottobre 2021.
  10. ^ Scott Kitterman, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC 7208, Internet Engineering Task Force, 2014-04. URL consultato il 16 ottobre 2021.
  11. ^ Murray Kucherawy e Elizabeth Zwicky, DMARC RFC 6.6.2. Determine Handling Policy - Punto 5, RFC 7489, Internet Engineering Task Force, 2015-03. URL consultato il 16 ottobre 2021.
  12. ^ a b Murray Kucherawy e Elizabeth Zwicky, Domain-based Message Authentication, Reporting, and Conformance (DMARC), RFC 7489, Internet Engineering Task Force, 2015-03, DOI:10.17487/rfc7489. URL consultato il 21 luglio 2025.
  13. ^ Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup, su mailarchive.ietf.org. URL consultato il 21 luglio 2025.
  14. ^ Murray Kucherawy e Elizabeth Zwicky, Domain-based Message Authentication, Reporting, and Conformance (DMARC), RFC 7489, Internet Engineering Task Force, 2015-03. URL consultato il 21 luglio 2025.
  15. ^ (EN) Recommended DMARC rollout, su support.google.com. URL consultato il 21 luglio 2025 (archiviato dall'url originale il 15 giugno 2025).
  16. ^ (EN) Implementation guidance: email ___domain protection (ITSP.40.065 v1.1), su Canadian Centre for Cyber Security, 22 novembre 2021. URL consultato il 21 luglio 2025.
  17. ^ User Guide for Cisco Domain Protection (PDF), in cisco.com, 25 May 2021. URL consultato il 21 luglio 2025.
  18. ^ "p=none" vs. "p=quarantine; pct=0", su Lists BIMI. URL consultato il 21 luglio 2025 (archiviato dall'url originale il 1º settembre 2021).
  19. ^ Scott Kitterman e Tim Wicinski, Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains, RFC 9091, Internet Engineering Task Force, 2021-07, DOI:10.17487/rfc9091. URL consultato il 21 luglio 2025.

Voci correlate

modifica

Collegamenti esterni

modifica
  Portale Sicurezza informatica: accedi alle voci di Wikipedia che trattano di sicurezza informatica
Estratto da "https://it.wikipedia.org/w/index.php?title=DMARC&oldid=145930422"