Тонкая настройка Rspamd: скоринг, greylisting и DKIM‑подпись исходящей почты

Если у вас уже крутится связка Postfix + Rspamd, следующий шаг — перестать жить на дефолтах и добиться предсказуемой фильтрации без сюрпризов для пользователей и без потерь в deliverability. Разберём ключевые области: пороги и скоринг, управляемый greylisting, а также корректную DKIM‑подпись исходящей почты.

Как мыслит Rspamd: действия, символы и скоринг

Rspamd складывает веса сработавших символов (rules/symbols) и сравнивает итоговый балл с порогами действий. Эти пороги — ваша почтовая политика: где «подозрение», где «мягкий отказ» (soft reject), где «окончательный отказ» (reject). При неграмотной разметке легко получить лавину ложных срабатываний или, наоборот, пропуск спама.

Базовая настройка порогов выполняется в /etc/rspamd/local.d/actions.conf. Рациональные значения для небольшого бизнеса/корп. почты с преобладанием транзакционной корреспонденции:

reject = 15;
soft_reject = 10;
rewrite_subject = 8;
add_header = 6;
greylist = 5;

Смысл такой: до 5 баллов — письмо проходит; с 5 до 6 — попадает в greylisting; 6–8 — просто добавляем заголовки; 8–10 — можем пометить тему; 10–15 — просим отправителя повторить (soft reject); от 15 — отвергаем. Эти пороги стоит привязать к вашим SLA и терпимости пользователей к задержкам.

Точная подстройка скоринга символов

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

Пример корректировок в /etc/rspamd/local.d/scores.d/00-custom.conf:

symbol "R_DKIM_ALLOW" { weight = -1.5; }
symbol "R_SPF_ALLOW" { weight = -1.0; }
symbol "DMARC_POLICY_ALLOW" { weight = -1.5; }
symbol "ARC_ALLOW" { weight = -0.5; }

symbol "BAYES_SPAM" { weight = 4.5; }
symbol "BAYES_HAM" { weight = -2.0; }

symbol "URIBL_BLACK" { weight = 6.0; }
symbol "URIBL_DBL_SPAM" { weight = 4.0; }
symbol "FUZZY_DENIED" { weight = 5.0; }

symbol "MIME_HTML_ONLY" { weight = 0.5; }
symbol "MISSING_MID" { weight = 1.0; }
symbol "FORGED_SENDER" { weight = 3.5; }

Групповые политики через settings

Rspamd позволяет задавать разные политики для разных потоков: аутентифицированные пользователи, локальные сервисы, входящая почта с внешних MX. Настройка делается в /etc/rspamd/local.d/settings.conf:

settings {
  inbound_default {
    priority = 10;
    apply {
      actions = { reject = 15; soft_reject = 10; add_header = 6; greylist = 5; }
    }
  }

  authenticated_outbound {
    priority = 20;
    authenticated = true;
    apply {
      actions = { reject = 18; soft_reject = 12; add_header = 8; }
      symbols_disabled = ["GREYLIST"];
    }
  }

  local_relay {
    priority = 30;
    ip = "127.0.0.1";
    apply {
      groups_disabled = ["ratelimit"];
    }
  }
}

Так вы отделяете входящий и исходящий потоки, исключаете greylisting для своих, поднимаете пороги «паники» на исходящем — и не ломаете пользователям отправку.

Greylisting без боли: быстро и безопасно

Greylisting всё ещё эффективен против примитивных спам-ботов, но вредит UX, если настроен грубо. Цель — минимальные задержки для добропорядочных отправителей и уверенное отсечение «одноразовых» попыток.

Базовая настройка в /etc/rspamd/local.d/greylist.conf:

enabled = true;
min_delay = 4m;
expire = 4h;
ipv4_mask = 19;
ipv6_mask = 64;
authenticated = true;
whitelist_symbols = ["WHITELIST_SENDER", "R_DKIM_ALLOW"];

Рекомендуется ввести белые списки отправителей/доменов и хорошо известных сторонних сервисов рассылок. Для удобства вынесите их в карты:

# /etc/rspamd/local.d/maps.d/whitelist_sender.map
postmaster@trusted.example
mailer@service.example
*.@partner.example

И привяжите карту к символу-whitelist через правило в /etc/rspamd/local.d/rules.local.lua:

local whitelist_sender = rspamd_config:add_map({
  url = "/etc/rspamd/local.d/maps.d/whitelist_sender.map",
  type = "set"
})

rspamd_config:register_symbol({
  name = "WHITELIST_SENDER",
  type = "prefilter",
  priority = 10,
  callback = function(task)
    local from = task:get_from("smtp")
    if from and from[1] and whitelist_sender:find(from[1].addr) then
      return 1.0
    end
    return 0.0
  end
})

Далее можно присвоить символу небольшой отрицательный вес или использовать его для исключения из greylisting через whitelist_symbols, как в примере выше.

Исключения для критичных адресатов

Списки рассылки, интеграции с внешними CRM и уведомления от платёжных шлюзов не должны зависать. Добавьте исключения через settings (отключая конкретные символы):

settings {
  no_greylist_for_lists {
    priority = 25;
    rcpt = "@lists.example.com$";
    apply {
      symbols_disabled = ["GREYLIST"];
    }
  }
}

Ключевой индикатор здоровья — медианная задержка доставки для белых отправителей. Если пользователи жалуются, уменьшайте min_delay или агрессивнее расширяйте whitelist.

DKIM‑подпись исходящей почты в Rspamd

Подписывать исходящую почту через модуль dkim_signing в Rspamd удобно: одна точка контроля, высокая производительность в milter‑цепочке, унифицированные заголовки Authentication-Results. Последовательность шагов простая. Если управляете DNS централизованно, удобнее держать домены и записи через регистрацию доменов у одного провайдера. Подробно о DNS‑записях для SPF/DKIM/DMARC — в материале настройка DNS‑записей для почтовой аутентификации.

1) Генерация ключей DKIM

Сгенерируйте ключ для домена, выберите селектор, сохраните приватник в каталоге, доступном Rspamd:

mkdir -p /var/lib/rspamd/dkim
rspamadm dkim_keygen -b 2048 -s s1 -d example.com -k /var/lib/rspamd/dkim/example.com.s1.key
chown -R _rspamd:_rspamd /var/lib/rspamd/dkim
chmod 600 /var/lib/rspamd/dkim/example.com.s1.key

Откройте публичную часть и создайте TXT‑запись в DNS по имени s1._domainkey.example.com:

cat /var/lib/rspamd/dkim/example.com.s1.key.pub
# Пример содержимого:
# s1._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA...IDAQAB"

После применения DNS не забудьте учесть TTL; до распространения записи рекомендации по deliverability — не форсировать массовую исходящую отправку.

2) Конфигурация dkim_signing

Минимальный рабочий вариант в /etc/rspamd/local.d/dkim_signing.conf:

sign_authenticated = true;
use_domain = "header";
selector = "s1";
path = "/var/lib/rspamd/dkim/$domain.$selector.key";
allow_envfrom_empty = true;
try_fallback = false;

Если у вас несколько доменов — можно задать блоки по доменам или карту доменов с селекторами. Для критичных доменов полезно настроить ротацию селектора раз в 3–6 месяцев с перекрытием TTL и своевременной заменой TXT‑записи. Детали — в статье ротация DKIM‑селекторов и TTL.

3) Заголовки и отчётность

Модуль milter_headers аккуратно добавляет Authentication-Results и Received-SPF. Базовые настройки в /etc/rspamd/local.d/milter_headers.conf:

extended_spam_headers = true;
routines {
  dkim = true;
  spf = true;
  dmarc = true;
}

Это помогает трекать причины повышения скоринга и ускоряет разбор инцидентов с доставкой.

Интеграция с Postfix через milter

Распространённая интеграция — через rspamd_proxy на 11332. В main.cf укажите:

smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen} {mail_host} {mail_mailer}

И перезапустите службы:

systemctl restart rspamd postfix

Параметр milter_default_action оставляем accept, чтобы не ломать поток при кратковременных сбоях антиспама. Ответственность за блокировку ложится на Rspamd через собственные действия (reject/soft_reject). Если вы поднимаете почтовый стек на VDS, убедитесь в достаточных ресурсах CPU и дисковой подсистемы: обучение Bayes и fuzzy‑сопоставления чувствительны к IO‑латентности.

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

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

Подробнее

Контроль ложных срабатываний: методика

Хорошая политика антиспама — это всегда компромисс. Чтобы не гадать, вводите процесс: «изменение — наблюдение — корректировка».

1. Фиксируйте базовый уровень: процент greylist, soft reject и reject за 7 дней до изменений.
2. Меняйте одну вещь: например, вес URIBL_BLACK или порог soft_reject.
3. Смотрите 3–7 дней тренды, анализируйте образцы писем по Authentication-Results и символам.
4. Формируйте карты исключений (отправители, сервисы) и валидационные кейсы.

Полезные инструменты:

# Символы и счёт по письму из файла
rspamc symbols < sample.eml

# Быстрая сводка статистики
rspamadm stat

# Журнал работы
journalctl -u rspamd -f

Deliverability: что реально влияет

Помимо DKIM есть ещё фундамент: корректный PTR для исходящих IP, SPF, DMARC, консистентный HELO, согласованные часовые пояса и точное время (NTP). Внутри Rspamd уделите внимание:

• Не переоценивайте «хорошие» символы: R_DKIM_ALLOW, R_SPF_ALLOW, DMARC_POLICY_ALLOW помогают, но не «амнистируют» явную рекламу, вложения-архивы и подозрительные URL.
• Аккуратнее с fuzzy и URIBL: они эффективны, но чувствительны к ложным срабатываниям. Держите веса так, чтобы одиночное срабатывание не уводило письмо в reject.
• Bayes: обучайте на репрезентативной выборке, избегайте автотренировок на основе пользовательских папок без модерации.
• Снижение порогов для внутренних нотификаций: отдельные settings под ваши сервисы, чтобы мониторинги не зависали на greylisting.

Политики для исходящей почты

Цель — не мешать нормальной отправке, но вовремя ловить компрометацию ящика. Простая тактика:

• Отключить greylisting и повысить пороги для аутентифицированных отправителей.
• Сигнализировать в логи и добавлять заголовки при достижении мягких порогов, не ронять письмо сразу.
• Следить за всплесками скоринга и аномалиями через rspamadm stat.

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

Тестирование и безопасный rollout

Не выкатывайте жёсткие изменения сразу на весь поток. Используйте feature‑toggle через settings с прицелом на часть доменов/пользователей:

settings {
  canary_group {
    priority = 40;
    user = "@canary.example$";
    apply {
      actions = { reject = 16; soft_reject = 11; add_header = 6; }
    }
  }
}

Так вы проверите новое соотношение порогов на «канарейках», прежде чем раскатить на всех.

Типичные ошибки и как их избежать

• Слишком большие отрицательные веса «хороших» символов. Итог — спам с валидным DKIM проходит.
• Отсутствие исключений для аутентифицированных отправителей в greylisting. Пользователи жалуются на задержки.
• Универсальные whitelist по IP для крупных провайдеров. Спамеры тоже приходят с их адресов. Старайтесь точнее сегментировать.
• Нулевой контроль за статистикой. Любая антиспам‑политика требует наблюдения и итераций.
• Неправильное хранение DKIM‑ключей. Проверяйте права, доступ только у пользователя службы Rspamd.

Чек‑лист после настройки

1. Пороги действий в actions.conf соответствуют вашим SLA, отделены для входящего/исходящего.
2. Скоринг ключевых символов отстроен, одиночные индикаторы не «решают всё».
3. Greylisting даёт предсказуемую задержку, есть белые списки и исключения.
4. DKIM‑ключ активирован, TXT‑запись видна ресиверам, подпись появляется на исходящих письмах.
5. Логи и статистика мониторятся, понятна динамика ложных срабатываний.

Хороший антиспам — это не «один раз настроил». Это небольшой, но регулярный процесс ухода: ревизия весов, корректировка whitelists, контроль метрик и дисциплина ротации DKIM.

Если вы интегрируете Rspamd в существующую инфраструктуру, начните с мягких порогов, включите серую зону только для «сомнительных» писем и дайте пользователям канал обратной связи. Через 2–3 итерации вы выйдете на баланс между качеством фильтрации и предсказуемой доставкой. А корректная DKIM‑подпись и спокойная политика для исходящих сообщений укрепят общую репутацию домена и помогут поддерживать высокую deliverability.