Guide@Debianizzati.Org

Configurare SPF and DKIM su Postfix: differenze tra le versioni

Pagina Discussione

Configurare SPF and DKIM su Postfix (visualizza wikitesto)

Versione delle 15:04, 28 giu 2022

14 796 byte aggiunti ,  28 giu 2022
Migliorata spiegazione per il multidominio
(Creata pagina con "{{Stub}} {{Versioni compatibili|bullseye}} ==Introduzione== ===Cosa è SPF (Sender Policy Framework)?=== SPF (Sender Policy Framework) è un sistema che identifica quale host...")
 
(Migliorata spiegazione per il multidominio)
 
(17 versioni intermedie di uno stesso utente non sono mostrate)
Riga 1: Riga 1:
{{Stub}}
{{Versioni compatibili|bullseye}}
{{Versioni compatibili|bullseye}}
==Introduzione==
==Introduzione==
===Cosa è SPF (Sender Policy Framework)?===
===Cosa è SPF (Sender Policy Framework)?===
SPF (Sender Policy Framework) è un sistema che identifica quale host è abilitato all'invio di mail per un determinato dominio. Configurare un SPF aiuta a prevenire la classificazione delle mail come SPAM.
SPF (Sender Policy Framework) è un sistema che identifica quale host è abilitato all'invio di mail per un determinato dominio. Configurare SPF aiuta a prevenire la classificazione delle mail come SPAM.


===Cosa è DKIM (DomainKeys Identified Mail)?===
===Cosa è DKIM (DomainKeys Identified Mail)?===
Riga 9: Riga 8:


===Cosa è DMARC (Domain Message Authentication, Reporting and Conformance)?===
===Cosa è DMARC (Domain Message Authentication, Reporting and Conformance)?===
DMARC (Domain Message Authentication, Reporting & Conformance) permette di avvisare i mail server delle politiche del tuo nominio. Le politiche riguardano le mail che falliscono la validazione SPF o DKIM. Inoltre permette di richiedere un responso in caso di fallimento della varifica dai mail server riceventi.
DMARC (Domain Message Authentication, Reporting & Conformance) permette di avvisare i mail server delle politiche del tuo dominio. Le politiche riguardano le mail che falliscono la validazione SPF o DKIM. Inoltre permette di richiedere un responso in caso di fallimento della verifica del mittente da parte del mail server ricevente.


Le istruzioni che permettono di settare SPF, DKIM e DMARC sono generiche. Le istruzioni per configurare le politiche SPF e OpenDKIM in Postfix funzionano su ogni distribuzione. È solo necessario fare piccoli aggiustimenti di codice per il gestore dei pacchetti e identificare il percorso esatto del socket Unix.
Le istruzioni che permettono di settare SPF, DKIM e DMARC sono generiche. Le istruzioni per configurare le politiche SPF e OpenDKIM in Postfix funzionano su ogni distribuzione. È solo necessario fare piccoli aggiustamenti di codice per il gestore dei pacchetti e identificare il percorso esatto del Socket Unix.


{{Suggerimento | I passi richiesti in questa guida richiedono i permessi di root. Assicurati di eseguire i passi successivi come root o con il prefisso sudo.}}
{{Suggerimento | I passi richiesti in questa guida richiedono i permessi di root. Assicurati di eseguire i passi successivi come root o con il prefisso sudo.}}
Riga 23: Riga 22:


Il valore di un record DNS per SPF deve essere simile ai seguenti esempi. Per la sintassi completa vedere <ref>[http://www.open-spf.org/Specifications open-spf pagina delle specifiche]</ref>
Il valore di un record DNS per SPF deve essere simile ai seguenti esempi. Per la sintassi completa vedere <ref>[http://www.open-spf.org/Specifications open-spf pagina delle specifiche]</ref>
Add SPF records to DNS


;Esempio 1:Permette le mail da tutti gli host elencati nel record MX del dominio:
;Esempio 1:Permette le mail da tutti gli host elencati nel record MX del dominio:
Riga 50: Riga 48:
L'agente Python per SPF aggiunge il controllo politiche SPF a Postfix. Il record SPF del dominio di chi spedisce le mail in ingresso è verificato e, se esiste, la mail è trattata in rsipetto delle politiche. Ne esiste anche una versione in Perl, ma è carente di tutte le caratteristiche dell'agente policy scritto in Python.
L'agente Python per SPF aggiunge il controllo politiche SPF a Postfix. Il record SPF del dominio di chi spedisce le mail in ingresso è verificato e, se esiste, la mail è trattata in rsipetto delle politiche. Ne esiste anche una versione in Perl, ma è carente di tutte le caratteristiche dell'agente policy scritto in Python.


Se utilizzi SpamAssassin per filtrare la spam, potresti voler modificare il file <code>/etc/postfix-policyd-spf-python/policyd-spf.conf</code> per cambiare la configurazioen <code>HELO_reject</code> e <code>Mail_From_reject</code> a <code>False</code>. Questa modifica fa sì che l'agente per le politiche SPF, dopo aver effettuato i propri test, aggiunge una intestazione (header) al messaggio con il risultato dell'analisi e non rifiuta alcun messaggio. Inoltre si potrebbe fare questa modifica anche per vedere i risultati dell'analisi senza applicarle. In caso contrario lasciare le configurazioni di default.
Se utilizzi SpamAssassin per filtrare la spam, potresti voler modificare il file <code>/etc/postfix-policyd-spf-python/policyd-spf.conf</code> per cambiare la configurazione <code>HELO_reject</code> e <code>Mail_From_reject</code> a <code>False</code>. Questa modifica fa sì che l'agente per le politiche SPF, dopo aver effettuato i propri test, aggiunge una intestazione (header) al messaggio con il risultato dell'analisi e non rifiuta alcun messaggio. Inoltre si potrebbe fare questa modifica anche per vedere i risultati dell'analisi senza applicarle. In caso contrario lasciare le configurazioni di default.


Modificare il file <code>/etc/postfix/master.cf</code> ed aggiungere le seguenti righe alla fine:
Modificare il file <code>/etc/postfix/master.cf</code> ed aggiungere le seguenti righe alla fine:
Riga 66: Riga 64:
     ...</pre>
     ...</pre>


Assicurarsi di aggiungere il parametro <code>check_policy_service</code> dopo <code>reject_unauth_destination</code> per evitare che il sistemi si comporti come un open relay. Se <code>reject_unauth_destination</code> è l'ultimo elemento della lista, aggiugnere una virgola <code>,</code> subito dopo e infine aggiugnere l'opzione per <code>check_policy_service</code> come sopra.
Assicurarsi di aggiungere il parametro <code>check_policy_service</code> dopo <code>reject_unauth_destination</code> per evitare che il sistemi si comporti come un open relay. Se <code>reject_unauth_destination</code> è l'ultimo elemento della lista, aggiungere una virgola <code>,</code> subito dopo e infine aggiungere l'opzione per <code>check_policy_service</code> come sopra.


Infine riavviare Postfix
Infine riavviare Postfix
Riga 78: Riga 76:
Questi header non appaiono nelle mail in uscita o locali.
Questi header non appaiono nelle mail in uscita o locali.


L'agente politiche SPF inoltre scrive log in <code>/var/log/mail.log</code>. Nel file <code>mail.log</code> si pososno vedere anche messaggi del tipo:
L'agente politiche SPF inoltre scrive log in <code>/var/log/mail.log</code>. Nel file <code>mail.log</code> si possono vedere anche messaggi del tipo:


<pre>Nov  1 17:25:23 hostname policyd-spf[21065]: None; identity=helo; client-ip=127.0.0.1; helo=mail.example.com; envelope-from=test@example.com; receiver=me@otherdomain.org
<pre>Nov  1 17:25:23 hostname policyd-spf[21065]: None; identity=helo; client-ip=127.0.0.1; helo=mail.example.com; envelope-from=test@example.com; receiver=me@otherdomain.org
Riga 90: Riga 88:
Installare i pacchetti richiesti, nel caso di DKIM
Installare i pacchetti richiesti, nel caso di DKIM
  apt install opendkim
  apt install opendkim
Aggiungiamo Postfix al gruppo opendkim (ci servirà per mettere in comunicazione openkim e Postfix)
  adduser postfix opendkim
  adduser postfix opendkim
Creiamo la directory per il Socket UNIX e diamo i giusti permessi
mkdir -m o-rwx /var/spool/postfix/opendkim
chown opendkim: /var/spool/postfix/opendkim
===Configurazione OpenDKIM===
Passiamo ora alla configurazione di OpenDKIM. La configurazione possiamo farla in due modi differenti: una modalità semplificata, adatta a gestire un singolo dominio, o una modalità più complessa, dove andremo a creare più file di configurazione, adatta alla gestione multi dominio. Potete scegliere quella più adatta alle vostre esigenze.
====Semplificata: dominio singolo====
Aprire il file <code>/etc/opendkim.conf</code>
Modificare i parametri selezionando
<pre>Domain                  mail.example.com
Selector                2021
KeyFile        /etc/dkimkeys/2021.private</pre>
Ed al posto di 2022 inserire l'anno corrente.
Più in basso, sempre nello stesso file attivare
<pre>Socket                  local:/var/spool/postfix/opendkim/opendkim.sock</pre>
ed assicurarsi che non ci siano altre righe relative a <code>Socket</code> non commentate.
Creiamo le chiavi crittografiche per OpenDKIM con
sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d mail.example.com -s 2022
In questo caso la chiave privata si troverà in <code>/etc/dkimkeys/2022.private</code> e quella pubblica in <code>/etc/dkimkeys/2022.txt</code>
====Completa: multi-dominio====
Aprire il file <code>/etc/opendkim.conf</code> e aggiungere i parametri
<pre># Specify the list of keys
KeyTable file:/etc/dkimkeys/keytable
# Match keys and domains. To use regular expressions in the file, use refile: instead of file:
SigningTable refile:/etc/dkimkeys/signingtable
# Match a list of hosts whose messages will be signed. By default, only localhost is considered as internal host.
InternalHosts refile:/etc/dkimkeys/trustedhosts</pre>
Più in basso, sempre nello stesso file attivare
<pre>Socket                  local:/var/spool/postfix/opendkim/opendkim.sock</pre>ed assicurarsi che non ci siano altre righe relative a <code>Socket</code> non commentate.Ora creare i file per la lista delle chiavi, la corrispondenza tra chiavi e domini e la lista degli host per i quali i messaggi saranno firmati.
sudo -u opendkim touch /etc/dkimkeys/keytable /etc/dkimkeys/signingtable /etc/dkimkeys/trustedhosts
Aprire il file <code>/etc/dkimkeys/keytable</code> ed aggiungere le informazioni sulle chiavi private con il seguente schema (uno per riga):
shortname yourdomain.org:selector:/etc/dkimkeys/mykey.private
Dove <code>shortname</code> è un nome breve per ricordarsi il dominio, mentre <code>selector</code> è il selettore per la chiave (esempio l'anno in corso, come <code>2022</code>).
Nel file <code>/etc/dkimkeys/signingtable</code>, specificare quale chiave firmerà quale dominio, qui un esempio:
<pre># Domain yourdomain.org
*@yourdomain.org shortname
# You can specify multiple domains
# Example.net www._domainkey.example.net (<= this is another shortname)</pre>
Nel file <code>/etc/dkimkeys/trustedhosts</code>, specificare per quali host si firmeranno i messaggi. Se necessario aggiungere localhost in quanto non è implicito (per esempio):
<pre>127.0.0.1
::1
localhost
myhostname
*yourdomain.org</pre>
In questo caso cambiare myhostname con quello del proprio server e yourdomain.org con il nome del dominio (l'asterisco iniziale può essere omesso se non si vogliono includere tutti i sotto-domini).
Per ciascun dominio creiamo le chiavi crittografiche eseguendo il seguente comando, cambiando di volta in volta il selector (opzione -s scegliendo quello che desideriamo, è comune utilizzare l'anno di generazione) ed eventualmente rinominando le chiavi generate in /etc/dkimkeys per capire a quali domini si riferiscono
sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d yourdomain.org -s 2022
In ogni caso, dopo la generazione ci si troverà la chiave privata si troverà in <code>/etc/dkimkeys/2022.private</code> e quella pubblica in <code>/etc/dkimkeys/2022.txt</code>
In questo caso, avendo specificato che le chiavi si trovano in <code>/etc/dkimkeys/mykey.private</code> è necessario rinominarle con <code>mv</code> per rispettare il nome corretto.
===Configurazione Postfix===
Apriamo il file <code>/etc/postfix/main.cf</code> ed aggiungiamo le righe
<pre>smtpd_milters = unix:/opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters</pre>
Che informato dove si trova opendkim e ne impone l'utilizzo.
Per rendere la configurazione attiva riavviare Postfix e Opendkim
systemctl restart opendkim
systemctl restart postfix
====Configurazione aggiuntiva====
Il parametro <code>milter_default_action</code> determina cosa fare quando un milter fallisce. Per esempio nel caso in cui non risponda perché è andato in crash. Al fine di non perdere email sarebbe bene aggiungere la seguente riga:
milter_default_action = accept
Postfix non passa messaggi generati internamente, come messaggi di bounce a OpenDKIM, così, di base, i messaggi di bounce non sono firmati con DKIM. Questo può essere un problema se si utilizzano politiche DMARC strette (così come la riga di sopra). Infatti questo comporterebbe che i messaggi non firmati con DKIM verrebbero rifiutati. Il parametro <code>internal_mail_filter_classes</code> può essere usato epr fare sì che anche i messaggi di  bounces passino attraverso i milters come segue:
internal_mail_filter_classes = bounce
=== Configurazione DNS per DKIM===
Le prima cosa da fare è aprire il file contenente la chiave pubblica precedentemente generata. Ricordo essere nella directory <code>/etc/dkimkeys/</code> ed ha estensione <code>.txt</code>.
Il file avrà un aspetto di questo tipo
<pre>2022._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzNujEZuDXhwTXrqyw4lvOlTfvevftY1bbKTKSiUXLTnT21fJ3y38DB88LFwW4XOtHq6hgx/bezivKuqa3Nvm5vn2S48aVDSKEM173KG20N/gapBvW3C0AVq607ds5TaeO3Wg5bBIZXSwJBboJaaJbNUMLJD31l25wkU+WD2gX2K32OSpJflXXPD5tWZIQPVQpM9q9ekoKxuUYD"
  "UFsrBj4u/OfmqO1hDRaJYLHRYKmDuw7UibnDEFlgQsczL6E9e7q5BjyVDC3pFvsM7jQatQVgYo+Ml3vBt4idoFwpTCt1MzE7bNMh/wwLni6/PKZXGGdjxoHqsp2o0UBXaXXZwfKwIDAQAB" )  ; ----- DKIM key a for yourdomain.org</pre>
Quello che dobbiamo fare è, dal gestore del nostro DNS creare un nuovo record di tipo TXT, dare il nome che troviamo, cioè nel caso mostrato <code>2022._domainkey</code> dove al posto del <code>2022</code> troverete il nome che avete passato a <code>-s</code> al momento della generazione della chiave, cioè il selector.
Nel campo inserire la seconda parte, ricordandosi di rimuovere i doppi apici <code>"</code> e gli accapo trovati. Cioè nel caso di esempio precedente dovremo inserire
<pre>v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzNujEZuDXhwTXrqyw4lvOlTfvevftY1bbKTKSiUXLTnT21fJ3y38DB88LFwW4XOtHq6hgx/bezivKuqa3Nvm5vn2S48aVDSKEM173KG20N/gapBvW3C0AVq607ds5TaeO3Wg5bBIZXSwJBboJaaJbNUMLJD31l25wkU+WD2gX2K32OSpJflXXPD5tWZIQPVQpM9q9ekoKxuUYDUFsrBj4u/OfmqO1hDRaJYLHRYKmDuw7UibnDEFlgQsczL6E9e7q5BjyVDC3pFvsM7jQatQVgYo+Ml3vBt4idoFwpTCt1MzE7bNMh/wwLni6/PKZXGGdjxoHqsp2o0UBXaXXZwfKwIDAQAB</pre>
===Test della configurazione===
Per testare la corretta firma e verifica delle chiavi si può utilizzare il comando <code>opendkim-testkey</code> nel seguente modo:
opendkim-testkey -d yourdomain.org -s 2022
Ricordandosi di sostituire a <code>yourdomain.org</code> il proprio dominio e a <code>2022</code> il selector impostato.
Se tutto è andato per il verso giusto non dovresti ottnere alcun output. Se vuoi vedere più informazioni aggiungi l'argomento <code>-vvv</code> alal fine del comando. La procedura mostrerà l'output di debug. L'ultimo messaggio dovrebbe essere <code>key OK</code>. Appena prima si può vedere il messaggio <code>key not secure</code>. È normale e non è un messaggio di errore. Significa semplicemente che il dominio non è configurato per DNSSEC. In caso sia supportato DNSSEC (per esempio usando google DNS) si troverà <code>key secure</code>.
==Configurazione DMARC==
Questo passaggio non è obbligatorio, ma consigliato.
Il record DNS DMARC può essere aggiunto per avvisare i mail server su cosa fare con le email che rivendicano la provenienza dal tuo dominio nel caso falliscano la validazione SPF o DKIM. DMARC inoltre ti permette di essere avvisato sulle email che falliscono una o più controlli di validazione.
DMARC va configurato solo se si è configurato sia SPF che DKIM ed è stato verificato il corretto funzionamento. Nel caso si aggiunga un record DNS DMARC senza avere configurato correttamente sia SPF che DKIM, i messaggi provenienti dal tuo dominio falliranno la validazione, pertanto, saranno scartati o marcati come SPAM dal server ricevente.
Il record DMARC è un record TXT per l'host <code>_dmarc</code> nel dominio contenente i seguenti valori raccomandati:
v=DMARC1;p=quarantine;sp=quarantine;adkim=r;aspf=r
Questa stringa richiede al mail server di inserire in quarantena (non eliminare, ma separare dai messaggi normali) ogni email che fallisce il controllo SPF o il DKIM. Nessun report è richiesto. In ogni caso, veramente pochi mail server implementano il software per generare report sui messaggi che falliscono la validazione, pertanto è spesso inutile richiedere il report.
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.
Con questa stringa si richiedono report aggregati in XML che mostrano quanti messaggi passano o no i controlli e il mail server che li ha inviati.
I record DMARC hanno un gran numero di tag e opzioni disponibili e servono a controllare la configurazione di autenticazione:
* <code>v</code> specifica la versione del protocollo, nel caso di esempio <code>DMARC1</code>;
* <code>p</code> determina la politica per il dominio principale, nell'esempio <code>yourdomain.com</code>. Le opzioni disponibili sono:
** <code>quarantine</code> se una mail fallisce la validazione, il ricevente dovrebbe considerarla a parte (solitamente viene messa nella SPAM);
** <code>reject</code> se una mail fallisce la validazione, il ricevente dovrebbe rifiutarla;
** <code>none</code> se una mail fallisce la validazione, il ricevente non dovrebbe prendere alcuna contromisura;
* <code>sp</code> determina la politiche per i sotto-domini, come per esempio <code>subdomain.yourdomain.com</code>. Accetta gli stessi argomenti del tag <code>p</code>.
* <code>adkim</code> specifica con che modalità i record DKIM sono validati. Le opzioni disponibili sono:
** <code>r</code> modalità rilassata, l’autenticazione DKIM avviene in maniera meno stringente;
** <code>s</code> modalità stringente. Solo una corrispondenza esatta con la chiave DKIM per il dominio principale è marcata come valida;
* <code>aspf</code> determina la modalità di convalida per SPF. Richiede gli stessi parametri di adkim.
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>.
==Metodo per la corretta rotazione delle chiavi==
Questo metodo è applicabile solamente se si è effettuata la configurazione di opendkim multi-dominio ed è necessario solo se ci si vuole assicurare di non perdere alcuna mail durante la propagazione dei record DNS.
Si premette che le chiavi DKIM non hanno scadenza, pertanto è tecnicamente possibile non cambiarle mai. Però è consigliato la creazione e la revoca di nuove chiavi almeno una volta l'anno<ref>[https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/configure-anti-spoofing-controls-/create-and-manage-a-dkim-record UK National Cyber Secyrity Center: Creation and managin of DKIM record ]</ref>
La procedura da eseguire è veramente semplice. Si genera una nuova coppia di chiavi (pubblica e privata) come nel passo per configurare [[#Completa:_multi-dominio|OpenDKIM in modalità multi-dominio]] ed aggiornare il selector nel file di configurazione <code>keytable</code> che elenca le chiavi (per esempio da 2022 passare a 2023).
Utilizzare il nuovo file .txt generato per aggiungere la nuova chiave al record DNS con il nuovo selector. Si ricorda di non rimuovere o modificare il record DKIM pre-esistente. Testare nuovamente la chiave (con il nuovo selector) sempre con il comando <code>opendkim-testkey</code>.
Il passo di verifca è molto importante, altrimenti per un qualsiasi errore è possibile che le email non verranno recapitate.
Riavviare opendkim e postfix
systemctl start opendkim
systemctl start postfix
Assicurarsi che si siano riavviati senza errori.
Dopo un paio di settimane, tutte le email in transito dovrebbero essere state recapitate o rifiutate e quindi il vecchio record DNS per DKIM non è più necessario e pertanto può essere eliminato. Lasciare solamente il più recente.
==Note==
<references />


{{Autori
{{Autori
Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/44547...44608"