Електронна пошта: приплив вхідного спаму — вижити під час атаки, не блокуючи реальних користувачів

З чим ви боретеся (і з чим ні)

Приплив вхідного спаму — це не «хтось надіслав нам спам». Це проблема пропускної здатності та справедливості, яка приходить через SMTP.
Атакуючому (або некоректно налаштованому масовому відправнику, або скомпрометованому ботнету) не потрібно бути винахідливим. Потрібно бути численним і наполегливим настільки, щоб ваша поштова лінія спіткнулася.

Режими відмов, які реально вас кладуть

• Роздування черги: ваш MTA приймає повідомлення швидше, ніж може їх обробити (фільтрація, DNS-запити, доставка), тож черга зростає, поки не з’явиться тиск на диск або інодіни.
• Колапс CPU: контент-фільтрація (AV, оцінка спаму, розпакування) стає найгарячішим шляхом. Один поганий тип вкладення може перетворитися на бомбу форків обчислень.
• Посилення затримки DNS: кожна перевірка SPF/DKIM/DMARC і RBL-пошук множиться на вхідні з’єднання. Повільний резольвер = повільне все.
• Виснаження таблиці з’єднань: занадто багато одночасних SMTP-сеансів; ядро та MTA починають скидати легітимні з’єднання.
• Зворотні відскоки й повторні спроби: якщо ви приймаєте, а потім відхиляєте, ви генеруєте бенси або примушуєте до повторів; ви самі стаєте частиною проблеми, і ваша черга залишається гарячою годинами.
• Ложні спрацьовування: «виправлення» блокує клієнтів, партнерські системи та скидання пароля. Так інциденти доходять до керівництва.

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

Одна цитата варта теґа на моніторі: Надія — це не стратегія. — Джин Кранц.
Припливи спаму — це місце, де «ми просто подивимось» помирає.

Жарт №1: Електронна пошта — єдиний протокол, де «Спробуйте пізніше» є легітимним бізнес-процесом.

Цікаві факти та трохи історії

Припливи спаму відчуваються сучасними, але екосистема розвивалася десятиліттями. Ось конкретні моменти, що впливають на сучасний захист:

1. SMTP передував спаму за своєю конструкцією: початкова модель припускала співпрацюючі хости, тому багато контролів — надбудови, а не вбудовані.
2. Відкриті ретранслятори були великим раннім вектором спаму: широка зловживаність у 1990-х змусила MTА за замовчуванням закрити ретрансляцію.
3. DNSBL/RBL стали популярними, бо були дешевими: один DNS-запит міг замінити дорогий скан контенту для очевидно поганих джерел.
4. Greylisting виник як економічний інструмент: затримайте першу спробу, і багато спам-ботів неправильно повторюють спробу, тоді як справжні MTA повторять.
5. SPF створили для зупинки спуфінгу envelope-from: він допомагає, але не доводить, що за цим стоїть людина; він підтверджує право домену використовувати шлях.
6. DKIM зробив автентифікацію повідомлень масштабованою: підписування контенту в заголовках дозволяє отримувачам перевіряти цілісність без спільних секретів.
7. DMARC додав політику та звітність: це шар примусу й видимості, а не чарівна кнопка «ні спаму».
8. Ботнети змінили шаблони обсягу спаму: замість кількох великих джерел з’являється багато малопотужних джерел, що оминають прості пороги по IP.
9. Сканування контенту ускладнилося з часом: сучасний спам використовує вкладені архіви, дивні кодування і пастки в «документах», які дорого розпакувати.

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

Коли наплив вдаряє, у вас немає часу на архітектурні дебати. Потрібно знайти вузьке місце за кілька хвилин.
Ця послідовність орієнтована на Linux MTA (Postfix, Exim) з типовими стеком фільтрів, але підхід застосовний і до Exchange та хостованих шлюзів.

Перше: відкидаємо рано чи приймаємо і тонуємо пізніше?

• Перевірте швидкість входу SMTP-сесій та одночасні з’єднання.
• Перевірте, чи зростає черга вхідна, активна, відкладена чи на утриманні.
• Перевірте співвідношення приймань 2xx до відмов 4xx/5xx.

Друге: який ресурс зараз насичений?

• CPU: робочі процеси спаму/AV завантажені, load зростає, багато контекстних переключень.
• Диск: директорія черги на повільному сховищі; iowait стрибає; виснаження інодін.
• DNS: затримки резольвера; багато вихідних DNS-запитів; таймаути блокують SMTP-сеанси.
• Мережа: backlog SYN; вичерпання conntrack; upstream-ліміти.

Третє: який найдешевший важіль дає час без блокування реальних користувачів?

• Підвищіть тертя для зловмисних відправників (обмеження з’єднань, tarpitting, postscreen, greylisting).
• Зменшіть вартість обробки (пропустіть дорогі скани для очевидно поганих; кешуйте DNS; віддавайте перевагу RBL-перевіркам).
• Захистіть критичні потоки (allowlist для відомих партнерів; окремий MX або порт/IP для транзакційної пошти).

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

Дванадцять+ практичних завдань: команди, виводи та рішення

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

Завдання 1: Виміряйте розмір і форму черги (Postfix)

cr0x@server:~$ mailq | tail -n 5
-- 12437 Kbytes in 1832 Requests.

Що це означає: У вас 1 832 повідомлення в черзі; важливіший саме рахунок повідомлень (операційні витрати на обробку кожного повідомлення).

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

Завдання 2: Знайдіть топові IP, що штурмують ваш SMTP

cr0x@server:~$ sudo ss -tn sport = :25 | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  312 203.0.113.55
  287 198.51.100.22
  190 192.0.2.77

Що це означає: Кілька IP займають сесії. Це можуть бути боти або зламаний масовий відправник.

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

Завдання 3: Визначте, чи витрачаєте час на DNS-запити

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "10 min ago" | tail -n 6
Jan 04 10:11:20 mx1 systemd-resolved[642]: Transaction 49231 for 55.113.0.203.zen.spamhaus.org. IN A timed out
Jan 04 10:11:20 mx1 systemd-resolved[642]: Transaction 49232 for 22.100.51.198.zen.spamhaus.org. IN A timed out

Що це означає: RBL-пошуки таймаутяться. Ваш MTA затримується, сеанси залишаються відкритими, конкуренція зростає, черга наростає.

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

Завдання 4: Перевірте CPU та iowait (це обчислення чи диск?)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          28.14    0.00    9.83   34.76    0.00   27.27

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  %util
nvme0n1         12.0   420.0    96.0  8120.0    8.40   98.0

Що це означає: Високий iowait і завантаження диска. Обмеження — I/O черги.

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

Завдання 5: Перевірте тиск на іноді (чергові директорії можуть помирати через іноди)

cr0x@server:~$ df -ih /var/spool/postfix
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2        2.0M  1.9M  120K   95% /

Що це означає: Ви близькі до виснаження інодін. Навіть при вільному місці неможливо створити нові файли. MTA це ненавидять.

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

Завдання 6: З’ясуйте, який стан черги вибухає (Postfix queue IDs)

cr0x@server:~$ sudo qshape deferred | head
T  5 10 20 40 80 160 320 640 1280 2560 5120 10240 20480 40960
5  0  2  3  6 15  44  98 210  380  390  230    54     0     0

Що це означає: Зростає deferred: помилки віддаленої доставки, greylisting в інших місцях або ваш вихідний шлях закупорений.

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

Завдання 7: Перевірте тиск процесів Postfix

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_client_connection_count_limit|default_process_limit|smtpd_client_message_rate_limit'
default_process_limit = 200
smtpd_client_connection_count_limit = 20
smtpd_client_message_rate_limit = 100

Що це означає: Дозволяєте 20 одночасних з’єднань на клієнта і 100 повідомлень/хв на клієнта; глобальний ліміт процесів 200.

Рішення: Під час напливу зменшіть конкуренцію на клієнта (боти виграють від паралелізму). Збільшуйте глобальний ліміт лише якщо CPU/диск це витримають; інакше ви лише посилите крах.

Завдання 8: Швидко порахуйте відмови проти прийомів у логах

cr0x@server:~$ sudo awk '{print $6}' /var/log/mail.log | grep -E 'reject:|status=sent|status=deferred' | head
reject:
status=sent
status=deferred

Що це означає: Груба вибірка. Потрібні пропорції.

Рішення: Якщо відмови низькі, а черга зростає — ви занадто дозволяєте на SMTP-етапі. Додайте дешеві відмови (RBL, postscreen, строгий HELO) і зменшіть дорогі скани.

Завдання 9: Витягніть топ отримувачів, яких атакують (захистіть їх)

cr0x@server:~$ sudo grep -h "to=<" /var/log/mail.log | sed -n 's/.*to=<\([^>]*\)>.*/\1/p' | cut -d, -f1 | sort | uniq -c | sort -nr | head
  842 info@
  731 sales@
  690 support@

Що це означає: Під ударом — загальні скриньки.

Рішення: Застосуйте контроль за отримувачами: суворіше фільтрування для catch-all/загальних, окремий MX для публічних псевдонімів, або вимагайте captcha/платформу для прийому на певні адреси (бізнес-рішення).

Завдання 10: Перевірте витрати та збої TLS-рукопотиску (спам любить дорогі рукопотиски)

cr0x@server:~$ sudo grep -h "TLS" /var/log/mail.log | tail -n 5
Jan 04 10:12:01 mx1 postfix/smtpd[23102]: TLS handshake failed: SSL_accept error from 203.0.113.55: -1
Jan 04 10:12:02 mx1 postfix/smtpd[23108]: Anonymous TLS connection established from 198.51.100.22: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384

Що це означає: Збої рукопотиску можуть споживати CPU; успішний TLS — добре, але важкі TLS-політики можуть бути використані спамерами, що можуть дозволити собі CPU.

Рішення: Тримайте TLS увімкненим, але додайте postscreen/контроль з’єднань, щоб не витрачати криптопроцеси на очевидний непотріб.

Завдання 11: Переконайтеся, що кеш резольвера працює

cr0x@server:~$ resolvectl statistics | head -n 12
Transactions:           98422
Cache Hits:             61210
Cache Misses:           37212
DNSSEC Verdicts Secure: 0

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

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

Завдання 12: Перевірте накопичення завдань ClamAV чи контент-сканера (приклад)

cr0x@server:~$ systemctl status clamav-daemon --no-pager | sed -n '1,12p'
● clamav-daemon.service - Clam AntiVirus userspace daemon
     Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled)
     Active: active (running) since Thu 2026-01-04 09:41:22 UTC; 30min ago
     Docs: man:clamd(8)
   Main PID: 1432 (clamd)
      Tasks: 42 (limit: 18956)
     Memory: 1.1G
        CPU: 18min 10.221s

Що це означає: Сканер працює, споживає CPU, з багатьма задачами. Не доводить швидкість обробки сама по собі.

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

Завдання 13: Подивіться, чи ядро скидає з’єднання

cr0x@server:~$ netstat -s | egrep -i 'listen|overflow|drops' | head
    2489 times the listen queue of a socket overflowed
    2489 SYNs to LISTEN sockets dropped

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

Рішення: Збільшіть backlog і налаштуйте ядро, але тільки після застосування обмежень на рівні MTA; інакше ви просто приймаєте більше болю.

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

cr0x@server:~$ sudo postcat -q 3F2A1C2B9E | sed -n '1,25p'
*** ENVELOPE RECORDS active ***
message_size: 28412              452             1               0               28412
sender: spammer@example.net
*** MESSAGE CONTENTS ***
Received: from unknown (HELO user) (203.0.113.55)
Subject: Invoice attached

Що це означає: Ви бачите шаблони: поганий HELO, підозрілі теми, повторювані джерела.

Рішення: Перетворіть шаблони на дешеві правила на рівні SMTP (обмеження HELO, postscreen, RBL), а не на важкі післяприйомні скани.

Жарт №2: Найшвидший спам-фільтр — це код відповіді 554. Це також єдиний, що ніколи не потребує оновлення підпису.

Контролюйте радіус ураження: ключові горлечка

Під час напливу ви не «боретеся зі спамом». Ви контролюєте споживання ресурсів. Ваш MTA — по суті конвеєр:
прийняти з’єднання → домовитися → прийняти повідомлення → виконати перевірки → поставити в чергу → доставити → повторити при необхідності.
Будь-який етап, що повільний, стає скупченням позаду нього.

1) Обробка з’єднань: зменште дорогі діалоги

Найбільш недооцінений захист — зробити вхідні SMTP-з’єднання нудними й дешевими. Більшість припливів спаму спираються на те, що ви виконуєте роботу:
TLS-рукопотиски, затримки банерів, політичні перевірки, контент-фільтри. Ваше завдання — робити менше роботи для підозрілих відправників.

• Обмеження конкурентності на клієнта: боти люблять паралельні сесії. Легітимні MTA зазвичай поводяться передбачувано.
• Обмеження швидкості з’єднань: лімітуйте нові з’єднання на вікно часу за IP/підмережу.
• Postscreen (Postfix): тримайте SMTP-демон подалі від очевидного сміття, поки клієнт не доведе базову компетентність.
• Tarpitting: додавайте невелику затримку для підозрілих клієнтів. Не занадто велику — хвилини це самоушкодження.

2) Відмова на рівні SMTP: не приймайте те, що вже знаєте, що відхилите

Якщо ви приймаєте повідомлення, а потім вирішуєте, що це спам, ви вже заплатили вартість: I/O на диск, елементи черги, час сканування,
і часто шторм повторних спроб. Відкидайте під час connect/helo/mail-from/rcpt-to коли це можливо.

• Блокуйте недійсні патерни HELO/EHLO: «HELO user» від публічної IP рідко є серйозним поштовим сервером.
• Вимагайте адекватного envelope sender де це доречно.
• Використовуйте RBL обережно: один надійний список кращий за п’ять ненадійних, що таймаутяться.
• Валідація отримувачів: відкидайте невідомих отримувачів на рівні SMTP, щоб уникнути backscatter і росту черги.

3) Справедливість для реальних користувачів: захищайте важливих відправників і отримувачів

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

• Allowlist партнерів на рівні шлюзу (IP-діапазони, аутентифіковані джерела або відомі домени зі стійкою інфраструктурою).
• Окремий вхідний MX: публічний MX, що поглинає сміття, і захищений канал для транзакційного/партнерського трафіку.
• Різні політики для отримувачів: керівники та адреси для скидання пароля заслуговують низької затримки й більшої довіри.

Стратегія фільтрації під час напливу: пріоритет потоку над досконалістю

Сканування контенту — це місце, де добрі наміри вичерпують 100% CPU. У нормальний час ви можете дозволити розпаковувати вкладення,
запускати AV, робити нечітке хешування і обчислювати складні спам-оцінки. Під час напливу кожна додаткова мілісекунда множиться.

Спочатку репутація, потім контент

Почніть з дешевих сигналів, що обриваються рано:

• Репутація IP і базова протокольна коректність: postscreen, RBL, неправильне конвеювання команд, надто багато помилок.
• Політика конверту: відхиляйте неіснуючих отримувачів; обмежуйте кількість отримувачів на повідомлення; блокуйте очевидні підроблені локальні домени.
• Перевірки аутентифікації: результати SPF/DMARC можна використовувати для оцінки або відхилення для доменів з високим ризиком, але остерігайтеся залежності від DNS.

Коли використовувати greylisting (і коли це пастка)

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

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

DMARC/SPF/DKIM під час шторми

Ці перевірки допомагають, але не дозволяйте їм стати вашим вузьким місцем:

• SPF: відмінний для усунення очевидних підроблень, але важкий для DNS. Кешуйте результати і ставте короткі таймаути.
• DKIM: валідація зазвичай має помірну вартість, але зламані підписи поширені; ставтеся до невдач як до сигналу, а не завжди як до відмови.
• DMARC: потужний для доменів з жорсткою політикою. Для інших це здебільшого оцінка й звітність.

Відкласти чи відхилити: оберіть свій біль

4xx тимчасова помилка каже легітимним MTA повторити пізніше. Спамери теж повторюють, але багато хто робить це погано. 5xx відмова чистіша і дешевша,
але підвищує ризик блокування реального повідомлення через помилку.

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

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

Припливи спаму часто діагностують як «проблему пошти», а вирішують як «проблему сховища». Директорії черги — це пекло з дрібних файлів:
тисячі малих записів, fsync-шаблони, пошуки в директоріях і метадані. Ваш крутий NVMe допомагає; ваша перевантажена мережна файловая система — ні.

Основи архітектури черги (чому боляче)

Більшість MTA зберігають кожне повідомлення як кілька файлів (конверт, вміст, стан deferred). Під великим навантаженням:

• Операції з директоріями домінують (створення, перейменування, unlink).
• Витрати журналювання стають видимими.
• Іноди швидко витрачаються.
• Агенти резервного копіювання, антивірус при доступі чи індексуючі інструменти можуть перетворити директорію черги на повільну трагедію.

Практичні рішення для сховища, які допомагають під час напливу

• Тримайте спул на локальному швидкому сховищі: не NFS, не «той спільний SAN, який усі використовують». Локальний NVMe або SSD — нудний, але правильний вибір.
• Розділяйте спул і об’ємні логи: уникайте конкуренції з ротацією логів або відправкою логів.
• Слідкуйте за використанням інодін: оповіщення лише по місцю на диску пропускають цю помилку повністю.
• Мінімізуйте синхронні записи там, де це безпечно: обережно з опціями монтування; надійність важлива, але часто можна тонко налаштувати без «обману» файлової системи.
• Майте готові інструменти очищення черги: під час напливу ви не хочете писати одноразовий скрипт під тиском.

Керування чергою — це реагування на інциденти, а не прибирання

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

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

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

Середній SaaS працював на парі поштових шлюзів і окремій системі тікетів. У них був пристойний фільтр і вони вважали, що захищені, бо «поперед нас стоїть хмарний провайдер».
Хибне припущення полягало в тому, що провайдер поглине будь-який наплив і переадресує лише «реальну пошту».

Наплив прийшов повільно: тисячі дрібних повідомлень за хвилину, здебільшого на support@ і info@.
Провайдер їх доставляв, бо вони технічно були коректними SMTP і не явно шкідливими.
Локальні шлюзи приймали їх і передавали на контент-сканування. Сканери не падали; вони просто уповільнювалися. Черга росла. Диск iowait зростав.

Реальні клієнтські листи почали таймаутитися. Пошта для скидання пароля (також вхідні відповіді і бенси) затримувалися.
Команда підтримки просила клієнтів «користуватися чатом». Постачальник чату обмежував їх. Так інциденти набувають ходи.

Вирішення не було «купити більше фільтрації». Воно полягало в тому, щоб перенести відхилення вперед: валідація отримувачів на рівні SMTP, суворі ліміти на клієнта і gating у стилі postscreen.
Потім вони створили захищений шлях для важливої вхідної пошти: партнери і транзакційні відповіді мали окремий MX з allowlist.

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

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

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

Під час хвилі спаму «оптимізація» стала множником. Через більшу конкуренцію вони приймали більше повідомлень за секунду і миттєво скидали їх на диск і сканери.
Сканери наситили CPU. Диск наситився IOPS. Затримка зросла, що тримало SMTP-сеанси відкритими довше, що ще більше підвищувало конкуренцію.
Система не вибухнула; вона повільно задихалась.

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

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

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

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

Фінансова організація мала репутацію повільності в змінах і настирливо прискіпливого ставлення до runbook’ів. Вони також серйозно ставилися до чергування on-call.
Це не робило їх популярними на afterwork, але робило поштову систему стійкою.

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

Коли наплив вдарив, on-call не імпровізував. Вони переключили інцидентний режим, спостерігали стабілізацію черги, а потім вибірково пом’якшили правила для партнера,
чия пошта потрапляла під надто агресивну HELO-перевірку. Цьому партнеру дали allowlist з тикетом на термін дії.

Бізнес-імпакт обмежився затримками для низькоприоритетних вхідних скриньок. Керівництво цього не помітило.
Пізніше команда переглянула логи, знайшла основні ASN ботнету і оновила довгострокову політику.

Урок: «нудне» — це фіча. Попередньо затверджені ручки й моніторинг фундаментальних речей перемагають героїчні вчинки.

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

Фаза 0: Перед напливом (це ви не робитимете під час напливу)

1. Інструментуйте конвеєр: розмір черги, розподіл віку черги, швидкість SMTP-сеансів, кількість відмов/приймань, затримка DNS, диск iowait, CPU на фільтр.
2. Розділяйте ролі: вхідний MX не має бути тією ж машиною, що виконує несумісні важкі завдання. Пошта хоче передбачуваних ресурсів.
3. Побудуйте політичний набір для інцидентів: відомо-робоча, попередньо протестована конфігурація «режим шторму», яку можна швидко включити.
4. Підтримуйте allowlist з власниками: кожен запис allowlist має мати причину й план закінчення дії.
5. Знайте критичні поштові потоки: скидання пароля, білінг, інтеграції з партнерами, юридичні повідомлення. Ідентифікуйте отримувачів і IP/домени відправників.

Фаза 1: Перші 15 хвилин (стабілізація)

1. Підтвердіть, що це вхідний трафік: перевірте швидкість SMTP-з’єднань і зростання вхідної черги.
2. Визначте вузьке місце: CPU проти диска проти DNS проти скидів ядра.
3. Увімкніть режим шторму: зменшіть конкуренцію на клієнта, увімкніть postscreen/tarpit/greylisting вибірково, посиліть використання RBL.
4. Захистіть критичних відправників: додайте тимчасові allowlist для відомих транзакційних провайдерів і ключових партнерів, якщо їх зачіпає політика.
5. Припиніть приймати те, що не можете обробити: віддавайте перевагу раннім відмовам; якщо потрібно — тимчасово 4xx для підозрілих джерел, щоб зберегти сервіс.

Фаза 2: Наступна година (відновити потік)

1. Зменшіть дорогі скани: відключіть глибоку рекурсію архівів, обмежте розміри вкладень для неаутентифікованих/ненадійних джерел, і переконайтеся, що «fail closed» використовується лише там, де це потрібно.
2. Виправте DNS: локальний кешуючий резольвер, налаштуйте таймаути, і скоротіть кількість DNS-перевірок на повідомлення.
3. Керуйте чергою: пріоритезуйте легітимну пошту і розгляньте карантин для очевидного трафіку напливу.
4. Комунікуйте: повідомте підтримку, що затримується, що безпечно, і які альтернативні канали існують, не обіцяючи чудес.

Фаза 3: Після стабілізації (очищення й загартування)

1. Приберіть тимчасові блоки з тикетом і перевіркою строку дії.
2. Квантифікуйте ложні спрацьовування: вибірково перевіряйте карантин/відхилену пошту, коригуйте правила.
3. План потужності: виміряйте пікові швидкості прийому й пропускну здатність сканування; вирішіть, куди вкладати (обчислення, сховище або upstream-фільтрація).
4. Документуйте що спрацювало, що ні, і які ручки були надто ризиковані.

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

1) Симптом: черга росте, CPU в нормі, iowait високий

Корінна причина: черга на повільному/контендованому сховищі; багато операцій з дрібними файлами; тиск інодін; можливо антивірус сканує директорію черги при доступі.

Виправлення: перемістіть спул на швидкий локальний диск; виключіть спул із on-access сканування; зменшіть швидкість прийому за допомогою відмов на рівні SMTP; моніторьте іноди.

2) Симптом: багато SMTP-сеансів зависло, мало відмов, таймаути в логах

Корінна причина: DNS-запити таймаутяться (RBL/SPF/DMARC), що змушує сеанси чекати; резольвер перевантажений або upstream блокує.

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

3) Симптом: spike load, процеси сканера множаться, доставки повільні

Корінна причина: контент-сканування — вузьке місце (AV/оцінка спаму, рекурсія архівів, витяг PDF/Office).

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

4) Симптом: легітимна партнерська пошта заблокована після посилення правил

Корінна причина: грубе використання RBL, суворі HELO-перевірки або агресивний greylisting без винятків.

Виправлення: додайте allowlist з власником; використовуйте мультисигнальну оцінку замість відмов по одному правилу; greylist тільки підозрілі джерела; тестуйте зміни на вибірці трафіку партнерів.

5) Симптом: ядро повідомляє про SYN-дропи / overflow listen queue

Корінна причина: потік з’єднань; недостатній backlog; MTA не приймає достатньо швидко; занадто багато одночасних SMTP-сеансів.

Виправлення: спочатку обмеження на рівні MTA; потім тонке налаштування backlog ядра; розгляньте upstream-фільтрацію або TCP-рівневий захист, якщо доступно.

6) Симптом: вихідна пошта затримується під час вхідного напливу

Корінна причина: спільні ресурси (та сама черга/диск/CPU) і шторм повторів; процеси доставки вихідної пошти голодують.

Виправлення: розділіть ролі inbound/outbound або принаймні розділіть черги; обмежте повтори вихідної пошти; переконайтеся, що вхідні відмови запобігають марному росту черги.

7) Симптом: ви бачите багато бенсів, які не планували надсилати

Корінна причина: приймаєте спам і потім відхиляєте або генеруєте DSN на підроблені відправники (backscatter).

Виправлення: відкидайте на рівні SMTP; перевіряйте отримувачів під час RCPT TO; уникайте генерації DSN для неаутентифікованих вхідних, де це можливо.

FAQ

1) Чи варто просто блокувати цілі країни або ASN під час напливу?

Тільки якщо бізнес-потреби дозволяють. Гео-блокування може дати час, але це грубий інструмент з передбачуваними боковими ефектами.
Якщо робите — робіть тимчасово, логовано й з переглядом. Краще блокувати по ASN на підставі спостереженого зловживання, а не відчуттів.

2) Чи корисний greylisting у 2026 році?

Так, вибірково. Масовий greylisting дратує легітимних нових відправників і ламає деякі погано зроблені SaaS-мейлери.
Greylistуйте підозрілі джерела, звільняйте відомих надійних відправників і контролюйте вплив затримки на підтримку та продажі.

3) Чому б не зробити оцінку спаму «дуже агресивною» і не вважати справу закритою?

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

4) Як уникнути блокування листів для скидання пароля та реєстрації?

Розділіть транзакційні потоки. Ідеально, якщо вхідні шлюзи мають захищений шлях для пошти від ваших провайдерів і ключових партнерів,
з явними allowlist і аутентифікацією там, де можливо. Також не маршрутуйте критичну пошту через той самий «публічний MX», що й випадковий вхідний трафік.

5) Яке найпоширеніше «ми про це не подумали» вузьке місце?

DNS. Кожна антиспам-фіча, що здається «легкою», часто перетворюється під навантаження в набір DNS-запитів.
Якщо ваш резольвер повільний або upstream обмежує вас, ваша поштова система стає розподіленою кімнатою очікування.

6) Чи можна видалити чергу, щоб швидко відновитися?

Можна, але краще не робити цього безпідставно. Спочатку стабілізуйте прийом, щоб черга припинила зростати.
Потім селективно видаліть очевидний спам із черги (за IP-відрізками, отримувачами на кшталт info@ під атакою, або відомими підписами спаму) з аудитом.
Видалення всього — як перетворити інцидент електронної пошти в бізнес-інцидент з юридичними наслідками.

7) Чи варто відключати антивірус під час припливу спаму?

Іноді — частково. Якщо наплив великий і низької складності, AV може марнувати CPU на сміття, яке варто відхилити раніше.
Але відключати AV повністю ризиковано, якщо ви також отримуєте таргетований зловмисний софт. Безпечніший підхід — гейтинг: запускати AV тільки після проходження перевірок репутації/протоколу.

8) Як зрозуміти, що я відкидаю занадто багато легітимної пошти?

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

9) Чи потрібні мені кілька записів MX і декілька шлюзів?

Для більшості організацій, яким важливий аптайм — так. Надлишковість — це не лише про апаратні збої; це про поглинання зловживань.
Два шлюзи дозволяють проводити обслуговування, ізолювати проблеми і застосовувати різні політики для різних потоків пошти.

10) Чому мої легітимні відправники потрапляють у RBL?

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

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

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

Зробіть це на наступному тижні

• Напишіть і протестуйте конфіг «режим шторму»: обмеження з’єднань, політика postscreen/greylisting і скорочений конвеєр фільтрації.
• Перенесіть чергу на швидке локальне сховище і додайте оповіщення по іноді. Оповіщення лише по місцю на диску — це оманливе заспокоєння.
• Розгорніть локальний кешуючий резольвер з метриками і розумними таймаутами; виміряйте затримку DNS під навантаженням.
• Визначте критичні вхідні потоки (скидання пароля, білінг, пошта партнерів) і забезпечте їм явні винятки та моніторинг.
• Попрактикуйтеся в триажі черги: вибір заголовків, ідентифікація топових джерел/отримувачів і репетиція безпечної процедури очищення.

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