Configurare SPF and DKIM su Postfix: differenze tra le versioni

Configurare SPF and DKIM su Postfix (visualizza wikitesto)

Versione delle 20:57, 2 nov 2021

1 byte aggiunto , 2 nov 2021

m

Correzione typo

Marcomg

Burocrati, Amministratori dell'interfaccia, Amministratori

534

contributi

@@ Riga 9: / Riga 9: @@
 ===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 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>
-Add SPF records to DNS
 ;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.
-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 65: @@
      ...</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 77: @@
 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 95: @@
   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 111: / Riga 110: @@
 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
 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>
-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
@@ Riga 162: / Riga 161: @@
   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
@@ 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.
-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:
   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
@@ 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>
-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>.