Configurare SPF and DKIM su Postfix

Versioni Compatibili Debian 11 "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 SPF aiuta a prevenire la classificazione delle mail come SPAM.

Cosa è DKIM (DomainKeys Identified Mail)?

DKIM (DomainKeys Identified Mail) è un sistema che aggiunge una firma all'header delle mail in uscita. La chiave è identificata a livello di dominio, cosè gli altri mail server possono verificare la firma. Inoltre DKIM aiuta ad evitare che la mail sia identificata come spam. Inoltre permette di identificare quando una mail è stata manomessa (modificata) durante il transito.

Cosa è DMARC (Domain Message Authentication, Reporting and Conformance)?

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 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.

ATTENZIONE Questa guida prevede di avere Postfix installato, configurato e funzionante. Fare riferimento alle altre guide su Postfix sul wiki. Puoi pubblicare anche un record DNS per SPF senza configurare le politiche SPF su Postfix. Invece, nel caso di DKIM non è possibile, perché senza aver configurato OpenDKIM su Postfix le email inviate saranno cestinate dal mail server del ricevente. Nel caso di creazione di un server solo invio, è possibile configurare solamente le politiche DNS per SPF.

Configurazione SPF

Configurazione politiche DNS per SPF

Aggiungere i record SPF ai DNS. Per farlo selezionare un nuovo record TXT e come nome host il dominio con il quale si intende spedire la posta.

Il valore di un record DNS per SPF deve essere simile ai seguenti esempi. Per la sintassi completa vedere

Esempio 1

Permette le mail da tutti gli host elencati nel record MX del dominio:

v=spf1 mx -all

Esempio 2

Permette la mail da uno specifico dominio.

v=spf1 a:mail.example.com -all

Il tag v=spf1 è richiesto e deve essere posto per primo.

L'ultimo tag, -all, indica che le mail per il dominio devono venire solamente da server identificati nella stringa SPF. Ogni mail proveniente da un'altra sorgente è da considerare falsificata. Una alternativa è ~all che indica al mail server di accettare il messaggio e segnalarlo come contraffatto al posto di rifiutarlo. -all rende più difficile per gli spammer inviare mail contraffatte con il tuo dominio. Pertanto è l'opzione raccomandata. ~all riduce le possibilità che una mail venga persa nel caso le email vengano inviade da un server mail errato (non configurato sui DNS), nel caso si tema che questo possa avvenire si può utilizzare ~all per scongiurare un tale problema.

I tag tra v=spf1 e -all indicano quali server sono abilitati ad inviare email per il dominio.

mx è una scorciatoia per indicare tutti gli host elencati nei record MX del dominio. Se hai un solo mail server mx è probabilmente la scelta giusta. Inoltre se avessi un mail server di backup, usare mx non causa alcun problema. Il server mail di backup è identificato come sorgente autorizzata a spedire mail anche se probabilmente non ne spedirà mai alcuna.

Il tag a permette di identificare uno specifico host per il nome o per l'indirizzo IP. Si dovrebbe utilizzare a se si vuole evitare che un eventuale server mail di backup sia autorizzato a spedire mail o se si vuole autenticare host esterni al proprio mail server come, per esempio, quello in uscita del proprio ISP (così le mail saranno riconosciute anche se spedite attraverso questi altri server).

Per questa guida ci limitiamo ad usare la versione con mx. È la più semplice ed è corretta per la maggior parte delle configurazioni base, incluse quelle che gestiscono domini multipli. Per aggiungere il record, andare nell'interfaccia del proprio gestore DNS ed aggiungere un record di tipo TXT per il proprio dominio contenente la stringa

v=spf1 mx -all

Configurazione politiche di ricezione SPF su Postfix

Installare i pacchetti richiesti

apt install postfix-policyd-spf-python postfix-pcre

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 /etc/postfix-policyd-spf-python/policyd-spf.conf per cambiare la configurazione HELO_reject e Mail_From_reject a False. 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 /etc/postfix/master.cf ed aggiungere le seguenti righe alla fine:

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

Inoltre aprire il file /etc/postfix/main.cf ed aggiungere le seguenti righe alla fine per aumentare il timeout dell'agente, che evita che Postfix annulli l'analisi se la transazione avviene un po' a rilento:

policyd-spf_time_limit = 3600

Inoltre, sempre nello stesso file, modificare il parametro smtpd_recipient_restrictions aggiungendo la direttiva check_policy_service come nell'esempio che segue

smtpd_recipient_restrictions =
    ...
    reject_unauth_destination,
    ...
    check_policy_service unix:private/policyd-spf,
    ...

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

Infine riavviare Postfix

systemctl restart postfix

Si può verificare il funzionamento dell'agente delle politiche guardando agli header row provenienti dai messaggi in ingresso riguardo le intestazioni SPF. L'agente delle politiche header aggiunge ai messaggi qualcosa come la seguente

Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=127.0.0.1; helo=mail.example.com; envelope-from=text@example.com; receiver=me@otherdomain.org

Questa intestazione indica un controllo positivo riguardo le politiche SPF del dominio mittente. Se si sono modificate le impostazioni dell'agente politiche per non rifiutare le mail che falliscono il controllo SPF, allora in questa intestazione apparirà Fail, nel caso il controllo fallisca.

Questi header non appaiono nelle mail in uscita o locali.

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

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
Nov  1 17:25:23 hostname policyd-spf[21065]: Pass; identity=mailfrom; client-ip=127.0.0.1; helo=mail.example.com; envelope-from=test@example.com; receiver=me@otherdomain.org

Il primo messaggio controlla il comando HELO e se ci sono informazioni SPF corrispondenti all'HELO. In questo caso non c'erano. Il secondo messaggio controlla l'indirizzo From del messaggio. In questo caso la riga indica che l'indirizzo ha passato la verifica ed è originata da uno dei server in uscita autorizzati. Infatti il dominio del mittente ha segnalato il server di invio come autorizzato a spedire la mail.

Potrebbero esserci altri stati nel primo campo dopo i due punti che possono indicare il fallimento, errori temporanei e permanenti e così via.

Configurazione DKIM

Installare i pacchetti richiesti, nel caso di DKIM

apt install opendkim

Aggiungiamo Postfix al gruppo opendkim (ci servirà per mettere in comunicazione openkim e Postfix)

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 /etc/opendkim.conf Modificare i parametri selezionando

Domain                  mail.example.com
Selector                2021
KeyFile         /etc/dkimkeys/2021.private

Ed al posto di 2022 inserire l'anno corrente.

Più in basso, sempre nello stesso file attivare

Socket                  local:/var/spool/postfix/opendkim/opendkim.sock

ed assicurarsi che non ci siano altre righe relative a Socket 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 /etc/dkimkeys/2022.private e quella pubblica in /etc/dkimkeys/2022.txt

Completa: multi-dominio

Aprire il file /etc/opendkim.conf e aggiungere i parametri

# 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

Più in basso, sempre nello stesso file attivare

Socket                  local:/var/spool/postfix/opendkim/opendkim.sock

ed assicurarsi che non ci siano altre righe relative a Socket 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 /etc/dkimkeys/keytable ed aggiungere le informazioni sulle chiavi private con il seguente schema (uno per riga):

shortname yourdomain.org:selector:/etc/dkimkeys/mykey.private

Dove shortname è un nome breve per ricordarsi il dominio, mentre selector è il selettore per la chiave (esempio l'anno in corso, come 2022).

Nel file /etc/dkimkeys/signingtable, specificare quale chiave firmerà quale dominio, qui un esempio:

# Domain yourdomain.org
*@yourdomain.org shortname

# You can specify multiple domains
# Example.net www._domainkey.example.net (<= this is another shortname)

Nel file /etc/dkimkeys/trustedhosts, specificare per quali host si firmeranno i messaggi. Se necessario aggiungere localhost in quanto non è implicito (per esempio):

127.0.0.1
::1
localhost
myhostname
*yourdomain.org

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 /etc/dkimkeys/2022.private e quella pubblica in /etc/dkimkeys/2022.txt In questo caso, avendo specificato che le chiavi si trovano in /etc/dkimkeys/mykey.private è necessario rinominarle con mv per rispettare il nome corretto.

Configurazione Postfix

Apriamo il file /etc/postfix/main.cf ed aggiungiamo le righe

smtpd_milters = unix:/opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters

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 milter_default_action 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 internal_mail_filter_classes 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 /etc/dkimkeys/ ed ha estensione .txt. Il file avrà un aspetto di questo tipo

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

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 2022._domainkey dove al posto del 2022 troverete il nome che avete passato a -s al momento della generazione della chiave, cioè il selector.

Nel campo inserire la seconda parte, ricordandosi di rimuovere i doppi apici " e gli accapo trovati. Cioè nel caso di esempio precedente dovremo inserire

v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzNujEZuDXhwTXrqyw4lvOlTfvevftY1bbKTKSiUXLTnT21fJ3y38DB88LFwW4XOtHq6hgx/bezivKuqa3Nvm5vn2S48aVDSKEM173KG20N/gapBvW3C0AVq607ds5TaeO3Wg5bBIZXSwJBboJaaJbNUMLJD31l25wkU+WD2gX2K32OSpJflXXPD5tWZIQPVQpM9q9ekoKxuUYDUFsrBj4u/OfmqO1hDRaJYLHRYKmDuw7UibnDEFlgQsczL6E9e7q5BjyVDC3pFvsM7jQatQVgYo+Ml3vBt4idoFwpTCt1MzE7bNMh/wwLni6/PKZXGGdjxoHqsp2o0UBXaXXZwfKwIDAQAB

Test della configurazione

Per testare la corretta firma e verifica delle chiavi si può utilizzare il comando opendkim-testkey nel seguente modo:

opendkim-testkey -d yourdomain.org -s 2022

Ricordandosi di sostituire a yourdomain.org il proprio dominio e a 2022 il selector impostato.

Se tutto è andato per il verso giusto non dovresti ottnere alcun output. Se vuoi vedere più informazioni aggiungi l'argomento -vvv alal fine del comando. La procedura mostrerà l'output di debug. L'ultimo messaggio dovrebbe essere key OK. Appena prima si può vedere il messaggio key not secure. È 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à key secure.

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 _dmarc 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

v=DMARC1;p=quarantine;sp=quarantine;adkim=r;aspf=r;fo=1;rf=afrf;rua=mailto:user@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.

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:

• v specifica la versione del protocollo, nel caso di esempio DMARC1;
• p determina la politica per il dominio principale, nell'esempio yourdomain.com. Le opzioni disponibili sono:
  • quarantine se una mail fallisce la validazione, il ricevente dovrebbe considerarla a parte (solitamente viene messa nella SPAM);
  • reject se una mail fallisce la validazione, il ricevente dovrebbe rifiutarla;
  • none se una mail fallisce la validazione, il ricevente non dovrebbe prendere alcuna contromisura;
• sp determina la politiche per i sotto-domini, come per esempio subdomain.yourdomain.com. Accetta gli stessi argomenti del tag p.
• adkim specifica con che modalità i record DKIM sono validati. Le opzioni disponibili sono:
  • r modalità rilassata, l’autenticazione DKIM avviene in maniera meno stringente;
  • s modalità stringente. Solo una corrispondenza esatta con la chiave DKIM per il dominio principale è marcata come valida;
• aspf 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.

• rua specifica l'indirizzo email al quale inviare i report aggregati. È necessario utilizzare la sintassi mailto:user@yourdomain.com ed accetta indirizzi multipli separati da virgole. I report aggregati sono generalmente generati una volta al giorno;
• ruf specifica gli indirizzi email che ricevono report dettagliati sulle autenticazioni fallite. L'argomento va inviato allo stesso modo del parametro rua. Con questa opzioni ogni mail non autenticata corrisponderà ad un report separato;
• fo permette di specificare quali autenticazioni fallite riportare. Si possono utilizzare ona o più opzioni:
  • 0 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;
  • 1 richiede un report appena fallisce almeno un metodo di autenticazione;
  • d richiede un report se fallisce l'autenticazione DKIM;
  • s richiede un report se fallisce l'autenticazione SPF;
• rf determina il formato utilizzato per i report delel autenticazioni fallite. Le opzioni disponibili sono:
  • afrf usa il formato di Abuse Report definito dalla RFC 5965 .
  • iodef usa il formato Incident Object Description Exchange definito dalla RFC 5070.

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

La procedura da eseguire è veramente semplice. Si genera una nuova coppia di chiavi (pubblica e privata) come nel passo per configurare OpenDKIM in modalità multi-dominio ed aggiornare il selector nel file di configurazione keytable 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 opendkim-testkey.

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

---

Guida scritta da: marcomg (discussioni) 16:32, 1 nov 2021 (UTC)	Debianized 20%
Estesa da:
Verificata da:
Verificare ed estendere la guida | Cos'è una guida Debianized