Mail in SPAM? Facciamo chiarezza

Spam

Quante volte ci è capitato di trovarci le mail di un sito nella cartella spam?

Al sottoscritto molte, moltissime volte!
Con questo articolo vi spiegherò come prendere una serie di accorgimenti per rendere le mail dei vostri siti, più presentabili agli occhi degli anti spam.

Premessa

Di seguito avrai modo di leggere degli esempi ma ci tengo a ricordati che non esiste una versione giusta o sbagliata, bensì ci saranno configurazioni più o meno adatte alle tue esigenze.
Tutto ciò servirà per farti prendere spunto o per avere un punto di partenza nella realizzazione del tuo setup.

Gli obiettivi che andremo ad affrontare sono i seguenti:

  1. Definire l’hostname del proprio server SMTP ed impostare la risoluzione inversa.
  2. Inviare le proprie mail su connessioni cifrate
  3. Capire il funzionamento dei record SPF/DKIM/DMARC ed imparare a configurarli.
  4. Riferimenti a tool di terze parti per effettuare analisi

Mentre i software che ho utilizzato per questo articolo sono:

  1. CentOS 7
  2. Postfix
  3. OpenDKIM
  4. Let’s Encrypt – Certbot

Configuriamo l’hostname di Postfix

Una delle verifiche più primitive che esistano nel mondo degli anti spam, è la corrispondenza tra l’hostname del nostro SMTP ed il record PTR.
Per verificare l’hostname di Postfix è sufficiente effettuare una connessione tramite telnet:

[root@26 ~]# sleep 1 | telnet localhost 25
    Trying ::1…
    Connected to localhost.
    Escape character is '^]'.
    220 26.207.XX.XX.provider.ext ESMTP Postfix
    Connection closed by foreign host.

Postfix assume come valore di default il nome del server, in questo caso “26.207.XX.XX.provider.ext”.
Il nome del nostro server è facilmente identificabile tramite il comando:

[root@26 ~]# hostname -f
    26.207.XX.XX.provider.ext

Possiamo procedere a valorizzare correttamente l’hostname del server SMTP – specificandolo in forma fqdn – tramite due differenti strade.

  1. Variare l’hostname del server tramite il comando:
[root@26 ~]# hostnamectl set-hostname ilmioserver.dominio.ext
  1. Impostando la variabile “myhostname” all’interno del file /etc/postfix/main.cf.
[root@ilmioserver ~]# echo 'myhostname = ilmioserver.dominio.ext' >> /etc/postfix/main.cf

Qualsiasi delle due strade si decidesse di adottare, il risultato – a seguito di un riavvio del demone – sarà lo stesso:

[root@ilmioserver ~]# systemctl restart postfix
[root@ilmioserver ~]# sleep 1 | telnet localhost 25
     Trying ::1…
     Connected to localhost.
     Escape character is '^]'.
     220 ilmioserver.dominio.ext ESMTP Postfix
     Connection closed by foreign host.

Modifichiamo la risoluzione inversa dell’IP del nostro server.
Come detto nella sezione precedente, è necessario che venga effettuato positivamente il match tra l’hostname del nostro server SMTP e la risoluzione inversa. La risoluzione inversa è una tipologia di query DNS che traduce un indirizzo IP (dato in ingresso), in un hostname.
Possiamo verificarlo in autonomia tramite il seguente comando (o usando tool online):

[root@ilmioserver ~]# nslookup XX.XX.207.26
     26.207.XX.XX.in-addr.arpa      name = 26.207.XX.XX.servereasy.it. 

La risoluzione inversa dell’indirizzo IP è chiamata anche:

  • Record PTR
  • Reverse Hostname
  • Reverse Lookup
  • RDNS

Tale modifica va richiesta al provider che fornisce la connettività internet, tramite l’ausilio dei portali web o tramite un ticket.
Terminata la configurazione ed atteso il tempo necessario (possono volerci diverse ore), verifichiamo che il record sia corretto:

[root@ilmioserver ~]# nslookup XX.XX.207.26
     26.207.XX.XX.in-addr.arpa      name = ilmioserver.dominio.ext. 

Aumentiamo la sicurezza e non solo!
Uno dei fattori che penalizzano le mail agli occhi dei cloud provider (GMail, Office 365, etc..), è l’invio tramite protocollo non sicuro, che allarmano l’anti spam. Proviamo subito ad inviare una mail ad una casella Gmail per verificare lo stato del nostro invio:

[root@ilmioserver ~]# echo "Questa bellissima mail" | mail -s "Questa bellissima mail, evvai!" -a 'MIME-Version: 1.0' -a 'Content-Type: text/plain' -a "From: prova@dominio.ext" ilmioindirizzo@gmail.com

Appena ricevuta, noteremo la presenza di un lucchetto rosso sbarrato.
Ciò vuol dire che non stiamo inviando le mail in forma cifrata.
Dobbiamo quindi munirci di un certificato valido.
In questo caso ho provveduto a generarne uno gratuito tramite l’ausilio di Let’s Encrypt. (https://certbot.eff.org/lets-encrypt/centosrhel7-other)
Una volta ottenuto, provvediamo ad impostare alcuni parametri all’interno di Postfix:

[root@ilmioserver ~]# echo 'smtpd_tls_cert_file = /etc/letsencrypt/live/ilmioserver.dominio.ext/fullchain.pem' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtpd_tls_key_file = /etc/letsencrypt/live/ilmioserver.dominio.ext/privkey.pem' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtpd_use_tls=yes' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtpd_tls_security_level = may' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtp_tls_cert_file = /etc/letsencrypt/live/ilmioserver.dominio.ext/fullchain.pem' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtp_tls_key_file = /etc/letsencrypt/live/ilmioserver.dominio.ext/privkey.pem' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtp_use_tls=yes' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtp_tls_security_level = may' >> /etc/postfix/main.cf

Ed eseguiamo un rapido restart:

[root@ilmioserver ~]# systemctl restart postfix

Inviando una seconda mai – se configurato tutto correttamente – noteremo l’assenza dello spaventoso lucchetto rosso:

[root@ilmioserver ~]# echo "questa seconda bellissima mail" | mail -s "questa seconda bellissima mail, yuppi!" -a 'MIME-Version: 1.0' -a 'Content-Type: text/plain' -a "From: prova@dominio.ext" ilmioindirizzo@gmail.com 

Configuriamo qualche record DNS.

In questa sezione vedremo degli esempi di configurazione dei record SPF, DKIM e DMARC.
Tutti e tre i sistemi servono per contrastare lo spoofing delle email, ma anche per aumentare il punteggio di affidabilità nei confronti degli antispam.

SPF (Sender Policy Framework) – https://tools.ietf.org/html/rfc7208
Si basa su un record di tipologia TXT e serve per definire “chi” è autorizzato a spedire delle email per conto di un dominio.
Il record SPF deve essere univoco per il dominio o sottodominio.
Di seguito un esempio di configurazione e la sua spiegazione:

     dominio.ext TXT "v=spf1 a mx ip4: -all"

In questo caso l’SPF effettuerà quanto segue:

  • abilitare l’invio dal server che corrisponderà alla risoluzione del record A (o AAAA) di “dominio.ext”
    es.
    dominio.ext A
    dominio.ext AAAA
  • abilitare l’invio dal server che corrisponderà alla risoluzione del record MX di “dominio.ext”
    es:
    mail.dominio.ext A
    dominio.ext MX 10 mail.dominio.ext
  • abilitare l’invio dall’indirizzo IPv4 specificato
  • negare l’invio da tutto il resto

Spesso si può trovare il parametro “include:”, serve ad abilitare il record SPF specificato all’interno dello stesso.
Solitamente è utilizzato dai provider per far ereditare le variazioni delle loro strutture, come l’aumento degli indirizzi IP da autorizzare.

DKIM (DomainKeys Identified Mail) – https://tools.ietf.org/html/rfc6376
Si basa su una coppia di chiavi (privata/pubblica) e serve per verificare la legittimità di un mittente.
La chiave privata sarà contenuta sotto forma di file all’interno del nostro server, mentre la chiave pubblica sarà definita tramite un record TXT nei nostri DNS.
A differenza dell’SPF, è possibile definire più record DKIM perchè il sistema si basa sui “selettori”.
Partiamo dal generare una coppia di chiavi, in questo caso ho adottato il selettore “default”:

[root@ilmioserver ~]# mkdir /etc/opendkim/keys/dominio.ext
[root@ilmioserver ~]# cd /etc/opendkim/keys/dominio.ext && opendkim-genkey -s default -d dominio.ext -b 2048 ; chown opendkim:opendkim default.private

Modifichiamo la configurazione di OpenDKIM per abilitare il supporto di chiavi multiple:

[root@ilmioserver ~]# echo 'KeyTable                /etc/opendkim/KeyTable' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'SigningTable            refile:/etc/opendkim/SigningTable' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'InternalHosts           refile:/etc/opendkim/TrustedHosts' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'AutoRestart             Yes' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'AutoRestartRate         10/1h' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'SubDomains              Yes' >> /etc/opendkim.conf

Integriamo OpenDKIM in Postfix:

[root@ilmioserver ~]# echo 'milter_protocol = 2' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'milter_default_action = accept' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtpd_milters = inet:localhost:8891' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'non_smtpd_milters = inet:localhost:8891' >> /etc/postfix/main.cf

Configuriamo la coppia di chiavi creata in precedenza:

[root@ilmioserver ~]# echo 'default._domainkey.dominio.ext  dominio.ext:default:/etc/opendkim/keys/dominio.ext/default.private'  >> /etc/opendkim/KeyTable
[root@ilmioserver ~]# echo '*@dominio.ext default._domainkey.dominio.ext' >> /etc/opendkim/SigningTable

Riavviamo i nostri demoni:

[root@ilmioserver ~]# systemctl restart postfix ; systemctl restart opendkim

Infine creaiamo il record DNS (la nostra chiave pubblica):

[root@ilmioserver opendkim]# cat /etc/opendkim/keys/dominio.ext/default.txt

DMARC (Domain-based Message Authentication, Reporting, and Conformance) – https://tools.ietf.org/html/rfc7489
Si basa su un solo ed unico record TXT (valido anche per i sottodomini) e serve per definire le preferenze riguardo la validazione delle proprie email.
In aggiunta, è possibile configurare anche della reportistica.
Necessita che i precedenti meccanismi (SPF e DKIM) siano configurati affinchè lo stesso venga considerato valido dagli antispam.
Partiamo da una configurazione minima del record:

     _dmarc.dominio.ext TXT "v=DMARC1; p=none; sp=none"

In questo precedente caso, notiamo definiti la versione di DMARC e i valori “policy”.
Rispettivamente “p” definisce la policy del dominio principale, mentre “sp” definisce i sottodomini.
Il valore della policy consiste di specificare l’azione che deve intraprendere l’antispam destinatario se i controlli SPF/DKIM falliscono.
E’ definibile – in ordine di restrizione – con:

  • “none”, nessuna particolare azione da intraprendere
  • “quarantine”, segnala la mail come sospetta
  • “reject”, rifiutare la mail

Altri valori configurabili sono “rua” e “ruf”. Essi definiscono l’indirizzo email a cui inviare la reportistica, rispettivamente le versioni “aggregata” e “forense”.
Possiamo quindi arrivare a configurare un record più complesso come il seguente:

     _dmarc.dominio.ext TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:mail_rua@dominio.ext; ruf=mailto:mail_ruf@dominio.ext"

E ora? Facciamo un po’ di test.

Se hai configurato tutto correttamente, le tue mail avranno meno probabilità di finire nella cartella SPAM.
Ma come verificare tutto ciò? Semplicemente utilizzando alcuni tool: