Rspamd Хибні спрацьовування: налаштуйте оцінювання спаму, не пропускаючи сміття

Ментальна модель: дії, символи та чому виникають хибні спрацьовування

Rspamd не «вирішує, що є спамом». Він підсумовує сигнали. Кожен сигнал — це символ з певною вагою. Загальний бал зіставляється з дією: нічого не робити, додати заголовок, застосувати greylist, переписати тему, відхилити або помістити в карантин (залежно від вашої політики).

Хибні спрацьовування зазвичай виникають з одного з чотирьох джерел:

1. Неправильні припущення про пороги. Хтось виставив reject = 6, бо «6 здається правильним», а потім забув, що один зламаний DKIM плюс удар по репутації можуть підняти чисту розсилку до відхилення.
2. Символ з надмірною вагою. Користувацьке регулярне правило, яке мало ловити «додаток рахунку», тепер натякає на кожне згадування «рахунок», включно з листами вашої власної фінансової команди.
3. Невирівняна аутентифікація. SPF проходить для одного домену, DKIM підписує інший, DMARC не проходить, і лист отримує штраф до оцінки — особливо це помітно при пересиланні та розсилках.
4. Налаштування та дрейф репутації. Bayes навчився на неправильній папці; fuzzy-хеші запам’ятали шаблон, який співпадає з легітимними шаблонами; історичні джерела репутації змінили поведінку.

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

Сухий операційний урок: «Просто піднімемо поріг reject» — це еквівалент відключити вогнегасник. Працює доти, доки не спричинить справжню катастрофу.

І ще одна цитата, яку варто тримати на стіні. Werner Vogels має переказану думку, яка є оперативним золотом: все ламається, тож проєктуйте так, ніби відмова — це нормальний стан. Застосуйте це тут: передбачайте, що деякі правила будуть помилкові, і побудуйте процес, який швидко їх виявляє й виправляє.

Факти та контекст, які дійсно мають значення в продакшні

Шість–десять коротких контекстних пунктів, бо продакшн-системи будуються на історії, хоч ми це й не визнаємо:

• Факт 1: Rspamd спроектований як високопродуктивна заміна старим монолітним фільтрам, із модульним движком правил і асинхронним ввід/вивід для прогнозованої латентності під навантаженням.
• Факт 2: Модель «символів» навмисно прозора в порівнянні з багатьма ML-тільки фільтрами: ви можете пояснити, чому повідомлення набрало 9.3 — це важливо, коли дзвонить юридичний відділ.
• Факт 3: Greylisting колись був майже безкоштовною перемогою, бо ранні спам-боти не повторювали спроби належним чином; сучасна інфраструктура спаму повторює, тож greylisting — це зараз політичне рішення, а не «хитрий хід».
• Факт 4: Прийняття DMARC змінило ландшафт оцінювання: невідповідність вирівнювання не завжди означає зловживання, але сильно корелює з абузою — особливо для доменів-клонів.
• Факт 5: Розсилки історично ламають DKIM, бо змінюють заголовки/тіло; «DKIM fail» частіше означає «розсилка», ніж «спам».
• Факт 6: Autolearn (автоматичне навчання Bayes) був джерелом самонанесеної шкоди в багатьох системах спаму, не тільки в Rspamd, бо нападники можуть підштовхнути вашу модель граничним контентом.
• Факт 7: Redis став де-факто сховищем для багатьох модулів Rspamd (Bayes, fuzzy, ratelimit тощо), бо швидкі пошуки важливіші за складну персистентність.
• Факт 8: Парсинг MIME і вилучення URL — постійні гарячі точки; регресії продуктивності часто виглядають як «хибні спрацьовування», бо таймаути змінюють набір виконуваних перевірок.
• Факт 9: «Легітимна масова розсилка» операційно ближча до спаму, ніж до персональної пошти. Трактуйте її як окремий клас трафіку з власною політикою.

План швидкої діагностики: знайдіть вузьке місце за кілька хвилин

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

По-перше: підтвердьте, яка дія відбулася і чому

• Отримайте результат Rspamd для повідомлення (з заголовків, логів або контролера).
• Визначте три символи з найбільшим внеском у бал.
• Перевірте, чи відповідає дія (reject/quarantine/greylist) політиці для цього класу трафіку.

По-друге: перевірте, чи це системна зміна або окремий відправник

• Порівняйте частоту появи символів та середні бали сьогодні проти вчора.
• Шукайте раптовий сплеск одного символу (наприклад, DNSBL або символ вирівнювання DMARC).
• Перевірте здоров’я DNS: таймаути тихо змінюють оцінювання, бо змінюють перелік перевірок.

По-третє: перевірте підсистеми (Rspamd і залежності)

• Чи здорові воркери Rspamd? Чи немає циклів краху? Чи немає бэклогу?
• Латентність і викиди в Redis? (Втрати даних Bayes/fuzzy можуть змінити поведінку.)
• Продуктивність і коректність DNS-резолвера.

По-четверте: застосуйте найменше можливе виправлення

• Якщо один символ помилковий, підкоригуйте цей символ або звужуйте його дію (по домену, IP, відправнику).
• Якщо вирівнювання аутентифікації шумить, налаштуйте відповідні символи, але не зводьте їх нанівець.
• Якщо потрібно послабити дії, робіть це тимчасово й у парі з компенсаторним контролем (карантин замість reject; додавайте заголовки й моніторте).

Практичні завдання: команди, виходи та що робити далі

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

Завдання 1: Підтвердити, що Rspamd запущено і яку версію ви налаштовуєте

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rspamd rapid spam filtering system
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-01-03 08:41:12 UTC; 2h 13min ago
   Main PID: 1342 (rspamd)
      Tasks: 18 (limit: 18910)
     Memory: 212.4M
        CPU: 7min 11.402s

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

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

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

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

Що це означає: Greylist на 4 — агресивно; add_header на 6 — нормально; reject на 15 — консервативно. Якщо ваші хибні спрацьовування — це відхилення при reject=15, то ймовірно декілька символів мають завеликі ваги або є баг.

Рішення: Якщо reject низький (наприклад, 6–8), вважайте це ймовірним фактором і рухайтеся в бік quarantine/add_header під час тонкого налаштування символів.

Завдання 3: Витягти результат конкретного повідомлення з логів (по queue ID)

cr0x@server:~$ grep -F "q1bC7R2kQz" /var/log/rspamd/rspamd.log | tail -n 1
2026-01-03 10:55:21 #1342(normal) <9c1f0b>; task; rspamd_task_write_log: id: <q1bC7R2kQz@mail.example>, qid: q1bC7R2kQz, ip: 203.0.113.44, from: <billing@vendor.example>, (default: F (no action): [8.11/15.00] [DMARC_POLICY_REJECT(3.50){vendor.example;reject;},DKIM_REJECT(2.00){fail;},R_SPF_FAIL(1.80){-all;},MANY_INVISIBLE_PARTS(0.80){2;},MIME_HTML_ONLY(0.20){},ARC_NA(0.10){},ASN(0.01){AS64500;}] len: 48712, time: 110.2ms real, 36.7ms virtual, dns req: 18, digest: <d2c7...>, mime_rcpts: <ap@yourco.example>

Що це означає: Не відхилено, але бал 8.11. Великим драйвером є DMARC policy reject + DKIM fail + SPF fail. Це не «випадково»; це проблема вирівнювання/аутентифікації.

Рішення: Не знижуйте глобально бали DMARC/DKIM/SPF. Дослідіть, чи відправник неправильно налаштований, чи пересилання зламало SPF, або чи лист надходить через шлюз, що змінює повідомлення.

Завдання 4: Аналіз сплесків частоти символів (швидка перевірка трендів)

cr0x@server:~$ awk -F'[][]' '/rspamd_task_write_log/ {print $4}' /var/log/rspamd/rspamd.log | \
tr ',' '\n' | sed 's/(.*//' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  4821 R_DKIM_ALLOW
  3912 R_SPF_ALLOW
  1104 MIME_HTML_ONLY
   988 DMARC_POLICY_REJECT
   811 R_SPF_FAIL
   620 DKIM_REJECT
   507 MANY_INVISIBLE_PARTS

Що це означає: DMARC_POLICY_REJECT і DKIM_REJECT високі. Або ви отримуєте цілеспрямоване спуфінгування (можливо), або щось змінилося в перевірках аутентифікації (також можливо).

Рішення: Корелюйте з DNS-змінами, змінами шляху MTA або онбордингом постачальника. Якщо тільки один постачальник триггерить, звужуйте виправлення під відправника/домен замість того, щоб притупляти глобальні правила.

Завдання 5: Перевірити здоров’я DNS-резолвера з хоста Rspamd

cr0x@server:~$ resolvectl statistics
Transactions               Current Transactions  0
Cache                       Cache Size           4632
Cache                       Cache Hits           191022
Cache                       Cache Misses         22114
DNSSEC Verdicts             Secure               0
DNSSEC Verdicts             Insecure             0
DNSSEC Verdicts             Bogus                0

Що це означає: Якщо кількість cache misses різко зростає і латентність підвищується, Rspamd може вчасно не виконувати DNS-перевірки (SPF, DKIM key lookups, DNSBL), що змінює поведінку оцінювання і іноді створює хибні спрацьовування або невідповідні дії.

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

Завдання 6: Заміряти латентність Redis і пам’ять

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock INFO stats | egrep 'instantaneous_ops_per_sec|keyspace_hits|keyspace_misses'
instantaneous_ops_per_sec:1420
keyspace_hits:982211
keyspace_misses:44102

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock INFO memory | egrep 'used_memory_human|maxmemory_human|evicted_keys'
used_memory_human:1.62G
maxmemory_human:2.00G
evicted_keys:18219

Що це означає: Викиди означають, що ви втрачаєте стан. Bayes і fuzzy можуть деградувати непередбачувано, якщо Redis постійно викидає дані.

Рішення: Не продовжуйте налаштування, поки Redis не матиме запасу пам’яті. Додайте пам’ять, відрегулюйте maxmemory policy або перемістіть Bayes/fuzzy на окремий інстанс Redis.

Завдання 7: Використати rspamc для аналізу підозрілого листа (збереженого у файлі)

cr0x@server:~$ rspamc -h /run/rspamd/rspamd.sock symbols /tmp/suspect.eml
Results for file: /tmp/suspect.eml (0.221 seconds)
Symbol: DMARC_POLICY_REJECT (score: 3.50)
Symbol: DKIM_REJECT (score: 2.00)
Symbol: R_SPF_FAIL (score: 1.80)
Symbol: MIME_HTML_ONLY (score: 0.20)
Message-ID: <1c9f...@vendor.example>
Action: no action
Spam: false
Score: 7.50 / 15.00

Що це означає: Ви можете відтворити оцінку поза MTA. Це необхідно для безпечного налаштування.

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

Завдання 8: Вивести сконфігуровану вагу символу та групу

cr0x@server:~$ rspamadm configdump --path scores | egrep 'DMARC_POLICY_REJECT|DKIM_REJECT|R_SPF_FAIL'
DMARC_POLICY_REJECT = 3.5;
DKIM_REJECT = 2;
R_SPF_FAIL = 1.8;

Що це означає: Підтверджує, що ви не женетеся за привидами; це реальні ваги, не «динамічні».

Рішення: Якщо потрібно зменшити біль, віддавайте перевагу звуженню (по домену/відправнику) над глобальним зниженням.

Завдання 9: Перевірити пер-доменні переоприділення політик (часте джерело несподіванок)

cr0x@server:~$ rspamadm configdump --path settings
settings {
    yourco.example {
        priority = high;
        apply {
            actions {
                reject = 12;
            }
        }
    }
}

Що це означає: Хтось понизив поріг reject лише для вашого основного домену (або підвищив тощо). Це часто навмисно, інколи забувається.

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

Завдання 10: Перевірити попадання в multimap allowlist (щоб побачити, чи ви покладаєтесь на «скотч»)

cr0x@server:~$ grep -F "MULTIMAP" /var/log/rspamd/rspamd.log | tail -n 3
2026-01-03 10:52:11 #1342(normal) <7a2e1c>; lua; multimap.lua: MULTIMAP_ALLOWLIST_DOMAIN hit for domain vendor.example
2026-01-03 10:54:40 #1342(normal) <11bd77>; lua; multimap.lua: MULTIMAP_ALLOWLIST_IP hit for ip 198.51.100.9
2026-01-03 10:54:45 #1342(normal) <1f33a9>; lua; multimap.lua: MULTIMAP_ALLOWLIST_FROM hit for from billing@vendor.example

Що це означає: Ви вже обходите перевірки для деяких відправників. Це може бути нормально, але це елемент ризику, а не перемога.

Рішення: Якщо allowlisting багато, звужуйте область: віддавайте перевагу allowlist по DKIM або обмежуйте за IP-діапазонами, якими ви контролюєте, і встановлюйте терміни перевірки.

Завдання 11: Підтвердити, що конфіг перезавантажується без помилок

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

Що це означає: Ви не зламали синтаксис. Це не доводить, що політика хороша. Це доводить, що вона не впаде воркери при завантаженні.

Рішення: Лише після проходження configtest робіть reload. Інакше ви налагоджуєте продакшн з зав’язаними очима.

Завдання 12: Перезавантажити Rspamd без перезавантаження машини

cr0x@server:~$ systemctl reload rspamd

cr0x@server:~$ journalctl -u rspamd -n 5 --no-pager
Jan 03 11:02:10 server rspamd[1342]: config reloaded successfully
Jan 03 11:02:10 server rspamd[1342]: workers state: normal workers: 4

Що це означає: Reload пройшов успішно; воркери залишилися в роботі.

Рішення: Негайно перевірте оцінювання на тестовому корпусі повідомлень і відстежуйте рівні відхилень/карантину протягом наступної години.

Завдання 13: Підтвердити, що MTA отримує заголовки з результатами Rspamd

cr0x@server:~$ postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5    48211 Thu Jan  3 11:03:12  billing@vendor.example
                                         ap@yourco.example

cr0x@server:~$ postcat -q A1B2C3D4E5 | egrep -i 'X-Spam|X-Rspamd|Authentication-Results' | head -n 20
X-Spam-Status: No, score=7.50 required=15.00
X-Spam-Action: no action
X-Spam-Score: 7.50
X-Spam-Level: *******
Authentication-Results: mx.yourco.example; dkim=fail header.d=vendor.example; spf=fail smtp.mailfrom=billing@vendor.example; dmarc=fail header.from=vendor.example

Що це означає: Заголовки підтверджують ту ж картину. Якщо заголовки відсутні, ваші хибні спрацьовування можуть бути проблемою політики MTA, а не Rspamd.

Рішення: Якщо MTA діє за іншим сигналом, ніж очікувалось (наприклад, інші milters або перевірки заголовків), вирівняйте конвеєр перед тим, як змінювати оцінювання Rspamd.

Завдання 14: Відстежити кількість дій за короткий інтервал

cr0x@server:~$ grep -oE 'default: [^ ]+ \([^)]*\)' /var/log/rspamd/rspamd.log | tail -n 2000 | sort | uniq -c | sort -nr
  1602 default: F (no action)
   287 default: R (reject)
    91 default: G (greylist)
    20 default: A (add header)

Що це означає: Відхилень доволі багато. Чи це «погано» — залежить від вашого міксу трафіку. Для корпоративної пошти 287 відхилень із останніх 2000 рішень варто дослідити.

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

Жарт 1: Пошта — єдиний продукт, де «доставлюваність» означає «будь ласка, дозвольте цій людині бути перерваною моїм повідомленням».

Розумна стратегія оцінювання: менше змін, більше вимірювань

Коли ви налаштовуєте систему на менше хибних спрацьовувань, ви торгуєтеся між двома режимами відмов:

• Тип I: спам доставлено (дратує, ризиково)
• Тип II: легітимна пошта заблокована (зламує бізнес)

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

Обирайте дії за бізнес-радіусом впливу

Поширені дії й як вони працюють на практиці:

• add_header: найменш ризикований варіант для «можливо спаму». Залишається доставка, але користувачі й SIEM бачать бал. Мінус: користувачі ігноруватимуть заголовки, доки їх не навчити (або ви не маршрутизуватимете на їх основі).
• greylist: підходить для невідомих відправників, але болісний для автоматизованих систем, що не повторюють коректно. Використовуйте, якщо ви можете терпіти затримки і знаєте, що легітимні відправники поводяться як справжні MTA.
• quarantine: зрілий варіант замість reject для спаму середньої впевненості. Зменшує шкоду від хибних спрацьовувань, при цьому тримає сміття подалі від вхідних.
• reject: резервуйте для високої впевненості. Якщо ви відхиляєте пошту з низькою впевненістю, ви створили генератор простоїв, який спрацьовуватиме випадково.

Міняйте оцінювання так само, як зміни у брандмауері

Чотири правила, які тримають вас чесними:

1. Робіть одну зміну за раз, якщо ви не відкочуєте відому погану девелоп-розгортку.
2. Віддавайте перевагу звуженню області над глобальними змінами: по домену, отримувачу, IP, аутентифікованому користувачу.
3. Тримайте тестовий корпус: принаймні 50 відомо-легітимних та 200 відомо-спамних повідомлень (або те, що підходить вашому середовищу). Переоцінюйте до/після.
4. Логовуйте рішення: чому ви змінили символ і яку метрику очікуєте змінити.

Де ховаються хибні спрацьовування: «хороша» пошта, що виглядає як спам

Легітимні повідомлення, які зазвичай накопичують спам-подібні сигнали:

• Постачальники, що надсилають рахунки з нової платформи (нові IP, невідповідність аутентифікації)
• Маркетингові розсилки (багато URL, трекінг, лише HTML, патерни для масової розсилки)
• Повідомлення безпеки (короткий текст + тривожний заголовок + посилання)
• Запрошення в календар і автоматичні повідомлення (дивна структура MIME)
• Переслані листи (SPF ламається; DMARC не проходить, якщо ARC не використовується коректно)

Мета не в тому, щоб видавати їх за «особисті листи». Мета — ідентифікувати їх і трактувати як категорію з власною політикою.

Інструменти цілеспрямованого налаштування: multimap, групи та політика по доменах

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

• Settings (по домену/користувачу/IP/отримувачу) для регулювання дій, застосування змін символів або пропуску перевірок.
• Multimap для allowlist/blacklist на основі заголовків, envelope, IP або інших селекторів.
• Бали символів і групи для балансування суміжних перевірок (аутентифікація, контент, репутація).

Віддавайте перевагу «пом’якшенню» над «відключенням»

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

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

Приклад: налаштування по домену, щоб уникнути відхилення сумнівної пошти

Для домену з високим бізнес-імпактом (наприклад, вашого власного) ви можете обрати карантин при нижчому балі, ніж для reject, зберігаючи reject для явно злочинного спаму.

Ключова практика: використовуйте переоприділення дій, а не повне allowlisting. Нехай система все ще оцінює; просто змініть, що робиться з результатом.

Приклад: multimap allowlist з запобіжними засобами

Якщо потрібно allowlist, робіть це з упором на перевіряєму ідентичність:

• Allowlist домен, підписаний DKIM, якому ви довіряєте (і перевірте стабільність).
• Allowlist IP-діапазон лише якщо відправник опублікував його і це не спільна інфраструктура.
• Уникайте allowlisting за заголовком «From:» або відображуваним іменем, якщо ви не хочете бути фішинговою мішенню.

Жарт 2: Найшвидший спосіб отримати бюджет на фільтрацію спаму — пропустити один фішинговий лист і назвати це «ініціативою навчання користувачів».

Аутентифікація та вирівнювання: SPF, DKIM, DMARC без культів

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

SPF: відмінно, доки пошта не переадресовується

SPF перевіряє IP з’єднання у політиці домену відправника. Пересилання ламає SPF, бо IP пересилювача не авторизований оригінальним відправником. Це не Rspamd «злий»; це природа SPF.

Операційне рішення: якщо у вашому середовищі багато пересилань (аліаси на зовнішні системи, інструменти тикетингу тощо), не трактуйте SPF fail як сигнал для майже відхилення. Збережіть його значущим, але збалансованим.

DKIM: переживає пересилання, але ламається при модифікації

DKIM підписує вміст повідомлення. Розсилки, футери та «корисні» шлюзи, що переписують HTML, можуть ламати DKIM. Ви побачите сплески DKIM fail, коли листувальний сервер змінить поведінку або коли пристрій безпеки почне «очищення» контенту.

Операційне рішення: DKIM fail має бути сильним сигналом у поєднанні з підозрілим контентом або індикаторами спуфінгу, а не окремим молотом.

DMARC: вирівнювання — ось у чому суть, і через це боляче

DMARC перевіряє, чи SPF і/або DKIM вирівняні з доменом у видимому «From:». Це спосіб зупинити очевидний спуфінг. Воно також карає легітимні, але незграбні потоки пошти.

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

ARC: складний друг, який інколи правий

ARC (Authenticated Received Chain) може зберегти результати аутентифікації через посередників. Коли його впроваджено правильно, він зменшує хибні спрацьовування на пересланій пошті. Коли погано — додає більше плутанини.

Операційне рішення: якщо ви бачите багато пересилань і ARC присутній, перевірте, чи ваша збірка та конфіг Rspamd правильно його оцінюють. Якщо ARC регулярно відсутній — це також сигнал.

Bayes і fuzzy: навчання без самопошкодження

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

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

Bayes у Rspamd може навчатися на повідомленнях, які ви маркуєте як ham/spam. Пастка хибних спрацьовувань виникає, коли:

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

Fuzzy: вузька область, висока впевненість

Fuzzy краще працює, коли ви хешуєте елементи з високим сигналом: відомі шаблони спаму, відомі фішингові набори, повторювані payload-и. Найгірше воно працює, коли ви хешуєте загальні бізнес-шаблони (рахунки, сповіщення про доставку), бо врешті-решт ви хешуєте себе у відхилення половини інтернету.

Запобіжні заходи, які слід вжити

• Вимагайте ручного перегляду для тренувальних наборів, які використовуються для зміни поведінки Bayes/fuzzy.
• Розділяйте навчання корпоративної пошти та масових розсилок, якщо можете. Масова пошта (навіть легітимна) має спільні риси зі спамом.
• Моніторьте розподіл впевненості Bayes, а не лише «спійманий спам». Модель Bayes, яка завжди невпевнена, часто або голодує, або забруднена.

Продуктивність і зворотний тиск: коли фільтрація породжує хибні спрацьовування

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

Rspamd виконує кілька перевірок: DNS-запити, запити до Redis, вилучення URL, парсинг MIME, запити зовнішніх репутацій. Коли залежні сервіси повільні, деякі перевірки таймаутяться. Залежно від конфігурації ви можете отримати:

• Відсутні негативні сигнали (спам проходить).
• Відсутні позитивні сигнали (легітимна пошта втрачає «дозволяючі» бали й піднімається в оцінці).
• ПовFallback-поведінка, що є консервативною (наприклад, тимчасові відмови трактуються як підозрілі).

Що моніторити, що корелює з хибними спрацьовуваннями

• Латентність DNS-запитів і частоту помилок
• Латентність Redis, викиди, проблеми персистентності
• CPU-час воркерів Rspamd проти реального часу (virtual vs real у логах)
• Кількість DNS-запитів на повідомлення (сплески можуть вказувати на кампанію з великою кількістю URL)

Шаблон проєктування: «карантин при невизначеності»

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

Три корпоративні міні-історії з поля бою

Міні-історія 1: Інцидент через невірне припущення

Середня компанія запустила Rspamd за шлюзом Postfix. У них була проста політика: все, що перевищує поріг reject, відштовхується. Хтось припустив, що «reject означає безпечніше», тож понизив reject з консервативного значення до ближчого до порога add_header. Зміна зайшла у п’ятницю. Звісно.

В понеділок фінанси поскаржилися, що постачальницькі перекази «не надходять». Пошта не затримувалася; її відхилили. Повідомлення про відмову йшли на неактивний ящик, бо постачальник використав no-reply адресу. Тож постачальник не знав, фінанси не знали, а шлюз тихо робив саме те, що йому сказали.

Коли ми взяли вибірку відхилених повідомлень, більшість були чистими, але мали проблеми вирівнювання DMARC, бо постачальник перейшов на нову платформу й неправильно налаштував DKIM. Rspamd не був параноїдальною; він просто був послідовним. Помилка була в припущенні, що поріг reject — це просто «лінія спаму». Це насправді «лінія бізнесового простою».

Виправлення було нудним і ефективним: відновили консервативний поріг reject, направили пошту середньої впевненості в карантин і створили процес онбордингу постачальників, який перевіряє SPF/DKIM/DMARC перед першим надходженням рахунку.

Міні-історія 2: Оптимізація, що відігралася проти

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

У продакшні новий резолвер інколи лімітував запити або відкидав їх під навантаженням. Логи Rspamd почали показувати довші «real» часи і менше успішних пошуків ключів DKIM та SPF. Курйоз у тому, що спам почав проходити і легітимна пошта почала набирати вищі бали — бо «дозволяючі» символи не присуджувалися послідовно.

Інцидент проявився як «Rspamd поводиться непослідовно». Насправді він не поводився — поводилася залежність. Після відкату змін резолвера вони додали локальний кешуючий резолвер у тій же мережі хоста, підвищили таймаути до здорових значень і моніторили частоту помилок DNS як ключову метрику. Латентність покращилася і хибні спрацьовування впали без торкань балів.

Урок: оптимізації продуктивності залежностей — це приховані зміни політики. Ставтесь до них з таким же контролем змін, як до порогів спаму.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Глобальна компанія мала рутину, що виглядала бюрократично: щоквартально вони переглядали топ-20 символів за сумарним внеском у бали і топ-20 доменів відправників, чиї повідомлення були відхилені. Жодних подвигів. Просто нудні звіти, коротка нарада і список задач.

Одного кварталу вони помітили поступове зростання відхилень, пов’язаних з DMARC, від легітимного SaaS-провайдера, якого використовував HR. До того, як це перетворилось на кризу, вони відкрили кейс у провайдера, надали докази збоїв аутентифікації і тимчасово застосували політику по відправнику, що поміщала повідомлення в карантин замість відхилення. HR нічого не помітив.

Через два тижні провайдер виправив вирівнювання DKIM. Компанія зняла тимчасове виключення. Ніяких рубців у allowlist, ніяких гнівних виконавців, ніяких «чому ви не сказали».

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

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

Симптом: Легітимна пошта відхиляється з високими балами, домінують символи аутентифікації.

Корінна причина: Відправник неправильно налаштував SPF/DKIM/DMARC, або пересилання/розсилки ламають вирівнювання.

Виправлення: Звужуйте політику: карантин замість reject для цього відправника, і вимагайте від відправника виправити вирівнювання. Уникайте глобального зниження балів DMARC/DKIM.

Симптом: Хибні спрацьовування різко зростають разом зі збільшенням «DNS req» у логах.

Корінна причина: Латентність/помилки резолвера DNS викликають непослідовні результати перевірок.

Виправлення: Стабілізуйте DNS (локальний кеш, адекватні таймаути, масштаб). Потім переоцініть оцінювання.

Симптом: Bayes раптом маркує загальний бізнес-шаблон як спам у кількох відділах.

Корінна причина: Неправильні вхідні для навчання (користувачі маркують небажану, але легітимну масову пошту як спам), або autolearn занадто агресивний.

Виправлення: Перегляньте pipeline навчання; зменшіть autolearn; перенавчіть на курованих наборах; розділіть обробку масової пошти.

Симптом: Ви «виправляєте» хибні спрацьовування, піднявши поріг reject, і вже за кілька днів вхідні наповнені спамом.

Корінна причина: Ви змінили неправильний контроль; дисбаланс символів залишився.

Виправлення: Відкотіть зміну порогу; знайдіть топ-символи в хибних спрацьовуваннях; налаштуйте/звузьте їх; додайте рівень карантину.

Симптом: Лист від одного внутрішнього додатку постійно маркується, а зовнішні листи — ні.

Корінна причина: Додаток генерує некоректний MIME, тільки HTML, відсутні Date/Message-ID або використовує спільну вихідну інфраструктуру з поганою репутацією.

Виправлення: Виправте генерацію листів у додатку (правильні заголовки, текстова частина, стабільний DKIM). Якщо потрібно, додайте політику по IP з мінімальним пом’якшенням під час ремонту.

Симптом: Логи Rspamd показують нормальне оцінювання, але MTA все одно відхиляє або перенаправляє пошту.

Корінна причина: Інший фільтр/milter/перевірка заголовків діє, або MTA неправильно інтерпретує заголовки.

Виправлення: Прослідкуйте конвеєр; підтвердьте, що політика MTA відображає дії Rspamd; видаліть конфліктні перевірки або вирівняйте рішення.

Симптом: Випадкові зміни класифікації після перезапуску Redis або події з тиском пам’яті.

Корінна причина: Redis викинув Bayes/fuzzy/метадані; стан моделі змінився.

Виправлення: Забезпечте запас пам’яті; уникайте викидів; розділіть інстанси Redis; підтвердіть стратегію персистентності; моніторте evicted_keys.

Симптом: Allowlisting «вирішує» проблему, але фішингові листи починають проходити повз фільтри.

Корінна причина: Allowlist за слабкими ідентифікаторами (заголовок From, домен без DKIM) або занадто широкі IP-діапазони.

Виправлення: Замініть широкі allowlist на звужені налаштування з сильними перевірками ідентичності; використовуйте терміни й періодичний перегляд.

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

Покроково: безпечно зменшити хибні спрацьовування (не відчиняючи ворота для спаму)

1. Зберіть докази: 20–50 хибних спрацьовувань з повними заголовками та розбором символів Rspamd.
2. Класифікуйте за типом трафіку: персональна пошта, транзакційні листи від постачальників, масові/маркетингові, системні сповіщення, розсилки.
3. Визначте повторювані топ-символи у хибних спрацьовуваннях (топ-3 для кожного повідомлення; агрегована частота).
4. Підтвердіть здоров’я залежностей: DNS, Redis, завантаження CPU, латентність воркерів.
5. Виберіть найменш ризикований міра:
   • Переоприділення дії по відправнику або домену (карантин замість reject).
   • Змінити один символ незначно (маленькі дельти, наприклад -0.5, а не -3.5).
   • Виправити аутентифікацію відправника або формування внутрішньої пошти.
6. Перепроранкуйте тестовий корпус за допомогою rspamc перед розгортанням змін.
7. Розгорніть через reload, не restart, і перевірте логи на успішний reload конфігу.
8. Моніторьте рівні дій (reject/quarantine/greylist/add_header) принаймні один бізнес-день.
9. Підстрахуйтеся карантином для середньої впевненості, поки метрики стабілізуються.
10. Документуйте винятки з власниками і датами перегляду.

Контрольний список: що має бути на місці перед налаштуванням

• Карантин або принаймні шлях відновлення для хибних спрацьовувань
• Централізоване логування і можливість пошуку по Message-ID/queue ID
• Курований корпус ham/spam для регресійного тестування
• Дашборди для латентності DNS, викидів Redis, латентності воркерів Rspamd
• Журнал змін для змін балів/налаштувань (коментарі в комітах важливі)

Список: «не робіть цього»

• Не вимикайте DMARC/DKIM/SPF глобально через одного постачальника, який не може налаштувати пошту.
• Не allowlist за заголовком From сам по собі.
• Не налаштовуйте під час відмови залежностей (DNS/Redis) і называйте це «політикою».
• Не встановлюйте пороги reject близько до add_header в бізнес-поштових середовищах.
• Не дозволяйте autolearn агресивно без готовності аудиту вхідних даних.

Поширені питання

1) Чи варто вирішувати хибні спрацьовування підняттям порогу reject?

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

2) Яка найбезпечніша конфігурація дій для корпоративної пошти?

Зазвичай: add_header для низької підозри, quarantine для середньої, reject для високої. Greylisting може працювати, але додає затримки і крихкість для автоматизованих відправників.

3) Постачальник постійно не проходить DKIM і DMARC. Чи allowlist його?

Краще звужена політика: карантин замість reject для домену відправника і збереження оцінювання. Якщо треба allowlist — робіть це максимально вузько (стабільна DKIM-ідентичність або суворий IP-діапазон) і встановіть дату перегляду.

4) Чому розсилки призводять до хибних спрацьовувань?

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

5) Як зрозуміти, який символ «неправильний»?

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

6) Чи може Bayes спричиняти хибні спрацьовування, навіть якщо все інше в порядку?

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

7) Чому хибні спрацьовування погіршуються, коли Redis під тиском пам’яті?

Викиди видаляють навчений стан і кеші. Це змінює ймовірності Bayes і поведінку fuzzy/reputation. Система стає менш послідовною, що здається «випадковими» змінами класифікації.

8) Чи корисний ще greylisting?

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

9) Як налаштовувати, не пропускаючи більше спаму?

Звужуйте зміни (по відправнику/домену), віддавайте перевагу карантину при невизначеності і тримайте регресійний корпус. Не послаблюйте глобальні символи аутентифікації без сильних компенсаторних контролів.

10) Який хороший індикатор, що проблема не в оцінюванні, а в інфраструктурі?

Коли патерни символів змінюються разом з таймаутами, помилками DNS або викидами Redis, і коли «real time» у логах зростає, а «virtual time» залишається низьким. Спочатку виправляйте залежності.

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

Якщо ви зробите лише кілька дій, зробіть ці:

1. Зберіть невеликий корпус хибних спрацьовувань з повними заголовками та розбором символів Rspamd. Перестаньте налаштовувати за анекдотами.
2. Впровадьте карантин для середньої впевненості, щоб можна було відновити помилки без бізнес-наслідків.
3. Аудит здоров’я залежностей: DNS і Redis маскують проблеми як помилки оцінювання.
4. Налаштовуйте через звуження: налаштування по домену/відправнику частіше кращі за глобальне зниження балів.
5. Встановіть нудний щоквартальний огляд топ-символів і топ-відхилених відправників. Це найдешевша робота з підвищення надійності.

Хибні спрацьовування — не містика. Це сигнал, що ваше середовище змінилося, ваше припущення було неправильним або залежності хиткі. Ставтеся до них як до операційної проблеми, а не як до забобонів, і Rspamd поводитиметься як належить.