Ten problem je ale take na strane provozovatelu postizenych mailserveru - v nedostatecne validaci vracene DNS odpovedi. Ono testovat jen, zda-li dotaz vrati nejaky "A" zaznam (jak tvrdi treba ten GigaServer) rozhodne nestaci, ono je take potreba kontrolovat take navratovou hodnotu jako takovou - zda se vrati adresa ocekavana v zavislosti na specifikaci blacklistu. Typicky 127.0.0.2; nektere blacklisty pouzivaji dalsi adresy v ramci 127.0.0.0/8; ale malokdy neco jineho - ale <u>vzdy</u> maji provozovatele popsano, jake navratove hodnoty ocekavat.
A ti, kteri dnes meli nejaky problem zcela prokazatelne tuto kontrolu neprovadi vubec - vyprsene zaparkovane DNS servery maji wildcard a pro domenu spamcop.net vraci na vsechny dotazy IP 91.195.240.87. Pri spravne validaci vstupu by problem nikdo ani nezaregistroval. Aneb kdyby si provozovatele poradne precetli RFC 5782, tak by problem vubec nemeli... :-) Nekontrolovat vstup v roce 2021 stoleti je amaterismus.
Nepouzivam, ale zvedavost mi nedala... SpamAssassin ve vychozi konfiguraci overuje existenci TXT zaznamu (volani check_rbl_txt). Takze ten by postizeny byt nemel.
tak mě to postihlo dnes taky - z ničeho nic uprostřed dne kolem oběda. Naštěstí se za pár desítek minut podařilo dohledat chybu. Ale je pravda, že mě neskutečně DERE naprosto laxní přístup Microsoftu a jeho programátorů při vývoji Exchange serveru.. Je fajn tam mít RBL listy, je správné, že každá příchozí zpráva se validuje oproti všem RBL listům a pokud jeden řekne NE, tak ji nepustí dále.. ale když ten jeden NEDA absolutně žádnou odpověď, tak by se na něj vůbec nemělo koukat a zprávu pustit dále.. jo a takový detail jako do NDR zprávy pro odesílatel přidat kromě "your IP is blocked" doplnit RBL list, který to tak vyhodnotil - no to už by bylo až moc.. jsem neskutečně na--ranej. Naštěstí, že se to dalo rychle odhalit.