Skip to content


Почему я ненавижу DNSBL

DNSBL (DNS Blocking List, также называемый RBL — Realtime Blackhole List) — один из самых массовых средств защиты почтовых серверов от спама. Сервер по протоколу DNS обращается к серверу блоклиста и получает информацию о том, находится ли сервер-отправитель письма в блокировке. Если да — письмо отвергается.

DNSBL — один из самых несовершенных, а в неопытных руках откровенно опасных методов защиты от SPAM-а.

И вот 7 пунктов, это подтверждающих:

1. Неадресность.

Большая часть блокировочных листов включает в себя не одиночные IP openRelay/cracked среверов, а целые подсети, а зачастую и автономные системы. Таким образом «благодаря» нескольким нарушителям в блокировку попадают сотни (а то и тысячи, в случае с крупными ДЦ) IP-адресов, в числе которых оказываются хостинг-провайдеры, провайдеры электронной почты, выделенные сервера и т.д. Ваши клиенты вместе со спамом лишаются почты и от них.

2. Неэффективность.

До 80% спама в наше время рассылается не арендованными спамерами выделенными серверами, а взломанными серверами или зараженными троянским ПО десктопами. Как правило, они используются одноразово — в процессе рассылки либо владелец замечает паразитную активность, либо его провайдер блокирует доступ к сети. DNSBL в силу медлительности самого способа обнаружения и регистрации спам-серверов просто не могут с должной скоростью реагировать на эту угрозу. Внесение сервера/подсети в список как правило происходит уже после того, как основная масса спама будет разослана (и получена).

Отсюда, также, вытекает и следующий пункт:

3. Инерционность

Сервер очищается от спам-скриптов, десктоп проверяется антивирусом. Казалось бы, проблема решена — спам-письма уже не отправляются. Но только не для DNSBL! Многие списки, например SpamHaus хранят записи о листинге месяцами, а то и годами. Таким образом, уже давно «чистый» сервер находится в черном списке, а ваши клиенты теряют уже вполне легитимную почту. Арендованный сервер может даже поменять владельца и размещенные на нем сайты, а ваши пользователи все еще лишены почты оттуда.

4. Ложные срабатывания.

Ложные срабатывания — беда практически всех DNSBL. Выполненная по всем правилам рассылка может быть ошибочно определена как спам, а автоматический ответ (например о регистрации тикета или том, что сотрудник находится в отпуске) — как backscatter. При этом, попасть в список намного проще, чем выбраться оттуда. Многие списки вообще не поддерживают досрочный delisting, остается только ждать отведенный «срок» (зачастую — месяц или более). Все это время часть адресатов будет лишена вашей электронной почты.

5. Неадекватность требований.

Практически все DNSBL требуют для исключения из списка объяснить причину туда попадания. Это разумное требование, но и оно нередко оказывается сложновыполнимым — если сервер попал в список в силу ошибки или случайных действий какого-то человека внутри компании.

Но есть и те, кто требует предоставить доступ к серверу или даже уплатить штраф(!!!) за исключение. Естественно, большинство вебмастеров игнорирует такие требования, особенно от мелких списков.

А пользователи тех, кто использует такой список лишаются почты от вполне безопасных сайтов/форумов/других пользователей.

6. Неадекватность администрации списка.

Примеры: RuCENTER -vs- SpamHaus, AGAVA -vs- SpamHaus

7. Взлом самого DNSBL.

Сами блок-листы не вечны. Их иногда взламывают, иногда они закрываются или просто сходят с ума. В лучшем случае DNSBL станет просто недоступен (а ваш сервер начнет генерировать тучу DNS-запросов вникуда), в худшем — начнутся ложные срабатывания и ваши клиенты потеряют нужную корреспонденцию.

8. Неподконтрольность.

DNSBL не имеет договорных отношений ни с отправителем, ни с получателем письма. Никаких рычагов воздействия на список нет, максимум, что можно сделать — перестать его использовать. А у отправителя письма нет и этого. Грубо говоря, список вам ничего не должен и влиять на его действия вы не можете.

Вывод: использование DNSBL требует крайней осторожности и понимания того, что вы делаете. Бездумное подключение списков может привести к печальным последствиям.

Наиболее правильная с точки зрения надеждности и гибкости методика — принятие решения об отправке письма в спам по многим признакам, где наличие в RBL — только один из них. Сделать это можно на базе собственного сервера (с использованием SpamAssasin или подобного ПО) или аутсорсингом антиспама (Google Hosted Mail, Янедекс.Спамооборона).

Posted in Без рубрики.

Tagged with , , , .


0 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.



Some HTML is OK

or, reply to this post via trackback.