Rspamd: первісне налаштування — мінімальна конфігурація, яка реально працює

January 25, 2026 • February 3, 2026 • Читання: 8 хв • Views: 5

Було корисно?

Деякі спам-фільтри «голосно» дають про себе знати. Rspamd поводиться як професіонал: приймає пошту, бурмоче у логи, а користувачі й далі надсилають скріншоти «Bitcoin invoice.pdf.exe». Тим часом ви дивитесь на розподіл балів, який виглядає коректно, але нічого не відкидається, не підписується й не навчається.

Це посібник для першого налаштування, орієнтований на production‑системи. Мінімальна конфігурація, але з розумом. Ми доведемо вас до робочої бази: сканування Rspamd, підпис DKIM, стан на Redis, безпечний UI та інтеграція з MTA, яка не обходиться сама по собі.

Що означає „мінімальне“ у production

Мінімальне — це не «найменше рядків конфігурації». Мінімальне — це «найменша кількість складових, яка дає передбачувані результати». Для Rspamd така база — це:

Працюючий демон rspamd і rspamd_proxy, що обробляють сканування.
Redis, ввімкнений для історії, fuzzy, Bayes та різних кешів (без нього можна обійтися, але ви пошкодуєте про це пізніше).
Інтеграція з MTA, яку неможливо «випадково обійти». Для Postfix це означає мilter і що сокет доступний з контексту процесу Postfix.
Підпис DKIM для вихідної пошти, ключі у здоровому місці та селектори, які можна обертати.
Порогові значення дій, що відповідають реальності (відхиляти очевидне сміття, додавати заголовок на межовому), і логи, що показують, що сталося.

Що не є мінімальним:

Увімкнення кожного модуля, бо «може допоможе». Саме так ви почнете greylist‑ити власні повідомлення моніторингу й назвете це «безпека».
Редагування файлів під /etc/rspamd/ напряму, коли слід використовувати local.d та override.d.
Пропуск DKIM зі словами «ми ще не готові». Ваші одержувачі готові; вони готові оцінювати вас як спамера.

Одна операційна істина: якщо ви не можете пояснити, чому повідомлення отримало певну кінцеву дію (reject/add‑header/no action), у вас не фільтр спаму — у вас чутка.

Кілька фактів і історія, які впливають на рішення

Це невеликі, конкретні факти, що рятують від неправильних архітектурних рішень опівночі.

Rspamd задумували як систему з кількома компонентами (типи воркерів, proxy, controller). Це не моноліт; якщо ви налаштуєте його як моноліт — будете неправильно діагностувати проблеми.
Він сильно покладається на Redis для речей поза Bayes: кешовані результати, репутація, fuzzy‑перевірки та історія. Розглядайте Redis як частину поштового конвеєра, а не «приємну опцію».
Модель оцінювання Rspamd побудована на символах: він не каже «спам/не спам», а дає «причини з вагою». Саме тому налаштування витримується—якщо не панікувати і не правити бали навмання.
Сучасна доставлюваність базується на автентифікації: DKIM, SPF, DMARC. Фільтрація допомагає на вході; DKIM допомагає вихідній пошті не виглядати як підробка.
Milter‑и старі, але ефективні. Їх також легко неправильно підключити. Більшість повідомлень «Rspamd не фільтрує» означають «MTA до нього ніколи не звертався».
Rspamd підтримує кілька паттернів інтеграції: milter, LMTP‑проксі, SMTP‑проксі. «Мінімум, що працює» залежить від вашого MTA, але режими відмов схожі: обхід, таймаути, неправильні сокети.
Ротація ключів DKIM операційно дешева, якщо правильно використовувати селектори. Якщо ви зашили один селектор назавжди, рано чи пізно вам доведеться планувати страшне вікно обслуговування заради простої задачі.
Rspamd має вбудований HTTP‑контролер для статистики й команд. Відкривати його без аутентифікації — маленька, але уникаєма трагедія.

Мінімальна робоча архітектура (і що пропустити)

Ось базова архітектура, яка зазвичай «просто працює» на одному поштовому хості з Postfix:

Postfix приймає пошту й передає її на milter‑сокет.
rspamd_proxy приймає milter‑запити, викликає воркери сканування, потім каже Postfix, що робити, і додає заголовки.
rspamd використовує Redis локально для кешів і Bayes, зберігає історію для дебагу.
Підпис DKIM робиться всередині Rspamd для вихідної пошти (Postfix пропускає пошту через той самий milter).

Що пропустити спочатку:

Кластеризацію Rspamd на декількох вузлах. Не тому, що це погано, а тому, що ви будете плутати мережеві проблеми з проблемами оцінювання.
Екзотичні модулі (кілька OCR‑систем, кастомні Lua‑правила). Спочатку переконайтесь, що пошту взагалі сканують.
Автоматизацію навчання Bayes до того, як у вас є коректне розділення ham/spam і стабільна модель. Автоматизація неправильної вибірки — дуже ефективний спосіб помилитись.

Жарт №1: Фільтр спаму без логів — це як парашут із думок: технічно легкий, операційно сміливий.

Встановлення та перевірка, що демон справді працює

Припустимо, хост на Debian/Ubuntu з systemd. Якщо інша система — транслюйте менеджер пакетів і імена сервісів, а не логіку.

Встановлення пакетів

cr0x@server:~$ sudo apt-get update
...output...
cr0x@server:~$ sudo apt-get install -y rspamd redis-server
...output...

Рішення: якщо пакети дистрибутива застарілі, ви це відчуєте в відсутніх модулях і багах, які не варто дебажити. Але «мінімум, що працює» і зі старими пакетами ще працює — просто не прикиньте, що це актуальна версія.

Перевірте, що сервіси запущені

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rapid spam filtering system
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2026-01-03 09:01:12 UTC; 2min ago
...output...
cr0x@server:~$ systemctl status redis-server --no-pager
● redis-server.service - Advanced key-value store
     Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2026-01-03 09:01:03 UTC; 2min ago
...output...

Рішення: якщо будь‑який сервіс не active (running), зупиніться. Виправте це в першу чергу. Сканування пошти — це конвеєр; мертвий компонент не «частково працює», він «не виконується».

Підтвердіть, що Rspamd слухає

cr0x@server:~$ sudo ss -lntp | egrep '11334|11333|11332'
LISTEN 0      4096         127.0.0.1:11334      0.0.0.0:*    users:(("rspamd",pid=1827,fd=6))
LISTEN 0      4096         127.0.0.1:11333      0.0.0.0:*    users:(("rspamd",pid=1827,fd=7))
LISTEN 0      4096         127.0.0.1:11332      0.0.0.0:*    users:(("rspamd",pid=1827,fd=8))

Що це означає: стандартні порти Rspamd живі (proxy/controller/worker інтерфейси залежать від пакування).

Рішення: якщо ці порти не слухають — ви або неправильно сконфігуровані, або пакет використовує інші сокети (часто UNIX). Не підключайте Postfix до порту, якого не довели існування.

Структура конфігурації: як не воювати з Rspamd

Конфіг Rspamd багаторівневий. Розглядайте конфіг постачальника як read‑only. Ваше завдання — чисто перекривати налаштування.

/etc/rspamd/: базовий конфіг, що постачається пакетом
/etc/rspamd/local.d/: ваші локальні зміни (найпоширеніший варіант)
/etc/rspamd/override.d/: жорсткі перекриття, коли потрібно перебити дефолти

Правило: якщо ви редагуєте /etc/rspamd/rspamd.conf напряму — ви підписуєтесь на біль під час оновлень і археологію «чому це змінилося».

Перевіряйте конфіг перед рестартом

cr0x@server:~$ sudo rspamd -t
syntax OK

Що це означає: парсер згоден з вашими файлами.

Рішення: якщо це падає — не рестартіть. Виправте синтаксис спочатку; зламаний фільтр спаму часто «відкриває шлюзи» так, що ви помітите це лише за скаргами користувачів.

Redis: єдина залежність, на якій не варто економити

Так, Rspamd можна запускати без Redis. Він ще сканує. Але ви втратите видимість і стан, які роблять сканування надійним: Bayes, fuzzy, історію та кеші. У production Redis не опційний; це ваша пам’ять.

Мінімальна конфігурація Redis для Rspamd

На одному хості використовуйте локальний UNIX‑сокет для швидкості та прозорості прав доступу. Помістіть це в /etc/rspamd/local.d/redis.conf:

cr0x@server:~$ sudo tee /etc/rspamd/local.d/redis.conf > /dev/null <<'EOF'
servers = "unix:/run/redis/redis-server.sock";
EOF

Тепер переконайтесь, що Redis видає цей сокет і Rspamd може його читати. На Debian‑подібних системах зазвичай так. Перевірка:

cr0x@server:~$ ls -l /run/redis/redis-server.sock
srwxrwx--- 1 redis redis 0 Jan  3 09:01 /run/redis/redis-server.sock

Що це означає: групові права мають значення. Якщо rspamd не в групі redis, він не зможе спілкуватись.

Рішення: додайте rspamd до групи redis (або налаштуйте ACL), а не перемикайте Redis на TCP «бо так простіше». Просто сьогодні, інцидент завтра.

cr0x@server:~$ sudo usermod -aG redis rspamd
cr0x@server:~$ sudo systemctl restart rspamd
...output...

Підтвердіть, що Rspamd може використовувати Redis

cr0x@server:~$ sudo rspamadm configdump redis
servers = "unix:/run/redis/redis-server.sock";

Рішення: якщо він і далі вказує інше — ви поклали файл не в той каталог або пакет використовує інший порядок include. Виправте це перед тим, як налаштовувати щось інше.

Інтеграція з Postfix (milter), яка справді фільтрує пошту

Головний режим відмов вражаюче простий: Postfix ніколи не викликає Rspamd. Усе інше — Redis, DKIM, Bayes — перетворюється на перформанс‑арт.

Для мінімальної налаштування використовуйте локальний milter‑сокет, який надає rspamd_proxy. Багато пакетів відкривають /run/rspamd/milter.sock. Спочатку перевірте:

cr0x@server:~$ sudo find /run -maxdepth 2 -type s -name '*milter*sock' -o -name 'rspamd*.sock'
/run/rspamd/milter.sock

Рішення: якщо сокета немає — треба ввімкнути milter‑воркер або пакет використовує TCP. Не вгадуйте; інспектуйте.

Налаштуйте Postfix використати Rspamd milter

Змініть основний конфіг Postfix. Використовуйте обидва шляхи — SMTPd і non‑SMTPd — якщо вас цікавлять локальні відправки. Мінімальні надійні дефолти:

cr0x@server:~$ sudo postconf -e 'smtpd_milters=unix:/run/rspamd/milter.sock'
cr0x@server:~$ sudo postconf -e 'non_smtpd_milters=unix:/run/rspamd/milter.sock'
cr0x@server:~$ sudo postconf -e 'milter_protocol=6'
cr0x@server:~$ sudo postconf -e 'milter_default_action=accept'
cr0x@server:~$ sudo postconf -e 'milter_mail_macros=i {mail_addr} {client_addr} {client_name} {auth_authen}'

Що це означає:

milter_default_action=accept — консервативно: якщо Rspamd впадає, пошта йде далі. Це уникає тотальних відмов, але може бути використано, якщо атакуючі примушують таймаути.
milter_protocol=6 — сучасний протокол з підтримкою загальних макросів.

Рішення: у деяких середовищах «fail open» прийнятний; в інших — це проблема відповідності. Якщо ви високовартісна ціль, розгляньте tempfail після того, як довіритесь стабільності.

Перезавантажте Postfix і перевірте, що він використовує сокет

cr0x@server:~$ sudo systemctl reload postfix
...output...
cr0x@server:~$ sudo postconf | egrep 'smtpd_milters|non_smtpd_milters|milter_default_action'
smtpd_milters = unix:/run/rspamd/milter.sock
non_smtpd_milters = unix:/run/rspamd/milter.sock
milter_default_action = accept

Рішення: якщо Postfix показує правильні значення, але пошта і далі не фільтрується — ймовірно, проблема з правами на сокет або chroot‑межа.

Перевірте, чи Postfix має доступ до milter‑сокета

cr0x@server:~$ sudo ls -l /run/rspamd/milter.sock
srwxrwx--- 1 rspamd rspamd 0 Jan  3 09:01 /run/rspamd/milter.sock

Що це означає: якщо сокет належить rspamd:rspamd з правами 770, процеси Postfix можуть не бути в цій групі.

Рішення: додайте користувача Postfix до групи rspamd, або налаштуйте права сокета у конфі воркера Rspamd. Не робіть chmod 777 на межі безпеки та не називайте це «тимчасовим». Тимчасове швидко стає постійним.

cr0x@server:~$ sudo usermod -aG rspamd postfix
cr0x@server:~$ sudo systemctl restart postfix
...output...

Підпис DKIM: мінімально, але правильно

DKIM — це не лише театрування доставлюваності. Це сильний сигнал для отримувачів, що ваша вихідна пошта консистентна, не підроблена й не «прохідна».

Мінімальний DKIM у Rspamd потребує:

Пару ключів, збережених на диску з коректними правами.
Селектор (наприклад, s2026), який ви зможете обертати.
Відображення домен → селектор і шлях до ключа.

Згенеруйте DKIM‑ключ

Створіть директорію для ключів і захистіть її:

cr0x@server:~$ sudo install -d -m 0750 -o rspamd -g rspamd /var/lib/rspamd/dkim

Згенеруйте 2048‑бітний ключ (базовий варіант):

cr0x@server:~$ sudo rspamadm dkim_keygen -b 2048 -s s2026 -d example.com -k /var/lib/rspamd/dkim/s2026.example.com.key > /tmp/s2026.example.com.txt
cr0x@server:~$ sudo chown rspamd:rspamd /var/lib/rspamd/dkim/s2026.example.com.key
cr0x@server:~$ sudo chmod 0640 /var/lib/rspamd/dkim/s2026.example.com.key

Що це означає: приватний ключ читає Rspamd; не читає весь світ; не читають випадкові демони.

Рішення: якщо вас тягне покласти DKIM‑ключі в /etc з менш суворими правами «щоб резервні копії їх підхоплювали» — краще виправте резервні копії. Секрети не перестають бути секретами через незручності.

Налаштуйте модуль підпису DKIM

Створіть /etc/rspamd/local.d/dkim_signing.conf:

cr0x@server:~$ sudo tee /etc/rspamd/local.d/dkim_signing.conf > /dev/null <<'EOF'
path = "/var/lib/rspamd/dkim/$selector.$domain.key";
selector_map = "/etc/rspamd/dkim_selectors.map";
key_map = "/etc/rspamd/dkim_keys.map";
signing_table = "/etc/rspamd/dkim_signing.map";
use_esld = false;
allow_username_mismatch = true;
EOF

Тепер створіть три невеликі файли‑мапи. Тримайте їх явними; «магія авто» — це шлях підписати не той домен.

cr0x@server:~$ sudo tee /etc/rspamd/dkim_selectors.map > /dev/null <<'EOF'
example.com s2026
EOF
cr0x@server:~$ sudo tee /etc/rspamd/dkim_keys.map > /dev/null <<'EOF'
example.com /var/lib/rspamd/dkim/s2026.example.com.key
EOF
cr0x@server:~$ sudo tee /etc/rspamd/dkim_signing.map > /dev/null <<'EOF'
*@example.com example.com
EOF

Що це означає: будь‑яка пошта з @example.com підписується ключем домену example.com, селектором s2026.

Рішення: якщо ви обслуговуєте кілька доменів — не «перевикористовуйте один ключ для всіх доменів». Технічно працює; але це запах для доставлюваності та гігієни.

Перезапустіть і перевірте, що модуль DKIM завантажується

cr0x@server:~$ sudo rspamd -t
syntax OK
cr0x@server:~$ sudo systemctl restart rspamd
...output...
cr0x@server:~$ sudo journalctl -u rspamd -n 50 --no-pager
...output...

Рішення: у логах ви хочете відсутність помилок DKIM. Якщо бачите «cannot load key», зазвичай це невідповідність шляху або права.

Дії та пороги: reject, add header, greylist

Rspamd може виконувати багато дій. Мінімальна конфіг: завжди додавати заголовки, відкидати лише при високій впевненості, і робити щось розумне для межового листа.

Помістіть це в /etc/rspamd/local.d/actions.conf:

cr0x@server:~$ sudo tee /etc/rspamd/local.d/actions.conf > /dev/null <<'EOF'
actions {
  add_header = 6.0;
  rewrite_subject = 8.0;
  reject = 15.0;
  greylist = 4.0;
}
EOF

Що це означає: нижче 4 — чисто; 4–6 — greylist; 6–8 — додати заголовки; 8–15 — змінити тему; 15+ — відхилити. Ваші числа можуть відрізнятись. Цей набір зазвичай переживе перший розгорт.

Рішення: якщо у вашій організації нуль толерантності до затримок, підніміть поріг greylist або тимчасово вимкніть його. Greylisting — не «безкоштовна точність», це обмін затримкою на сигнал.

Жарт №2: Greylisting — як корпоративні закупівлі: все врешті‑решт погодять, просто не під час наради.

Веб‑інтерфейс: захистіть його або вимкніть

Контролер‑UI корисний. Він також — операційний інструмент, який легко зіпсувати, якщо ви відкриєте його в інтернеті, бо можна змінювати конфіг і викликати навчання залежно від прав.

Прив’яжіть контролер до localhost (мінімально безпечний варіант)

У багатьох пакетах це вже так. Перевірте й зафіксуйте в /etc/rspamd/local.d/worker-controller.inc:

cr0x@server:~$ sudo tee /etc/rspamd/local.d/worker-controller.inc > /dev/null <<'EOF'
bind_socket = "127.0.0.1:11334";
password = "$2$5$z0JwF4Tj9p7vVh2q3l8y8u3n7q9rHk0rHk0rHk0rHk0rHk0rHk0";
enable_password = "false";
EOF

Що це означає: контролер доступний лише локально. Хеш‑пароль показаний як приклад; згенеруйте свій за допомогою rspamadm pw.

Згенеруйте хеш пароля для контролера:

cr0x@server:~$ rspamadm pw -p 'ChangeThisNow'
$2$5$V1m0JwA3WcEoTg6hS2mY3uWJ5FzqKXHcGJ7x1VZy9uVw9d9QmGq2

Рішення: якщо потрібен віддалений доступ — захаруйте його через SSH‑тунель або VPN. Якщо наполягаєте прив’язати до публічного інтерфейсу, додайте firewall та сильну аутентифікацію. «Це просто UI» — шлях до того, що політику пошти змінюватимуть сторонні.

Практичні завдання (команди + виводи + рішення)

Цей розділ — м’ясо: конкретні завдання, які ви запустите в перший день. Кожне включає, що означає вивід і яке рішення ухвалювати.

Завдання 1: Підтвердіть, які воркери Rspamd запущені

cr0x@server:~$ sudo rspamadm control stat
Uptime: 0 days, 00:03:21
Messages scanned: 122
Messages learned: 0
Connections: 18

Що це означає: сканування відбувається десь; ненульове «Messages scanned» — добре.

Рішення: якщо scanned = 0, а пошта йде — ви обходите Rspamd. Перейдіть одразу до налаштування milter у Postfix і логів.

Завдання 2: Перевірте, чи Postfix справді викликає milter

cr0x@server:~$ sudo journalctl -u postfix -n 80 --no-pager | egrep -i 'milter|rspamd'
... postfix/smtpd[2140]: milter-connect: connect to unix:/run/rspamd/milter.sock: No such file or directory

Що це означає: Postfix намагався, але не зміг підключитись. Фільтр обходиться (бо ми встановили milter_default_action=accept).

Рішення: виправте шлях до сокета або впевніться, що rspamd milter‑воркер/проксі створює його. Не «вирішуйте» переключенням на TCP без розуміння, чому сокет відсутній.

Завдання 3: Перевірте наявність і власника milter‑сокета

cr0x@server:~$ sudo ls -l /run/rspamd/milter.sock
srwxrwx--- 1 rspamd rspamd 0 Jan  3 09:01 /run/rspamd/milter.sock

Що це означає: лише власник/група можуть підключитись.

Рішення: переконайтесь, що Postfix має груповий доступ (додайте до групи або змініть режим сокета через конфіг воркера). Не ставте 777 на загальному хості.

Завдання 4: Підтвердіть, що Rspamd може говорити з Redis

cr0x@server:~$ sudo rspamadm configdump redis
servers = "unix:/run/redis/redis-server.sock";

Що це означає: Rspamd вважає, що Redis на цьому сокеті.

Рішення: якщо Redis на TCP або іншому сокеті — вирівняйте конфіг. «Дві конфігурації Redis» — класична самонанесена причина простоїв під час рестарту.

Завдання 5: Швидко перевірте здоров’я Redis і латентність

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock ping
PONG
cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock --latency -i 1
min: 0, max: 1, avg: 0.22 (55 samples)

Що це означає: Redis відповідає; латентність низька. Якщо бачите стрибки до десятків/сотень мс — Rspamd почуватиметься повільно.

Рішення: якщо латентність висока — перевірте диск I/O, свап і чи Redis агресивно персистить. Виправте стан хоста перед тим, як налаштовувати правила.

Завдання 6: Протестуйте сканування прикладного повідомлення локально

cr0x@server:~$ printf 'From: a@example.net\nTo: b@example.com\nSubject: test\n\nHello\n' | rspamc
Results for file: stdin (0.012 seconds)
[Metric: default]
Action: no action
Spam: false
Score: 0.30 / 15.00
Symbol: MIME_GOOD (-0.10)
Symbol: R_SPF_ALLOW (-0.20)
Symbol: R_DKIM_NA (0.60)

Що це означає: сканування працює; символи генеруються. DKIM «NA», бо це вхідний невідпісаний лист.

Рішення: якщо rspamc сканує, але в потоках пошти не видно заголовків — ваша інтеграція MTA неправильна, а не Rspamd.

Завдання 7: Підтвердіть, що заголовки додаються на реальній пошті

cr0x@server:~$ sudo postqueue -p
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9C1B23D4A1      1244 Sat Jan  3 09:10:05  alerts@example.com
                                         user@example.com
-- 1 Kbytes in 1 Request.

Що це означає: пошта в черзі; але це не доказ фільтрації.

Рішення: візьміть доставлене повідомлення й інспектуйте на наявність X-Spam- або Authentication-Results. Якщо нема — Postfix не передав його через milter.

Завдання 8: Перевірте, чи DKIM підпис відбувається на вихідній пошті

cr0x@server:~$ sudo journalctl -u rspamd -n 120 --no-pager | egrep -i 'dkim|sign'
... rspamd[1827]: dkim_signing: sign example.com with selector s2026

Що це означає: Rspamd намагався підписати; хороший знак.

Рішення: якщо ви ніколи не бачите логів підпису — перевірте, що вихідна пошта проходить через milter (не забувайте про non_smtpd_milters для локальних відправлень).

Завдання 9: Згенеруйте DNS‑запис з публічного ключа

cr0x@server:~$ sudo head -n 5 /tmp/s2026.example.com.txt
s2026._domainkey IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." ) ;

Що це означає: це те, що ви публікуєте в DNS. Селектор входить у DNS‑мітку.

Рішення: поки DNS не опубліковано й не пропаговано — приймачі не валідовуватимуть DKIM. Це не вина Rspamd; це керування змінами у вас.

Завдання 10: Перевірте пропускну здатність Rspamd і час на повідомлення

cr0x@server:~$ sudo rspamadm control stat | egrep 'Messages scanned|Uptime'
Uptime: 0 days, 00:08:44
Messages scanned: 486

Що це означає: повідомлення обробляються. Порівняйте швидкість сканування з об’ємом вхідної пошти.

Рішення: якщо сканування відстає — перевірте CPU, DNS і латентність Redis перед тим, як регулювати кількість воркерів.

Завдання 11: Визначте повільні правила через логи (за симптомом)

cr0x@server:~$ sudo journalctl -u rspamd -n 200 --no-pager | egrep -i 'slow|timeout|lua'
... rspamd[1827]: rspamd_task_timeout: processing of task exceeded 8.0 seconds

Що це означає: Rspamd досяг таймауту, часто через DNS, HTTP‑перевірки або перевантажені ресурси.

Рішення: якщо таймаути відбуваються під навантаженням — ви фактично «відкриваєте шлюзи». Виправляйте залежності (DNS/Redis/CPU) перед тим, як зменшувати часи очікування.

Завдання 12: Перевірте швидкість DNS‑резолюції з поштового хоста

cr0x@server:~$ time dig +tries=1 +timeout=1 mx gmail.com @127.0.0.53 | egrep 'status|Query time'
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59504
;; Query time: 18 msec
real	0m0.040s
user	0m0.010s
sys	0m0.004s

Що це означає: DNS швидкий. Якщо час запиту високий або таймаути — Rspamd уповільниться і ви побачите затримки milter.

Рішення: якщо DNS повільний — виправте локальний кеш‑резолвер або надійність upstream DNS. Фільтрація спаму — робота з великою кількістю DNS‑запитів.

Завдання 13: Переконайтесь, що ваші зміни читаються з local.d (а не ігноруються)

cr0x@server:~$ sudo rspamadm configdump actions | head
actions {
    add_header = 6;
    greylist = 4;
    reject = 15;
    rewrite_subject = 8;
}

Що це означає: ваш actions.conf завантажений.

Рішення: якщо видно інші значення — ви редагували неправильний файл або інше перекриття перемагає. Вирішіть шарування конфігів перед тим, як ганятися за привидами.

Завдання 14: Підтвердіть версію Rspamd і опції збірки

cr0x@server:~$ rspamd --version
Rspamd 3.4

Що це означає: ваша runtime‑версія. Це важливо, бо дефолти модулів і синтаксис змінюються.

Рішення: якщо у вас дуже стара версія — уникайте глибокого тонкого налаштування до плану оновлення. Не хочете налаштовувати під баги.

Швидкий план діагностики

Ви на чергуванні. Пошта повільна або спам проскакує. У вас десять хвилин, перш ніж хтось скаже «можна просто вимкнути». Ось порядок, що швидко знаходить вузькі місця.

1) Чи справді пошта сканується?

Перевірте статистику Rspamd: sudo rspamadm control stat. Якщо scanned залишається на місці, поки пошта йде — MTA обходить Rspamd.
Перегляньте логи Postfix на предмет підключень/помилок milter.

Інтерпретація: якщо обхід є — налагодження балів марне. Виправляйте підключення.

2) Чи доступний milter‑шлях з Postfix?

Існує сокет? ls -l /run/rspamd/milter.sock
Права дозволяють Postfix підключитись? Членство в групі та режим.
Chroot завадив? Якщо Postfix працює в chroot для smtpd, сокет має існувати в тому chroot‑шляху або треба вимкнути chroot.

Інтерпретація: «connection refused» або «no such file» майже завжди локальні проблеми з правами/шляхом, а не мережею.

3) Чи повільний Rspamd через повільну залежність?

Латентність Redis: redis-cli --latency
Час DNS: dig з невеликим таймаутом і перевірка Query time
CPU і load: top або systemd-cgtop
Дискова навантаженість: якщо персист Redis блокує, ви побачите стрибки латентності

Інтерпретація: таймаути у логах Rspamd зазвичай вказують на DNS/HTTP‑перевірки або навантажені ресурси. Виправляйте платформу перш за все.

4) Rspamd працює, але політика надто м’яка?

Інспектуйте символи спам‑прикладу: rspamc -h 127.0.0.1:11333 (або дефолт)
Перевірте пороги дій через rspamadm configdump actions
Підтвердіть, що Postfix не обрізує заголовки далі по ланцюгу (деякі фільтри так роблять)

Інтерпретація: якщо завжди «додати заголовок», але ніколи не відкидати — користувачі скаржаться на спам. Вони не помиляються; ви просто не дали Postfix жорсткої дії.

5) Лише потім: налаштовуйте бали або ввімкніть додаткові модулі

Якщо pipeline і продуктивність стабільні — регулюйте пороги і подумайте про модулі: greylisting‑тонкощі, multimap, fuzzy і частоту навчання Bayes.

«Надія — не стратегія.» — генерал Джеймс Н. Маттіс

Типові помилки: симптом → причина → виправлення

1) «Rspamd запущений, але в доставлених листах немає заголовків»

Симптом: UI показує активність, але повідомлення в ящиках не мають X-Spam заголовків; спам проходить незмінним.
Корінь проблеми: Postfix не використовує milter для цього шляху (часто відсутні non_smtpd_milters) або сокет недоступний через права/chroot.
Виправлення: Встановіть обидва smtpd_milters і non_smtpd_milters. Перевірте доступність сокета та налаштування chroot у Postfix. Перезапустіть Postfix і перевірте логи на успішні підключення milter.

2) «Логи Postfix показують таймаути milter; пошта повільна»

Симптом: SMTP‑сесії зависають; у логах Postfix згадується таймаут milter; у логах Rspamd — таймаути задач.
Корінь проблеми: повільний DNS‑резолвер, латентність Redis, перевантажений CPU або довгі зовнішні перевірки (HTTP‑базовані модулі).
Виправлення: Зміряйте час DNS, латентність Redis і завантаження CPU. Виправте кешування резолвера, конфлікти ресурсів або відключіть дорогі модулі перед тим, як змінювати таймаути.

3) «DKIM‑підписування взагалі не відбувається»

Симптом: відсутній заголовок DKIM-Signature в исходящій пошті; логи мовчать.
Корінь проблеми: вихідна пошта не проходить через milter (шлях відправки оминає smtpd), або мапи підпису не відповідають домену відправника.
Виправлення: Переконайтесь, що non_smtpd_milters встановлено. Перевірте відповідність записів у signing table шаблонам відправника. Слідкуйте за логами за рішеннями підпису.

4) «Помилки DKIM: cannot load key»

Симптом: логи Rspamd показують помилки завантаження ключа; підпис пропускається.
Корінь проблеми: неправильний шлях у мапах, невірна комбінація селектор/домен або занадто суворі права (або неправильний власник).
Виправлення: Переконайтесь, що шлях до ключа існує, власник — rspamd, режим дозволяє читання і мапи вказують на правильне місце. Повторно запустіть rspamd -t.

5) «Все позначається як спам після увімкнення greylisting»

Симптом: легітимна пошта затримується або отримує повторні тимчасові помилки; скарги починаються негайно.
Корінь проблеми: пороги greylist надто низькі, або ви greylist‑ите внутрішні ретранслятори й SaaS‑відправників, які не повторюють відправку очікуваним чином.
Виправлення: Підніміть поріг greylist, внесіть у білий список відомих відправників або вимкніть greylisting, поки не змоделюєте поведінку відправників.

6) «Rspamd працює для вхідних, але вихідні відкидають одержувачі»

Симптом: боти одержувачів надсилають bounced‑повідомлення з DMARC/DKIM помилками; ваша пошта виглядає неаутентифікованою.
Корінь проблеми: DKIM не підписує, селектор не опубліковано в DNS або підписують невірний домен.
Виправлення: Опублікуйте DNS‑запис DKIM, перевірте підписування потрібного домену і переконайтесь, що SPF/DMARC‑вимоги не порушуються перезаписами заголовків десь далі.

7) «Контролер UI доступний з Інтернету»

Симптом: скан безпеки відзначає відкритий порт 11334; ви бачите дивні зміни конфігу або події навчання.
Корінь проблеми: контролер прив’язаний до 0.0.0.0 без firewall і аутентифікації.
Виправлення: Прив’яжіть контролер до localhost; вимагайте пароль; використовуйте SSH‑тунель/VPN для доступу. Ставтесь до нього як до адмінського інтерфейсу — бо це воно.

Контрольні списки / покроковий план

Чекліст: мінімальне первісне налаштування (один хост)

Встановіть rspamd і redis-server.
Підтвердіть, що обидва сервіси працюють через systemd.
Налаштуйте Redis через /etc/rspamd/local.d/redis.conf на використання локального сокета.
Переконайтесь, що користувач rspamd має доступ до Redis‑сокета (членство в групі).
Знайдіть або увімкніть Rspamd milter‑сокет.
Налаштуйте Postfix smtpd_milters і non_smtpd_milters на використання того сокета.
Переконайтесь, що Postfix має доступ до milter‑сокета (права, chroot).
Встановіть мінімальні пороги дій у local.d/actions.conf.
Згенеруйте DKIM‑ключі і налаштуйте dkim_signing.conf та мапи.
Перезапустіть Rspamd; перевірте конфіг через rspamd -t.
Перезавантажте Postfix; підтвердіть у логах успішні підключення milter.
Проскануйте приклад повідомлення через rspamc і перевірте реальне доставлене повідомлення на наявність заголовків.

Чекліст: «відправити в продакшн» — ускладнення після того, як все працює

Вирішіть, fail‑open або tempfail для відмов milter (milter_default_action).
Прив’яжіть контролер до localhost і встановіть сильні хеші паролів.
Встановіть зберігання логів і просте оповіщення при повторюваних помилках/таймаутах milter.
Документуйте політику ротації селекторів DKIM (навіть якщо «раз на рік»).
Визначте процес навчання ham/spam і хто за це відповідає.
Запишіть базову латентність: час задач Rspamd, латентність Redis, час DNS‑запитів.

Три короткі корпоративні історії

Інцидент через хибне припущення: «Воно налаштовано — отже фільтрує»

Компанія була на міграції: стара on‑prem пошта на нову VM‑стек. Вони встановили Rspamd, увімкнули Redis, створили DKIM‑ключі і навіть додали скріншот дашборда до завдання змін. Всі перейшли до інших справ.

Через два тижні команда безпеки підняла тривогу: обсяг фішингу зріс, а скарги користувачів були дивно схожі. Адміни пошти запевняли, що фільтр на місці. Зрештою сервіс працював і rspamc теж.

Хибне припущення було тонким: «Rspamd запущений» не означає «пошта сканується». Postfix мав smtpd_milters, але не non_smtpd_milters. Більшість вихідних і внутрішніх листів додавалися локально додатками і не проходили через smtpd.

Гірше: було milter_default_action=accept. Тому навіть коли сокет був неправильний на одному хості, пошта все одно йшла. Це була поступова деградація в повний обхід.

Виправлення було нудним: застосували milter до обох шляхів, перевірили успішні підключення у логах Postfix і додали щоденну перевірку, що «messages scanned» зростає з трафіком. Додали також канаркове повідомлення з відомим заголовком Rspamd і оповіщенням, якщо його не видно.

Оптимізація, що повернулась бумерангом: «Перенесемо Redis поза хост»

Інша організація мала сильну команду платформи і рефлекс: централізувати стан. Вони перенесли Redis з кожного поштового хоста на спільний «кластер кешу», бо «так ефективніше». Мережа була швидкою. Латентність у синтетичних тестах виглядала нормально.

Потім настала понеділкова пікова хвиля. Невеликі латентності від інших клієнтів Redis спричинили періодичні стрибки часу відповіді. Не настільки великі, щоб тривожити Redis‑аларми — але достатні, щоб Rspamd іноді перевищував свій таймаут. SMTP‑сесії почали накопичуватись. Клієнти повторювали спроби. Об’єм зростав. Система ввійшла в класичну спіраль: повтори створюють навантаження, навантаження спричиняє таймаути, таймаути — повтори.

Команда пошти підняла таймаути Rspamd вгору, щоб «стабілізувати» ситуацію. Це зменшило зависання SMTP, але збільшило черги й тиск на пам’ять. Доставлюваність постраждала, бо пошта приходила із затримкою. Користувачі звинувачували фільтр.

Вирішення було повернути Redis локально для стану сканування (або хоча б використовувати локальні репліки). Централізація підіймається для деяких сервісів; для поштового конвеєра важливіше передбачувана низька латентність, ніж умовна ефективність. Оптимізація зекономила сервер і принесла місяць періодичного болю.

Нудна, але правильна практика, що врятувала день: «Шарування конфігів і єдине джерело правди»

Фінансова компанія мала ту саму нудну дисципліну — поки вона не почала приносити гроші. У них було правило: не редагувати configs постачальника. Усі зміни йшли в local.d, і кожен файл керувався через деплой‑систему з рев’ю.

Під час планового оновлення ОС пакет Rspamd оновив дефолти. У багатьох командах це місце, де починається «чому тепер інші бали?». У них оновлення пройшло, Rspamd перезапустився і пошта йшла далі. Деякі символи змінили поведінку, але основні дії і DKIM‑підписування лишились стабільними, бо локальні перекриття були на місці.

Потім стався реальний інцидент: вихідна пошта не проходила DKIM для одного домену. Оскільки конфіги були шаровані й відслідковувані, вони швидко зробили diff карт DKIM і знайшли домен з опечаткою в signing table. Виправлення, рестарт — готово.

Що їх врятувало — не якась хитра Lua‑правила. Це була непоказна дисципліна зберігати локальну політику окремо від дефолтів пакета і можливість легко аналізувати зміни. У поштових системах нудне — це фіча.

Питання й відповіді (FAQ)

1) Чи потрібен Redis для «мінімальної» настройки?

Якщо хочете демо‑сканер — ні. Якщо хочете операційну систему, яку можна дебажити й покращувати — так. Redis зберігає корисний стан Rspamd.

2) Використовувати UNIX‑сокети чи TCP для milter?

На одному хості: UNIX‑сокети. Менше питань з firewall, менше латентності, прозоріші права. Використовуйте TCP, коли дійсно потрібне мережеве розділення — і тоді сприймайте це як проект інтеграції, а не як короткий шлях.

3) Чому я бачу «Rspamd запущений», але scanned‑повідомлення лишаються нульовими?

Бо ніхто до нього не звертається. Перевірте milters у Postfix, чи існує сокет і чи Postfix може підключитися. Використовуйте логи; не покладайтеся на інтуїцію.

4) Який найбезпечніший `milter_default_action`?

accept — найбезпечніший для доступності; tempfail — кращий для безпекової позиції. Вибирайте свідомо. Якщо обираєте accept, додайте моніторинг, що кричатиме при недоступності milter.

5) Чи потрібно навчання Bayes з першого дня?

Ні. Спочатку налаштуйте сканування, дії і DKIM. Bayes допомагає, коли у вас стабільна класифікація пошти і процес годиться віддавати приклади ham/spam.

6) Чому DKIM налаштований, але одержувачі все одно бачать «DKIM=fail»?

Найчастіше: DNS‑запис не опублікований, селектор в DNS неправильний, підписують не той домен, або лист змінюють після підпису (деякі фільтри переписують заголовки). Перевірте порядок у конвеєрі.

7) Можна запускати контролер UI на публічному інтерфейсі, якщо поставити пароль?

Можна, так само як можна зберігати резерви на флешці з написом «DO NOT LOSE». Прив’яжіть до localhost і заходьте через SSH‑тунель/VPN. Зробіть безпечний шлях простим.

8) Який мінімальний набір порогів слід взяти за стартовий?

Починайте з консервативного reject (високе число), add‑header на середньому рівні і відкладальні тактики (greylist) лише після вимірювання бізнес‑ефекту. Приклад у actions.conf — пристойна відправна точка.

9) Як дізнатися, яке правило спричинило відхилення?

Інспектуйте символи і суму в заголовках повідомлення або проскануйте його з rspamc. Сенс моделі Rspamd — пояснюваність — використайте її.

10) Чи розгортати Rspamd як SMTP‑проксі замість milter?

Не для «першого мінімального». Це може бути корисно, але додає складність маршрутизації і більший blast radius при помилках. Спочатку стабілізуйте milter‑підхід.

Наступні кроки, які варто виконати

Тепер у вас є мінімальна конфігурація, яка працює у єдиному значенні, що має значення: пошта сканується, дії виконуються, DKIM підписує вихідні, і ви можете швидко діагностувати відмови.

Доведіть pipeline щодня: створіть простий канарковий лист і налаштуйте оповіщення, якщо очікувані заголовки Rspamd не з’являються.
Вирішіть ставлення до відмов: зберігайте accept або переходьте на tempfail, коли продуктивність і залежності стабільні.
Опублікуйте DKIM‑DNS записи і перевірте зовні (з боку приймача) перед оголошенням перемоги.
Заміряйте латентність під навантаженням: латентність Redis, час DNS‑запиту і час задач Rspamd. Коли пошта повільна — ці три покажуть, куди дивитись.
Лише потім — налаштовуйте бали: коригуйте пороги на підставі реальних false positive/negative, а не анекдотів з поштових скринь керівництва.

Якщо хочете, щоб система працювала далі — ставте її як частину транспорту пошти, а не як аксесуар. Фільтри не падають красиво; вони мовчки виходять з ладу. Ваше завдання — зробити мовчання неможливим.