Configurare al meglio un server SMTP non è una cosa semplice, soprattutto quando tale server si appoggia ad una normalissima linea ADSL. Infatti, la maggior parte dei mail provider utilizzza tutta una serie di policy per limitare l'enorme mole di spam che, giornalmente, cerca di atterrare sui loro server.
Una di queste rende la vita difficile a tutti coloro che utilizzano una linea ADSL che prevede il rilascio di un IP pubblico dinamico, ovvero che varia ogni qual volta il router/modem si disconnette/riconnette. Per la precisione, i server dei mail provider controllano che l'IP del server SMTP che fa richiesta di inoltro email su una casella di posta che risiede sul loro POP3/IMAP4 abbia un record PTR associato.
Ora, senza addentrarmi troppo nei meandri del protocollo DNS e dei vari tipi di record che esso gestisce, per verificare che il nostro server SMTP abbia un record PTR associato è sufficiente lanciare il comando:
nightfly@nightbox:~$ host smtp.nostrodominio.com
smtp.nostrodominio.com has address 212.41.43.43
e successivamente:
nightfly@nightbox:~$ host 212.41.43.43
43.43.41.212.in-addr.arpa domain name pointer smtp.nostrodominio.it
Nel primo caso ho effettuato una query DNS diretta, richiedendo l'IP associato ad un determinato FQDN. Nel secondo caso, invece, ho eseguito una query DNS inversa, identificando un eventuale FQDN associato a quel particolare IP.
Ora, il comando host non è l'unico in grado di effettuare una query di questo tipo. Ad esempio, si potrebbe utilizzare dig oppure nslookup, a seconda del sistema operativo dal quale tale operazione viene effettuata.
Con dig potremmo lanciare una query diretta del tipo:
nightfly@nightbox:~$ dig smtp.nostrodominio.com
; <<>> DiG 9.7.0-P1 <<>> smtp.nostrodominio.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19912
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION:
;mail.tiscali.it. IN A
;; ANSWER SECTION:
smtp.nostrodominio.com. 41481 IN A 212.41.43.43
;; AUTHORITY SECTION:
. 427597 IN NS h.root-servers.net.
. 427597 IN NS a.root-servers.net.
. 427597 IN NS c.root-servers.net.
. 427597 IN NS i.root-servers.net.
. 427597 IN NS m.root-servers.net.
. 427597 IN NS f.root-servers.net.
. 427597 IN NS j.root-servers.net.
. 427597 IN NS k.root-servers.net.
. 427597 IN NS l.root-servers.net.
. 427597 IN NS d.root-servers.net.
. 427597 IN NS g.root-servers.net.
. 427597 IN NS e.root-servers.net.
. 427597 IN NS b.root-servers.net.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 21 10:41:15 2012
;; MSG SIZE rcvd: 260
Mentre, per la query inversa, è sufficiente lanciare il comando:
nightfly@nightbox:~$ dig -x 212.41.43.43
; <<>> DiG 9.7.0-P1 <<>> -x 212.41.43.43
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65061
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION:
;43.43.41.212.in-addr.arpa. IN PTR
;; ANSWER SECTION:
43.43.41.212.in-addr.arpa. 79146 IN PTR smtp.nostrodominio.com.
;; AUTHORITY SECTION:
. 427408 IN NS j.root-servers.net.
. 427408 IN NS g.root-servers.net.
. 427408 IN NS i.root-servers.net.
. 427408 IN NS d.root-servers.net.
. 427408 IN NS m.root-servers.net.
. 427408 IN NS a.root-servers.net.
. 427408 IN NS e.root-servers.net.
. 427408 IN NS k.root-servers.net.
. 427408 IN NS b.root-servers.net.
. 427408 IN NS c.root-servers.net.
. 427408 IN NS l.root-servers.net.
. 427408 IN NS f.root-servers.net.
. 427408 IN NS h.root-servers.net.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 21 10:44:24 2012
;; MSG SIZE rcvd: 285
E' molto importante che nell'output relativo al suddetto comando, il contenuto di ;; ANSWER SECTION: non sia nullo. In quest'ultimo caso, infatti, significherebbe che il nostro server SMTP non è dotato di un record PTR e quindi, molto probabilmente, le email che cercherà di inoltrare a certi provider verranno respinte (bounced).
Ora, solitamente i record PTR non sono supportati dai DNS provider (uno su tutti GoDaddy), ma la loro gestione è a carico dell'ISP, poichè tali record sono direttamente associati agli indirizzi IP pubblici che quest'ultimo rilascia ai propri clienti.
Ma perchè controllare se esiste un record PTR associato all'indirizzo IP del nostro server SMTP? Su che cosa si basa la logica di questo sistema antispam elementare? Semplice: poichè gli IP che generano moli abnormi di email vengono inseriti all'interno di opportune blacklist (come SpamCop o SpamHouse), che, a loro volta, vengono consultate insistentemente dai mail provider per capire quali sono i server di posta che generano spam, nel caso in cui l'IP pubblico di un server SMTP fosse dinamico, basterebbe una connessione/disconnessione del router per aggirare tale blocco. Quindi, facendo una query DNS inversa, i server dei mail provider verificano che il PTR (se esiste) non contenga alcune keyword, quali dynamic, dyn, ecc.
Alcuni mail provider hanno definito delle regole un po' più restrittive rispetto alla semplice risoluzione inversa dell'IP. Una di queste prevede che il banner del server SMTP che li contatta contenga un FQDN che sia identico a quello riportato nel record PTR.
Potete identificare il banner del vostro server SMTP utilizzando telnet, con il seguente comando:
C:Userseldo>telnet smtp.vostrodominio.com 25
Il banner conterrà il prefisso 220 seguito dall'FQDN del server:
220 smtp.vostrodominio.com
Altro fattore molto importante da tenere in considerazione quando si configura un server SMTP riguarda la sicurezza. Infatti, è estremamente importante che il server preveda dei meccanismi di autenticazione prima di consentire l'inoltro di email (open relay, anyone?) e soprattutto utilizzi dei canali di comunicazione cifrati. In quest'ultimo caso, se il protocollo SMTP viene utilizzato in modo "standard", l'invio delle credenziali da parte dell'utente avviene in chiaro, con pesanti risvolti dal punto di vista della confidenzialità. Per evitare ciò, è possibile costringere il server ad utilizzare SSL/TLS come protocollo di cifratura per tutte le connessioni inbound, oppure, se il server lo consente, utilizzare STARTTLS, molto più comodo e performante. Infatti, a differenza della cifratura SSL/TLS classica, la quale prevede l'apertura di una porta TCP apposita, ovvero la 456 (differente dalla classica TCP 25), con una maggiore mole di lavoro lato networking, il protocollo STARTTLS rende sicuro un canale nativamente non sicuro, rimanendo in ascolto sulla porta 25 ed appoggiandosi al protocollo SSL o TLS in base alla configurazione scelta (si, lo so, il nome STARTTLS può trarre in inganno).
Altro aspetto importante riguardante la sicurezza si basa sulla definizione dei domini autorizzati ad inoltrare le email. Non è un caso che fino a qualche anno fa, mail server di alcuni ISP italiani, come Telecom oppure Libero, consentissero, dopo la fase di autenticazione, di inoltrare email con dominio sorgente arbitrario. Mi spiego meglio: dopo la connessione ad uno dei suddetti server mediante un comunissimo client telnet, era possibile impostare arbitrariamente il campo MAIL FROM:, ad esempio presidente@governoitaliano.it. Ovviamente, non essendoci filtri, la mail sarebbe giunta a destinazione nonostante l'indirizzo mittente fraudolento (una manna per il phishing).
In definitiva, se volete testare la configurazione del vostro server SMTP potete utilizzare questo tool online:
http://mxtoolbox.com/diagnostic.aspx
Enjoy!