Почему лучше не использовать DNSBL

Всем привет!!!

Когда вы запускаете свой почтовый сервер, то наверняка читаете кучу статей, в которых описаны различные варианты защиты от спама и в 95% этих статей рекомендуют использовать DNSBL как один из самых продвинутых вариантов защиты. Но я хочу вас переубедить в этом, что бы вы никогда не использовали DNSBL для защиты вашего сервера от спама.

DNSBL – это база ip адресов, которые рассылают спам. Ваш сервер при получении письма запрашивает у сервера, который хранит все ip адреса спамеров, и получает ответ хороший это ip адрес или он есть списке. Таких серверов DNSBL сейчас очень много. Как правило зарабатывают такие сервера DNSBL на том, что если ваш IP в их списке и вы хотите удалить, то платите деньги. Ну или на рекламе на сайте. Например, на странице удаления IP адреса из списка этого сервиса.

Казалось бы это решение очень крутое и простое. Да на первый взгляд действительно все просто. Вам не нужно париться, за вас все сделали другие. Вы заходите в поиск и находите кучу таких серверов, добавляете их в свой почтовый сервер и радуетесь, что теперь спам к вам не попадает. И это действительно так. Таким образом можно отсечь практически весь спам, который попадает на ваш почтовый сервер.

Например, в Synology Mail Plus сервере эта настройка уже выполнена и остается только включить ее:

На скриншоте выше включен DNSBL и добавлено два сервера с оценкой 1, а порог так же 1. Это означает, что если хотя бы в одном из этих серверов есть запрашиваемый ip адрес в базе, то почта будет отброшена.

Победа умного человека над тупыми машинами )))) Дело сделано, пошли пить чай.

Но тут не все так однозначно. Дело в том, что в эти базы данных DNSBL могут попадать и попадают не только IP адреса рассылающие спам, но и другие, зачастую невиновные организации. Как это происходит если честно я не знаю. Некоторые говорят это происходит специально ради вымогательства денег. Другие говорят, что это ложные срабатывания. Но в эти же базы данных зачастую попадают и крупные почтовые системы например yandex или mail.ru. Вот вам пример ниже:

Если дело касается какой-то небольшой организации, то как правило на ум приходит простое решение: косяк у них пусть они и чинят. Или еще: просто добавить ip адрес почтового сервера организации в свой белый список. Да так можно поступить и это будет работать. Но проблему от этого не решить. На администратора рано или поздно свалится огромная гора жалоб от коллег, что почто постоянно не приходит. И на своем опыте скажу, коллеги начнут пользоваться не корпоративной почтой, а своей личной, так как она не глючит. Но самое плохое может быть в другом, когда директор не получит очень важное письмо и очень важный контракт сорвется из-за этого. Вот тогда администратор почтового сервера, который включил защиту от спама DNSBL узнает много нового про себя и про свою работу.

Еще всегда нужно помнить, что люди не все хорошие. Очень много всяких ЛГБТ поклонников и прочих больных на всю голову людей. И вы не знаете, кто управляет сервера DNSBL. Так например после начала СВО такие люди стали проявлять себя более активно и дошло до того, что часть IP адресов с РФ по каким-то непонятным причинам попала в списки DNSBL. Практически все, кто пришел ко мне после февраля 2022 года столкнулись с этой проблемой. Почта просто намертво встала в некоторых организациях.

Ну а как тогда быть, если не включать DNSBL? Решение тоже есть и оно тоже работает. Дело в том, что сообщения, пришедшие из бот нетов имеют одну или несколько перечисленных характерных особенностей: 

• У хоста отправителя нет обратной DNS-записи. 
• Синтаксис представления HELO не верный. 
• В HELO хост отправитель представляется не полным именем. 
• В HELO хост отправитель представляется именем, для которого нет A или MX записи. 
• Хост отправитель не повторяет попытку доставки сообщения в ответ на ошибку 4хх 
• Сообщение имеет в поле From несуществующий домен. 
• Сообщение имеет в поле From существующий домен, но несуществующий адрес
• SPF запись отсутствует в DNS записях домена
• В теле письма неверный или отсутствует поле DKIM

Зная это разработчики почтовых серверов, в том числе и Synology, заложили весь необходимый функционал, который достаточно только включить и спаму не пройти.

Начну с настроек Synology Mail Plus Server

Первым делом включаем программу защиты от спама:

Ставим одну галочку и настраиваем периодическое обновление Rspamd. Как видите DNSBL я не включаю. Можно включить серый список, но имейте в виду, что тогда почта может долго доходить. Работает это следующим образом. Когда к вам приходит новая почта, то сервер запоминает ее и отклоняет по причине занятости. В этом случаи, если письмо писал бот, то ответ о занятости никто не получит и соответственно на этом история этого спама закончится. Если же это полноценный почтовый сервер, с которого действительно было отправлено это письмо, то оно останется в очереди и сервер попытается отправить его снова. И вот когда оно придет повторно, то наш сервер увидит его в своем сером списке и спокойно примет, зная что это не спам бот писал. Я бы не рекомендовал включать этот метод без особой необходимости.

Идем дальше на вкладку Проверка подлиности и включаем SPF и DKIM.

Проверку DMARС я не включал, мой сервер справляется и без нее. Тут надо понимать, что чем больше вы настроите, тем больше отсеете спама, но и вероятность отсеивания нужной почты возрастет. Нужно найти минимально необходимые настройки.

Дальше включаем сканирование опасного содержимого

Теперь переходим в доставка почты вкладка безопасность:

Рекомендую выставить параметры как у меня, это отсеет очень много если не весь спам и только спам. Так как почта от реальных пользователей будет содержать все необходимые поля, а спам нет.

Все выше сказанное относилось к Synology Mail Plus Server. Все настройки выполняются мышкой, в понятных местах и меню. А если у вас Linux сервер с postfix, то практически теже настройки будут выглядеть так.

Я не буду подробно расписывать что означает каждый из пунктов, а всего лишь приведу часть конфигурационного файла postfix со ссылкой в скобках на пункты характеристик. Скобки, естественно, нужно убрать перед использованием опций в своем конфиге. 

unverified_recipient_reject_code=550 
smtpd_helo_required = yes 

smtpd_client_restrictions = 
permit_mynetworks, 
reject_unknown_client

smtpd_helo_restrictions = 
permit_mynetworks, 
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unknown_hostname

smtpd_sender_restrictions = 
permit_mynetworks, 
reject_non_fqdn_sender, 
reject_unknown_sender_domain,
reject_unverified_sender

smtpd_recipient_restrictions = 
permit_mynetworks, 
reject_non_fqdn_recipient, 
reject_unauth_pipelining, 
reject_unauth_destination, 
reject_unlisted_recipient, 
check_policy_service inet:127.0.0.1:10023 

По последнему параметру нужно сделать замечание, что использование данной особенности называется Greylisting. Более подробную информацию по Greylisting’у можно прочитать в википедии. В данном случае для грейлистинга рекомендуется пакет postgrey. 

Что получим в итоге? Вот, пожалуйста, скриншотик:

Этих настроек должно хватить, что бы отсеять спам на вашем сервере, но, как и все в интернете эти настройки не гарантируют полную блокировку спама. Он все равно будет, но его будет очень мало.

Почему лучше не использовать DNSBL