Configurare SPF and DKIM su Postfix

Attenzione: questo articolo è ancora incompleto e in fase di scrittura da parte del suo autore. Sentitevi liberi di contribuire, proponendo modifiche alla guida tramite l'apposita pagina di discussione, in modo da non interferire con il lavoro portato avanti sulla voce. Per altre informazioni si rimanda al template.

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

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.

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 Add SPF records to DNS

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 configurazioen 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, aggiugnere una virgola , subito dopo e infine aggiugnere 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 pososno 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 2021 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 2021

In questo caso la chiave privata si troverà in /etc/dkimkeys/2021.private e quella pubblica in /etc/dkimkeys/2021.txt

Completa: multi-dominio

Aprire il file /etc/opendkim.conf e modificare 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

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:mail:/etc/dkimkeys/mykey.private

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 al name del proprio server ed 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

sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d yourdomain.org -s 2021

In ogni caso, dopo la generazione ci si troverà la chiave privata si troverà in /etc/dkimkeys/2021.private e quella pubblica in /etc/dkimkeys/2021.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 aggintiva

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

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