Обмеження швидкості в Postfix: запобігайте зловживанням без блокування реальних користувачів

Що насправді означає обмеження швидкості в Postfix (і чого воно не означає)

Обмеження швидкості в Postfix — це не одна функція. Це набір клапанів тиску на різних рівнях:

• Контроль на рівні з’єднання: скільки TCP-сесій клієнт може відкрити, як швидко їх можна відкривати і скільки часу ви будете терпіти їхню неактивність.
• Контроль на рівні протоколу: скільки одержувачів на повідомлення, скільки команд за сесію, наскільки швидко клієнт може робити pipelining.
• Контроль на рівні аутентифікації: обмеження для SASL-авторизованої відправки, щоб скомпрометований акаунт не відправив 50 000 листів перш ніж ви зреагуєте.
• Контроль черги й доставки: запобігання тому, щоб один домен або пункт призначення зайняв усі слоти доставки й не призвів до обмежень зі сторони великих провайдерів.
• Політичний контроль: зовнішній «мозок», який застосовує правила на рівні користувача/відправника/клієнта залежно від стану, репутації або бізнес-контексту.

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

Крім того, обмеження швидкості — це не «блокування». Найкраще обмеження — це тимчасова відмова (defer-first) — уповільнити підозрілу поведінку, одночасно дозволяючи нормальному трафіку проходити. Відмовляти треба за явні порушення політики, а не тому, що у вас завантаження. Коли ви відмовляєте через перевантаження, ви експортуєте свою інцидентну проблему комусь іншому — і вони це запам’ятають.

Сухо-смішна істина №1: SMTP охоче дозволить ноутбуку в кав’ярні спробувати стати вашим «платформою для масової розсилки». Він має впевненість дитини з перманентним маркером.

Три принципи, що рятують від самостійних аварій

1. Формуйте трафік, не вгадуйте. Використовуйте вимірювані межі (за IP, за користувачем, за призначенням), а не відчуття.
2. Віддавайте перевагу «тимчасовій відмові» замість «постійної відмови». Відповіді 4xx зберігають шаблони доставки й зменшують кількість звернень у підтримку.
3. Зробіть винятки явними. Якщо потрібно дозволити релей-партнера або масового відправника, виділіть для них контрольовану смугу замість підняття глобальних лімітів.

Цитата, варта стікера

Сподівання — це не стратегія. — генерал Гордон Р. Салліван

Обмеження швидкості — це місце, де ви замінюєте сподівання на контроль.

Факти та контекст: чому обмеження в Postfix виглядають саме так

Трохи контексту допоможе зрозуміти, чому Postfix дає цілу купу регуляторів замість однієї кнопки «обмежити спам»:

1. SMTP передує комерційному інтернету. Він був розроблений для співпраці хостів, а не для ворожих клієнтів, тому обмеження швидкості стало доповненням для виживання.
2. Postfix створений як альтернатива Sendmail з безпекою й продуктивністю як першочерговими цілями, включаючи багатопроцесну архітектуру, яка може працювати навіть коли частини системи під навантаженням.
3. anvil існує тому, що рахувати з’єднання дорого. Postfix додав сервіс anvil(8) для ефективного відстеження швидкостей по клієнту, щоб кожен процес не винаходив це заново.
4. Грейлістинг популяризував ідею «гальмувати поганих». Обмеження швидкості — це сусідня концепція: змусити автоматизацію зловмисників платити часом.
5. Великі отримувачі почали застосовувати репутацію відправника в масштабі (швидкість, скарги, відскоки), перетворивши обмеження вихідної швидкості на функцію доставлюваності, а не лише безпеки.
6. Ботнети змінили гру для вхідного трафіку. Раніше джерелом був один IP. Тепер зловживання йде від роїв, що робить обмеження по IP необхідним, але недостатнім.
7. Заповнення облікових даних мігрувало в подачу пошти через повторне використання паролів. Обмеження спроб входу тепер — базова гігієна.
8. Cloud NAT ускладнив «справедливість по IP». Сотні легітимних користувачів можуть виглядати як один IP, тому потрібні ліміти, що враховують ідентичність, а не лише адресу клієнта.

Виберіть модель загрози перед тим, як крутити регулятори

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

Вхідні загрози (роль SMTP-сервера)

• Потоки з’єднань (черги SYN/accept, виснаження процесів, CPU через TLS): вирішуються за допомогою postscreen, anvil-лімітів і налаштування ОС.
• Атаки збору адрес (багато RCPT TO-проб): вирішуються обмеженням одержувачів, tarpitting і політичними обмеженнями.
• Slowloris-подібний SMTP (утримання сесій відкритими, повільні команди): вирішується таймаутами і мінімальною одночасною кількістю з’єднань на клієнта.

Вихідні загрози (роль submission/relay)

• Скомпрометована поштова скринька: обмежуйте за користувачем/SASL і сповіщайте про аномалії.
• Масовий відправник «випадково» використовує вас: застосовуйте політику за клієнтом і за відправником; виділіть окремий інстанс або транспорт.
• Тротлінг зі сторони отримувачів (великі провайдери): обмежуйте конкурентність за призначенням і згладжуйте сплески, щоб захистити репутацію.

Визначте, як виглядає «добра пошта»

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

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

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

Перше: це прийом вхідних повідомлень чи вихідна доставка?

• Якщо користувачі скаржаться, що не можуть відправляти з клієнтів: перевірте сервіс submission, SASL, демон політики та вихідні ліміти.
• Якщо віддалені відправники кажуть, що «не можуть до вас дістатися»: перевірте вхідні слухачі, postscreen, обмеження з’єднань і DNS.

Друге: подивіться на чергу і причини відкладення

Зростаюча deferred-черга — це тротлінг зовнішніх отримувачів або ваша проблема з конкурентністю доставки. Зростаюча active-черга вказує на локальну конкуренцію або занадто низьку конкурентність.

Третє: підтвердіть, що Postfix робить з клієнтами

Логи скажуть, чи ви відхиляєте (5xx), відкладаєте (4xx) чи просто повільні. Обмеження швидкості зазвичай проявляються як «too many connections», «policyd: … action=defer» або пеки postscreen.

Четверте: визначте найактивніших відправників

Знайдіть IP, SASL-користувачів або адреси відправників, що домінують у трафіку. Накладайте обмеження вибірково.

Набір інструментів для обмеження швидкості: anvil, postscreen, policyd та інші

1) anvil(8): відстеження з’єднань та швидкостей по клієнту

Anvil тримає лічильники, як-от «з’єднання на клієнта за одиницю часу» і «одночасні з’єднання на клієнта». Він підживлює параметри Postfix, такі як:

• smtpd_client_connection_count_limit
• smtpd_client_connection_rate_limit
• smtpd_client_message_rate_limit
• smtpd_client_recipient_rate_limit

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

2) postscreen: зупиняйте сміття до того, як воно стане SMTP-навантаженням

postscreen обробляє початкову стадію з’єднання і може дешево відкидати очевидний спам. Це ваш «швейцар при вході». Використовуйте його, коли вхідний SMTP отримує великі обсяги спаму або бот-трафіку.

postscreen особливо корисний, коли TLS-ручні узгодження та SMTP-переговори споживають CPU. Краще уникнути переговорів, ніж обмежувати після того, як ви вже оплатили їхню вартість.

3) Сервіси політики: розумніші ліміти за ідентичністю й контекстом

Делегування політики Postfix (check_policy_service) дозволяє зовнішньому сервісу вирішувати приймати/відкладати/відхиляти на основі:

• SASL username
• Sender address
• Client IP and HELO
• Recipient, domain, and message metadata

Саме тут ви реалізуєте «повідомлень на годину для кожного користувача», «обмеження за планом клієнта» і «спеціальна смуга для довірених систем» без перетворення smtpd на таблицю Excel.

4) Формування доставки: не дайте великим отримувачам вас тротлити

Postfix може обмежувати конкурентність і швидкість за призначенням через транспорти і налаштування за доменом (наприклад, тюнінг concurrency і delays). Це менше про зупинку зловживань і більше про те, щоб залишатися бажаним відправником.

5) Розділення сервісу submission: захистіть вхідні від вихідних

Якщо ви запускаєте і вхідний MX, і вихідну submission на тому ж хості, ізолюйте сервіси. Різні порти, різні обмеження, різні ліміти. Та сама бінарна програма, різна поведінка. Правильна конфігурація здається нудною. Залишайте її нудною.

Розумні базові налаштування: стартові значення, що не зіпсують вам день

Універсального числа не існує. Але є універсальні помилки: встановити ліміти настільки низько, що легітимні повторні спроби перетворюються на лавину звернень у підтримку, або настільки високо, що компроміс стає PR-подією.

Рекомендації для вхідного (MX)

• Використовуйте postscreen, якщо отримуєте значний бот-обсяг.
• Встановіть консервативну одночасність на клієнта (smtpd_client_connection_count_limit), щоб один IP не займав усі ресурси.
• Використовуйте таймаути для завершення повільних сесій: smtpd_timeout, smtpd_helo_timeout, smtpd_recipient_limit (кількість одержувачів — не таймаут, але захищає від поширеного шаблону зловживань).

Рекомендації для вихідного (submission/relay)

• Обмежуйте за SASL-користувачем, а не за IP, якщо у вас є NAT-овані клієнти.
• Віддавайте перевагу відкладанню перед відмовою при перевищенні швидкості. Користувачі повторюють спробу; шкідливе ПЗ теж повторює, але це дає вам час для виявлення.
• Встановіть жорсткі обмеження на одержувачів у повідомленні для submission, щоб уникнути катастроф типу «один лист на 10 000 одержувачів».

Сухо-смішна істина №2: Кожен поштовий сервер рано чи пізно стає сервісом масових розсилок. Єдине питання — чи відбувається це з вашого дозволу.

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

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

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

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (running) since Fri 2026-01-02 08:14:03 UTC; 1 day ago

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

Рішення: Якщо inactive/failed — перегляньте journalctl -u postfix і запустіть postfix check перш ніж чіпати тюнінг.

Завдання 2: Перевірити ключові параметри обмежень, що діють

cr0x@server:~$ postconf -n | egrep 'anvil|client_.*rate|client_.*count|recipient_limit|smtpd_timeout|postscreen'
smtpd_client_connection_count_limit = 20
smtpd_client_connection_rate_limit = 60
smtpd_client_message_rate_limit = 120
smtpd_client_recipient_rate_limit = 600
smtpd_recipient_limit = 200
smtpd_timeout = 60s

Значення: Це недефолтні налаштування у вашому робочому конфігу. Багато інцидентів починаються словами «хтось міняв це кілька місяців тому».

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

Завдання 3: Перевірити, чи anvil увімкнено (адже від нього залежать ці ліміти)

cr0x@server:~$ postconf anvil
anvil = unix - - n - 1 anvil

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

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

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

cr0x@server:~$ mailq | tail -n 20
-- 12 Kbytes in 23 Requests.

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

Рішення: Якщо черга величезна — переключайтеся на причини defer і тротлінг призначень (Завдання 5–7).

Завдання 5: Підсумувати причини deferred у логах (що саме не вдається)

cr0x@server:~$ grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 5
Jan 03 09:12:44 mx postfix/smtp[22184]: 8A3C73C2F: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.140.27]:25, delay=12, delays=0.2/0.1/9.6/2.1, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[74.125.140.27] said: 421-4.7.0 Try again later, closing connection. (in reply to end of DATA command))

Значення: Зовнішній отримувач вас тротлить (421 4.7.0). Це не виправить підняття вхідних лімітів. Вирішується згладжуванням вихідної доставки і зменшенням підозрілої активності.

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

Завдання 6: Ідентифікувати топових SASL-користувачів (хто генерує обсяг)

cr0x@server:~$ grep "sasl_username=" /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  842 sales.bot@example.com
  113 j.smith@example.com
   77 alerts@example.com

Значення: Одна ідентичність домінує. Це може бути легітимна автоматизація або компроміс.

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

Завдання 7: Ідентифікувати топові IP клієнтів на вхідному SMTP (хто підключається)

cr0x@server:~$ grep "connect from" /var/log/mail.log | awk '{print $NF}' | sed 's/[][]//g' | sort | uniq -c | sort -nr | head
  502 203.0.113.44
  311 198.51.100.77
  148 192.0.2.10

Значення: Кілька IP вас «б’ють». Якщо це невідомі мережі — ви під бот-атаками або неправильно налаштованими upstream-релеями.

Рішення: Використайте postscreen/anvil-ліміти або rate limiting на рівні firewall; вносіть у білий список тільки якщо можете довести легітимність.

Завдання 8: Перевірити, чи клієнти обмежуються Postfix

cr0x@server:~$ grep -E "too many (connections|commands|messages)|rate limit" /var/log/mail.log | tail -n 8
Jan 03 09:10:02 mx postfix/smtpd[21901]: warning: too many connections from 203.0.113.44
Jan 03 09:10:03 mx postfix/smtpd[21902]: warning: 203.0.113.44: SMTP command rate limit exceeded

Значення: Сервер активно тротлить. Це може бути правильно (боти) або неправильно (NAT-ована офісна мережа, балансувальник навантаження, система моніторингу).

Рішення: Якщо це легітимний upstream — створіть контрольований виняток. Якщо ні — ужоростіть і додайте postscreen.

Завдання 9: Перевірити стан postscreen (якщо увімкнений)

cr0x@server:~$ systemctl status postfix@postscreen --no-pager
● postfix@postscreen.service - Postfix postscreen
     Loaded: loaded (/lib/systemd/system/postfix@.service; enabled)
     Active: active (running) since Fri 2026-01-02 08:14:03 UTC; 1 day ago

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

Рішення: Якщо не запущено — виправте enable в master.cf і переконайтеся, що порт 25 спрямований на postscreen як задумано.

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

cr0x@server:~$ postconf | egrep 'default_process_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_destination_recipient_limit'
default_process_limit = 100
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
smtp_destination_recipient_limit = 50

Значення: Ви можете потрапляти під тротлінг великих провайдерів, тому що доставляєте занадто агресивно (rate_delay=0s) або занадто конкурентно.

Рішення: Якщо бачите 421-відкладення від домену — додайте rate delay і зменшіть concurrency для того призначення через transport maps.

Завдання 11: Помітити навантаження на CPU від TLS (поширений прихований ліміт)

cr0x@server:~$ top -b -n 1 | head -n 12
top - 09:13:01 up 12 days,  2:41,  1 user,  load average: 7.82, 6.90, 5.11
Tasks: 212 total,   3 running, 209 sleeping,   0 stopped,   0 zombie
%Cpu(s): 78.2 us,  3.1 sy,  0.0 ni, 18.3 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st

Значення: Високе завантаження CPU з низьким IO wait вказує на обчислювально витратну роботу (TLS-рукопотискання, фільтри контенту, виклики політики). Обмеження на рівні SMTP може бути найдешевшим полегшенням.

Рішення: Увімкніть postscreen і зменшіть витратну роботу для невідомих клієнтів; згодом розгляньте повторне використання TLS-сесій і розумні набори шифрів.

Завдання 12: Переконатися, що ви не блокуєте себе занадто низькими таймаутами

cr0x@server:~$ postconf | egrep 'smtpd_.*timeout|smtp_.*timeout'
smtpd_timeout = 60s
smtpd_helo_timeout = 30s
smtpd_client_connection_timeout = 10s
smtp_connect_timeout = 30s
smtp_data_done_timeout = 600s

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

Рішення: Якщо бачите багато «lost connection after CONNECT/HELO» від легітимних партнерів — помірно збільшіть таймаути і покладіться на обмеження конкурентності замість цього.

Завдання 13: Перевірити виклики політичного сервісу (і затримки) в логах

cr0x@server:~$ grep -E "check_policy_service|policy.*timeout|policyd" /var/log/mail.log | tail -n 6
Jan 03 09:11:22 mx postfix/smtpd[22010]: warning: problem talking to server 127.0.0.1:10031: Connection timed out
Jan 03 09:11:22 mx postfix/smtpd[22010]: NOQUEUE: reject: RCPT from mail.example.net[192.0.2.10]: 451 4.3.0 <127.0.0.1:10031>: Temporary lookup failure; from=<a@b> to=<c@d> proto=ESMTP helo=<mail.example.net>

Значення: Демон політики — вузьке місце; Postfix відкладає, бо не може отримати рішення.

Рішення: Виправте продуктивність/доступність політичного демона або тимчасово обійдіть його для критичних потоків. Не «вирішуйте» це підняттям ліміту процесів smtpd; ви просто створите більшу купу роботи.

Завдання 14: Підтвердити розділення сервісів у master.cf (submission vs smtp)

cr0x@server:~$ postconf -Mf | egrep '^(smtp|submission|smtps)'
smtp/inet=smtp inet n - y - - smtpd
submission/inet=submission inet n - y - - smtpd
smtps/inet=smtps inet n - y - - smtpd

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

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

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

Інцидент №1: Неправильне припущення (NAT = «один користувач»)

Середня компанія запускала Postfix для вихідної пошти працівників і вхідного MX на одній віртуальній машині. Вони щойно переїхали офіс і, як часто буває при переїздах, мережевий відділ зробив «тимчасовий» NAT, який став постійним. Тепер сотні користувачів ділили один публічний IP для submission.

Адмін пошти помітив невелике зростання спроб вихідного спаму (реальні, але не масштабні). Вони швидко відреагували: встановили smtpd_client_message_rate_limit і smtpd_client_connection_rate_limit для сервісу submission. Числа здавалися щедрими — якщо уявляти одного користувача на одному IP.

Наступного дня о 09:00 служба підтримки задзвонила. Клієнти Outlook показували періодичні помилки відправлення. Мобільні користувачі спостерігали затримки. Асистентка CEO виявила, що «спробуйте пізніше» — не дуже задовольняюче повідомлення при бронюванні квитків.

Логи були ясні: «too many connections from [office public IP]». Система не була під атакою. Вона працювала нормально, але ліміт дивився не на ту вимірність. Вони припустили, що IP == користувач; мережа спростувала це.

Виправлення не було «підняти ліміт, поки скарги не зникнуть». Вони перенесли контролі submission на рівень SASL-ідентичності через політичний сервіс і додали невеликий per-IP кап як запасний захід. Зловживання було обмежено, а реальні користувачі перестали заважати один одному.

Інцидент №2: Оптимізація, що зіграла проти (більше конкурентності — більше тротлінгу)

SaaS-провайдер відправляв транзакційну пошту — скидання паролів, квитанції, сповіщення — через Postfix. Доставлюваність була важлива. Хтось помітив, що вихідна черга час від часу накопичується у пікові години, і зробив класичний ход: збільшив default_process_limit і concurrency по призначеннях, щоб доставка «йшла швидше».

Вона йшла швидше — близько години. Потім deferred-черга почала наповнюватися 421-відповідями від великого поштового провайдера. Провайдер не був незадоволений добовим обсягом; він реагував на сплески та зміну з’єднань. Більша конкурентність виглядала як агресивна поведінка.

Пішли тікети в підтримку: «Я не отримую лист для скидання пароля». Під тиском інженери знову підняли конкурентність. Це посилило тротлінг. Це поштовий еквівалент багаторазового натискання кнопки ліфта.

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

Урок: швидкість доставки — це не лише ваша пропускна здатність. Це також сприйняття вашої поведінки отримувачем. Обмеження виходу іноді найшвидший шлях до доставки.

Інцидент №3: Нудна правильна практика, що врятувала день (окремі смуги)

Фінансова компанія навчилася важким шляхом, що «один Postfix, щоб правити ними всіма» стає єдиною зоною відмови. Вони запускали окремі екземпляри Postfix: один для вхідного MX, один для авторизованої submission і один для внутрішніх relay додатків. Ті ж хости, різні порти, різні політики, окремі черги.

В одну п’ятницю ввечері легасі-додаток зламався після деплою. Він почав генерувати масові повідомлення через цикл. Не зловмисно, просто помилка. Спершу це влучило в внутрішній relay.

Ліміти на тій смузі були суворі: по відправнику і по облікових даних додатка встановлені обмеження, і дозволи на вибухи були маленькі. Релей-інстанс відкладав надлишок і тримав чергу під контролем. Пошта від додатку сповільнилась, спрацювали алерти, і on-call знайшов баг.

Тим часом відправка співробітників працювала, а вхідний MX продовжував приймати пошту. Ніяких видимих клієнтам інцидентів. Жодного «вимкнути все» рішення. Система деградувала в потрібному місці.

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

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

1) Симптом: «Too many connections» з одного IP, і це ваш офіс

Корінь: Ви застосували per-IP anvil-ліміти до NAT-ованої популяції (trаffic submission).

Виправлення: Лімітуйте за SASL-користувачем через політичний сервіс; збережіть м’який per-IP кап як захист від справжніх потоків.

2) Симптом: Випадкові партнери скаржаться на обірвані з’єднання

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

Виправлення: Помірно збільшіть таймаути; внесіть відомих партнерів у білліст postscreen; залишайте суворість для невідомих.

3) Симптом: Черга росте, здебільшого deferred з 421/4.7.x від великих провайдерів

Корінь: Вас тротлять; ви доставляєте дуже сплесково, або ваша репутація під підозрою.

Виправлення: Знизьте конкурентність за призначенням, додайте rate delay і перевірте вихідні джерела (компрометовані акаунти, хвилі відскоків).

4) Симптом: CPU стрибає під час хвиль спаму, хоча ви відхиляєте пізніше

Корінь: Дорога робота (TLS, політика, фільтри контенту) відбувається до того, як ви відкинете сміття.

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

5) Симптом: Легітимні масові відправлення не проходять (розсилки, рахунки)

Корінь: Ви використали глобальні ліміти на одержувачів/повідомлення без виділених смуг.

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

6) Симптом: Користувачі бачать періодичні 451/4.3.0 тимчасові помилки

Корінь: Таймаути демонів політики або перевантажена бекенд-база даних.

Виправлення: Зробіть сервіс політики високодоступним і швидким; встановіть розумні таймаути і явно визначте поведінку при збої (fail-open або fail-closed) залежно від сервісу.

7) Симптом: Доставка повільна, навіть при малій черзі

Корінь: Ви занадто сильно обмежили глобальну конкурентність (default_process_limit занадто низький), або один призначений домен споживає слоти.

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

8) Симптом: Після додавання обмежень ви отримуєте більше скарг на спам

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

Виправлення: Для авторизованої submission застосовуйте жорсткі per-user ліміти плюс сповіщення і механізми автоматичної блокувальної обробки.

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

Покроково: впровадження безпечних вихідних лімітів для submission

1. Сепарація політики submission у master.cf (submission на порті 587) з обов’язковою авторизацією і TLS.
2. Встановіть обмеження отримувачів для submission (захист від «один лист тисячам»).
3. Реалізуйте per-SASL ліміти за допомогою політичного демона (рекомендується) або, як мінімум, обережно використовуйте anvil-ліміти.
4. Визначте смуги винятків для відомих автоматизаційних акаунтів (alerts, invoicing) з явними вищими лімітами.
5. Інструментуйте логи: витягайте топ SASL-користувачів, топ адрес відправників і кількість відхилень/відкладань.
6. Налаштуйте оповіщення про аномалії: раптові сплески по користувачу, різке зростання deferred-черги, повторні невдалі входи.
7. Проведіть контрольований тест: один нормальний користувач, один акаунт автоматизації і один синтетичний зловмисник у стейджингу, якщо він у вас є.

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

1. Увімкніть postscreen, якщо вхідний обсяг це виправдовує.
2. Застосуйте помірні per-client ліміти конкурентності, щоб один хост не займав smtpd workers.
3. Використовуйте перевірки протоколу: обмежуйте одержувачів, вимагайте коректний HELO за потреби і відкидайте явний смітник рано.
4. Віддавайте перевагу тимчасовим відмовам для підозрілих сплесків, особливо для невідомих клієнтів.
5. Підтримуйте невеликий білий список для відомих партнерів з особливими потребами, але переглядайте його щоквартально.
6. Переглядайте таймаути, щоб не карати високозатримані легітимні MTA.

Покроково: формування вихідної доставки, щоб уникати тротлінгу отримувачів

1. Вимірюйте відкладення за доменом (gmail, outlook, yahoo, корпоративні партнери).
2. Створіть per-domain транспорти для проблемних отримувачів.
3. Зменшіть конкурентність і додайте rate delay там, де бачите 421/4.7.x відмови.
4. Тримайте транзакційну пошту пріоритетною через окрему чергу/транспорт, якщо можете.
5. Спочатку зупиніть витік: якщо є скомпрометовані користувачі — відключення їх краща міра, ніж «налаштовуванння навколо» спаму.

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

1) З чого починати: обмежувати вхідний чи вихідний трафік?

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

2) У чому різниця між лімітами з’єднань і лімітами швидкості повідомлень?

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

3) Лімітування має відхиляти (5xx) чи відкладати (4xx)?

Для більшості випадків обмеження швидкості — відкладати (4xx). Це уповільнює зловживання і зберігає доставлюваність для легітимних відправників. Відхиляйте за політичні порушення (відкрите реле, недійсні одержувачі, якщо ви відхиляєте на RCPT тощо).

4) Чому мої користувачі блокуються, якщо один IP перевищує ліміт?

Через NAT. Готелі, офіси, мобільні мережі і деякі VPN концентрують багатьох користувачів за одним IP. Не сприймайте IP як ідентичність для submission. Лімітуйте за SASL-username або за відправником.

5) Чи вирішиться тротлінг від Gmail/Microsoft підняттям concurrency в Postfix?

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

6) Чи безпечно вмикати postscreen на продакшн-MX?

Так, якщо тестувати і моніторити. Ризик — хибні позитиви для незвичних відправників. Почніть з консервативних налаштувань і тримайте малий білий список важливих партнерів. Не вносіть весь інтернет у білий список через один дивний MTA.

7) Як обмежувати по поштовій скринці без політичного демона?

Чистий Postfix найкраще працює з per-client/IP лімітами через anvil. Per-user потребує логіки політики. Без неї можна наблизитися, використовуючи окремі submission-сервіси (різні порти) і обмеження для авторизованих клієнтів, але це незграбно. Якщо вам потрібні per-user ліміти — використовуйте політичний сервіс.

8) Які метрики найважливіші для налаштування лімітів?

Розмір черги (active vs deferred), причини deferred (особливо 421/4.7.x), топ SASL-користувачі за обсягом, топ IP клієнтів і попадання в логи про ліміти. Також відстежуйте тренди скарг і відскоків — шкода репутації з’являється там першою.

9) Як уникнути ламання легітимних масових відправлень?

Дайте масовим відправникам окрему смугу з явними лімітами і моніторингом. Не піднімайте глобальні ліміти «для них». Глобальні ліміти — для інтернету; смуги — для бізнес-виключень.

Висновок: що робити далі

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

1. Вимірюйте: знайдіть топ-токерів (IP, SASL-користувач, відправник) і прочитайте причини defer/reject.
2. Розділіть смуги: inbound MX, авторизована submission і relay-додатки не повинні ділити одну політику.
3. Впровадьте обмеження з урахуванням ідентичності: per-user капи для submission; per-IP капи для вхідних; формування за призначенням для доставки.
4. Віддавайте перевагу defer при перевищенні швидкості, і залишайте reject для реальних порушень політики.
5. Запишіть винятки і переглядайте їх. Кожен постійний виняток починає своє життя як «тимчасовий».

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