Rspamd: налаштування антиспаму, що блокує атаки, не блокуючи людей

Виробнича модель: Rspamd — це двигун політик, а не чарівна коробка

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

У продакшні ви не оптимізуєте під «максимальний забраний спам». Ви оптимізуєте під: (1) мінімальні хибні позитиви, (2) контрольоване використання ресурсів під час атаки,
і (3) швидку відмотку, коли ваші припущення провалюються.

Хитрість — побудувати багаторівневий конвеєр рішень:

• Аутентифікувати (SPF/DKIM/DMARC) і вирішити, що означають відмови для ваших доменів проти решти Інтернету.
• Класифікувати контент (символи, правила, Bayes де доречно) без перетворення цього процесу на невпорядкований фестиваль CPU.
• Застосувати політику (ratelimits, greylisting, репутація URL, контроль вкладень) на основі виявлених шаблонів зловживань.
• Доставити безпечно (переписати тему, додати заголовки, карантин), щоб люди могли відновити листи, коли класифікатор помилиться.

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

Парафраз думки Вернера Фогельса: Усе виходить з ладу; проектуйте для цього, виявляйте швидко й відновлюйте без героїзму.

Цікаві факти та історія, що важливі на практиці

Кілька контекстних моментів, які справді впливають на те, як ви керуєте Rspamd щодня. Не тривіальні факти — ті, що змінюють рішення.

1. Аутентифікація пошти молода в порівнянні з SMTP. SMTP існує з початку 1980‑х; SPF, DKIM і DMARC з’явилися значно пізніше, і більшість світу ще наздоганяє.
2. Rspamd побудований навколо модульної системи символів. Ви не просто «отримуєте бал»; ви отримуєте набір символів із вагами, саме тому налаштування кероване.
3. Redis став поширеним бекендом стану для сучасного фільтрування. Репутація, ratelimits, fuzzy‑хеші та стан Bayes потребують швидкої спільної пам’яті; Redis — прагматичний вибір у багатьох розгортаннях.
4. Greylisting працює, бо спамери оптимізовані під пропускну спроможність. Легітимні MTA роблять повторні спроби; дешеві спам‑боти часто ні. Це вже не так магічно, як раніше, але все ще корисно при правильному налаштуванні.
5. DMARC змінив соціальний контракт. Він дозволяє власникам доменів публікувати наміри «reject/quarantine», що дає приймачу дозвіл бути суворішим щодо певних доменів.
6. «Спам» еволюціонував у крадіжку облікових даних. ROI змістився від продажу пігулок до викрадення логінів. Це змінює значущість сигналів: імперсонація бренду, репутація URL і трюки з іменем відображуваного відправника.
7. Хвилі пошти часто — димова завіса. Атакувальники бомблять поштові скриньки, одночасно намагаючись скинути паролі або провести шахрайські транзакції в інших місцях.
8. Сучасний спам використовує легітимну інфраструктуру. Компрометовані акаунти SaaS і маркетингові платформи надсилають пошту, яка «проходить аутентифікацію», змушуючи вас покладатися на контентні та поведінкові контролі.

Жарт №1: Електронна пошта — єдиний протокол, де «напевно нормально» традиційно перевіряється, чекаючи три дні і дивлячись, хто скаржиться.

Як Rspamd приймає рішення (і де насправді живе налаштування)

Rspamd оцінює повідомлення і видає:

• Символи: іменовані виявлення, наприклад R_SPF_FAIL або DKIM_VALID.
• Бали: ваги, застосовані до символів, що комбінуються в загальний оцінювальний бал.
• Дії: що робити при досягненні порогів (нічого, додати заголовок, greylist, переписати тему, відхилити).

Дії — це політика. Бали — лише підключення.

Більшість виробничого болю походить від змішування «налаштування балів» з «налаштуванням політики». Стабільний підхід:

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

Модулі, на які дійсно варто звернути увагу

Прагматичний «ядро» для багатьох середовищ:

• SPF/DKIM/DMARC (сигнали аутентифікації, політика домену)
• ARC (ланцюги пересилань; допомагає не карати легітимні форварди/розсилки)
• RBL / SURBL (репутація IP/доменів; обережно з агресивними списками)
• Reputation (історично‑засноване, зазвичай зберігається в Redis)
• Ratelimit (контроль хвиль)
• Multimap (ваша кастомна логіка allow/deny у масштабі)
• Fuzzy (хеш‑схожість; добре для повторюваних кампаній)
• Bayes (корисний, але легко отруїться і його легко неправильно зрозуміти)

Де розміщувати кастомну логіку

Якщо ви постійно додаєте Lua‑скрипти тому, що «ще одне правило потрібно», зрештою отримаєте саморобний фільтр, написаний трьома колишніми співробітниками.
Віддавайте перевагу:

• multimap для більшості кастомних політик (домени, відправники, MIME‑типи, шаблони тем)
• local.d/ overrides замість редагування стандартної конфігурації
• малий, тестований Lua тільки коли multimap не може виразити логіку

Стратегія оцінювання: припиніть гнатися за «ідеальним балом»

Система балів — це механізм для вираження компромісів. Ваше завдання — зробити ці компроміси явними.

Почніть з дій, потім налаштовуйте ваги

Звичайна базова схема:

• додати заголовок при відносно низькому балу (інформувати downstream, полегшити пошук)
• переписати тему трохи вище (щоб користувачі помітили)
• greylist використовувати помірно (особливо для вхідних від невідомих відправників)
• відхилити лише коли впевнені (або коли атака змушує до цього)

Приймайте «м’які відмови» для сигналів аутентифікації

SPF і DKIM цінні, але реальний світ брудний: пересилання, зламаний DNS, неправильно налаштовані відправники.
Використовуйте відмови як сигнали, що комбінуються з іншими, а не як привод для однозначного відхилення — крім доменів із сильною політикою DMARC.

Побудуйте окремі політики для «ваших доменів» і «Інтернету»

Вхідні та вихідні потоки — різні задачі.

• Для вхідних важливі фішинг, спуфінг і хвилі.
• Для вихідних важливі компрометація акаунтів і збереження репутації.

Ваші домени можна тримати під строгішими стандартами: вимагайте підписання DKIM, вирівнювання From, контролі швидкості. Якщо ваші власні системи не можуть відповідати —
це не провина Rspamd. Це питання управління, замасковане під технічне.

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

Це продакшн‑рівневі «зроби це зараз» завдання. Кожне має: команду, що означає вивід, і рішення, яке з нього випливає.
Припущення: Rspamd встановлено, Linux на systemd, Redis доступний, та інтеграція з Postfix або іншим MTA.

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

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rspamd daemon
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2026-02-04 08:10:21 UTC; 2h 12min ago
   Main PID: 1423 (rspamd)
      Tasks: 32 (limit: 18958)
     Memory: 410.2M
        CPU: 8min 33.120s
     CGroup: /system.slice/rspamd.service
             ├─1423 rspamd: main process
             ├─1431 rspamd: proxy process (localhost:11332)
             ├─1432 rspamd: controller process (localhost:11334)
             └─1440 rspamd: worker process (normal)

Значення: статус «Active» — мінімальна очікувана умова. Пам’ять/CPU дають ранню підказку про витоки, вибухи правил або умови хвилі.
Багато процесів — нормально; слідкуйте за кількістю воркерів і їх зростанням.

Рішення: Якщо пам’ять неконтрольовано зростає або CPU завжди завантажений, пропустіть налаштування ваг і перейдіть до плейбуку швидкої діагностики.

Завдання 2: Перевірте синтаксис конфігурації Rspamd перед змінами

cr0x@server:~$ rspamadm configtest
syntax OK
modules OK

Значення: «Syntax OK» означає, що Rspamd може завантажити конфіг. «Modules OK» означає, що модулі ініціалізуються без помилок.

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

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

cr0x@server:~$ rspamc stat
Uptime: 7964 seconds
Messages scanned: 184295
Messages learned: 312
Messages with action reject: 3911, 2.12%
Messages with action add header: 22144, 12.01%
Messages with action rewrite subject: 8021, 4.35%
Messages with action no action: 150219, 81.52%
Scanned messages per second: 23.15
Actions histogram:
no action: 150219
add header: 22144
rewrite subject: 8021
reject: 3911

Значення: Це ваша контрольна панель. Раптові сплески в «reject» або «rewrite subject» зазвичай корелюють з вхідною кампанією або зламаним відправником.

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

Завдання 4: Проаналізуйте топ‑символи, щоб знайти, що справді викликає дії

cr0x@server:~$ rspamc counters
Symbol: R_SPF_FAIL: 12401
Symbol: DKIM_SIGNED: 98234
Symbol: DMARC_POLICY_REJECT: 821
Symbol: RBL_DBL_SPAM: 6402
Symbol: URL_COUNT_5: 4901
Symbol: MIME_HTML_ONLY: 17322
Symbol: BAYES_SPAM: 2501
Symbol: BAYES_HAM: 1811

Значення: Лічильники показують частоту символів. Часті символи не завжди погані; вони описують ландшафт середовища.

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

Завдання 5: Отримайте результат сканування конкретного повідомлення (заголовки або EML)

cr0x@server:~$ rspamc -h localhost:11334 -P 'controllerpass' symbols < /var/spool/mail/samples/suspect.eml
{"is_spam":true,"score":18.50,"required_score":15.00,"action":"reject","symbols":{"R_SPF_FAIL":{"score":2.00},"DMARC_POLICY_REJECT":{"score":4.00},"RBL_DBL_SPAM":{"score":5.00},"MIME_HTML_ONLY":{"score":1.00},"PHISHING":{"score":6.00}}}

Значення: Це «чому». Недостатньо знати, що повідомлення відхилено; потрібно бачити, які символи переважили лінію.

Рішення: Якщо спрацьовує DMARC policy reject для домену, який має бути дозволеним (форвардери, розсилки), дослідіть ARC і ланцюг аутентифікації, а не лише ваги.

Завдання 6: Перевірте здоров’я Redis і латентність (Rspamd залежить від нього більше, ніж ви думаєте)

cr0x@server:~$ redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep 'instantaneous_ops_per_sec|keyspace_hits|keyspace_misses'
instantaneous_ops_per_sec:1240
keyspace_hits:9319921
keyspace_misses:42112

Значення: Ops/sec показує навантаження. Hits vs misses — ефективність кеша. Багато misses може означати холодний кеш або сильний churn.

Рішення: Якщо ops/sec підскакує під час хвиль, переконайтесь, що Redis не насичений однопотоково, і подумайте про ізоляцію або масштабування воркерів Rspamd відповідно.

Завдання 7: Перевірте пам’ять Redis і політику витіснення (щоб уникнути «забування» репутацій)

cr0x@server:~$ redis-cli INFO memory | egrep 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
used_memory_human:2.13G
maxmemory_human:3.00G
mem_fragmentation_ratio:1.12

Значення: Якщо встановлено maxmemory і Redis починає витісняти ключі, ваша репутація та стан ratelimit стануть ненадійними. Фрагментація вказує на поведінку аллокатора.

Рішення: Якщо пам’яті замало, або підніміть maxmemory, або зменшіть те, що ви зберігаєте (модулі, строки збереження). «Дозволити витісняти» — це політичний вибір, а не дефолт.

Завдання 8: Дізнайтеся, чи прив’язаний Rspamd до CPU (занадто важкі правила, занадто багато воркерів або замало)

cr0x@server:~$ pidstat -p $(pidof rspamd | tr ' ' ',') 1 3
Linux 6.1.0 (server)  02/04/2026  _x86_64_  (8 CPU)

12:40:11 PM   PID  %usr %system  %CPU  Command
12:40:12 PM  1423  1.00    0.00  1.00  rspamd
12:40:12 PM  1440 92.00    2.00 94.00  rspamd
12:40:12 PM  1441 88.00    1.00 89.00  rspamd

Значення: Воркер‑процеси, що підходять до 100% — нормальне явище під навантаженням, але тривале заповнення CPU із збільшенням черг означає вузьке місце.

Рішення: Якщо CPU насичений, зменшіть повільні перевірки (глибина витягання URL, важкі regex, забагато DNS‑запитів) або додайте потужність. Не «вирішуйте» проблему CPU через зниження порогів відхилення.

Завдання 9: Виміряйте здоров’я резолюції DNS (багато модулів залежать від DNS)

cr0x@server:~$ resolvectl statistics
Transactions: 219381
Cache Hits: 171224
Cache Misses: 48157
DNSSEC Verdicts Secure: 0
DNSSEC Verdicts Insecure: 0
DNSSEC Verdicts Bogus: 0

Значення: Багато misses можуть означати погане кешування або агресивні TTL. У фільтрації пошти DNS часто прихований податок латентності.

Рішення: Якщо misses високі й латентність помітна, поставте локальний кеш‑резольвер на тій же хості або в LAN і переконайтесь, що Rspamd ним користується.

Завдання 10: Протестуйте шлях RBL/SURBL‑запиту (і виявляйте таймаути)

cr0x@server:~$ dig +time=1 +tries=1 2.0.0.127.zen.spamhaus.org A +short
127.0.0.2

Значення: Швидка відповідь означає, що шлях DNS працює і список доступний. Тайм‑аути тут стають затримками на повідомлення.

Рішення: Якщо запити таймаутяться, або виправте вихідний DNS, або змініть резольвер, або відключіть список. Тайм‑аути під навантаженням — спосіб самозаподіяти DDoS вашому шлюзу пошти.

Завдання 11: Переконайтесь, що Postfix дійсно передає пошту в Rspamd (перевірка інтеграції)

cr0x@server:~$ postconf -n | egrep 'smtpd_milters|non_smtpd_milters|milter_protocol|milter_default_action'
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332
milter_protocol = 6
milter_default_action = accept

Значення: Якщо milters не налаштовані, ви налаштовуєте фільтр, який ніколи не бачить трафіку. Значення за замовчуванням «accept» — це захід безпеки під час відмов.

Рішення: Тримайте milter_default_action=accept, якщо ви не любите пояснювати, чому пошта закрилась у найневдаліший момент.

Завдання 12: Стежте за пропускною спроможністю і тиском черг (перевірка «це атака?»)

cr0x@server:~$ mailq | tail -n +1 | head -n 12
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     2480 Tue Feb  4 12:38:02  sender@example.net
                                         recipient@yourdomain.com

F6G7H8I9J0     3121 Tue Feb  4 12:38:02  sender2@random.tld
                                         recipient@yourdomain.com

-- 2814 Kbytes in 742 Requests.

Значення: Зростання черги вказує на повільність downstream: Rspamd, DNS, контентні перевірки або проблеми доставки.

Рішення: Якщо черга росте під час хвилі спаму, увімкніть або посильте ratelimits/greylisting замість того, щоб лише коригувати ваги контенту.

Завдання 13: Перегляньте логи Rspamd на предмет таймаутів і болючих модулів

cr0x@server:~$ journalctl -u rspamd --since "30 min ago" | egrep -i 'timeout|slow|error|redis' | tail -n 12
Feb 04 12:22:11 server rspamd[1440]: <0c1d3a>; lua; lua_rsa.lua:142: slow hash computation: 215ms
Feb 04 12:22:18 server rspamd[1441]: ; rbl; rbl.c:512: timeout while resolving zen.spamhaus.org for 203.0.113.44
Feb 04 12:23:04 server rspamd[1440]: ; redis; redis_pool.c:98: cannot connect to redis: Connection refused

Значення: Ці повідомлення вказують на точні модулі, що спричиняють латентність або відмови. Таймаути RBL = DNS або egress. Проблеми з підключенням до Redis = модулі стану можуть відкрито/закрито працювати неправильно.

Рішення: Виправте залежність (DNS/Redis) перед налаштуванням правил. Інакше ви налаштовуєтеся на зламані датчики.

Завдання 14: Безпечно перезавантажте Rspamd після змін конфігурації

cr0x@server:~$ rspamadm configtest && systemctl reload rspamd && systemctl is-active rspamd
syntax OK
modules OK
active

Значення: Reload зберігає uptime процесу під час застосування змін; «active» підтверджує, що він не впав у цикл перезавантажень.

Рішення: Завжди робіть configtest перед reload. Ви не хочете вивчати синтаксис через простій пошти.

Плейбук швидкої діагностики

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

Перше: це пропускна спроможність, латентність чи політика?

• Проблема пропускної спроможності: черги ростуть, швидкість сканування падає, CPU заповнений.
• Проблема латентності: затримки на повідомлення, таймаути в логах, зависання DNS.
• Проблема політики: раптові хибні позитиви/негативи, зміни в розподілі дій.

Друге: перевірте три звичних підозрюваних

1. DNS:
   • Шукайте таймаути RBL/SURBL у логах.
   • Перевірте статистику кешуючого резольвера.
   • Тестуйте репрезентативні запити з dig із низьким таймаутом.
2. Redis:
   • Чи Redis вгору? Чи не свопить? Чи не витісняє ключі?
   • Перевірте піки латентності й помилки підключення.
3. Навантаження CPU/пам’яті:
   • Чи воркери Rspamd закриті? Чи витрачають вони час на один важкий модуль?
   • Чи не трешиться чи не йде I/O через пам’ять або диск (особливо якщо Redis персистить)?

Третє: подивіться на гістограму дій і топ‑символи

Якщо «reject» або «rewrite subject» вибухають, не поспішайте змінювати ваги.
Витягніть 10 зразків (суміш відхилених і граничних) і порівняйте набори символів. Ви шукаєте одне з наступного:

• Один поганий джерело репутації (RBL повертає хибні позитиви, DNS‑отруєння, занадто агресивні блок‑списки)
• Зміни в ланцюгу аутентифікації (форвардери, нова маркетинг‑платформа, неправильна ротація ключів DKIM)
• Новий шаблон кампанії (нові URL, тип вкладення, трюки з темою)

Четверте: оберіть правильний важіль

• Атака‑хвиля: ratelimit + greylisting + контролі з’єднань.
• Цілеспрямований фішинг: multimap/URL‑правила + суворе DMARC‑оброблення для захищених брендів + евристика теми/імени відображення.
• Хибні позитиви: карантин + вузькі allowlist‑и + виправлення конкретної ваги модуля.
• Колапс продуктивності: зменшити повільні DNS‑модулі, додати кешування, ізолювати Redis, масштабувати воркерів.

Три міні‑історії з корпоративного фронту

1) Інцидент через хибне припущення: «DKIM valid означає безпечно»

Середня компанія перенесла вхідний шлюз на один Rspamd. Вони щойно завершили багатомісячний проєкт з доставлюваності,
тому аутентифікація була головною: SPF вирівняний, DKIM підписано, DMARC застосовано для власних доменів.
Вони припустили, що вхідна пошта з DKIM_VALID здебільшого легітимна, бо «спамери не можуть робити DKIM».

Потім прийшла хвиля фішингу. Це не було спуфінгом. Пошта надходила з компрометованих акаунтів легітимної SaaS‑платформи, яка правильно підписувала DKIM.
Пошта проходила SPF і DKIM, і DMARC вирівнювався, бо зловмисник використав схожий домен з валідною аутентифікацією.
Контент був мінімальний, URL щойно зареєстрований, а payload ховався за ланцюжком редиректів, що не виявлявся базовими перевірками.

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

Виправлення було менш видовищним, але ефективнішим: вони припинили трактувати DKIM як сигнал довіри і почали розглядати його як сигнал ідентичності.
Побудували multimap‑правила для захищених брендів і внутрішніх робочих процесів, додали перевірки репутації URL з безпечним розв’язуванням редиректів,
і впровадили карантин для «прошедших аутентифікацію, але підозрілих» повідомлень. DKIM і далі мав значення, але не голосував двічі.

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

2) Оптимізація, що вдарила у відповідь: «Просто увімкнемо всі RBL»

Інша організація мала проблему зі спамом і проблему з закупівлями. Вони не хотіли платити за щось нове, і команда
знайшла довгий список DNS‑блоклистів. Хтось запропонував: «Увімкнемо їх усі. Чим більше списків — тим більше захисту».
Це звучить розумно, доки ви не пригадаєте, як DNS працює під навантаженням.

Вони увімкнули стек RBL/SURBL з агресивними таймаутами і без кешування. Першого дня все виглядало чудово.
Рівень відхилень зріс, скарги на спам впали, і команда насолоджувалась рідким відчуттям правоти.

На другий день прийшла хвиля. DNS‑запити підскочили, почалися таймаути, і воркери Rspamd проводили час в очікуванні відповідей, яких не було.
Черги в Postfix зросли. Легітимна пошта затримувалась на хвилини. Потім хтось «вирішив» проблему, збільшивши кількість воркерів Rspamd, що лише примножило тиск на DNS.
Система вже не фільтрувала спам; вона сама DDoSила свій резольвер.

Відновлення було простим, але не гламурним: вони зменшили кількість RBL до невеликого набору з доведеним сигналом,
поставили локальний кеш‑резольвер попереду і встановили розумні таймаути для модулів, щоб відмови деградували плавно.
Вони також почали моніторити метрики латентності DNS. На графіку, що кричить, важко сперечатись.

3) Нудна, але правильна практика, що врятувала день: «Карантин і рев’ю, завжди»

Регульована компанія обробляла юридичну пошту, фінансову пошту і ті HR‑листи, що стають доказами, якщо з ними щось не так.
Вони хотіли агресивного відхилення спаму. Поштова команда відмовилась. Вони впровадили політику карантину:
більшість «високої впевненості» спаму відхиляли, але все, що у сірій зоні, йшло в карантин на визначений термін зберігання.

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

Одного дня великий партнер неправильно обернув ключі DKIM і почав падати вирівнювання. Їхня пошта виглядала як спуфінг, і частина потрапила в карантин.
Бізнес‑вплив був реальним, але обмеженим: листи затримались, а не знищились.

Оскільки команда мала нудну практику, інцидент перетворився на 30‑хвилинну операційну вправу, а не на багатоденний скандал.
Вони ввели тимчасове виключення з вузькими межами, повідомили партнера, що зламалося, і прибрали виключення, коли партнер виправив DNS.
Нічого «розумного» не сталося. Ось чому це спрацювало.

Налаштування під сучасні атаки: хвилі, фішинг і «косплей бізнес‑пошти»

Хвилі спаму та mail‑бомби: перемагаємо, обмеживши використання ресурсів

Під час хвилі контент‑класифікація стає менш надійною, бо атакувальники розпилюють варіації. Краще скоротити радіус ураження:
обмежуйте швидкість по IP/відправнику, уповільнюйте невідомих і захищайте downstream MTA та скриньки.

Використовуйте модуль ratelimit Rspamd і розгляньте селективний greylisting:

• Ratelimit на основі IP або ASN, коли кампанія концентрується.
• Ratelimit на основі одержувача під час mail‑бомб (коли дроблять одну скриньку).
• Greylist для невідомих відправників, які не проходять базову гігієну (немає валідного rDNS, немає аутентифікації, підозрілий HELO), але уникайте greylisting великих провайдерів з гарною репутацією.

Крадіжка облікових даних: вважайте URL payload‑ом

Більшість фішингових листів — це системи доставки URL, а не вкладень. Ваші налаштування повинні це враховувати:

• Надійно витягувати URL (але не перетворювати витяг у CPU‑пекло).
• Перевіряти репутацію URL і нові домени.
• Виявляти домени‑імітування і бренд‑приманку в імені відображення.
• Обережно ставитись до ланцюжків редиректів; атакувальники ховаються за «легітимними» трекінговими доменами.

Імперсонація та атаки типу BEC: аутентифікації недостатньо

Business email compromise часто використовує:

• Підміна імені відображення («Ім’я CEO» з випадкового домену)
• Маніпуляцію Reply‑to (From виглядає нормально; Reply‑To йде в інше місце)
• Угону ниток (використання тем типу «Invoice» і «Re: Payment»)

Rspamd може допомогти кастомними правилами (multimap/Lua), але реальний контроль — це політика:
скеровуйте підозрілі шаблони імперсонації в карантин або додавайте гучний заголовок для клієнтів, що показують банери.

Жарт №2: Єдина річ більш наполеглива, ніж спам, — це запрошення на зустріч «Quick Sync», яке постійно воскресає як привид у календарі.

Не блокувати людей: контроль хибних позитивів по‑дорослому

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

Спроектуйте шлях відновлення перед тим, як посилювати політику

• Карантин для граничної пошти з визначеним робочим процесом перевірки.
• Перепис теми для середньої впевненості, щоб користувачі могли самостійно фільтрувати без втрати листа.
• Додавання заголовків для низької впевненості. Нехай downstream‑системи вирішують (SIEM, правила поштових клієнтів, користувачі).

Віддавайте перевагу вузьким allowlist‑ам над широкими

«Allowlist домен відправника» зазвичай занадто широкий. Віддавайте перевагу:

• Allowlist конкретної envelope sender + DKIM domain комбінації
• Allowlist конкретного контрольованого вами IP‑діапазону
• Allowlist виділеного домену відправника відомого постачальника (а не всього їхнього корпоративного домену)

Будьте суворі там, де безпечно: ваші домени і критичні бренди

Для пошти, що претендує на походження від ваших доменів, суворість — невід’ємна умова:
невирівняний From має каратись. Це спосіб зупинити спуфінг і внутрішні спроби імперсонації.

Для «захищених брендів» (банки, постачальники зарплат, провайдери ідентифікації) суворість також виправдана:
ці домени атакувальники використовують частіше, бо користувачі їм довіряють.

Bayes: використовуйте, але не ставте його за кермо

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

• Бути отруєна цілеспрямованими кампаніями
• Перепідлаштуватись під внутрішній жаргон
• Створити невидиме зв’язування між «поведінкою тренування» і результатами пошти

Якщо ви використовуєте Bayes, сприймайте тренування як операційний процес, а не хобі. Обмежте, хто може тренувати, логуйтесь з тренування та періодично оцінюйте точність.

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

1) Симптом: раптовий сплеск відхилених легітимних листів

Корінна причина: Одна джерело репутації стала «гарячою» (RBL/SURBL хибні позитиви) або DNS почав таймаутити і помилково фіксувати відмови.

Виправлення: Визначте символ, що викликає відхилення через rspamc symbols на зразках. Зменшіть вагу або відключіть цей список, додайте кешування DNS, встановіть таймаути і перевірте в реальному часі.

2) Симптом: черги ростуть, CPU Rspamd завантажений, швидкість сканування падає

Корінна причина: Забагато дорогих перевірок (RBLи, витяг URL, regex) + недостатнє кешування; або хвиля штовхає систему в гірший випадок.

Виправлення: Посильте ratelimits/greylisting, зменшіть повільні модулі, забезпечте локальний кеш‑резольвер і масштабування горизонтально за потреби. Вимірюйте до/після.

3) Симптом: «Спам проходить» навіть при високих налаштованих балах

Корінна причина: Rspamd насправді не в шляху пошти (помилка налаштування milter) або він відкрито працює через проблеми із залежностями (Redis впав, таймаути).

Виправлення: Перевірте MTA milters, логи Rspamd, підтвердьте зв’язність з Redis. Не міняйте бали, поки не впевнитесь, що повідомлення скануються.

4) Симптом: переслані листи відхиляються через DMARC

Корінна причина: Пересилання ламає SPF і може зламати DKIM; вирівнювання DMARC провалюється, і ви застосовуєте політику занадто суворо без обробки ARC.

Виправлення: Увімкніть і перевірте обробку ARC, створіть цільові винятки для відомих форвардерів і ставте такі випадки в карантин замість відхилення.

5) Симптом: легітимна масова пошта (рахунки, сповіщення) потрапляє в спам

Корінна причина: Неправильна конфігурація вендора: відсутній List‑Unsubscribe, погане вирівнювання DKIM, спільна IP‑репутація або контент маркетингового шаблону тригерить правила.

Виправлення: Побудуйте вузькі allow‑правила (конкретні домени/IP), вимагайте вирівнювання DKIM від постачальників і регулюйте ваги тільки для конкретних патернів символів.

6) Симптом: періодичні помилки, «cannot connect to redis»

Корінна причина: Redis на тому ж хості конкурує за пам’ять/CPU, досягає maxclients або перезапускається OOM‑кілером.

Виправлення: Виділіть ресурси правильно, встановіть maxmemory з усвідомленою політикою витіснення, моніторьте і подумайте про ізоляцію Redis на виділеній інфраструктурі.

7) Симптом: «Усе у greylist» і користувачі скаржаться на затримки

Корінна причина: Greylisting застосований занадто широко (включно з великими провайдерами) або whitelist не налаштовано для відомих хороших відправників.

Виправлення: Обмежте greylisting для невідомих/низькорепутаційних джерел, whitelist‑те великі MTA де доречно і використовуйте ratelimit для хвиль замість загального greylist.

8) Симптом: хибні позитиви пов’язані з одним внутрішнім відділом

Корінна причина: Внутрішні системи надсилають машинно‑згенеровані HTML‑листи або дивну MIME‑структуру, що виглядає як спам.

Виправлення: Виправте відправника, щоб він генерував коректний MIME, додайте нормальний DKIM, і лише потім додавайте вузьке allow‑правило за потреби.

Чеклісти / покроковий план

Покроково: ущільнити Rspamd, не підірвавши довіру користувачів

1. Базова спостережуваність: гістограма дій, швидкість сканування, глибина черги, латентність DNS, здоров’я Redis.
2. Встановіть консервативні дії: додати заголовок > переписати тему > карантин/greylist > відхилити.
3. Перевірте ланцюг аутентифікації: SPF/DKIM/DMARC/ARC на репрезентативному трафіку (не лише на одному «щасливому» відправнику).
4. Контролюйте хвилі: увімкніть ratelimits; вирішіть план захисту одержувачів від mail‑бомб.
5. Обирайте джерела репутації свідомо: менше, але якісні списки з суворими таймаутами і кешуванням.
6. Побудуйте політику multimap: захищені бренди, відомі постачальники, внутрішні системи і «ніколи не відхиляти» шляхи, скеровані в карантин.
7. Визначте робочий процес винятків: хто може allowlistити, термін життя винятків, як ви їх аудитуєте і видаляєте.
8. Проведіть тренування на хибні позитиви: симулюйте помилку партнера з DKIM; підтвердіть, що ви швидко відновлюєте пошту з карантину.
9. Стрес‑тест: відтворіть зразкові хвилі спаму; перевірте швидкість сканування та поведінку черг під навантаженням.
10. Ітерація щотижня: невеликі зміни, вимірюваний вплив, план відкату.

Чекліст: перед підвищенням агресивності відхилення

• Карантин існує і пошуковий з визначеним SLA на перевірку.
• Топ‑символи відхилень зрозумілі з реальними прикладами.
• Кешування DNS налаштовано і таймаути RBL контролюються.
• Redis має запас по ресурсам і без неочікуваних витіснень.
• Шляхи пересилання оцінені (ARC там, де потрібно).
• На‑колл runbook є для «партнер зламав DKIM» і «атака mail‑бомба».

Чекліст: під час активної атаки

• Підтвердьте, що це атака: зростання черг + зміни гістограми дій + концентрація джерел.
• Увімкніть/посильте ratelimits для атакуючих джерел або одержувачів.
• Розгляньте тимчасовий greylisting для невідомих джерел.
• Зменшіть повільні перевірки, що посилюють латентність (додаткові RBLи, важкий витяг URL) до стабілізації.
• Карантинуйте підозрілі листи з пройденою аутентифікацією замість відхилення, якщо невпевнені.
• Після інциденту: відкотіть тимчасові широкі контролі і перетворіть отримані уроки на цільові правила.

Питання та відповіді

1) Чи відхиляти спам на рівні SMTP чи ставити в карантин?

Відхиляйте на рівні SMTP у випадках високої впевненості (чистий малвар/фішинг, сильні невідповідності DMARC reject для захищених доменів, відомі погані IP).
Карантин — для неоднозначних випадків. Якщо ви не можете надійно відновити пошту, ви не готові агресивно відхиляти.

2) Який найшвидший спосіб зменшити хибні позитиви?

Не «знижуйте всі бали». Визначте топ‑символ(и), що викликають хибні позитиви, просканувавши зразки і переглянувши counters. Виправте вагу модуля або правило,
і додайте вузький виняток для конкретної поведінки відправника, якщо потрібно.

3) Чи досі корисний greylisting?

Так, але лише селективно. Загальний greylisting карає легітимні масові провайдери і створює видимі користувачеві затримки.
Використовуйте його як клапан тиску для невідомих джерел або під час хвиль, а не як основний фільтр.

4) Скільки RBL/SURBL списків мені слід увімкнути?

Менше, ніж ви думаєте. Обирайте невелику кількість високосигнальних списків, з жорсткими таймаутами, і переконайтесь, що кешування DNS налаштовано.
Більше списків може зменшити спам — поки не зменшить вашу пропускну спроможність.

5) Чому спам зараз проходить SPF/DKIM/DMARC?

Бо атакувальники використовують компрометовані акаунти і легітимних відправників, або реєструють схожі домени і правильно налаштовують аутентифікацію.
Аутентифікація доводить ідентичність відправного домену, а не намір повідомлення.

6) Де зберігати локальні кастомізації?

У local.d/ overrides і визначення multimap. Уникайте редагування стандартних конфігів напряму; це ускладнює оновлення й робить дрейф невидимим.

7) Як налаштувати Rspamd під високим навантаженням, не погіршивши ситуацію?

Розглядайте латентність залежностей як ворога: DNS і Redis перш за все. Використовуйте ratelimit/greylisting, щоб обмежити роботу.
Тимчасово відключіть або пом’якште повільні перевірки. Не додавайте воркерів, поки не зрозумієте спільне вузьке місце.

8) Чи потрібен мені Bayes‑фільтр?

Не обов’язково. У різноманітному вхідному середовищі Bayes може бути шумним і операційно дорогим.
Якщо ви його використовуєте, фіксуйте тренування, моніторте точність і переконайтесь, що він не переважає інші сигнали.

9) Як обробляти пересилання та розсилки без підвищення ризику фішингу?

Увімкніть оцінку ARC там, де потрібно, ставте в карантин неоднозначні відмови і напишіть явну політику для відомих форвардерів і списків.
Не ігноруйте DMARC загалом. Саме так повертається спуфінг.

Висновок: наступні кроки, які ви можете зробити цього тижня

Rspamd із задоволенням дозволить вам збудувати складний собор конфігурацій. Не робіть цього. Побудуйте машину політик, яка деградує плавно,
спостережувана і має шлях відновлення для людей.

1. Запустіть rspamc stat і rspamc counters; зробіть скриншоти базових показників дій і топ‑символів.
2. Перевірте залежності DNS і Redis; виправте таймаути і кешування перед тим, як торкатись ваг.
3. Впровадьте (або посильте) ratelimits для захисту від mail‑бомб та очевидних хвиль.
4. Налаштуйте карантин для граничних випадків; визначте, хто його переглядає і наскільки швидко.
5. Створіть multimap‑політику для захищених брендів і критичних внутрішніх робочих процесів.
6. Зробіть одне контрольоване налаштування, виміряйте ефект тиждень і майте план відкату.

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