Server di posta: consigli per configurarlo a dovere

Capita sempre più spesso di ricevere segnalazioni per email rifiutate, email segnalate come sospette, email buona che vengono taggate come spam e la lista potrebbe continuare all’infinito.

In questo articolo vorrei fare solo una breve check list, su come andrebbe configurato un buon server di posta, non solo sulla configurazione dello stesso, ma anche su tutte le altre tecniche necessarie a far si che la nostra posta venga recapitata correttamente e senza intoppi al destinatario.

Mailserver

Chiaramente il nostro server di posta è il core su cui si basano i nostri controlli, in quanto è l’ultima difesa che rimane se tutti gli altri controlli vengono verificati con esito negativo.

In questo esempio analizziamo nello specifico postfix, uno dei server di posta linux based più diffusi del mondo. Ritengo che i seguenti parametri siano di fondamentale importanza per la lotta allo spam quando ricevete le mail.

Fra i vari parametri che vi consiglio di inserire nel vostro file main.cf vi riporto i seguenti

  • disable_vrfy_command = yes : Disabilita il cmoando SMTP VRFY. Questo parametro blocca alcune tecniche utilizzate per raccogliere indirizzi email presenti sul vostro server
  • smtpd_delay_reject = yes : Permette a postfix di loggare informazioni sugli indirizzi dei destinatari quando vengono bloccato un client o un indirizzo oppure l’indirizzo di un mittente, in tal modo è possibile capire quale mail è stata rifiutata.
  • smtpd_helo_required = yes : Richiede che l’SMTP remoto da cui stiamo ricevendo una mail, inizi una sessione con il comando HELO o EHLO. Gran parte dei bot presenti su internet infatti (utilizzati per inviare spam), non utilizzano questo comando in connessione. Di seguito riporto altri due comandi che si legano questo:
  • smtpd_helo_restrictions = permit_mynetworks (per disabilitare il check sulle nostre reti)
  • reject_non_fqdn_hostname : scarta la mail se l’hostname del mittente non ha un formato FQDN (vedi ad esempio un server che spedisce posta con hostname mx1.network.local…). Moltissimi bot non hanno un hostname con FQDN
  • reject_invalid_hostname : Rifiuta tutte le mail inviate da computer connessi via connessioni di dialup (vedi ADSL ad ip dinamico), questo tipo di computer infatti solitamente non hanno un hostname valido

Altri controlli utili, abbastanza autoesplicativi sono

smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client dul.dnsbl.sorbs.net,
permit

Una menzione a parte va fatta per le RBL, configurate sopra con il parametro reject_rbl_client. RBL è l’acronimo di Real-Time Blackhole List o più comunemente noto come DNSBL (Dns Black List), ci sono degli organismi appositi che si occupano di tenere aggiornate queste liste (Spamhouse fra i più famosi), se l’ip del mittente fa parte di queste liste semplicemente verrà scartato.

In questo caso fate attenzione ai falsi positivi che potrebbero verificarsi.

Reverse DNS

Per migliorare ancora di più l’affidabilità dei nostri server, in questo caso riguardo la posta in uscita, quindi come ci presentiamo noi verso il mondo, parliamo di Reverse DNS (conosciuto come DNS inverso).

Tutti conosciamo il concetto di DNS, ovvero la traduzione di un hostname (www.temporini.net) in un indirizzo IP (104.27.134.122).

Il Reverse DNS altro non è che l’operazione inversa, ovvero dall’indirizzo ip all’hostname.

Per verificare se un indirizzo ip ha correttamente configurato il suo reverse ci basta usare questo semplice comando linux

host -n 212.83.178.52
52.178.83.212.in-addr.arpa domain name pointer mx.servisys.it.

In questo caso, il reverse è correttamente configurato in quanto a partire dell’indirizzo ip mi da il corretto hostname del server di posta.

SPF

Continuiamo a parlare di DNS e server di posta, e focalizziamoci ora sui record SPF acronimo di Sender Policy Framework.

Questo record servono a puntualizzare il fatto, di quali indirizzi ip sono riconosciuti come indirizzi autorevoli del nostro dominio per inviare posta a nostro nome.

Se facciamo un controllo su temporini.net con il comando dig txt temporini.net vederemo che il record txt apposito avrà la seguente configurazione

temporini.net.          300     IN      TXT     “v=spf1 a a:temporini.net ip4:37.59.120.54 ip6:2001:41d0:51:1::1745 include:spf.mandrillapp.com ~all”

In questo caso ho specificato come attendibili

  • Tutti i record di tipo A associati a temporini.net
  • gli indirizzi IPv4 37.59.120.54 e IPv6 2001:41d0:51:1::1745
  • l’indirizzo SPF per le mailing list di Mandrill spf.mandrillapp.com

A questo punto la domanda sorge spontanea: perchè dovrei usare SPF? Tanto per cominciare Google controlla il record SPF e declassa la vostra mail se non è correttamente cofigurata, se controllate il contenuto originale della mail e il controllo è passato correttamente vedrete qualcosa di simile a questo

Received-SPF: pass (google.com: domain of [email protected] designates 2607:f8b0:4003:c06::22b as permitted sender) client-ip=2607:f8b0:4003:c06::22b;

Altrimenti se il check fallisce vederete invece qualcosa di simile a questo

spf=neutral (google.com: 66.33.200.130 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]
Received-SPF: neutral (google.com: 66.33.200.130 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=66.33.200.130;

In questo secondo caso come vedete il record SPF non è stato configurato e quindi Gmail lo considera Neutrale declassando di fatto il nostro messaggio che ha alta probabilità di finire nella cartella spam (cosa che in questo caso è avvenuta).

DKIM

Passiamo ora ad introdurre DKIM, di recente introdotto anche su Gmail e quindi da considerarsi ormai un must.

DKIM è l’acronimo di DomainKeys Identified, è un sistema di identificazione ed autoreferenziazione della propria posta elettronica. Se attivato il DKIM provvede a certificare il contenuto del messaggio. DKIM permette di conoscere il reale gestore del dominio da cui parte il messaggio, oltre che ad applicare una firma che certifica sia il contenuto che l’ intestazione del messaggio stesso.

A differenza di SPF, dkim non è di banalissima configurazione richiede conoscenze abbastanza approfondite per la sua configurazione, dipendente dal sistema di posta che volete utilizzare.

Ci sono alcuni sistemi (tra cui ISPconfig) che integrano già la parte di configurazione lato server, a cui andrà aggiunta anche la parte di configurazione lato DNS.

Per un implementazione su postfix vi consiglio l’ottima guida presente su Digital Ocean

https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy

Crittografia TLS/SSL

Anche questa opzione sta diventando pressochè mandatoria, vi consiglio quindi vivamente l’attivazione. Anche questa feature è utilizzata da gmail per i controlli, per vedere se la vostra mail è criptata basta controllare in alto la vostra mail.

Se la mail non è criptata vedere una cosa simile a questo

 

 

Se invece è tutto regolare non ci sarà nulla.

Postgrey (Opzionale)

Postgrey è una tecnica utilizzata per le mail in ingresso, in cui il sistema simula un “fail” e chiede al mittente di rispedire la mail dopo un certo numero di minuti.

Quando una mail viene ricevuta, e rinviata dopo il numero di minuti richiesto, il sistema memorizza l’indirizzo ip per un certo periodo di tempo, in modo che le prossime mail che arrivano dallo stesso indirizzo passeranno subito senza ritardi.

Il sistema ad alcuni può non piacere a causa dei ritardi delle mail in arrivo, non essendo obbligatorio per il corretto recapito lo cito solo come opzione aggiuntiva.

Che provider scegliere?

Servisys da anni sul mercato è in grado di offrire soluzioni che rispondono a tutte queste caratteristiche con il servizio Servisys Collaboration Suite.

Author: Matteo Temporini

Nato nel 1979 a Udine (Italia), ho conseguito il diploma di scuola superiore come Programmatore. Ho proseguito gli studi ottenendo nel 2006 la Laurea in Informatica, presso l'università degli studi di Udine. Da sempre appassionato al mondo del Web, ho maturato un esperienza decennale come sistemista Linux e Windows presso varie aziende. Quello che state leggendo su questo sito è frutto della mia esperienza diretta, che continua a crescere grazie ad amici e colleghi.

Share This Post On

Submit a Comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Per postare il commento, risolvi il quesito sottostante * Time limit is exhausted. Please reload CAPTCHA.

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.

All original content on these pages is fingerprinted and certified by Digiprove