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

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

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

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

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

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

Synology Mail Plus Server DNSBL

На скриншоте выше включен 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

Канал Телеграм Канал Дзенс Группа ВКонтакте Канал YouTube Канал Rutube

Подписаться
Уведомить о
guest
2 Комментарий
Старые
Новые
Межтекстовые Отзывы
Посмотреть все комментарии