
Qualche giorno fa, improvvisamente, il mio server di posta aveva iniziato a rifiutare tutte le mail in arrivo: Da un momento all’altro, le DNSBL di Spamhaus (ma anche qualunque altra abbia provato ad utilizzare) segnalavano la posta in ingresso come spam. All’inizio ho pensato a qualche mio errore di configurazione (anche se è strano che un sistema cambi di colpo il suo comportamento) e ho disabilitato temporaneamente i filtri antispam, in modo da ricevere almeno la posta.
Avevo subito notato una particolarità nei log: le mail legittime, ma scartate per errore, non avevano il campo “reason”, che punta all’indirizzo web in cui trovare il motivo per cui l’indirizzo IP in questione è iscritto alle liste di Spamhaus.
Grazie all’aiuto del buon Gervystar, ho capito che il problema stava in qualche modo nei DNS, anche se apparentemente tutto funzionava a dovere tranne la consultazione delle liste antispam. Mi sono quindi documentato sul funzionamento delle DNSBL e ho capito che il problema era effettivamente nei DNS, ma in quelli che Alice fornisce agli utenti ADSL.
Una DNSBL non è altro che una lista di indirizzi IP in cui vengono inseriti gli indirizzi delle fonti di spam: affinchè funzionino bene, devono essere costantemente aggiornate. Spesso contengono anche i blocchi di indirizzi assegnati dai provider come IP dinamici agli utenti dialup o ADSL, che grazie a worm o configurazioni fatte alla pene di segugio si trovano ad essere fonti inconsapevoli di tonnellate di spam.
Un server di posta, nel momento in cui vuole utilizzare una DNSBL come filtro antispam per le mail in arrivo (o in transito verso altri server), si comporta in questo modo:
Il controllo avviene in maniera analoga a una normale query DNS (per questo le liste vengono chiamate DNSBL: DNS Blackhole List). Partendo dall’indirizzo IP da controllare (aaa.bbb.ccc.ddd) e dalla zona DNS assegnata alla lista (lista.antispam.tld), si ricava l’hostname su cui fare una normale richiesta DNS sul record di tipo A. Nell’esempio considerato, l’hostname da controllare sarebbe:
ddd.ccc.bbb.aaa.lista.antispam.tld
La richiesta DNS può avere due esiti:
Nel caso specifico, per controllare l’IP 87.4.233.209 (uno degli indirizzi IP che Telecom mi ha assegnato ultimamente) su Spamhaus (zen.spamhaus.org) bisogna utilizzare questa query DNS:
mbg@mercury:~$ dig +short 209.233.4.87.zen.spamhaus.org
127.0.0.10
Come si può vedere, trattandosi di un indirizzo IP dinamico assegnato a utenti ADSL casalinghi (io, nella fattispecie), è indicato come fonte di spam. Il significato del codice di risposta (10, in questo caso) è variabile da gestore a gestore: nel caso di Spamhaus, è disponibile una comoda tabella.
Negli ultimi giorni, per via di una maldestra iniziativa commerciale, i server DNS (non so se tutti o solo alcuni) che Alice ADSL assegna ai suoi utenti si comportano in modo anomalo: se si richiede un hostname inesistente, anzichè rispondere che l’host non esiste restituiscono l’indirizzo IP 212.48.8.140.
Perchè tutto questo? Semplice, quell’indirizzo IP corrisponde a un server Web che mostra una pagina di ricerca di Virgilio, motore di proprietà di Telecom Italia. Per cercare di recuperare un po’ di svantaggio da Google, i geni del marketing di Telecom Italia hanno pensato di stravolgere la logica di funzionamento di un server DNS. Ne hanno parlato in molti e nessuno sembra contento della cosa:
Ad onor del vero, bisogna dire che anche OpenDNS fa cose simili, pur con altre finalità.
In un primo momento non avevo collegato le due cose, ma poi il problema è diventato ovvio. Affinchè un messaggio in arrivo sia considerato valido dal mio mail server, la query DNS sulla lista antispam non deve fornire risultati. Se il DNS di Alice fornisce in ogni caso un risultato (l’IP del server di Virgilio, nel caso in cui l’host sia inesistente), si può capire come mai tutte le mail entranti venissero bloccate.
La soluzione? Utilizzare il DNS già presente e configurato sul mio server. Per una mia leggerezza, tutte le macchine della rete lo usavano già, ad eccezione del server stesso. Mi è bastato disabilitare l’impostazione automatica del DNS e inserire “nameserver 127.0.0.1” in /etc/resolv.conf per avere tutto nuovamente funzionante. Con robuste e meritate imprecazioni a chi, in Telecom, ha avuto questa brillante pensata.
Nel 2003 Verizon utilizzò una tecnica simile, chiamata Site Finder, per mostrare agli utenti pagine pubblicitarie e portarsi in vantaggio sulla concorrenza nella registrazione dei domini. Il sistema, sommerso dalle proteste, rimase attivo per una quindicina di giorni. Quello di Telecom Italia è in funzione da una settimana: con tutta probabilità resterà attivo per un bel po’ di tempo e verrà visto come una funzionalità anzichè come il problema tecnico che è in realtà.
Se vuoi inserire un commento, per favore completa il form sottostante.
Il contenuto di questo sito web è pubblicato sotto una Licenza Creative Commons.