DMARC (Domain-based Message Authentication, Reporting & Conformance) è una specifica progettata per ridurre gli abusi tramite i messaggi e-mail, come messaggi di phishing e spam in arrivo che dissimulano le proprie origini mediante la contraffazione dell'intestazione From: del messaggio. DMARC consente ai proprietari di dominio di utilizzare il sistema DNS (Domain Name System) per informare i server riceventi dei criteri DMARC, che specificano in che modo tali server devono gestire i messaggi che dichiarano di provenire dal proprio dominio ma non possono essere autenticati come messaggi effettivamente inviati da tale dominio. Questi criteri, che vengono recuperati dal server ricevente tramite un'interrogazione DNS durante l'elaborazione del messaggio in arrivo, possono indicare al server di porre in quarantena o rifiutare i messaggi non in linea con i criteri o di non intraprendere alcuna azione (lasciando ad esempio che il messaggio venga elaborato normalmente). Oltre ai criteri, il record DNS DMARC del dominio può anche contenere richieste the indicano al server di inviare i report DMARC a un utente, definendo il numero di messaggi in arrivo che dichiarano di provenire da tale dominio, specificando se hanno superato o meno le procedure di autenticazione e fornendo informazioni dettagliate su eventuali errori. Le funzioni di generazione di report di DMARC possono essere utili per determinare l'efficacia delle procedure di autenticazione dei messaggi e-mail e la frequenza con cui il nome del dominio viene utilizzato nei messaggi contraffatti.
Nella sezione Autenticazione mittente della finestra di dialogo Impostazioni di sicurezza sono disponibili schermate per la configurazione delle funzioni di generazione di report e verifica DMARC di MDaemon: Verifica DMARC, Report DMARC e Impostazioni DMARC.
MDaemon, come parte del processo di verifica DMARC, esegue un'interrogazione DNS DMARC sul dominio presente nell'intestazione From: di ciascun messaggio in arrivo. Questa operazione viene eseguita per determinare se il dominio utilizza DMARC e, in tal caso, per recuperare il relativo record DNS DMARC, che contiene i criteri e altre informazioni correlate alla specifica DMARC. Inoltre, DMARC utilizza SPF e DKIM per convalidare ciascun messaggio e richiede che il messaggio superi almeno uno di questi controlli per superare la verifica DMARC. Se supera la verifica, il messaggio procederà normalmente con le fasi successive dei processi di filtraggio e recapito di MDaemon. Se non supera la verifica, il messaggio verrà gestito in base a una combinazione dei criteri DMARC del dominio e della modalità di configurazione di MDaemon per la gestione di tali messaggi.
Se un messaggio non supera la verifica DMARC e il dominio DMARC contiene il criterio "p=none", non verranno intraprese contromisure e si proseguirà con la normale elaborazione del messaggio. Al contrario, quando il dominio DMARC contiene i criteri restrittivi "p=quarantine" o "p=reject", MDaemon può filtrare automaticamente il messaggio nella cartella Spam (posta indesiderata) del destinatario. È inoltre possibile scegliere di configurare MDaemon in modo da rifiutare completamente il messaggio che non ha superato la verifica quando il dominio utilizza il criterio "p=reject". Oltre ai messaggi che non hanno superato la verifica con criteri restrittivi, MDaemon inserirà l'intestazione "X-MDDMARC-Fail-policy: quarantine" o "X-MDDMARC-Fail-policy: reject", a seconda dei criteri definiti. Questo consente di utilizzare la funzione Filtro contenuti per eseguire alcune azioni in base alla presenza di tali intestazioni, come l'invio del messaggio a una specifica cartella per un ulteriore controllo.
L'opzione Verifica DMARC è attivata per impostazione predefinita ed è consigliata per la maggior parte delle configurazioni MDaemon.
Quando MDaemon esegue interrogazioni sul server DNS relative a un record DMARC, il record potrebbe contenere diversi tag che indicano che il proprietario del dominio desidera ricevere report aggregati o sugli errori DMARC relativi ai messaggi che dichiarano di provenire da tale dominio. Le opzioni nella schermata Report DMARC consentono di indicare se si desidera inviare o meno i tipi di report richiesti e per specificare i metadati che tali report devono contenere. I report aggregati vengono inviati quotidianamente in corrispondenza della mezzanotte UTC, mentre i report sugli errori vengono inviati per ciascun messaggio, quando si verificano gli incidenti che determinano tali report. I report vengono sempre inviati come allegati di file XML compressi. Sono disponibili diversi strumenti di analisi online che possono facilitarne la visualizzazione da parte dei destinatari.
Per impostazione predefinita, MDaemon non invia report aggregati o sugli errori. Se si desidera inviare uno di questi tipi di report, attivare le opzioni corrispondenti nella schermata Report DMARC.
La schermata Impostazioni DMARC contiene diverse opzioni per l'inclusione di informazioni specifiche nei report DKIM, la registrazione di record DNS DMARC e l'aggiornamento del file dei suffissi pubblici utilizzato da MDaemon per DMARC.
Poiché lo scopo della specifica DMARC è assicurare che il dominio presente nell'intestazione From: di un messaggio non sia stato contraffatto, è necessario che al server di invio sia consentito inviare messaggi per conto di tale dominio. Questo può rappresentare un problema per le liste di distribuzione, in quanto le liste di distribuzione in genere distribuiscono i messaggi per contro dei membri delle liste da domini esterni, lasciando invariata l'intestazione From:. Ne consegue che, quando un server ricevente tenta di utilizzare la verifica DMARC in uno di questi messaggi, è possibile che il messaggio sia stato inviato da un server che ufficialmente non appartiene al dominio dell'intestazione From:. Se il dominio DMARC utilizza un criterio DMARC restrittivo, il messaggio potrebbe essere posto in quarantena o persino rifiutato dal server ricevente. In alcuni casi, questo potrebbe anche causare la rimozione del destinatario dalla lista dei membri. Per aggirare questo problema, quando MDaemon rileva che un messaggio per una lista proviene da un dominio con un criterio DMARC restrittivo, MDaemon sostituirà l'intestazione From: del messaggio con l'indirizzo della lista di distribuzione. In alternativa, è possibile configurare MDaemon in modo da rifiutare qualsiasi messaggio per una lista quando proviene da un dominio con criteri restrittivi. Questa seconda opzione renderebbe impossibile l'invio di un messaggio alla lista da parte di un utente appartenente a un dominio con criteri restrittivi. L'opzione per sostituire l'intestazione From: è disponibile nella schermata Intestazioni dell'editor delle liste di distribuzione. L'opzione per rifiutare i messaggi è disponibile nella schermata Impostazioni.
Se si desidera utilizzare DMARC per uno dei domini di appartenenza, ad esempio nel caso in cui si desideri che i server di posta riceventi che supportano DMARC utilizzino questa specifica per verificare i messaggi che dichiarano di provenire dal proprio dominio, è necessario innanzitutto assicurarsi di creare record DNS SPF e DKIM formattati correttamente per il dominio. Per utilizzare DMARC, è necessario che almeno una di queste opzioni funzioni in modo appropriato. Se si utilizza DKIM, è necessario configurare le opzioni di Firma DKIM di MDaemon per firmare i messaggi del dominio. È necessario inoltre creare un record DNS DMARC per il dominio. Eseguendo un'interrogazione sul server DNS relativa a questo record TXT in formato speciale, il server ricevente può determinare i criteri DMARC e diversi parametri opzionali, ad esempio è possibile specificare il metodo di autenticazione utilizzato, se si desidera o meno ricevere report aggregati, l'indirizzo e-mail a cui i report devono essere inviati e altre opzioni.
Dopo aver configurato correttamente DMARC e aver iniziato a ricevere i report XML DMARC, è possibile leggere questi report e diagnosticare potenziali problemi mediante l'uso di un'ampia gamma di strumenti online. Per comodità, è possibile anche utilizzare lo strumento DMARC Reporter, disponibile nella cartella \MDaemon\App\. Consultare il file DMARCReporterReadMe.txt per le istruzioni relative all'uso del file.
Di seguito viene riportata una panoramica dei componenti di base più comunemente utilizzati di un record DMARC. Per ulteriori informazioni o per informazioni su configurazioni più avanzate, visitare il seguente sito: www.dmarc.org.
Il campo Proprietario (denominato anche "Nome" o "di sinistra") del record di risorse DMARC deve essere sempre nel formato _dmarc o può essere espresso nel formato _dmarc.domain.name se si desidera specificare il dominio o il sottodominio a cui il record si applica.
Esempio:
Record DMARC per il dominio esempio.com
_dmarc IN TXT "v=DMARC1;p=none"
Questo record è applicabile ai messaggi e-mail provenienti da utente@esempio.com o qualsiasi sottodominio di esempio.com, come utente@supporto.esempio.com, utente@posta.supporto.esempio.com e così via.
_dmarc.support.esempio.com IN TXT "v=DMARC1;p=none"
Questo record è applicabile solo ai messaggi e-mail inviati da utente@supporto.esempio.com, non ai messaggi e-mail provenienti, ad esempio, da utente@esempio.com.
_dmarc.support IN TXT "v=DMARC1;p=none"
Questo record è applicabile ai messaggi e-mail inviati da: utente@supporto.esempio.com, utente@a.supporto.esempio.com, utente@a.b.supporto.esempio.com e così via.
Tag |
Valore |
Note |
v= |
DMARC1 |
Tag relativo alla versione, il primo tag nella porzione di testo del record specifica di DMARC. Anche se i valori degli altri tag DMARC non rilevano la distinzione tra lettere maiuscole e minuscole, il valore del tag v= deve essere scritto in caratteri maiuscoli: DMARC1. Esempio: _dmarc IN TXT "v=DMARC1;p=none" |
p= |
nessuno quarantine reject |
Tag relativo ai criteri, il secondo tag nel record DMARC, successivo al tag v=. p=none indica che il server ricevente non deve intraprendere alcuna azione in base ai risultati dell'interrogazione DMARC. I messaggi che non superano il controllo DMARC non devono essere posti in quarantena né rifiutati per questo motivo. I messaggi possono essere posti in quarantena o rifiutati per altri motivi, ad esempio nel caso in cui non superino i test di filtro spam o altri controlli di sicurezza non correlati a DMARC. L'utilizzo di p=noneè talvolta definito "monitoraggio" o "modalità di monitoraggio" in quanto è possibile utilizzare questo criterio con il tag rua= per ricevere report aggregati dai domini dei destinatari relativi ai propri messaggi, ma tali messaggi non verranno penalizzati dai domini qualora non superino il controllo DMARC. Questo criterio deve essere utilizzato fino a quando l'implementazione DMARC non è stata completamente testata e non si è pronti per passare a un criterio più restrittivo, come p=quarantine. p=quarantine è il criterio da utilizzare quando si desidera che altri server di posta gestiscano un messaggio come sospetto quando la relativa intestazione From: indica la provenienza del messaggio ma il messaggio non supera il controllo DMARC. In base ai criteri locali del server, l'utilizzo di questo criterio può determinare la necessità di sottoporre il messaggio a un ulteriore controllo, spostandolo nella cartella spam del destinatario, instradandolo a un server differente o intraprendendo un altro tipo di azione. p=reject indica che si desidera che il server ricevente rifiuti tutti i messaggi che non superano la verifica DMARC. Alcuni server, tuttavia, possono comunque accettare questi messaggi, ma i messaggi potrebbero essere posti in quarantena o sottoposti a ulteriore controllo. Questo è il criterio più restrittivo e, è in generale, è consigliabile non utilizzarlo, a meno che non si conoscano con certezza assoluta i criteri dei messaggi e-mail e i tipi di messaggi o servizi che si desidera vengano utilizzati dagli account. Se, ad esempio, si desidera consentire agli utenti di unirsi a liste di distribuzione di terze parti, usufruire dei servizi di inoltro posta, utilizzare funzioni di condivisione sui siti Web o altre funzionalità simili, l'utilizzo di p=reject potrebbe determinare quasi certamente il rifiuto di alcuni messaggi legittimi. L'uso di questo criterio potrebbe inoltre causare la rimozione o l'esclusione automatica di alcuni utenti da specifiche liste di distribuzione. Esempio: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:dmarc-report@esempio.net" |
Tutti i tag elencati di seguito sono opzionali. Se uno di questi tag non viene utilizzato in un record, verrà utilizzato il relativo valore predefinito.
Tag |
Valore |
Note |
sp= |
nessuno quarantine reject — Valore predefinito: Se sp= non viene utilizzato, il tag p= si applica al dominio e ai sottodomini. |
Questo tag viene utilizzato per specificare un criterio da utilizzare per i sottodomini del dominio a cui il record DMARC si applica. Se, ad esempio, questo tag viene utilizzato in un record che copre il dominio esempio.com, il criterio designato nel tag p= sarà applicabile ai messaggi provenienti da esempio.com, mentre il criterio designato nel tag sp= sarà applicabile ai messaggi provenienti dai sottodomini di esempio.com, come posta.esempio.com. Se questo tag viene escluso dal record, il tag p= verrà applicato al dominio e ai relativi sottodomini. Esempio: _dmarc IN TXT "v=DMARC1;p=quarantine;sp=reject" |
rua= |
Elenco separato da virgola di indirizzi e-mail a cui i report aggregati DMARC devono essere inviati. Gli indirizzi devono essere immessi come URI nel seguente formato: — Valore predefinito: none Se questo tag non viene utilizzato, non verranno inviati report aggregati. |
Questo tag indica che si desidera ricevere i report aggregati DMARC dai server che ricevono messaggi che dichiarano nell'intestazione From: di provenire da un mittente nel proprio dominio. Specificare uno o più indirizzi e-mail come URI nel seguente formato: mailto:utente@esempio.com, separando più URI con virgole. Esempio: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:utente01@esempio.com,mailto:utente02@esempio.com" In genere, questi indirizzi appartengono al dominio coperto da questo record. Se si desidera inviare i report a un indirizzo appartenente a un altro dominio, il file di zona DNS di tale dominio deve anche contenere un record DMARC speciale che indica che accetterà i report DMARC per il dominio. Record di esempio in esempio.com: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:utente-non-locale@esempio.net" Record obbligatorio in esempio.net: esempio.com._report._dmarc TXT "v=DMARC1" |
ruf= |
Elenco separato da virgola di indirizzi e-mail a cui i report sugli errori DMARC devono essere inviati. Gli indirizzi devono essere immessi come URI nel seguente formato: — Valore predefinito: none Se questo tag non viene utilizzato, non verranno inviati report sugli errori. |
Questo tag indica che si desidera ricevere i report sugli errori DMARC dai server che ricevono messaggi che dichiarano nell'intestazione From: di provenire da un mittente nel proprio dominio, una volta soddisfatte le condizioni specificate nel tag fo=. Per impostazione predefinita, se non viene specificato alcun tag fo=, i report sugli errori vengono inviati qualora il messaggio non superi tutti i controlli di verifica DMARC (ad esempio non supera le verifiche SPF e DKIM). Specificare uno o più indirizzi e-mail come URI nel seguente formato: mailto:utente@esempio.com, separando più URI con virgole. Esempio: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc-errori@esempio.com" In genere, questi indirizzi appartengono al dominio coperto da questo record. Se si desidera inviare i report a un indirizzo appartenente a un altro dominio, il file di zona DNS di tale dominio deve anche contenere un record DMARC speciale che indica che accetterà i report DMARC per il dominio. Record di esempio in esempio.com: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:utente-non-locale@esempio.net" Record obbligatorio in esempio.net: esempio.com._report._dmarc TXT "v=DMARC1" |
Per ulteriori informazioni sulla specifica DMARC, visitare il seguente sito: www.dmarc.org.
Vedere: