PTR: questo sconosciuto
Capita spesso e volentieri che periodicamente si ritorni a discutere di problematiche che si sono già sviscerate nel dettaglio più intimo. E capita spesso, quando si additano i filtri antispam di far perdere della posta, di trovarsi in situazioni che, per me, hanno del ridicolo.
Gestendo qualche server di posta con diversi domini il problema dello spam è sempre stato molto sentito sia dagli utenti finali che da me. Questa piaga non è semplice da affrontare in maniera ferma e funzionale senza porre molta attenzione ad ogni singola decisione o modifica.
Anni fa esistevano solo controlli tramite filtri bayesiani, poi si sono aggiunte le liste dinamiche di host compromessi o mal configurati e riconosciuti come tali e poi ancora si sono aggiunte le varie modalità di greylisting.
Un controllo banale che taglia la testa ad una buona parte di problematiche di spam è il reverse lookup.
Il procedimento è banale: ogni volta che un host prova ad inviare un messaggio al server di posta, si presenta (otre che con il suo IP) dichiarando il suo hostname; il reverse lookup non fa altro che risolvere l’hostname partendo dall’indirizzo IP di questo host controllando che sia lo stesso con cui si è presentato.
La sezione 2.1 di questo RFC http://www.ietf.org/rfc/rfc1912.txt, che stabilisce le modalità di uso, funzionamento e alcuni errori comuni che si fanno quando si configura un DNS, dice che ogni indirizzo IP pubblico (a cui viene definito un hostname o dominio) debba avere il suo record PTR. Quindi ad un record A deve corrispondere un record PTR per il reverse lookup.
Il grosso problema è che ancora oggi ricevo alcune chiamate che mi segnalano messaggi di posta mai arrivati o tornati indietro con strani errori. Analizzando i log poi noto che chi prova a mandare posta verso i server mail da me gestiti non ha configurato in modo corretto le informazioni del DNS per quel dominio, ovvero non ha il campo PTR per il reverse lookup.
Essendo obbligatoria la definizione per gli host in internet del reverse lookup mi sembra normale rifiutare tali messaggi e so per certo che molti amministratori applicano questo controllo.
Eppure ce ne sono molti che non configurano accuratamente i propri DNS, confortati magari dal fatto che servizi di registrazione di domini web e posta non professionali come aruba e register.it non danno questo servizio, nemmeno nella gestione avanzata.
Se non si seguono gli standard definiti dagli ingegneri che hanno costruito negli anni il funzionamento di ARPANET e poi di Internet saremo sempre in balia di problemi e non solo di sicurezza.
E’ vero che ci sono standard di fatto, non definiti da alcun ente ma diventati tali per la loro diffusione ed utilizzo, ma a lungo andare questi non pagano (per fare un esempio eclatante pensate ai file .doc).
Per il momento mi limito a segnalare agli svogliati amministratori i loro errori chiedendo di prendere provvedimenti. Se poi questi standard non vengono più seguiti e ci sarà un ripensamento anche da parte degli ingegneri di IETF allora cambierò anche io il mio modo di lavorare. Per il momento decido di seguire gli standard e di spiegare perché alcune cose non funzionano, anche se è sempre più difficile farsi capire e spiegare il perché.
