Из‑за недельного игнорирования со стороны поддержки Spamhaus и частых ложных блокировок легитимных доменов, стоит ли отключить проверку Spamhaus DBL в конфигурациях Rspamd/SpamAssassin?

Привет всем, <br/> <br/> Хочу поставить вопрос о надёжности Spamhaus как «золотого стандарта» антиспама: у нас возникла абсурдная ситуация, которая демонстрирует, что Spamhaus способен внести в бан-лист вполне чистый проект, а служба поддержки игнорирует проблему, нанося финансовый и репутационный ущерб. <br/> <br/> Суть: наш домен внезапно попал в черный список Spamhaus DBL. <br/> <br/> Технические детали: при первоначальном автоматическом ответе бот Spamhaus объяснил блокировку правилом «плохого соседства» (bad neighborhood). При этом проверка репутации самой подсети и нашей автономной системы (AS) в интерфейсах Spamhaus показывает идеальную чистоту — с соседних адресов спама не идёт. <br/> <br/> Мы 28 июня подали мотивированное техническое требование о передаче тикета на ручное рассмотрение как очевидной ошибке автоматики. На 6 июля тикет остаётся в статусе "Open", и после запроса ручного разбора со стороны поддержки последовал <b>полный игнор</b>: ни одного ответа от живого человека более недели. <br/> <br/> Из‑за этого крупные почтовые провайдеры (например, Hotmail и Proton Mail), которые проверяют Spamhaus на уровне SMTP-сессии, отбрасывают письма нашим пользователям. Поддержка Proton Mail в переписке пояснила: «Мы видим ваш тикет в Spamhaus и понимаем ситуацию, но не можем вручную внести вас в allowlist, пока соединение блокируется на серверном уровне фильтрами Spamhaus». <br/> <br/> В итоге возникает вопрос о том, насколько безопасно слепо полагаться на Spamhaus: может ли администратор почтового сервера, полностью доверяющий этой базе, по ошибке навсегда заблокировать легитимные проекты?
  • 6 июля 2026 г. 18:00
Ответы на вопрос 2
Короткий ответ
- Не рекомендую сразу полностью отключать DBL глобально — это снизит защиту и откроет дорогу спаму.  
- Лучше временно убрать DBL из правил «жёсткого» SMTP‑отклонения и/или снизить его вес в скоринге, добавить локальный whitelist для пострадавшего домена и одновременно добиваться ручного разбора у Spamhaus и у получателей (MS/Proton).  

Почему так
- Spamhaus — действительно очень хороший источник, но не безошибочен: бывают ложные срабатывания автоматики.  
- Полное отключение DBL означает потерю одного из уровней фильтрации — это увеличит процент пропускающегося спама.  
- Более безопасный подход — уменьшить влияние одной некорректной сигнатуры, при этом сохранить её для диагностики и статистики.

Практические шаги (порядок действий)
1) Немедленная смягчающая мера (рекомендуется первой)
   - Переведите проверку DBL в «мягкий» режим: не использовать результат DBL как единственную причину для SMTP‑REJECT. Оставьте DBL для скоринга, но так, чтобы одна только метка DBL не давала порога reject.
   - Параллельно добавьте локальную белую запись для пострадавшего домена/поддомена/URI чтобы восстановить доставку срочных писем.

2) Конфигурация Rspamd (примерные варианты)
   - Отключить модуль DBL полностью (если решите так): создать local.d/dbl.conf с:
     enabled = false;
     (Это полностью исключит DBL.)
   - Более гибко: оставить модуль включённым, но снизить его влияние — уменьшить score символа DBL в local.d/metrics.conf или в override списка символов. Также можно настроить whitelist в local.d/dbl.conf (map с доменами).
   - ИМХО лучший вариант: оставить DBL, но поднять порог reject в actions так, чтобы DBL сама по себе не вызывала reject.

3) Конфигурация SpamAssassin
   - Уменьшите или обнулите вес правила URIBL_DBL, например в local.cf:
     score URIBL_DBL 0.0
     (либо установите небольшое положительное значение, чтобы DBL влияла на общий скор, но не порочила ранний reject).
   - Добавьте whitelist_from / whitelist_from_rcvd для критичных отправителей, если нужно.

4) Локальные исключения и правила
   - Ведите централизованный локальный whitelist (map), в который можно быстро добавить заблокированные домены/поддомены/отправителей.
   - Убедитесь, что подпись DKIM, SPF и DMARC настроены правильно — это уменьшит зависимость от сторонних DBL у принимающей стороны.

5) Обращения и эскалация
   - Повторно подайте заявку на разбор через официальный removal/lookup на сайте Spamhaus, приложите конкретные логи (MAIL FROM/RCPT TO, пример отклонения на SMTP‑уровне, ответ сервера Spamhaus, whois домена, подтверждение отсутствия рассылки с адресов сети). Чем больше техданных — тем быстрее ручной разбор.
   - Если тикет игнорируют — сделайте follow‑up через тот же канал, сохраняя/архивируя переписку; для срочных случаев попробуйте каналы для сетевых операторов (если у вашего почтового хоста есть «network/operator» статус у Spamhaus), либо подумайте о платной подписке/доступе к оперативной поддержке (если вы на неё готовы).
   - Сообщите принимающим провайдерам (Microsoft, ProtonMail и т.д.) о проведённых действиях и приложите ссылку на тикет у Spamhaus — иногда они сами могут помочь ускорить разбор или посоветовать обходной путь.

6) Долгосрочные меры
   - Не полагайтесь на один источник — используйте несколько репутационных баз и локальные эвристики. Мульти‑сигналы дают устойчивость.
   - Настройте мониторинг и alerting: автоматическое обнаружение падения доставляемости + генерация тикета/уведомления.
   - Документы/процедуры: у команды должна быть стандартная процедура на случай, если внешняя RBL ошибочно блокирует легитимный сервис (куда писать, какие логи собирать, как временно обойти блок).

Когда имеет смысл полностью отключить DBL
- Если у вас хроническая проблема с частыми ложными положительными от этой конкретной базы, и вы не можете получить адекватной поддержки, и при этом вы готовы компенсировать потерю этой защиты другими мерами — можно отключить DBL, но только с чётким понимаем рисков и с усилением остальных фильтров. До отключения лучше понизить вес и использовать whitelist + обращение/эскалацию.

Короткая чек‑лист рекомендаций для вас сейчас
- Снять DBL из критических правил reject на SMTP (или поднять reject‑порог).  
- Добавить пострадавший домен в локальный белый список.  
- Снизить вес DBL в скоринге (или обнулить пока).  
- Подать/обновить заявку в Spamhaus с доказательствами, логами и запросом ручного разбора.  
- Проинформировать получателей (MSN/Proton и т.д.) с данными тикета и логами.  
- Настроить мониторинг и процедуру эскалации на будущее.

Если хотите, могу:
- Подготовить конкретные конфигурационные примеры для вашей версии Rspamd и SpamAssassin (укажите версии и фрагменты текущих конфигов).  
- Сформулировать шаблон письма/заявки для Spamhaus и для провайдеров (Microsoft/Proton) с нужными логами и доказательствами.
UPD (07.07.2026): Проблема полностью решена вручную руководством Spamhaus. Вскрылись дикие технические подробности. <br/> <br/> Делюсь финалом этой истории, который подтверждает самые худшие опасения касательно логики работы современных блеклистов и их "черных ящиков". Наш домен и его IP-адрес полностью вычищены из баз Spamhaus лично Полом Барбером (одним из топ-менеджеров компании). Они официально признали баг своей тикет-системы и извинились за задержку. <br/> <br/> В чем была реальная причина: <br/> Автоматика Spamhaus забанила наш домен из-за ложного триггера пассивного DNS. Месяц назад (6 июня) наш хостер (VDSina) экстренно переезжал в другой дата-центр. Сайт был полностью недоступен, т.к. дата-центр VDSina был полностью отрезан от Интернета, мы на два дня привязали домен к временному IP-адресу (другого провайдера), где крутилась статическая заглушка типа "Сайт на техобслуживании" (почта оттуда вообще не ходила). Через 2 дня домен вернулся на чистый основной IP. <br/> <br/> Спустя аж три недели (26 июня) этот временный IP попадает в DROP-лист Spamhaus за какую-то сетевую активность (по принципу "плохого соседства"). И робот Spamhaus задним числом начинает банить наш домен, проигнорировав тот факт, что домен уже почти 3 недели как не имеет к этому IP никакого отношения. <br/> <br/> Как удалось пробить стену игнора: <br/> Первоначальный тикет от 28 июня до сих пор висит в статусе "Open". Помог только жесткий обходной маневр: <br/> <br/> 1. Жалоба была отправлена напрямую в обход первой линии через форму корпоративного комплаенс-центра Spamhaus (Contact Center) с указанием на технические нестыковки. <br/> <br/> 2. Параллельно велась переписка с поддержкой Proton Mail, которые, судя по всему, со своей стороны также пнули Spamhaus по закрытым B2B-каналам postmaster'ов, так как блокировка ломала почту их собственным клиентам. <br/> <br/> Вывод для сисадминов по поводу доверия к Spamhaus: <br/> Прецедент закрыт, но осадок остался огромный. Робот Spamhaus может заблокировать вас на основе устаревших исторических данных, даже если вы идеально чисты прямо сейчас. При этом их базовая тикет-система из-за внутреннего бага (re-tagging bug) способна молча похоронить ваш легитимный запрос на ручной разбор на многие дни (у нас 9+ дней). <br/> <br/> Если для решения проблемы чистого 7-летнего проекта требуется поднимать на уши комьюнити Rspamd, подключать юристов и заставлять Proton Mail эскалировать тикеты — Spamhaus определенно больше не является золотым стандартом. Оставлять его в дефолтных конфигах Rspamd/SpamAssassin с высоким весом — это огромный инфраструктурный риск для любой компании. <br/> <br/> Всем спасибо!
Похожие вопросы