Quando anche le reverse s’inversano…
Qualche tempo stavo mettendo in produzione un mail server e nel far ciò ho richiesto (tramite apposito ticket aperto su apposita interfaccia web) la variazione della reverse sull’IP pubblico che avremmo utilizzato dal default QUALCHECOSA.retedelprovider.it al più appropriato (come da RFC1912) mail.dominio.tld.
Dopo aver ricevuto conferma del ticket ed aver fatto le prove del caso sul sistema dichiaro “good to go” il mail server, gli utenti cominciano ad usarlo, e non ci sono apparenti problemi. Me ne dimentico felicemente, sicuro che il fido nagios mi avrebbe avvisato in caso di qualsiasi problema – ma ovviamente mi sbagliavo.
Solo un po’ di tempo più avanti mi scrive un utente di quel mailserver girandomi una DSN che recitava:
Remote host said: 421 4.1.2 <tiziocaio@suodominio.hu>: Recipient address rejected: The reverse name of your IP address doesn’t map back to the same IP (see http://blahblah for details)
Incuriosito vado a verificare che reverse avevo richiesto, vedo che è giusta, verifico che ci sia il corrispondente record A, vedo che c’è. Allora mi viene un dubbio e verifico quale reverse viene effettivamente servita dai dns del provider: mail.dominio.tld.X.Y.Z.in-addr.arpa!!!
Un banale errore di battitura è passato inosservato sia da me che dal provider che ha effettuato la variazione, e la conseguenza era che alcuni antispam molto zelanti si irritavano e rifiutavano la posta.
Morale della favola #1: non fidarsi mai nemmeno di chi sta sopra di te, verifica sempre il loro operato
Morale della favola #2: ora ho uno script nagios che tiene sott’occhio anche le reverse 
