Parliamoci chiaro, te che ti vuoi mettere un server mail in ufficio: se non rispetti alcune regole basilari, farai un solo un gran casino e poi non ti venire a lamentare qui che le tue mail ti tornano indietro, rifiutate come si rifiuta la presenza di un appestato.
La prima di queste regole fondamentali, è che i server si devono presentare tra di loro, e non devono cercare di spacciarsi per chi non sono, come spesso fanno gli spammer. Buone maniere e sincerità sono alla base di una buona comunicazione anche nella vita reale, o no?
I server mail, quando iniziano a parlare fra di loro prima di cominciare a scambiarsi messaggi di posta, si pongono alcune domande. Anzi è il server di destinazione che le pone al mittente, per verificare che sia davvero un server di posta “perbene” come vorrebbe far credere, che non sia uno spammer o peggio ancora un untore.
Dialogo tra server SMTP:
- Mittente: “Ciao, devo mandarti un paio di mail per i tuoi utenti!”
- Destinatario: “Si OK, però prima fa il bravo e dimmi chi sei…”
- Mittente “Giusto, presentarsi è da serverini ben educati, io mi chiamo mail.cicciabombacanottiera.it”
Il server del destinatario, che non è uno scemo, ha già memorizzato l’indirizzo IP del server del mittente e zitto zitto effettua immediatamente due prove per stabilire che il server del mittente sia effettivamente chi dica di essere.
- Come prima verifica, si accerta che al nome host dichiarato corrisponda effettivamente l’indirizzo IP con cui si presenta.
- La seconda verifica è la classica prova del nove, verifica cioè che all’IP con cui il server mittente si è collegato corrisponda esattamente il nome host di cui sopra.
In pratica, se al nome mail.cicciabombacanottiera.it è stato assegnato l’IP 123.123.123.123, e questo deve essere convalidato dai DNS, all’indirizzo IP 123.123.123.123 deve corrispondere dell’host, mail.cicciabombacanottiera.it.
Record A, Record PTR, Risoluzione Inversa…
Le due prove sono banali interrogazioni ai server DNS, la prima chiede il record A di un dato nome host, la seconda chiede il record PTR di un indirizzo IP, entrambe devono corrispondere, ma un peso maggiore viene dato in genere al secondo test, per una serie di motivi che magari spiegherò in un secondo tempo.
Succede, e pure molto frequentemente, che chi decide di mettersi in casa un mail server si preoccupa, per forza di cose, di far assegnare un nome all’indirizzo IP pubblico destinato al server, un Record A affinché il server mail sia raggiungibile dal mondo. Per forza di cose, dicevo, altrimenti non riceverebbe una beata fava da nessuno…
L’improvvisato postmaster però non si preoccupa di far assegnare un record PTR all’IP da chi gli fornisce la connessione. Se ha fortuna, ma capita di rado, la connessione e i DNS sono gestiti dalla stessa azienda, e il responsabile della gestione dei DNS, quando riceve la richiesta del Record A capisce che è importante associare anche il Record PTR. Santuomo…
È vero anche (e va detto, sic!) il problema contrario, ossia che molti mail server non effettuano o non considerano il test del reverse check come un errore, come dovrebbe essere, il più delle volte per una configurazione discutibile o frettolosa, e si lasciano recapitare porcherie da chiunque. Postmaster maldestri…
Morale della favola: i server mail non devono accettare missive dagli sconosciuti, e gli aspiranti postmaster devono preoccuparsi, prima di mettere in produzione un server mail, di avere un indirizzo IP ben configurato nei DNS, con tanto di Risoluzione Inversa.
Non è finita qui, ma il resto lo vediamo poi, un pezzo per volta…
Mentre ero arrivato ormai alla fine della stesura di questo post, mi sono accorto che avevo già scritto riguardo Indirizzi IP e Risoluzione Inversa. La memoria non è più quella di una volta.
Poco male, repetita iuvant…
