Postfix: greylisting и 4xx rate limit — как читать логи и убрать лишние задержки

В Postfix коды 4xx — это «временная» ошибка: отправитель обязан повторить доставку позже. На практике именно такие ответы чаще всего дают delivery delays (задержки доставки) и рост очереди deferred. При этом на 4xx же держатся полезные защитные механизмы: greylisting, ограничение скорости, postscreen и внешние policy-проверки.

Ниже — практический разбор, как читать логи Postfix при 4xx temporary failure, как отличить «нормальную» антиспам-задержку от конфигурационной проблемы и где именно искать первопричину: в maillog, в очереди, в postscreen или в ограничениях SMTP.

Что такое 4xx в SMTP и почему письма попадают в deferred

SMTP-коды делятся на постоянные (5xx) и временные (4xx). Для получателя 4xx — это «сейчас не могу принять, попробуй позже». Для отправителя — необходимость повторить доставку по своему расписанию.

Важно различать роли:

• Если ваш Postfix отправляет наружу (outbound), ответы удалённых серверов 4xx оставляют письмо в очереди deferred, и оно будет переотправляться позже.
• Если ваш Postfix принимает входящую почту (inbound), 4xx отдаёте вы — и именно вы создаёте (или не создаёте) задержку у отправителей.

Практически полезно сразу классифицировать ситуацию:

• Нормальная задержка: точечный greylisting или мягкий rate limit, письмо приходит через несколько минут.
• Проблемная задержка: массовые 4xx из-за слишком жёстких лимитов, DNS-таймаутов, перегруза, неправильного postscreen или зависаний внешних проверок. Тогда очередь растёт, а задержки становятся часами.

Быстрая диагностика: maillog и очередь Postfix

Цель диагностики — ответить на два вопроса: кто выдаёт 4xx (вы или удалённые серверы) и на каком этапе это происходит. Для этого обычно достаточно очереди и пары срезов по логам.

Смотрим очередь: postqueue

Проверить очередь:

postqueue -p

Если очередь большая — начните с первых сотен строк, чтобы увидеть повторяющиеся причины:

postqueue -p | sed -n '1,200p'

Оценить количество сообщений (грубая оценка по ID):

postqueue -p | grep -c '^[A-F0-9]'

Если значимая часть сообщений в deferred, почти всегда причина в ответах удалённых серверов 4xx на исходящей доставке (вас «тормозят» получатели), либо в том, что ваша инфраструктура доставки не успевает (ресурсы, DNS, внешние проверки).

Ищем 4xx в логах: maillog

На разных дистрибутивах лог будет в /var/log/maillog или /var/log/mail.log. Быстрый поиск по 4xx:

grep -E ' (4[0-9][0-9]|451) ' /var/log/maillog | tail -n 200

Чтобы собрать историю одного письма, используйте queue id:

grep 'QUEUEID_HERE' /var/log/maillog

Ориентиры по подсистемам:

• postfix/smtpd — входящие SMTP-сессии (вы принимаете письмо).
• postfix/smtp — исходящие доставки (вы отправляете наружу).
• postfix/postscreen — ранняя фильтрация соединений до smtpd.

Если 4xx в строках postfix/smtp — вас ограничивают удалённые сервера. Если 4xx в postfix/smtpd или postfix/postscreen — задержку создаёте вы на входящем потоке.

Postfix greylisting: как работает и когда превращается в проблему

Greylisting в Postfix обычно реализуют не встроенным параметром, а через policy service (например, postgrey) или антиспам-шлюз. Суть: при первом обращении новой комбинации «IP/отправитель/получатель» сервер отвечает временным отказом 4xx (часто 451 4.7.1). Нормальный SMTP-сервер повторит доставку, а часть спам-ботов — нет.

Как это выглядит в жизни:

• первое письмо может задержаться на 1–15 минут (зависит от окна ожидания и графика повторов у отправителя);
• дальше письма обычно проходят сразу (в пределах «белого окна»).

Как распознать greylisting по логам

Типичная строка содержит 451 4.7.1 и формулировки вроде greylisted, try again later, temporary failure. Пример формата:

NOQUEUE: reject: RCPT from ...: 451 4.7.1 Service unavailable - try again later;

Ключевая деталь: отказ часто происходит на этапе RCPT TO или DATA и выглядит «намеренным» (понятная причина, повторяемость, короткая задержка у большинства отправителей).

Когда greylisting даёт лишние delivery delays

Greylisting становится проблемой, когда задержки выходят за разумные рамки или бьют по критичным сценариям (заявки, пароли, чеки, тикеты). Частые причины:

• слишком длинное окно ожидания (первое письмо задерживается десятками минут);
• отправитель использует большой пул IP и меняет адрес между попытками;
• часть легитимных сервисов повторяет доставку редко или «своими правилами», и пользователь видит «пришло через час»;
• greylisting включён в цепочке фильтров там, где он почти не даёт выигрыша, но добавляет задержку всем.

Если вы обслуживаете бизнес-критичные входящие, чаще работает подход «минимум задержек, максимум предсказуемости»: корректный SPF/DKIM/DMARC, репутационные проверки, антиспам-скоринг. По этой части полезно свериться со статьёй про доставляемость и базовую настройку домена: SPF и PTR для доставляемости Postfix.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

451 4.7.1: что реально означает этот ответ

451 4.7.1 — один из самых частых кодов «временного отказа по политике/доступности». Это не диагноз, а контейнер для причин: «временно не могу принять по правилам или из-за сервиса».

В контексте Postfix наиболее типичные источники:

• greylisting (осознанно);
• антифлуд и ограничения (осознанно);
• решение postscreen на раннем этапе соединения;
• таймаут или ошибка внешнего check’а (policy/milter/DNSBL), и вы отвечаете 4xx, чтобы не терять письмо (fail-soft/fail-open в зависимости от вашей политики).

Задача администратора — найти в логах «подпись» механизма: имя policy-сервиса, пометку postscreen, сообщение о лимите или указание на таймаут DNS/проверки.

Rate limit SMTP в Postfix: где он полезен и как не устроить self-DoS

Ограничение скорости и количества сообщений полезно в двух направлениях:

• Inbound: снижает эффективность перебора логинов, спам-штормов и «проливов» на MX.
• Outbound: уменьшает ущерб, если скомпрометировали учётку/сайт и он начал слать спам, а также помогает удерживать репутацию.

Опасность одна: слишком агрессивные лимиты превращают Postfix в источник задержек для легитимных писем. В результате клиенты получают 4xx, письма копятся в очереди, а бизнес-уведомления приезжают поздно.

Ключевой параметр: smtpd_client_message_rate_limit

Параметр smtpd_client_message_rate_limit ограничивает скорость отправки сообщений от одного клиента. Ошибка, которую я вижу чаще всего: включили лимит «на всякий случай», но забыли, что через этот же listener ходят доверенные источники (ваши сайты, очереди задач, мониторинги, интеграции).

Практические принципы настройки:

• разделяйте потоки: отдельный submission (587) для клиентов и отдельный MX (25) для интернета, с разными ограничениями;
• доверенные источники выводите в отдельные политики (например, отдельный listener/ограничения по mynetworks), чтобы не резать свои же приложения;
• любое ограничение подкрепляйте мониторингом очереди и частоты 451 4.7.1.

Если вы поднимаете почту на сервере под нагрузкой, где важны предсказуемые лимиты и ресурсы (CPU/RAM/Disk I/O), удобнее держать Postfix на VDS и отдельно контролировать метрики очереди, DNS и I/O.

Как по логам понять, что 4xx даёт именно rate limit

Типичные признаки:

• отказы идут сериями от одного IP;
• текст причины одинаковый или очень похожий;
• пики совпадают с задачами рассылки, cron-джобами, очередями веб-приложения.

Быстрый срез по последним событиям с IP клиента (как стартовая точка):

grep -E 'reject:|warning:| (4[0-9][0-9]|451) ' /var/log/maillog | grep 'client=' | tail -n 2000

Дальше уже точечно выцепляйте конкретный IP и смотрите контекст на несколько минут вокруг события.

postscreen: ранняя защита, которая тоже может создавать «ложные» 4xx

postscreen принимает входящее соединение раньше smtpd и может проверять клиента по DNSBL, делать протокольные тесты, замедлять или временно отклонять подозрительные подключения. Это экономит ресурсы на спам-шторме, но при жёстких настройках может мешать нормальным отправителям.

Если postscreen создаёт проблему, в логах вы увидите postfix/postscreen, а не postfix/smtpd. Это важное отличие: в первом случае письмо может даже не дойти до этапа передачи данных.

Типовая причина массовых 4xx: DNS и внешние проверки

Частая история: деградировал DNS (резолвер, таймауты, ограничения UDP, перегрузка), из-за чего DNSBL/policy начинают отвечать медленно. Postfix в итоге временно отказывает, и вы сами создаёте delivery delays «на ровном месте».

Проверьте базовую гигиену:

• стабильный DNS-резолвинг на сервере;
• понятные таймауты внешних проверок;
• сценарий деградации: где уместен fail-open (лучше пропустить часть мусора), а где нужен fail-close (важнее не принять подозрительное).

Что делать, если растёт deferred mail: пошаговый план

1) Определить направление проблемы

• Много 4xx в postfix/smtp — проблема на исходящей доставке: получатели вас ограничивают, либо у вас слишком агрессивная параллельность/объёмы.
• Много 4xx в postfix/smtpd/postfix/postscreen — вы сами временно отклоняете входящие (greylisting, лимиты, проверки, DNS).

2) Классифицировать причину 4xx

Практически все причины укладываются в четыре группы:

• Политика: greylisting, rate limit, антифлуд.
• Репутация: провайдеры временно ограничивают вашу доставку.
• Ресурсы: CPU/RAM/диск/DNS/перегруз очереди.
• Интеграции: таймауты policy/milter/DNSBL и их деградация.

3) Проверить, не «режете» ли вы сами легитимный трафик

Если 4xx выдаёт ваш сервер:

• сократите окно ожидания greylisting или исключите критичных отправителей (по понятной и документированной процедуре);
• пересмотрите лимиты вокруг smtpd_client_message_rate_limit, особенно если у вас есть клиенты, отправляющие письма пачками (CMS, воркеры очередей, биллинг);
• проверьте, не «стреляют» ли проверки в postscreen по легитимным MX крупных провайдеров.

4) Если 4xx приходит от внешних серверов

Когда проблема на исходящей доставке:

• сгруппируйте, какие домены чаще всего отвечают 4xx;
• смотрите на текст причины в логе: там часто прямо написано rate limit/policy/spam suspicion;
• не пытайтесь «продавить» доставку ростом параллельных соединений: обычно это ухудшает ситуацию и увеличивает хвост deferred.

Если исходящая доставка идёт через submission с авторизацией, проверьте, что он отделён от MX и правильно защищён TLS/SMTP AUTH: как настроить submission, SMTP AUTH и TLS в Postfix.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Мини-чеклист: как отличить полезный 4xx от поломки

• 4xx редкий и точечный, письма приходят за минуты — чаще всего это ожидаемая защита.
• 4xx массовый, очередь deferred растёт часами — ищите слишком жёсткие лимиты, DNS-таймауты, проблемы postscreen или деградацию внешних проверок.
• Код 451 4.7.1 сам по себе не диагноз: всегда важно, кто его выдал (smtpd/postscreen/smtp) и какая фраза причины рядом.
• postscreen в логах — это ранняя фильтрация соединений, не путайте её с отказом на уровне письма.

Заключение

4xx temporary failure в Postfix — это инструмент управления потоком: от борьбы со спамом (greylisting, postscreen) до защиты от злоупотреблений (rate limit и ограничения). Проблемой он становится тогда, когда создаёт непредсказуемые задержки и раздувает deferred.

Самый быстрый путь к исправлению — дисциплина диагностики: сначала определить направление (вход/выход), затем по maillog понять конкретный механизм, и только после этого менять параметры. Так вы сохраните защиту и уберёте лишние задержки для нормальной почты.