Помилка «421 too many connections»: налаштування паралельних підключень без затримки листів

Що насправді означає «421 too many connections»

SMTP 421 — це тимчасова помилка: «Service not available» мовою RFC. На практиці її використовують як запобіжний клапан: «Зараз не приймаю, спробуйте пізніше». Фраза «too many connections» підказує, що ви перевищили якийсь ліміт — часто одночасні сесії з вашого IP, іноді по обліковому запису, іноді по домену одержувача, іноді за категорією репутації вхідних IP.

Дві поширені реальності під одним повідомленням

• Віддалене обмеження: Ваш MTA відкриває забагато одночасних SMTP-сесій до того самого провайдера/домену, і віддалена сторона тимчасово відмовляє у відкритті нових сесій з 421. Це часто трапляється з великими поштовими провайдерами, корпоративними шлюзами та загальними релей-провайдерами.
• Локальне обмеження: Ваш власний MTA (або проміжний релей/балансувальник) обмежує підключення — наприклад, Postfix smtpd_client_connection_count_limit для вхідних, або поліси, що спеціально повертають 421.

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

Цитата на стикер: «Hope is not a strategy.» — Gene Kranz. Якщо ви «чекаєте, поки пройде», ви займаєтеся неконтрольованим керуванням перевантаженням.

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

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

Коли пейджер гарячий, філософія не потрібна. Потрібно відповісти на три питання по порядку:

1) 421 приходить від віддаленого сервера чи від нас?

Подивіться SMTP-транскрипт у логах. Якщо Postfix каже «host mx.remote.tld said: 421 …», це віддалене обмеження. Якщо ваш власний smtpd повертає 421 клієнтам — це локальне обмеження.

2) Що саме наситилося: з’єднання, пропускна здатність, CPU, диск чи DNS?

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

• Повільний DNS, що спричиняє довготривалі SMTP-сесії.
• Навантаження TLS-ручного керування та стрибки CPU під час рукостискання.
• Затримки дискового вводу/виводу, які спричиняють конкуренцію файлів черги.
• Провайдерські обмеження по IP/підмережі.

3) Чи підсилюють проблему повторні спроби?

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

Швидкі дії, які зазвичай безпечні

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

Цікаві факти та історичний контекст (бо системи мають пам’ять)

1. SMTP передує вебу: SMTP стандартизовано на початку 1980-х, коли «великий трафік» означав зовсім інші речі.
2. 421 навмисно невизначений: Це клас тимчасових відмов, призначений для «поверніться пізніше», а не для точної діагностики.
3. Тимчасові відмови — основа надійності пошти: Модель зберігання й пересилання передбачає, що мережі падають і MTAs повторно надсилають.
4. Обмеження з’єднань стали нормою через спам: Провайдери почали обмежувати по IP через те, що спамери робили безмежний паралелізм небезпечним.
5. Дизайн Postfix модульний: Кілька демонів із контрольованими лімітами процесів, щоб уникнути режиму «одного великого поштовика».
6. Greylisting популяризував контрольовані тимчасові відмови: Багато систем навмисно використовували тимчасові відмови для відсіювання спаму; законні MTAs повторюють.
7. «Під домен» налаштування існують через нерівномірність інтернету: Деякі домени витримують високу паралельність, інші «тануть» від двох з’єднань.
8. TLS зробив вартість підключення суттєвою: SMTP через TLS додає CPU і затримки; повторне використання з’єднань стало важливим.

Практична модель: паралелізм, сесії та черги

Уявіть вашу систему вихідної пошти як вантажний майданчик:

• Черга — ваш склад.
• SMTP-сесії — вантажівки біля рамп завантаження.
• Паралелізм — скільки рамп ви відкриваєте одночасно.
• Віддалені ліміти з’єднань — приймальний склад, який каже «перестаньте присилати вантажівки; ми не встигаємо розвантажувати».

Коли ви отримуєте 421 too many connections, ви надсилаєте більше вантажівок, ніж інша сторона хоче. Якщо ви відповідаєте «відкриваючи більше рамп» (збільшуючи глобальний паралелізм), ви лише створите більше відхилених вантажівок. Якщо ви «закриваєте весь майданчик» (глобальне уповільнення), ви затримаєте все — навіть пошту, яку можна було б доставити швидко іншим доменам.

Тож вам потрібне цільове формування потоку:

• Обмежуйте паралелізм за одержувачем (домен, MX або хост релея).
• Робіть сесії ефективними (відправляйте кілька повідомлень за з’єднання).
• Підтримуйте чергу в здоровому стані (уникати штурмів; за потреби пріоритезуйте свіжу пошту).

Жарт №2: Пошта як трафік: додавання смуг (паралелізму) працює доти, доки всі не вирішать використати один і той же з’їзд (великий провайдер).

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

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

Завдання 1: Підтвердити точний текст 421 і звідки він

cr0x@server:~$ sudo grep -R "421" /var/log/mail.log | tail -n 5
Jan 04 09:12:19 mx1 postfix/smtp[19822]: 9A1C12E3F4: to=<user@example.com>, relay=mx.example.com[203.0.113.20]:25, delay=12, delays=0.1/0.2/5.3/6.4, dsn=4.3.2, status=deferred (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)
Jan 04 09:12:20 mx1 postfix/smtp[19825]: 0B3E99F1A2: to=<user@example.com>, relay=mx.example.com[203.0.113.20]:25, delay=10, delays=0.1/0.2/4.5/5.2, dsn=4.3.2, status=deferred (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)

Значення: «host … said» вказує, що 421 повернув віддалений сервер. Ваш Postfix працює правильно; вас обмежують.

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

Завдання 2: Визначити, які напрямки спричиняють найбільше відмов

cr0x@server:~$ sudo postqueue -p | awk '/^[A-F0-9]/{id=$1} /status=deferred/{print id, $0}' | head
9A1C12E3F4 (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)
0B3E99F1A2 (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)

Значення: У вашому беклозі є відкладена пошта з 421. Це не випадковість; вона кластеризується.

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

Завдання 3: Порахувати причини відмов у масштабі (top N)

cr0x@server:~$ sudo postqueue -p | sed -n 's/.*status=deferred (//p' | sed 's/)$//' | sort | uniq -c | sort -nr | head
  418 host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later
   52 connect to mx.other.tld[198.51.100.10]:25: Connection timed out
   11 host mx.third.tld[192.0.2.55] said: 450 4.2.0 Mailbox busy

Значення: 421 домінує. Таймаути є, але вони не в заголовку.

Рішення: Насамперед вирішуйте проблему 421; не відволікайтеся на дрібні шуми, якщо це не інша інцидентна ситуація.

Завдання 4: Перевірити, скільки процесів SMTP-клієнтів у вас працює

cr0x@server:~$ ps -eo pid,comm,args | grep -E "postfix/smtp" | grep -v grep | wc -l
74

Значення: У вас активні 74 процеси вихідної доставки. Це може бути нормально, або проблемно, якщо 60 з них нищать одного провайдера.

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

Завдання 5: Подивитись активні з’єднання до портів 25/587 і куди вони йдуть

cr0x@server:~$ sudo ss -ntp '( dport = :25 or dport = :587 )' | head -n 15
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port Process
ESTAB  0      0      10.0.0.10:53422     203.0.113.20:25   users:(("smtp",pid=19822,fd=12))
ESTAB  0      0      10.0.0.10:53426     203.0.113.20:25   users:(("smtp",pid=19825,fd=11))
ESTAB  0      0      10.0.0.10:53430     203.0.113.20:25   users:(("smtp",pid=19826,fd=13))

Значення: Багато з’єднань до однієї IP свідчать, що ви тригерите обмеження по IP або клієнту.

Рішення: Обмежте паралелізм до того релєя/одержувача і збільшіть кількість повідомлень за з’єднання.

Завдання 6: Перевірити значення паралелізму Postfix за замовчуванням

cr0x@server:~$ sudo postconf | egrep "default_destination|smtp_destination|initial_destination"
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = $default_destination_concurrency_limit
initial_destination_concurrency = 5

Значення: За замовчуванням ви можете досягати 20 одночасних доставок на призначення (залежить від версії/конфігу). Це агресивно для деяких провайдерів.

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

Завдання 7: Перевірити використання transport map (чи ви вже маршрутизуєте через релей?)

cr0x@server:~$ sudo postconf | egrep "transport_maps|relayhost"
transport_maps =
relayhost =

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

Рішення: Розгляньте transport maps для проблемних напрямків, щоб застосувати ліміти по-transport’у чисто.

Завдання 8: Перевірити, чи Postfix повторно використовує SMTP-з’єднання

cr0x@server:~$ sudo postconf | egrep "smtp_connection_cache|smtp_destination_recipient_limit|smtp_extra_recipient_limit"
smtp_connection_cache_destinations =
smtp_destination_recipient_limit = 50
smtp_extra_recipient_limit = 1000

Значення: Кешування з’єднань може бути вимкнено (порожнє). Без кешування ви відкриваєте нове з’єднання на процес доставки, що підвищує тиск на паралелізм.

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

Завдання 9: Перевірити поведінку повторних спроб і backoff

cr0x@server:~$ sudo postconf | egrep "minimal_backoff_time|maximal_backoff_time|queue_run_delay"
queue_run_delay = 300s
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Значення: Повторні спроби починаються через 5 хвилин і зростають до ~66 хвилин. Якщо ви налаштували це нижче, можна створити шторм повторних спроб.

Рішення: Для напрямку, що каже «too many connections», backoff допомагає. Не встановлюйте minimal backoff на 10 секунд і чекайте поваги.

Завдання 10: Перевірити затримки DNS (нешумний множник паралелізму)

cr0x@server:~$ time dig +tries=1 +timeout=2 mx example.com @127.0.0.53
;; ANSWER SECTION:
example.com.     1800 IN MX 10 mx.example.com.

real    0m0.018s
user    0m0.004s
sys     0m0.004s

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

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

Завдання 11: Перевірити вартість TLS-рукостискання та помилки

cr0x@server:~$ sudo grep -E "TLS|SSL" /var/log/mail.log | tail -n 5
Jan 04 09:12:18 mx1 postfix/smtp[19822]: Trusted TLS connection established to mx.example.com[203.0.113.20]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
Jan 04 09:12:19 mx1 postfix/smtp[19825]: Trusted TLS connection established to mx.example.com[203.0.113.20]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

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

Рішення: Якщо TLS нестабільний — стабілізуйте його (шифри, SNI, ланцюг сертифікатів, MTU) перш ніж вважати, що «too many connections» — лише політика.

Завдання 12: Перевірити затримки диска й стан директорій черги

cr0x@server:~$ iostat -xz 1 3
Linux 6.2.0 (mx1)  01/04/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.12    0.00    1.44    0.80    0.00   94.64

Device            r/s     w/s   rkB/s   wkB/s  %util  await
nvme0n1          3.00   55.00   120.0  2400.0   6.40   1.20

Значення: Низький await і завантаження. Диск не задуває. Якщо await стрибає до десятків/сотень мс, операції з чергою сповільнюються й ваш патерн доставки стає поривчастим — якраз те, що тригерить віддалені обмеження.

Рішення: Якщо диск — вузьке місце, виправляйте зберігання (ізоляція I/O, швидше медіа, тюнінг файлової системи) до того, як «настройка паралелізму» стане вашою основною дією.

Завдання 13: Перевірити власні лічильники обмеження Postfix (anvil)

cr0x@server:~$ sudo postconf | egrep "smtpd_client_connection_count_limit|smtpd_client_connection_rate_limit|anvil_rate_time_unit"
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 0
anvil_rate_time_unit = 60s

Значення: Це контролі вхідних підключень, але вони мають значення, якщо ви релей для внутрішніх додатків. Якщо ваші додатки отримують 421 від вашого Postfix — ці налаштування підозрілі.

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

Завдання 14: Підтвердити, чи трафік концентрується в одного відправника/додатку

cr0x@server:~$ sudo pflogsumm -d today /var/log/mail.log | head -n 30
Grand Totals
------------
messages
  12450   received
  12110   delivered
  310     deferred  (2.4%)
...
Per-Sender Totals
-----------------
  8200   noreply@service.local
  2400   billing@service.local

Значення: Один відправник домінує. Якщо «noreply@service.local» — масовий відправник, його сплески можуть задушити транзакційну пошту.

Рішення: Розділіть трафік за transport’ами (транзакційна vs масова), дайте транзакційній пріоритет, масову загальнозатримуйте суворіше.

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

cr0x@server:~$ sudo find /var/spool/postfix/deferred -type f | wc -l
1832

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

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

Завдання 16: Переглянути заголовки одного застряглого повідомлення (маршрут, одержувач, transport)

cr0x@server:~$ sudo postcat -q 9A1C12E3F4 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size: 4289
recipient: user@example.com
sender: noreply@service.local
*** MESSAGE CONTENTS ***
Received: by mx1 (Postfix, from userid 1001)
Date: Sat, 04 Jan 2026 09:11:58 +0000
Subject: Your login code

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

Рішення: Якщо це транзакційна пошта — маршрутизуйте її через transport з вищим пріоритетом і безпечнішими лімітами та кращою репутацією.

Правильний тюнінг Postfix (без уповільнення пошти)

Принцип 1: Не «виправляйте» проблему за призначенням глобальним уповільненням

Глобальні зміни, як зниження default_destination_concurrency_limit, можуть зменшити 421, звісно. Вони також уповільнять доставку до всіх, включно з тими доменами, які були цілком задоволені. Саме так ви перетворюєте політику одного провайдера на ваш універсальний збій.

Принцип 2: Робіть менше, але кращих з’єднань

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

Конкретні ручки, що зазвичай важливі

1) Обмеження паралелізму за призначенням (велика важіль)

У Postfix можна обмежити паралелізм за призначенням. Якщо ви доставляєте напряму, «призначення» зазвичай — домен (а іноді і MX-хост, залежно від того, як Postfix групує доставки). Безпечний патерн у корпоративних налаштуваннях — використовувати transport maps, щоб створити явні «канали» для великих провайдерів.

Приклад підходу: маршрутизувати конкретний домен (або набір доменів) через іменований transport, потім застосувати ліміти до цього transport у master.cf.

cr0x@server:~$ sudo postconf -n | egrep "transport_maps"
transport_maps = hash:/etc/postfix/transport

cr0x@server:~$ sudo tee /etc/postfix/transport > /dev/null
example.com      slowmx:
example.net      slowmx:

cr0x@server:~$ sudo postmap /etc/postfix/transport

Потім у /etc/postfix/master.cf визначте transport з нижчим паралелізмом. (Це патерн; підлаштуйте значення під своє середовище.)

cr0x@server:~$ sudo postconf -M | grep -E "^slowmx"
slowmx/unix=slowmx unix - - n - - smtp

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

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

2) Кешування з’єднань (повторне використання)

Кешування з’єднань утримує SMTP-сесію відкритою для повторного використання. Це означає менше TCP-хенкшейків, менше TLS-рукостискань, менше шансів потрапити під політику «максимум з’єднань».

cr0x@server:~$ sudo postconf -e "smtp_connection_cache_destinations = example.com example.net"

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

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

3) Збалансуйте обмеження за кількістю одержувачів за з’єднання

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

cr0x@server:~$ sudo postconf -n | egrep "smtp_destination_recipient_limit"
smtp_destination_recipient_limit = 50

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

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

4) Зробіть повторні спроби «менш дурними» для обмеженого напрямку

Якщо віддалена сторона каже «too many connections», повторна спроба через 30 секунд — це фактично аргумент із фаєрволом. Сформуйте повторні спроби так, щоб система природно припинила штурмувати.

cr0x@server:~$ sudo postconf -n | egrep "minimal_backoff_time|maximal_backoff_time"
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Значення: Це глобально. Глобальні зміни впливають на всі напрямки.

Рішення: Віддавайте перевагу управлінню за transport’ом (окрема черга/transport-клас) якщо потрібно інше поводження з повторними спробами для одного провайдера; тримайте глобальний backoff простим і стабільним.

Чого не слід робити (якщо не хочете повторні інциденти)

• Не підвищуйте глобальний паралелізм, щоб «протиснути через». 421 — не проблема пропускної здатності, а проблема координації.
• Не відключайте TLS, щоб пришвидшити рукостискання. Ви обміняєте проблему черги на інцидент безпеки й збиток репутації.
• Не «вирішуйте» додаванням більше MTA за тим самим NAT IP. Віддалені ліміти зазвичай по джерельному IP. Ви просто паралелізуєте відмови.

Коли віддалена сторона вас обмежує

Віддалене обмеження часто керується політикою. Віддалена сторона може обмежувати:

• Одночасні сесії за адресу відправника (source IP)
• Повідомлення за хвилину/годину за IP або за автентифікованим акаунтом
• Одержувачів за повідомленням
• Підключення за хвилину (не лише одночасні)
• Швидкість за репутацією, коефіцієнтом скарг, рівнем bounce’ів або категорією вмісту

Як відрізнити «політичний ліміт» від «перевантаження віддаленої сторони»

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

Шукайте такі патерни в логах:

• Багато швидких відмов з 421 відразу після підключення: класичний політичний ліміт.
• Довгі затримки, потім 421: віддалена сторона могла приймати, а потім скидати навантаження; або ваші TLS/DNS затримки роблять сесію довшою.
• Мікс 421 + таймаути: може бути мережна проблема або одночасне поєднання режимів обмеження й деградації.

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

У реальних компаніях часто є два класи пошти:

• Транзакційна: коди входу, MFA, квитанції. Користувачі помічають це за секунди.
• Масова/залучення: розсилки, нагадування, кампанії. Користувачі помітять… згодом, можливо.

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

Режими відмов, що нагадують проблему з паралелізмом (але не є нею)

Повільний DNS: тихий подовжувач сесій

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

Конкуренція за диск: операції черги стають поривчастими

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

Зламані припущення про повторне використання з’єднань

Деякі NAT-шлюзи, брандмауери або middlebox-и не люблять довгоживучі SMTP-сесії. Якщо вони скидають неактивні з’єднання агресивно, кешування не працює й ви повертаєтесь до «шторму підключень».

Асиметрія IPv6 vs IPv4

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

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

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

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

Потім бізнес запустив «поліпшення безпеки»: кожен вхід вимагав одноразовий код електронною поштою. Команда думала, що пошта поводитиметься як їхні HTTP API — масштабування горизонтально, збільшення паралельних воркерів, зростання пропускної здатності. Вони зробили те, що роблять веб-інженери: додали воркерів. Більше процесів SMTP — більше паралельних спроб доставки.

За годину великі поштові провайдери почали відправляти 421 too many connections. Черга збільшилась. Користувачі просили більше кодів, бо вони не приходили, що породило ще більше пошти й повторних спроб. Класичний зворотний зв’язок із панікою користувачів зверху.

Неправильне припущення було не в «провайдерах злі», а в тому, що SMTP — це push-протокол, де приймач встановлює правила. Паралелізм — це соціальна домовленість, а не технічний диктат.

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

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

Інша організація хотіла швидші метрики доставки. Хтось помітив, що пошта іноді сидить кілька хвилин, тому вони налаштували Postfix частіше обробляти чергу й зменшили backoff. Графіки виглядали чудово тиждень.

Потім вони підключили нового клієнта з корпоративним поштовим шлюзом, суворим щодо кількості з’єднань. MTA почав отримувати 421. Через зменшений backoff MTA повторював агресивно. Шлюз це інтерпретував як зловживання й посилив обмеження ще більше.

Доставка перейшла з «іноді затриманої» до «постійно затриманої». Гірше — агресивні повторні спроби збільшили churn з’єднань, підвищили TLS-рукостискання й CPU, що сповільнило інші доставки. Моніторинг кричав «SMTP помилки», продукт — «зниження реєстрацій».

Оптимізація провалилася, бо намагалася проламати тимчасові відмови. У світі SMTP ввічливе відступлення — обов’язкове; інакше ви викликаєте самообмеження системи.

Вони відкатали глобальні зміни retry, створили окремий transport для домену клієнта з жорстким паралелізмом (та трохи більшим backoff), і решта системи відновилась одразу.

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

Одна команда мала звичку: кожен раз, додаючи нове джерело пошти, маркувати його унікальним envelope sender і логувати ідентичність подачі. Нічого модного — просто послідовно. Більшість інженерів вважали це «додатковою рутиною».

Під час інциденту з 421 ця практика виявилась золотою. Вони швидко визначили, що 90% проблемного трафіку йшло від одного щойно запущеного пакетного завдання, що відправляло звіти по рахунках. Воно мало працювати щогодини, але помилково запускалося кожні п’ять хвилин через помилку планувальника.

Спочатку вони не чіпали Postfix. Призупинили пакетне завдання, дали черзі очиститись, а потім повернули трафік через виділений transport зі строгим паралелізмом за призначенням. Транзакційна пошта отримала власну смугу з кешуванням з’єднань і стабільними лімітами.

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

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

1) Симптом: «421 too many connections» усюди

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

Виправлення: Відкотіть глобальні зміни. Розділіть transport’и за основними групами призначень. Якщо ви використовуєте smarthost, переконайтесь, що не перевищуєте його пер-акаунтні ліміти.

2) Симптом: черга росте, але CPU і мережа в нормі

Причина: Вас швидко відкидають (швидкі 421), тож ресурси не споживаються — генеруються лише повторні спроби.

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

3) Симптом: 421 піки лише у пікові години

Причина: Бурстовий відправлення (cron-завдання, маркетингові розсилки) стикається з часовими лімітами провайдера.

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

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

Причина: Ви застосували глобальне обмеження замість ізоляції проблемного призначення.

Виправлення: Поверніть глобальні налаштування. Використайте transport maps/master.cf, щоб застосувати жорсткі обмеження лише до уражених доменів/провайдерів.

5) Симптом: багато з’єднань, мало повідомлень за з’єднання

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

Виправлення: Увімкніть кешування для цих напрямків, перевірте idle timeout брандмауера, і переконайтесь, що ваш MTA може групувати одержувачів адекватно.

6) Симптом: 421 супроводжується таймаутами і «втраченими з’єднаннями»

Причина: Мережні проблеми (втрати пакетів, повторні передачі), MTU-блоки або віддалена нестабільність; іноді вас «тапплять» через репутацію.

Виправлення: Перевірте здоров’я мережі (втрати пакетів, retransmits), перевірте стабільність TLS і тимчасово зменшіть паралелізм, поки досліджуєте сигнали репутації.

7) Симптом: внутрішні додатки отримують 421 при відправці на ваш релей

Причина: Ваші власні вхідні ліміти (anvil) захищають вас від шумного клієнта.

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

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

Покроково: виправити 421, не затримуючи пошту

1. Класифікуйте джерело 421. Підтвердіть: віддалене чи локальне з логів. Якщо віддалене — дійте далі. Якщо локальне — перевірте smtpd_* та поліси.
2. Ранжуйте напрямки за болем. Порахуйте топ причин відмов і визначте домени/провайдерів, що домінують.
3. Захистіть транзакційну пошту першою. Якщо у вас змішана масова й транзакційна пошта — розділіть їх зараз. Один сервер підходить; одна поведінка черги — ні.
4. Створіть виділений transport для уражених напрямків. Transport maps дають важіль без побічних ефектів.
5. Зменшіть паралелізм на тому transport’і. Починайте консервативно. Якщо провайдер дозволяє 2–5 одночасних сесій, ставте 2–3 і вимірюйте.
6. Увімкніть кешування з’єднань для цього напрямку/transport’у. Менше сесій, більше корисного трафіку за сесію.
7. Перевірте затримки DNS і TLS. Повільні запити й рукостискання підвищують час сесії й сприйманий паралелізм.
8. Спостерігайте вік черги, а не лише розмір. Більшу чергу можна терпіти, якщо вона регулярно спадає й пошта залишається «молодою».
9. Обережно відрегулюйте пакетування. Збільшіть кількість одержувачів за сесію помірно, якщо повідомлення малі й помилок мало.
10. Переконайтесь, що повторні спроби заспокоїлись. Мета — менше відкинутих сесій і більше успішних доставок, а не просто менше рядків у логах.
11. Після стабілізації задокументуйте ліміт. Напишіть, яке обмеження паралелізму працює. Майбутній ви забуде.
12. Додайте моніторинг відмов за напрямком. Зловіть наступне обмеження раніше, ніж воно стане горою черги.

Операційний чекліст: що моніторити постійно

• Розмір відкладеної черги і розподіл за віком
• Топ причин відмов (421 vs таймаути vs 5xx)
• Вихідні з’єднання за IP/доменом призначення
• Швидкість доставки SMTP (доставлено/хв) розбита за transport’ами
• Затримки резольвера DNS і частота помилок
• Затримка дискового I/O на файловій системі спула MTA
• Завантаження CPU і частота TLS-рукостискань

FAQ

1) Чи 421 — це постійна відмова?

Ні. Це тимчасова відмова. Ваш MTA має відкладати і повторювати спроби. Питання в тому, чи ці повторні спроби контрольовані чи хаотичні.

2) Чому провайдери обмежують з’єднання, а не повідомлення?

З’єднання дорогі: стан TCP, TLS-рукостискання і пост-сесійне сканування. Обмеження одночасних сесій — ефективний спосіб захистити інфраструктуру від сплесків і зловживань.

3) Чи просто знизити default_destination_concurrency_limit?

Тільки якщо вам подобається уповільнювати пошту до доменів, що не скаржилися. Краще використовувати per-transport або per-destination тюнінг, щоб ліміт одного провайдера не став глобальним.

4) Наскільки низьким має бути паралелізм за призначенням?

Достатньо низько, щоб зупинити 421, але достатньо високо, щоб досягати цілей доставки. Почніть з 2–5 для суворих провайдерів, потім поступово підвищуйте, стежачи за відмовами й віком черги.

5) Чи завжди увімкнення кешування з’єднань допоможе?

Часто так — особливо з TLS. Але це може зруйнуватися через брандмауери, що вбивають неактивні сесії. Якщо кешування не зменшує нові підключення, перевірте проміжні пристрої на idle timeout.

6) Чому зменшення паралелізму зробило частину листів швидшими?

Бо ви перестали витрачати спроби даремно. Успішні сесії доставляють пошту; відкинуті генерують повторні спроби й churn. Менший паралелізм може означати більше корисної пропускної здатності.

7) Що робити, якщо 421 відбувається при підключенні додатків до нашого релею (вхідні)?

Тоді це ваш релей обмежує клієнтські підключення (або політичний сервіс). Досліджуйте налаштування anvil, поведінку клієнтів і чи один додаток не відкриває сотні паралельних SMTP-сесій.

8) Чи можу я виправити це, додавши більше MTA?

Лише якщо ви також додаєте більше джерельних IP і відповідально керуєте репутацією. Якщо все виходить через один NAT-IP, більше MTA означатиме тільки більше відкинутих підключень за секунду.

9) Чи змінює IPv6 щось?

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

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

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

Висновок: практичні наступні кроки

«421 too many connections» — це керування перевантаженням під маскою. Ваше завдання — припинити поводитись з ним як із загадкою і почати формувати трафік як доросла система.

1. Підтвердіть, чи 421 віддалене чи локальне за формулюванням у логах.
2. Визначте топ призначень, що спричиняють відмови.
3. Розділіть трафік: транзакційний vs масовий, і ізолюйте великі провайдери у виділені transport’и.
4. Зменшіть паралелізм за призначенням для ураженої групи і увімкніть кешування з’єднань.
5. Перевірте DNS, TLS і дисковий I/O, щоб випадково не підсилювати паралелізм.
6. Оцінюйте вік черги й успішні доставки, а не лише відсутність помилок.

Зробіть це — і ви припините гратися в whack-a-mole з 421. Пошта перестане «просто доставлятись згодом». Вона приходитиме вчасно, з меншою кількістю з’єднань і без драм — а це найвища похвала, яку може заслужити продакшн-система.