535
contributi
Riga 198: | Riga 198: | ||
Nel caso comunque tu voglia richiedere un resoconto, nel caso di mancata validazione, bisogna inserire una stringa simile alla seguente | Nel caso comunque tu voglia richiedere un resoconto, nel caso di mancata validazione, bisogna inserire una stringa simile alla seguente | ||
<pre>v=DMARC1;p=quarantine;sp=quarantine;adkim=r;aspf=r;fo=1;rf=afrf;rua=mailto:user@yourdomain.com</pre> | |||
Ovviamente bisogna sostituire user@yourdomain.com nel link mailto con un indirizzo email dedicato alla ricezione dei report, per esempio dmarc@yourdomain.com. | Ovviamente bisogna sostituire user@yourdomain.com nel link mailto con un indirizzo email dedicato alla ricezione dei report, per esempio dmarc@yourdomain.com. | ||
Riga 217: | Riga 217: | ||
Nel caso si voglaino ricevere i report per le autenticazioni fallite, DMARC fornisce un gran numero di opzioni di configurazione. Si possono utilizzare i tag seguenti per personalizzare la formattazione dei report, così come il criterio con cui vengono creati i report. | Nel caso si voglaino ricevere i report per le autenticazioni fallite, DMARC fornisce un gran numero di opzioni di configurazione. Si possono utilizzare i tag seguenti per personalizzare la formattazione dei report, così come il criterio con cui vengono creati i report. | ||
* <code>rua</code> specifica l'indirizzo email al quale inviare i report aggregati. È necessario utilizzare la sintassi <nowiki>mailto:user@yourdomain.com</nowiki> ed accetta indirizzi multipli separati da virgole. I report aggregati sono generalmente generati una volta al giorno; | |||
* <code>ruf</code> specifica gli indirizzi email che ricevono report dettagliati sulle autenticazioni fallite. L'argomento va inviato allo stesso modo del parametro <code>rua</code>. Con questa opzioni ogni mail non autenticata corrisponderà ad un report separato; | |||
* <code>fo</code> permette di specificare quali autenticazioni fallite riportare. Si possono utilizzare ona o più opzioni: | |||
** <code>0</code> richiede un report se entrambi i metodi di autenticazione falliscono. Per esempio, se SPF fallisce, ma DKIM va a buon fine, non viene inviato alcun report; | |||
** <code>1</code> richiede un report appena fallisce almeno un metodo di autenticazione; | |||
** <code>d</code> richiede un report se fallisce l'autenticazione DKIM; | |||
** <code>s</code> richiede un report se fallisce l'autenticazione SPF; | |||
* <code>rf</code> determina il formato utilizzato per i report delel autenticazioni fallite. Le opzioni disponibili sono: | |||
** <code>afrf</code> usa il formato di Abuse Report definito dalla RFC 5965 <ref>[https://www.ietf.org/rfc/rfc5965.txt IETF RFC5965]</ref>. | |||
** <code>iodef</code> usa il formato Incident Object Description Exchange definito dalla RFC 5070<ref>[https://www.ietf.org/rfc/rfc5070.txt IETF RFC5070]</ref>. | |||
==Note== | ==Note== |