Тонкая настройка greylisting в rspamd и postgrey: антиспам без задержек и потери писем
Классический greylisting по IP-триплету задерживает всех и теряет письма крупных ESP из-за ротации пулов. Разбираем, как настроить score-band greylisting в rspamd, чтобы он был невидим для легитимной почты и грел только пограничный спам.
EvilMail Team20 июля 2026 г.10 мин чтения
Почему триплетный greylisting теряет письма крупных отправителей
Сценарий, который вы уже видели в логах. Клиент ждёт письмо-подтверждение из Salesforce, оно уходит через Amazon SES. На вашем MX сидит postgrey, для этого триплета (client_ip, sender, recipient) записи нет, и Postfix отвечает:
450 4.2.0 <[email protected]>: Recipient address rejected: Greylisted, please try again later
Отправляющий MTA честно ставит письмо в очередь и ретраит через 12 минут — но уже с соседнего IP. 10.0.4.17 было в первой попытке, 10.0.7.203 во второй, и оба принадлежат одному пулу SES размером с целый /19. Триплет не совпал, postgrey снова отвечает 450
, счётчик задержки обнуляется. Письмо, которое человек ждёт «мгновенно», болтается в очереди отправителя.
Тут три отдельные патологии, и их важно различать:
Налог задержки на 100% первых контактов. postgrey по определению греет каждого нового отправителя. Дефолт --delay=300 — это пять минут задержки на любой первый разговор с новым корреспондентом, даже идеально чистым.
Ротация пулов ломает совпадение триплета. Крупные ESP — SES, SendGrid, Google, Outlook — отправляют с сотен исходящих адресов. Второй ретрай почти гарантированно приходит не с того IP, который вы уже «видели». Для postgrey это новый триплет, отсчёт начинается заново.
Bulk-MTA, которые не ретраят вовсе. Часть транзакционных и рассыльных систем на 4xx просто дропает сообщение — для них временный отказ неотличим от постоянного. Письмо теряется навсегда, и вы об этом не узнаете: в логе будет аккуратная строчка «greylisted», как будто всё в порядке.
Поведение ретраев различается и по самим MTA. Postfix стартует с minimal_backoff_time = 300 секунд, Exim обычно ждёт около 15 минут между попытками, ряд ESP использует экспоненциальный backoff и растягивает вторую попытку до 30–60 минут. То есть «задержка 5 минут» на практике легко превращается в полчаса тишины на стороне получателя.
Два движка greylisting: IP-триплет postgrey против score-band rspamd
Разница не в настройках, а в архитектуре — где именно в конвейере принимается решение и по какому ключу.
postgrey — это policy-демон на 127.0.0.1:10023, к которому Postfix обращается в smtpd_recipient_restrictions через check_policy_service. Решение принимается до контентной фильтрации, на этапе RCPT TO. Ключ — тот самый триплет (client_ip, envelope_from, envelope_to). Демон ничего не знает о теле письма, о SPF, о DKIM — он греет всё подряд по факту «нового IP-адреса».
Модуль greylist в rspamd работает принципиально иначе. Это пост-фильтр: он срабатывает уже после того, как письмо просканировано и получило итоговый score. Ключ — не IP, а хеш тела письма (первые max_data_len байт) плюс список получателей, и хранится он в Redis. Из этого следуют два вывода:
Ротация пула больше не важна. Байт-в-байт тот же ретраенный мейл даёт тот же хеш — неважно, с какого IP из /19 он пришёл. Совпадение находится всегда.
Чистая почта вообще не доходит до greylist. Модуль включается, только если score попал в узкую полосу между порогом действия greylist и порогом reject. Письмо с валидными SPF/DKIM/DMARC уходит в минус по score, не достаёт до нижней границы полосы и проходит без единой секунды задержки.
Базовый конфиг: /etc/rspamd/local.d/greylist.conf
Ничего не правьте в /etc/rspamd/modules.d/ — всё в local.d. Минимально осмысленный рабочий блок:
ini
# /etc/rspamd/local.d/greylist.conf
servers = "127.0.0.1:6379"; # Redis, где живут метазаписи
expire = 1d; # TTL записи после первого контакта
timeout = 5min; # окно, в течение которого примем ретрай
key_prefix = "rg"; # префикс ключей в Redis
max_data_len = 10k; # сколько байт тела берём в хеш
ipv4_mask = 19; # группировка meta по блоку /19
ipv6_mask = 64;
message = "Greylisted, please try again later";
symbol = "GREYLIST";
Ключевой параметр — timeout. Это окно, в течение которого повторная попытка будет принята. Меньше 1 минуты — рискуете отбить агрессивных ботов вместе с быстрыми легитимными ретраями; больше 5 минут — копите задержку без пользы, потому что честный MTA всё равно вернётся в свой интервал backoff.
Сам факт greylisting rspamd отдаёт как soft reject — это SMTP-код 451, временный отказ. Отдельно его включать в конфиге не нужно, но убедитесь, что дальше по цепочке (milter, транспорт, релей) 4xx нигде не переписывается в 5xx, иначе временный отказ превратится в постоянный и письмо потеряется.
Про маски. ipv4_mask = 19 означает, что метазапись «этот отправитель уже грелся» привязывается не к конкретному /32, а к блоку /19. Это компенсирует ротацию: ретрай с соседнего IP того же провайдера попадает в ту же группу. Не опускайте маску ниже `/16` — сгребёте в одну корзину целого провайдера и дадите спамеру бесплатный проход по чужой прогретой записи.
После правки — перезагрузка и проверка, что конфиг действительно применился:
score < 4 — письмо уходит получателю без всякого greylisting;
score 4–6 — попадает в полосу greylist и греется;
score 6–15 — помечается как спам (заголовок / папка Junk);
score > 15 — режется на reject.
Теперь суть: почему легитимная почта физически не доходит до порога 4. Отрицательные символы честной аутентификации тянут score вниз. R_SPF_ALLOW даёт примерно −0.2, R_DKIM_ALLOW около −1.0, DMARC_POLICY_ALLOW порядка −0.5, плюс ARC_ALLOW и whitelist-модуль для крупных провайдеров (Google, Microsoft, Apple) от −1 до −3. Письмо с валидными SPF+DKIM+DMARC стартует в глубоком минусе и просто не может доползти до нижней границы полосы.
Отсюда практический вывод, который часто понимают наоборот. Поднять порог greylist с 4 до 7 — это не «сделать мягче». Это осознанно решить, какую полосу подозрительности вы готовы задерживать. greylist = 4 — строгий узел, греется всё пограничное. greylist = 6..7 разумно, если у вас много ложных грейлистов от мелких корпоративных доменов, которые вообще не подписывают почту DKIM и потому естественно набирают +1..+2 «ни за что».
Белые списки для пулов крупных ESP
Даже со score-band иногда нужно явно вытащить конкретного отправителя из-под подозрения. В rspamd для этого есть multimap.
# /etc/rspamd/maps.d/dkim_whitelist.map — по d= домену подписи, не по IP
amazonses.com
sendgrid.net
google.com
Предостережение, которое отличает грамотную настройку от опасной: не делайте whitelist по IP shared-пула ESP. IP-адреса SES или SendGrid используют тысячи отправителей, и среди них есть спамеры. Whitelist по IP означает «доверяю всем на этом пуле». Whitelist по DKIM-домену (d=) привязан к конкретному подписанту и куда безопаснее.
Для тех, кто ещё на postgrey, эквивалент — файлы whitelist по PTR:
Как отличить «погрелось и доставилось» от «отправитель не вернулся»: в первом случае в логе будет пара событий по одному хешу — soft reject, затем через несколько минут no action / доставка. Если второго события нет, а запись в Redis дожила до expire без повторного попадания — отправитель не ретраит, и это ваш кандидат в whitelist.
Метрика для дашборда — доля писем с символом GREYLIST от общего потока. Норма меньше 3–5%. Если греется 15% потока, то либо порог greylist выставлен слишком низко, либо ломается whitelist (например, DKIM не проходит проверку из-за рассинхрона ключей) и легитимная почта валится в полосу.
Чеклист перед продакшеном
Валидация SPF/DKIM/DMARC на приём работает — без этого отрицательные символы не начисляются и чистая почта попадает в полосу.
Пороги в actions.conf выставлены явно (greylist, add_header, reject), а не унаследованы от дефолтов.
timeout ≤ 5min — иначе копите задержку впустую.
ipv4_mask не ниже /16, чтобы не прогревать спамерам чужие записи.
Whitelist критичных ESP сделан по DKIM-домену, а не по IP shared-пула.
Redis запущен с appendonly yes — иначе после рестарта Redis весь поток греется заново.
soft reject уходит с кодом 451, а не 5xx — проверьте, что нигде в цепочке 4xx не переписывается в постоянный отказ.
Тестовое письмо с внешнего чистого домена (валидные SPF+DKIM+DMARC) не греется — прогоните через rspamc symbols и убедитесь, что GREYLIST не сработал.
postmaster@ и abuse@ в whitelist получателей — их греть нельзя по RFC.
Правильно настроенный greylisting в 2026-м невидим для реальных корреспондентов и жжёт ботам ресурс на ретраи, которых у них нет. Если пользователи жалуются на «пропавшую почту», проблема не в том, что greylisting включён, а в том, что он греет по IP-триплету вместо score-полосы.
