È buona norma, per convivere in pace con i Mail Server sparsi per il mondo, presentarsi ad essi ed essere presentati con credenziali confermate.

A questo fine, ci vengono in aiuto SPF, DKIM e DMARC .

SPF: Sender Policy Framework.

Sistema per identificare chi, quale host, può mandare mail per quel determinato dominio.
Viene determinato dal proprietario del dominio in un record DNS di tipo Txt.
Ogni dominio può avere un solo record SPF, ma si possono prevedere molteplici server abilitati a spedire posta per quel dominio.

Il server che riceve la posta controlla il record SPF, per accertarsi che il server del dominio, che spedisce la mail, sia autorizzato dal proprietario del dominio a spedire posta in nome suo. In questo caso, il server ricevente attua una politica di controllo (SPF Policy).

Creazione del record SPF

Il record SPF è una riga di testo, contenente "meccanismi" (funzioni) e relativi valori.

v : versione di spf ed è obbligatorio; il suo valore attuale è spf1;

ip4 o ip6 : ip autorizzato o autorizzati a spedire mail in nome del dominio;

a : in questo caso, come valore non indichiamo l'ip, ma il nome di dominio autorizzato, nella forma dominio.tld;

mx : stavolta, usiamo il record MX per autorizzare il server a spedire mail;

include : usato per autorizzare altri server di altri domini a spedire posta nel nome del dominio.

all : indica, come valore, che riguarda tutte le mail spedite dal server autorizzato. Può avere 2 valori:
    ~all : indica che se il server mittente non è nel record SPF, comunque il server ricevente accetta la mail, ma la marca come sospetta;
    -all : in questo caso, tutte le mail provenienti da server mittenti non identificati nel record SPF saranno rifiutate.

Per chi ha un nome di dominio e NON spedisce mail, cioè non ha un Mail Server, v=spf1 ~all previene l'appropriazione indebita dello spedire mail a nome di quel dominio, cioè impersonando il dominio abusivamente, cosiddetto Spoofing.

Volendo essere restrittivi, il nostro record SPF sarà: v=spf1 mx -all

Rechiamoci nella pagina di gestione dei record dns del nostro dominio e creiamo, per ogni dominio, un record spf.




Accertiamoci che il record SPF si sia propagato nella rete:

Answer question confrma la propagazione.

Facciamo il controllo per ogni sito gestito.

Controllo record SPF sulla posta in entrata

Adesso agiamo sul nostro server, affinchè usi il filtro SPF per verificare le mail.

Come sempre, aggiorniamo il sistema:
ed installiamo il pacchetto necessario :
Apriamo il file di configurazione dei servizi di Postfix, master.cf ; ed inseriamo, alla fine del file, la richiesta di controllo della politica SPF :

Salviamo e chiudiamo master.cf


Passiamo alla configurazione SPF nel file di configurazione generale di Postfix, main.cf :
Andiamo alla sezione smtp_recipient_restrictions ed aggiungiamo sopra di essa il limite del timeout, per aumentarlo, evitando un annullo dell'analisi SPF, se questa è lenta :
Dentro smtp_recipient_restrictions, aggiungiamo anche la politica riguardante SPF:

Ctrl+X, Y, Invio, così salviamo le modifiche.

DKIM: DomainKeys Identified Mail.

Sistema per certificare la posta in uscita del dominio.

All'interno dell' header della mail viene aggiunta una firma, una chiave cifrata.
Questa firma sarà confrontata ad un testo inserito in un record DNS, testo creato con una applicazione apposita: Opendkim. Installiamo il pacchetto richiesto :
Sempre per via della "gabbia" di Postfix, aggiungiamo Postfix al gruppo Opendkim: Creiamo la cartella per il "Gate" tra Opendkim e Postfix e togliamo i permessi agli altri utenti: Diamo la proprietà della cartella a opendkim:

Passiamo alla modifica del file di configurazione di Opendkim:

Incominciamo col togliere il commento (#) a Mode e SubDomains

Nella sezione Socket, dobbiamo indicare dove sarà il "Gate" di comunicazione.

Per fare ciò, commentiamo il primo socket local e decommentiamo l'ultimo, relativo alla "gabbia" di Postfix:

Alla fine del file, ci sono 2 enunciati.

Il primo, TrustAnchorFile convalida il DNSSEC : se il provider fornitore del nome di dominio, non fornisce questa opzione se non a pagamento, commentiamo la riga, altrimenti, alla prova risulterà Key not secure.
Possiamo lo stesso lasciarlo così, non ci saranno conseguenza, oltre l'avviso.

Il secondo è commentato, nameservers; decommentiamolo ed indichiamo i nameserver (NS) da consultare.
In questo caso, noi rimandiamo al nostro router/gateway, ma possiamo benissimo indicare i NS di google: 8.8.8.8

Infine, dato che abbiamo più domini da gestire, inseriamo tre righe, sempre alla fine del file.

La prima riga indica dov'è la lista delle chiavi.

La seconda riga indica a quale dominio corrisponde la tale chiave.

Il terzo rigo indica gli hosts a cui applicare la firma.

Chiudiamo opendkim.conf e salviamo il contenuto.


Dobbiamo creare la cartella ove inserire i 3 file summenzionati :
Ne cambiamo il proprietario da root a opendkim
ed impostiamo i permessi, sulla cartella delle chiavi, allo scopo di permettere la scrittura e la lettura solo a opendkim:



Creiamo il file KeyTable: ed inseriamo al suo interno, per ogni dominio, una riga : Ripetiamo questo rigo, adeguandolo ad ogni sito, cioè modificando 3 volte il dominio.


Ctrl+X, Y, Invio per salvare e chiudere.


Spetta a SigningTable ad essere creato: e, al suo interno, ordiniamo a Opendkim, che ad ogni (*) mail spedita dal dominio gestito, deve incorporare la chiave posta nel file nominato: Anche per questo file, aggiungiamo, modificandolo, un rigo per ogni dominio.


Salviamo il tutto.


Manca TrustedHosts ad essere creato: ed inseriamo gli host Credibili (anteponendogli un punto), indicando ad Opendkim che nell'eventualità di una mail proveniente dallo stesso host, in questo caso localhost, oppure da un dominio gestito da noi, di firmare la mail, ma di non verificarla : Inseriamo una entrata per ogni dominio gestito.


Salviamo e chiudiamo.


Finalmente, possiamo generare le chiavi.

Dobbiamo prima creare una cartella per ogni dominio, dove metteremo le chiavi:
Fatte le cartelle per ogni dominio, generiamo le relative chiavi, indicando dove porle (-D), il dominio per cui generarle (-d) ed il selettore scelto (-s) : Ripetiamo il rigo ad ogni dominio, modificando 2 volte il dominio.



Rendiamo opendkim proprietario della cartella dkimkeys e delle sue sottocartelle : Elenchiamo i file dentro una delle cartelle, per vederne il contenuto:

Dobbiamo permettere a Postfix di chiamare Opendkim con il protocollo milter : Per far ciò aggiungiamo , in fondo al file :
Chiudiamo il file, salvandolo.


Riavviamo Opendkim e Postfix:

Ci manca di creare il/i relativo/i record DNS .

Apriamo in lettura il file .txt dov'è stata messa la chiave pubblica del singolo dominio :

Pubblichiamo un nuovo record TXT nella sezione gestione DNS del nostro dominio, dandogli il nome di sottodominio impostato in Opendkim: chiave._domainkey.
Copiamo al suo interno tutto quanto compreso tra le parentesi della nostra chiave pubblica .txt e cancelliamo tutte le doppie virgolette e gli spazi, altrimenti il record non sarà accettato.



Proviamo a mandare una mail con un nostro nuovo account verso un account GMail e, poi, apriamo la mail ricevuta sul nostro account GMail, scegliendo l'opzione <> Mostra originale dal menu dei 3 puntini


Possiamo controllare l'esito positivo dei DNS SPF ed DKIM




Manca DMARC

Torniamo a far visita al provider del nostro sito e ritorniamo nella sezione dedicata ai DNS e generiamo un nuovo record TXT che chiameremo _dmarc, con valore v=DMARC1; p=none; pct=100; fo=1; rua=mailto:info@giubbe.org


Abbiamo indicato ai Mail Server, che ricevono la posta da un dominio gestito da noi, cosa fare di quelle mail.

v=DMARC1 è la versione;
p=reject è la politica da noi scelta, ovvero rigettare le mail a nome del nostro dominio, ma non proveniente dal nostro indirizzo IP;
pct=100 indica la percentuale delle mail da sottoporre alla regola, per noi, il 100%;
fo=1 permette di generare un report ad ogni fallimento, il quale sarà inviato alla mail indicata;
rua=mailto: indica la mail per ricevere i reports

Quale miglior test di quello provato prima,

Rispediamo una mail ad un account Gmail, da un nostro indirizzo e vediamone i risultati.


Promossi; con questi risultati, saremo ben accettati nella comunità dei Mail Servers.


Stavolta, il Mail Server è completo e pronto.


Il prossimo passo sarà difenderci da attacchi verso i nostri Server, sia Web, sia Mail, con una applicazione da noi molto amata: Fail2ban.

"Sbagli e sei bannato."