[Часть 1] Когда в блоклисте не ты, а весь дата-центр

Начиналось всё безобидно: я хотел разобраться, что такое «Почтовый сервис» у Selectel и можно ли через него отправлять почту с моего iRedMail. Закончилось тем, что я нашёл на сервере четыре независимых поломки, две из которых тихо лежали несколько дней.

Эта статья — про первую и самую фундаментальную.

Симптом

Смотрю лог после того, как настроил релей и отправил тестовое письмо. Оно уходит. И вместе с ним уходит что-то ещё:

postfix/selectel/smtp: 4gyhQs2LTQzyb3: to=<user@example.info>,
  relay=smtp.relay-provider.example[...]:1126, delay=71997, ... status=sent

delay=71997. Это секунды. Двадцать часов. А в следующей строке — delay=116847, то есть тридцать два часа.

Письма лежали в очереди больше суток, и никто этого не заметил. Исходящая почта была мертва, потому что исходящий 25-й порт у провайдера закрыт, а релей ещё не был настроен. Postfix честно ретраил, письма честно копились, алертов не было — потому что мониторинга глубины очереди тоже не было.

Первый вывод, банальный, но выстраданный: postqueue -p | tail -1 должен быть в мониторинге. Порог хоть какой-нибудь. Тихо растущая очередь — один из самых противных отказов, потому что снаружи всё выглядит работающим.

Почему закрыт 25-й порт

Провайдеры закрывают исходящий 25-й, чтобы с их облака не рассылали спам. Это стандартная практика, и обычно она означает: «отправляйте через наш SMTP-релей». Логично.

Но у меня возник вопрос: а можно ли попросить открыть? Сервер настоящий, домены подтверждены, DKIM/SPF/DMARC на месте, PTR запрошу. Ответ провайдера был примерно такой: «IP в блоклисте, вытащить не можем».

Вот тут и началось интересное.

Попытка проверить IP: сюрприз номер один

Казалось бы, тривиально:

dig +short 10.113.0.203.zen.spamhaus.org A
127.255.255.254

Есть! Листинг! Но погодите. 127.255.255.254 — это не листинг. У Spamhaus это служебный код: «запрос отклонён».

Дело в том, что Spamhaus давно закрыл бесплатные публичные зеркала для запросов из дата-центров и с публичных резолверов вроде 1.1.1.1 и 8.8.8.8. В моём /etc/resolv.conf стоял как раз Cloudflare, так что ответ был предопределён.

Ставлю локальный unbound, чтобы ходить к корням самому:

apt install -y unbound
dig @127.0.0.1 +short 10.113.0.203.zen.spamhaus.org A
127.255.255.254

То же самое. Потому что режут не резолвер, а исходный IP запроса. Мой сервер стоит в дата-центре — значит, отказ независимо от того, чей резолвер я использую.

Побочное открытие

И тут доходит вторая мысль, куда неприятнее исходной задачи. Если Spamhaus не отвечает на запросы с этого сервера — значит, он не отвечает и моему postscreen. И SpamAssassin тоже.

Проверяю:

postconf -n | grep postscreen_dnsbl
postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]*3 b.barracudacentral.org=127.0.0.2*2
postscreen_dnsbl_threshold = 2

Хорошая новость: iRedMail фильтрует по кодам возврата (=127.0.0.[2..11]), поэтому служебный 127.255.255.254 не попадал в маску и очков не давал. Ложных блокировок легитимной почты не было.

Плохая новость: Spamhaus с весом 3 не сработал ни разу. При пороге 2 всю оборону держала одна Barracuda с весом 2.

grep -c "postscreen.*CONNECT" /var/log/mail.log     # 385
grep -c "postscreen.*DNSBL rank" /var/log/mail.log  # 5

385 соединений, 5 отбитых. 1,3%. Для почтового сервера с белым IP в интернете это неправдоподобно мало — обычно DNSBL режет десятки процентов мусора на входе. Разница и есть цена молча отключённого Spamhaus.

В тестах SpamAssassin та же картина, просто в другой обёртке:

Tests: [..., RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001,
        URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001]

Суффикс _BLOCKED_OPENDNS означает ровно то же: «запрос отклонён». Не работали ни репутация IP, ни проверка доменов в ссылках (DBL), ни URIBL. Три основных механизма — вхолостую.

Как всё-таки проверить IP

Два пути.

Через веб — быстро и без регистрации: check.spamhaus.org. Там квоты ни при чём.

Через DQS — правильно и на постоянку. Spamhaus раздаёт бесплатные ключи Data Query Service. С ключом зоны выглядят так:

<key>.zen.dq.spamhaus.net

IP инвертируется и подставляется перед зоной:

dig @127.0.0.1 +short 2.0.0.127.<KEY>.zen.dq.spamhaus.net A

2.0.0.127 — их тестовый «заведомо грязный» адрес. Ожидаем коды, а не тишину.

Сюрприз номер два: DNSSEC

С DQS-ключом запрос через unbound вернул SERVFAIL. Через 1.1.1.1 — нормальный ответ. Значит, дело в валидаторе.

dig @127.0.0.1 +short +cd 2.0.0.127.<KEY>.zen.dq.spamhaus.net A
127.0.0.4
127.0.0.2
127.0.0.10

С флагом +cd (checking disabled) — работает. Диагноз: DNSSEC-валидация режет зону. Лечится одной строкой:

# /etc/unbound/unbound.conf.d/spamhaus.conf
server:
    domain-insecure: "dq.spamhaus.net"

unbound-checkconf && systemctl restart unbound

Момент истины

dig @127.0.0.1 +short 10.113.0.203.<KEY>.zen.dq.spamhaus.net A
127.0.0.2

Один код. 127.0.0.2 — это SBL. И больше ничего:

Код	Что означает	У меня
`127.0.0.2`	SBL — листинг за спам	есть
`127.0.0.3`	CSS — автоматический компонент SBL	нет
`127.0.0.4`–`7`	XBL/CBL — заражённая машина, открытый прокси	нет
`127.0.0.10`, `11`	PBL — «отсюда почта только через relay»	нет

Отсутствие XBL означает, что машина не заражена. Отсутствие CSS — что меня лично ни в чём не уличили. Отсутствие PBL — что провайдер даже не задекларировал диапазон как непригодный для прямой отправки.

Тогда откуда SBL?

Разгадка

Открываю детали листинга:

SBL###### — 203.0.113.0/17
2026-02-11
Escalation: spam support service

Far too many repeat listings, Spamhaus is advising its users not to accept
email from this IP range until the problem has been properly addressed.

/17. Это 32 768 адресов. Весь блок провайдера целиком, вместе со всеми клиентами в нём. Мой сервер тут вообще ни при чём — он просто прописан по неудачному адресу.

Формулировка про снятие листинга ещё выразительнее: удаление обусловлено «полным и постоянным прекращением всей абьюзивной активности, тщательным разбором и убедительным объяснением того, как могли возникнуть эти ложные заявления abuse-отдела».

То есть Spamhaus не просто говорит «у вас спамят». Он говорит «ваш abuse-отдел нам врал». Листинг висит с февраля — пять месяцев на момент раскопок.

И заявка на делистинг принимается только от провайдера. Клиент не может ни подать её, ни ускорить.

Что из этого следует

Разница между PBL и SBL здесь принципиальна, и её стоит проговорить.

PBL — это декларация владельца сети: «с этих адресов почта должна идти через relay». Не наказание, а описание топологии. Обычный статус для облачных диапазонов. Из PBL конкретный IP можно исключить самостоятельно.

SBL — это санкция за реальную спам-активность. И когда она наложена на /17 с эскалацией против провайдера, это уже характеристика площадки.

Практические выводы для клиента, оказавшегося внутри:

Прямая отправка невозможна. Spamhaus использует половина мира, включая Gmail.
Смена IP внутри провайдера не поможет — /17 покрывает всё.
Давить на техподдержку бессмысленно. Пять месяцев — достаточный срок, чтобы понять: не могут или не хотят.
Релей обходит проблему отправки, но не репутацию ASN. Письма пойдут, но вы остаётесь в сети, которую Spamhaus публично называет спам-хостингом.

Последний пункт вылез неожиданным образом. Уже после настройки релея одно из моих писем корпоративный фильтр получателя пометил как спам:

X-Spam-Status: Yes, score=7.102 required=6.2
  tests=[..., SH_BODYURI_REVERSE_SBL=8, ...]

Единственный источник баллов — правило с весом 8. Оно берёт URL из тела письма, резолвит его в IP и проверяет этот IP в SBL. А в подписи у меня ссылка на собственный сайт, который хостится… правильно, в том же /17.

Круг замкнулся: блок провайдера бьёт не только по отправке, но и по ссылке на свой же сайт в подписи. Причём чем лучше настроен антиспам у получателя, тем надёжнее письмо улетает в спам.

Итог

Задача «настроить релей» решилась за час. Диагностика заняла в разы больше — и не потому, что проблема сложная, а потому, что инструменты диагностики сами были сломаны.

Чтобы узнать, что с моим IP, мне пришлось сначала обнаружить, что Spamhaus вообще не отвечает моему серверу; поставить локальный резолвер; выяснить, что и это не помогает; получить DQS-ключ; починить DNSSEC. Пять шагов, чтобы задать один вопрос.

И попутно выяснилось, что эти же пять шагов были нужны для нормальной работы входящей фильтрации — которая молча не работала неизвестно сколько времени.

Мораль простая: если DNSBL-проверка не даёт результата, сначала убедитесь, что она вообще выполняется. Пустой ответ и «не в листе» — разные вещи, и отличить их без правильного резолвера невозможно.

О том, как я настраивал релей и чем транзакционный сервис отличается от рассылочного, — в следующей статье.