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 20:57, 2 nov 2021

1 byte aggiunto ,  2 nov 2021
m
Correzione typo
m (Correzione typo)
Riga 9: Riga 9:


===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 23:


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 49:
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 65:
     ...</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 77:
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 96: Riga 95:
  chown opendkim: /var/spool/postfix/opendkim
  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====
====Semplificata: dominio singolo====
Riga 111: Riga 110:
ed assicurarsi che non ci siano altre righe relative a <code>Socket</code> non commentate.
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 2021
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/2021.private</code> e quella pubblica in <code>/etc/dkimkeys/2021.txt</code>
Riga 145: Riga 144:
yourdomain.org</pre>
yourdomain.org</pre>


In questo caso cambiare myhostname al name del proprio server ed yourdomain.org con il nome del dominio.
In questo caso cambiare myhostname con quello del proprio server e yourdomain.org con il nome del dominio.


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
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
Riga 162: Riga 161:
  systemctl restart postfix
  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:
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
  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
  internal_mail_filter_classes = bounce


Riga 191: Riga 190:
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.
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 validazion e, pertanto, saranno scartati o marcati come SPAM dal server ricevente.
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:
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
  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) ongi 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.
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
Nel caso comunque tu voglia richiedere un resoconto, nel caso di mancata validazione, bisogna inserire una stringa simile alla seguente
Riga 233: Riga 232:
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>
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 2021 passare a 2022).
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 2021 passare a 2022).


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>.
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>.
Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/44565"