Configurare SPF and DKIM su Postfix: differenze tra le versioni

← Differenza precedente

Configurare SPF and DKIM su Postfix (visualizza wikitesto)

Versione delle 15:04, 28 giu 2022

10 056 byte aggiunti , 28 giu 2022

Migliorata spiegazione per il multidominio

Marcomg

Burocrati, Amministratori dell'interfaccia, Amministratori

535

contributi

@@ Riga 1: / Riga 1: @@
-{{Stub}}
 {{Versioni compatibili|bullseye}}
 ==Introduzione==
 ===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)?===
@@ Riga 9: / Riga 8: @@
 ===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.}}
@@ 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>
-Add SPF records to DNS
 ;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.
-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:
@@ Riga 66: / Riga 64: @@
      ...</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
@@ Riga 78: / Riga 76: @@
 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
@@ Riga 96: / Riga 94: @@
   chown opendkim: /var/spool/postfix/opendkim
-===Configurazione 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.
+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====
@@ Riga 105: / Riga 103: @@
 Selector                2021
 KeyFile         /etc/dkimkeys/2021.private</pre>
-Ed al posto di 2021 inserire l'anno corrente.
+Ed al posto di 2022 inserire l'anno corrente.
 Più in basso, sempre nello stesso file attivare
@@ Riga 111: / Riga 109: @@
 ed assicurarsi che non ci siano altre righe relative a <code>Socket</code> non commentate.
-Creiamo le chiavi crittografiche per Opendkim con
+Creiamo le chiavi crittografiche per OpenDKIM con
-  sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d mail.example.com -s 2021
+  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/2021.private</code> e quella pubblica in <code>/etc/dkimkeys/2021.txt</code>
+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 modificare i parametri
+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>
-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.
+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):
-  mail._domainkey.yourdomain.org yourdomain.org:mail:/etc/dkimkeys/mail.private
+  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 mail._domainkey.yourdomain.org
+*@yourdomain.org shortname
 # You can specify multiple domains
-# Example.net www._domainkey.example.net</pre>
+# 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.0.0/16
+::1
-.2.3.4/24</pre>
+localhost
+myhostname
+*yourdomain.org</pre>
-Per ciascun dominio creiamo le chiavi crittografiche eseguendo il seguente comando, cambiando di volta in volta il selector (opzione -s cambiando da mail a 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
+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).
-  sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d yourdomain.org -s mail
-In ogni caso, dopo la generazione ci si troverà la chiave privata si troverà in <code>/etc/dkimkeys/mail.private</code> e quella pubblica in <code>/etc/dkimkeys/mail.txt</code>
+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===
@@ Riga 154: / Riga 163: @@
   systemctl restart postfix
-====Configurazione aggintiva====
+====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 meessaggi di bounce non sono firmati con DKIM. Questo pul 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:
+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==