mailcow сообщает Spamhaus BLOCKED_OPENRESOLVER: мой IP спамит или блокировка DNSBL по IP-диапазону

В логах Rspamd или Postfix на mailcow вдруг появляется BLOCKED_OPENRESOLVER или код 127.255.255.254 от Spamhaus — и первая мысль администратора: сервер попал в спам-лист, надо переезжать на новый IP. На деле это чаще совсем другая история — Spamhaus просто отказывается отвечать на запрос через открытый или публичный DNS-резолвер, а IP сервера тут ни при чём. Разбираю, как отличить одно от другого и что чинить.

Симптом: код 127.255.255.254 вместо реального ответа DNSBL

Администратор мониторит корпоративную почту на mailcow, замечает в логах Rspamd сообщения вроде BLOCKED_OPENRESOLVER или странный код ответа от DNS-зоны Spamhaus — 127.255.255.254 вместо привычных кодов листинга (127.0.0.2 и подобных). Первый импульс — проверить репутацию своего внешнего IP через сторонние сервисы: не попал ли сервер в чёрный список из-за утечки учётных данных или взломанного ящика, который начал рассылать спам.

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

Код 127.255.255.254 — это не «ваш IP в списке», это специальный служебный ответ Spamhaus, который означает отказ обслуживать конкретный DNS-запрос из-за того, откуда он пришёл — то есть с какого резолвера. В штатном rbl.conf Rspamd в mailcow он так и называется: SPAMHAUS_BLOCKED_OPENRESOLVER (для доменного списка — DBL_BLOCKED_OPENRESOLVER), а соседний 127.255.255.255 (SPAMHAUS_BLOCKED) — отказ из-за превышения объёма запросов. Кроме Rspamd, списки Spamhaus в mailcow подключены и в Postfix через postscreen, поэтому смотреть стоит оба лога: docker compose logs rspamd-mailcow и docker compose logs postfix-mailcow. Спутать это с реальным листингом легко, если не знать про существование этого отдельного диапазона кодов ответа.

Особенно обидно, что эта путаница часто приводит к неправильным, но дорогим решениям: администратор видит слово «BLOCKED» и код, похожий на IP-адрес, делает вывод о репутационном блоке и запускает процедуру смены внешнего адреса сервера — а это не только время на DNS-пропагацию новых записей MX/SPF/DKIM, но и риск на несколько недель потерять уже наработанную репутацию отправителя у крупных почтовых провайдеров вроде Gmail и Mail.ru, которые доверяют устоявшимся IP больше, чем новым.

Почему так происходит: политика Spamhaus по открытым резолверам

20 июня 2023 года Spamhaus начал блокировать доступ к своим DNS-блок-листам с публичных DNS-резолверов и у крупных облачных провайдеров, которые маскируют исходный источник запроса — в частности у OVH, AWS и Cloudflare. Причина в требовании Terms of Use: Spamhaus нужна возможность соотнести объём запросов с конкретной организацией («attributable reverse DNS»), а публичный или замаскированный резолвер делает это невозможным — с точки зрения зоны Spamhaus запросы идут от анонимного крупного резолвера, а не от конкретного почтового сервера.

Технически публичные резолверы (условный 8.8.8.8 или аналогичные) агрегируют DNS-трафик тысяч разных клиентов через один и тот же исходящий IP. Spamhaus не может понять, сколько именно запросов реально принадлежит вашему почтовому серверу, а сколько — миллионам других пользователей того же резолвера, и на уровне лимитов это выглядит как один клиент, который делает астрономическое число запросов. Отсюда и отказ обслуживать — не потому что кто-то спамит, а потому что источник запроса нельзя атрибутировать.

Официальная документация mailcow отдельно предупреждает: публичные резолверы могут нарушать DNSBL-проверки в принципе, не только для Spamhaus, потому что у списков блокировки в целом есть лимиты запросов с одного IP, и mailcow рекомендует не использовать публичный резолвер как основной внешний DNS для сервера.

У этой истории есть и вторая волна: часть ограничений Spamhaus затронула не тех, кто сам вручную настроил публичный резолвер, а клиентов конкретных облачных провайдеров, у которых исходящий DNS-трафик по умолчанию идёт через общую инфраструктуру провайдера — то есть проблема возникает даже при дефолтной конфигурации mailcow, если сам хостинг заворачивает исходящие DNS-запросы на свой общий резолвер на уровне сети. Это и объясняет, почему администратор ничего не менял в unbound.conf, а ошибка всё равно появилась после определённой даты — изменилась не конфигурация сервера, а политика Spamhaus по отношению к конкретному провайдеру.

Как правильно диагностировать: свой IP или блокировка резолвера

Первое, что нужно понять — какой резолвер использует ваш mailcow для DNS-запросов вообще. По умолчанию стек mailcow разворачивает собственный контейнер unbound-mailcow, который резолвит рекурсивно сам, без обращения к публичным резолверам — и в такой конфигурации BLOCKED_OPENRESOLVER обычно не возникает — исключение составляют хостеры, к которым Spamhaus применил ограничения целиком (о них ниже и в разделе 2). Если ошибка появилась, стоит в первую очередь проверить data/conf/unbound/unbound.conf на предмет самодельной секции forward-zone, которую кто-то мог добавить для решения другой задачи (например, чтобы резолвить внутренние зоны компании через корпоративный DNS) и случайно перенаправить туда весь внешний DNS-трафик, включая проверки DNSBL.

Второй шаг — сверить факт листинга напрямую через официальный инструмент Spamhaus (Spamhaus Intelligence / lookup по вашему исходящему IP), а не полагаться на код ответа из логов Rspamd. Если официальный lookup не находит IP ни в одном списке Spamhaus, а в логах при этом видно именно 127.255.255.254 — это подтверждает, что проблема в резолвере, а не в репутации. Если же ваш сервер вообще недавно потерял поддержку версии — стоит заодно свериться, не истёк ли у вас срок поддержки Legacy-ветки mailcow: переменная SPAMHAUS_DQS_KEY и проверка через asn-check появились в mailcow с обновлением 2023-07, на более старой сборке их просто нет.

Третий шаг, специфичный для mailcow — проверка через встроенный механизм ASN: при генерации конфигурации и обновлении система сверяет автономную систему публичного IP сервера через asn-check.mailcow.email, чтобы определить, относится ли сервер к провайдеру из списка затронутых новой политикой (условно, крупные облачные хостеры, где Spamhaus массово заблокировал доступ к бесплатным зонам). Если сервер развёрнут у одного из таких провайдеров, DQS-ключ становится обязательным условием для продолжения работы Spamhaus-проверок, а не опцией на будущее.

Решение: свой резолвер плюс DQS-ключ, а не переезд

Если причина в том, что кто-то настроил пересылку DNS на публичный резолвер — решение простое: вернуть mailcow к рекурсивному резолвингу через собственный unbound-mailcow без forward-zone, либо, если внешний резолвер нужен по инфраструктурным причинам, использовать не публичный сервис, а собственный или провайдерский резолвер, который обязательно валидирует DNSSEC: документация mailcow прямо предупреждает, что с публичными резолверами «многие, если не все» DNSBL-проверки будут падать из-за лимитов на один IP, и что работают только DNSSEC-валидирующие DNS-сервисы. Пересылка задаётся блоком forward-zone в data/conf/unbound/unbound.conf с последующим docker compose restart unbound-mailcow.

Если же дело в том, что провайдер сервера попал под ограничение Spamhaus на уровне ASN — единственный официальный путь восстановить проверки Spamhaus это DQS (Data Query Service): регистрация аккаунта на сайте Spamhaus и добавление полученного ключа в mailcow.conf через переменную SPAMHAUS_DQS_KEY. Честно про деньги: бесплатный Free DQS по условиям Spamhaus рассчитан на некоммерческие небольшие организации и частных лиц с объёмом до 100 000 запросов в сутки; коммерческой компании условия нужно читать внимательно и, скорее всего, закладывать платную подписку. Переменная передаётся в контейнеры rspamd-mailcow и postfix-mailcow через окружение, поэтому после правки нужен docker compose up -d — он пересоздаст эти контейнеры с новым значением.

# mailcow.conf
SPAMHAUS_DQS_KEY=ваш_ключ_из_личного_кабинета_spamhaus

# применить (пересоздаст rspamd-mailcow и postfix-mailcow)
cd /opt/mailcow-dockerized && docker compose up -d

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

• Проверить unbound.conf на forward-zone к публичному резолверу
• Сверить листинг IP напрямую через официальный Spamhaus lookup
• Если провайдер под ограничением ASN — оформить DQS-ключ
• SPAMHAUS_DQS_KEY в mailcow.conf вместо смены IP или переезда

Кейс: «Коуч-гавань», 29 рабочих мест

Клиент — коучинг-центр «Коуч-гавань», 29 рабочих мест, mailcow на VPS у облачного провайдера, который позже попал в список ASN, затронутых новой политикой Spamhaus. Администратор клиента (в штате есть свой ИТ-специалист на полставки) увидел BLOCKED_OPENRESOLVER в почтовых логах, испугался репутационной блокировки и уже запросил у хостера смену внешнего IP, что означало бы простой почты на время DNS-пропагации и риск начать репутацию заново с чистого листа.

Мы подключились до того, как смена IP была запущена. Заодно, раз уж речь шла об обновлении и работоспособности сервера, свериться помогло и с нашим регламентом эксплуатации mailcow — у клиента накопилось ещё несколько отложенных плановых задач, которые решили закрыть тем же визитом. Проверили официальный Spamhaus lookup по текущему IP клиента — листинга не было ни в одном списке, включая сам Spamhaus. Дальше через asn-check.mailcow.email подтвердили: провайдер клиента действительно входит в список ASN, для которых Spamhaus требует DQS. Резолвер unbound-mailcow при этом был в дефолтной конфигурации, без сторонних forward-zone.

Решение — 20 минут: зарегистрировали аккаунт Spamhaus DQS на клиента, получили ключ, добавили SPAMHAUS_DQS_KEY в mailcow.conf, выполнили docker compose up -d. Поскольку «Коуч-гавань» — коммерческая организация, сразу прочитали с директором условия Free DQS и заложили в бюджет платную подписку на случай, если Spamhaus её потребует: это всё равно на порядок дешевле и спокойнее переезда. Проверки Spamhaus восстановились в течение следующего цикла проверки почты, без единой минуты простоя и без смены IP — запрос на переезд к хостеру отменили.

Отдельно зафиксировали для клиента итоговую экономию: смена IP у их хостера подразумевала окно техработ около двух часов, повторную настройку SPF/DKIM/DMARC записей на стороне регистратора домена и риск временного попадания части исходящих писем в спам у крупных получателей на период накопления новой репутации — по нашим прошлым проектам это обычно одна-две недели повышенного процента писем в папке «Спам» у адресатов. Вместо этого — регистрация DQS и одна строка в конфиге.

Когда IP всё же реально в списке — и как это отличить

Стоит отдельно проговорить обратный сценарий, чтобы не создавать ложное ощущение «Spamhaus всегда ошибается»: если IP сервера реально начал рассылать спам — например, через скомпрометированный ящик сотрудника или открытый relay — официальный Spamhaus lookup покажет реальный листинг с конкретной причиной и конкретным блок-листом (SBL, CSS, XBL и так далее), а не служебный код 127.255.255.254. В этом случае DQS-ключ не поможет вообще — нужно сначала устранить источник спама (сменить пароли, проверить правила пересылки и relay-настройки Postfix), и только потом запрашивать делистинг через официальную форму Spamhaus.

Разница на практике простая: 127.255.255.254 — это отказ обслуживать конкретный запрос из-за резолвера, реальный листинг — это конкретный код из диапазона 127.0.0.x (в ZEN: 127.0.0.2 — SBL, 127.0.0.3 — CSS, 127.0.0.4–127.0.0.7 — XBL, 127.0.0.10–127.0.0.11 — PBL, причём PBL означает лишь «динамический/не предназначенный для отправки почты диапазон», а не спам) с указанием причины и обычно с найденным источником проблемы на самом сервере. Если вы видите первое — чините DNS и DQS; если второе — сначала закрывайте инцидент безопасности (в том числе проверьте, не пропускает ли Postfix лишнее — я отдельно разбирал похожий кейс открытого релея на Postfix), и только потом разбирайтесь с делистингом.

На практике я советую клиентам добавить обе проверки в регламент реагирования на почтовые инциденты: если в логах Rspamd или Postfix появляется что угодно похожее на код Spamhaus, первым шагом всегда идёт официальный lookup по IP через сайт Spamhaus, а не паника и не немедленный запрос на смену адреса у хостера. Это занимает пять минут и сразу отсекает половину ложных тревог, которые иначе превращаются в часы ненужной работы и реальный простой почты.

Частые вопросы