Черга електронної пошти зростає — знайдіть винуватця, поки листування не зупиниться

December 1, 2025 • February 3, 2026 • Читання: 5 хв • Views: 6

Було корисно?

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

Зростаюча черга пошти рідко є самою проблемою. Це найпомітніший симптом вузького місця: DNS, TLS-рукопотискання, віддалені обмеження швидкості,
локальна затримка диска, збої резольвера, проблема репутації або добре продумане зміни конфігурації, що перетворили ваш MTA на однополосний міст.
Ось як знайти винуватця до того, як пошта зупиниться — і до того, як ви дізнаєтеся про інцидент із пересланого скриншота.

Як ростуть черги (і чому вони продовжують рости)

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

Крива зростання черги підказує клас проблеми:

Лінійне зростання: ви доставляєте частину пошти, але пропускна здатність менша за вхідний потік. Думайте про віддалене обмеження, занадто низьку паралельність або повільне сховище.
Стрибок із подальшим плато: тимчасовий збій або неполадка DNS/TLS. Черга накопичується, а потім спадає після виправлення.
Вибухоподібне зростання: масштабні відмови (резольвер впав, блокування вихідного трафіку, диск заповнений) або «поштовий шторм» (петля, неправильно налаштований застосунок, скомпрометований обліковий запис).
Переважають «deferred»: ви намагаєтеся доставляти, але віддалені системи відхиляють або тайм-аутять.
Переважають «active»: локальна обробка зависла — часто диск, блокування, фільтрація вмісту або завислий дочірній процес.

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

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

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

Коли черга зростає, у вас немає часу на повільні археологічні розкопки. Потрібна чітка послідовність, яка за хвилини відокремить «віддалені відмови»
від «локальних зависань» і від «мережевих/DNS/TLS» проблем.

Перше: класифікуйте накопичення (deferred проти active, найстарший вік, домінуюча причина)

Чи переважає черга deferred? Часто це мережа/DNS/TLS/віддалені політики.
Чи переважає active? Частіше це локальна конкуренція за ресурси (диск, CPU, фільтр вмісту) або завислий процес.
Який вік найстарішого повідомлення? Якщо дні — у вас постійний режим відмов або надто довгий графік повторів для вашого бізнесу.

Друге: перевірте локальний стан (диск, затримки ввід/вивід, закінчення inode, резольвер)

Перевірте вільне місце на диску та використання inode там, де зберігається черга.
Перевірте iowait і затримки сховища; черги пошти інтенсивно працюють із записами дрібних файлів.
Перевірте швидкість і правильність DNS-розв’язування з хоста MTA.

Третє: перевірте вихідний шлях (egress по порту 25, TLS-рукопотискання, віддалені обмеження швидкості)

Перевірте базову TCP-зв’язність до відомих коректних пунктів призначення на порту 25.
Перевірте на наявність помилок TLS і тайм-аутів; вони можуть послідовно блокувати спроби доставки.
Шукайте патерни «421 Try again later», «4.7.0 rate limited» або «temporarily deferred».

Четверте: переконайтеся, що ви не є джерелом проблеми (петлі, сплески, неправильні повтори)

Визначте топ-відправників і топ-отримувачів у черзі. Один застосунок може отруїти систему.
Шукайте дублікати, авто-відповіді або петлі bounced-повідомлень.
Перевірте, чи файли черги безперервно змінюються (високий рівень записів) без прогресу доставки.

П’яте: коригуйте обережно (збільшуйте паралельність тільки після виправлення вузького місця)

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

Цікаві факти та історичний контекст

SMTP передував більшості «корпоративних поштових рішень»: RFC 821 (1982) стандартизував SMTP, коли інтернет ще був переважно дослідницькими мережами.
«Store-and-forward» — це суть: ранні мережі були ненадійними, тому черги і повторні спроби були спроєктовані з самого початку.
Черги пошти за своєю сутністю залежать від файлової системи: класичні MTA зберігають кожне повідомлення як один або кілька файлів; це робить затримки диска ключовим фактором.
DNS став критичною залежністю пізніше: записи MX і маршрутизація через DNS змінили доставку з фіксованих таблиць на залежність від резольвера.
Greylisting популяризував відкладення: на початку 2000-х багато серверів використовували «спробуйте пізніше», щоб зменшити спам, навчивши MTA терпінню.
TLS додав складності по CPU і рукопотисканням: STARTTLS покращив приватність, але вніс нові режими відмов — тайм-аути, невідповідності шифрів, проблеми з проміжними сертифікатами.
Антиспам перетворив доставку пошти на політику: сучасні «4xx deferrals» часто відображають оцінку репутації, а не зламану інфраструктуру.
Ідентифікатори черги стали судовими артефактами: можливість простежити одне повідомлення крізь повторні спроби — одна з найкорисніших операційних властивостей MTA.

Одна цитата, яку варто тримати на стікері біля терміналу:
Успіх робить системи простими на вигляд; відмова виявляє заплутану реальність того, як робота справді відбувається. від Richard Cook.

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

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

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

cr0x@server:~$ mailq | tail -n 20
-- 5234 Kbytes in 412 Requests.
-- 18452 Kbytes in 1923 Requests.
-- 23686 Kbytes in 2335 Requests.

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

Рішення: Якщо кількість запитів зростає, поки не чіпайте паралельність. Перейдіть до аналізу причин (Завдання 3) і перевірки локального стану (Завдання 5/6).

Завдання 2: Отримайте структурований підсумок черги (Postfix)

cr0x@server:~$ postqueue -p | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5*    1487 Thu Jan  3 10:21:52  alerts@example.com
                                         user@remote.tld
F6G7H8I9J0     9210 Thu Jan  3 10:22:01  billing@example.com
                                         finance@remote.tld

-- 23686 Kbytes in 2335 Requests.

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

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

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

cr0x@server:~$ sudo grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 20
Jan  3 10:23:10 server postfix/smtp[21944]: A1B2C3D4E5: to=<user@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=120, delays=0.2/0.1/60/59, dsn=4.4.1, status=deferred (connect to mx.remote.tld[203.0.113.7]:25: Connection timed out)
Jan  3 10:23:12 server postfix/smtp[21947]: F6G7H8I9J0: to=<finance@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=90, delays=0.2/0.1/30/59, dsn=4.7.0, status=deferred (host mx.remote.tld[203.0.113.7] said: 421 4.7.0 Try again later)

Значення: Причина вказана в дужках. Тайм-аути кричать про мережу/egress/DNS; 421/4.7.0 часто означає обмеження швидкості або проблеми з репутацією.
Розбиття delays= — золото: воно показує, де було витрачено час (до менеджера черги, DNS, підключення, передача).

Рішення: Якщо домінантна причина — connect timeout, тестуйте зв’язність (Завдання 11). Якщо це 421/4.7.0, перевіряйте шаблони відправлення і віддалене обмеження (Завдання 14).

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

cr0x@server:~$ sudo grep "status=deferred" /var/log/mail.log | sed -n 's/.*status=deferred (//p' | sed 's/)$//' | sort | uniq -c | sort -nr | head
  842 connect to mx.remote.tld[203.0.113.7]:25: Connection timed out
  311 host mx.other.tld[198.51.100.9] said: 421 4.7.0 Try again later
   97 TLS is required, but our TLS engine is unavailable
   52 lost connection with mx.third.tld[192.0.2.10] while receiving the initial server greeting

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

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

Завдання 5: Перевірте місце на диску там, де Postfix зберігає черги

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   38G  1.2G  97% /

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

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

Завдання 6: Перевірте закінчення inode (тихий вбивця)

cr0x@server:~$ df -i /var/spool/postfix
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2      2621440 2619000   2440  100% /

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

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

Завдання 7: Визначте, чи обмежений ви по I/O (iowait і затримки)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/03/2026 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    5.01   48.22    0.00   34.46

Device            r/s     w/s   rKB/s   wKB/s  avgrq-sz avgqu-sz   await  svctm  %util
sda              4.00  220.00   120.0  9800.0     86.2      9.8   44.10   3.20  72.00

Значення: Високий iowait і високий await означають, що диск не встигає. Черги пошти чутливі до поведінки fsync дрібних файлів.

Рішення: Не намагайтеся спочатку тонко налаштовувати Postfix. Виправте сховище: перемістіть спул на швидкий диск/SSD, зменшіть конкуруючі I/O або змініть політику зберігання в віртуальному оточенні.

Завдання 8: Перевірте стан служби 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 Thu 2026-01-03 09:01:02 UTC; 1h 22min ago
   Main PID: 1021 (master)
      Tasks: 68 (limit: 18945)
     Memory: 212.4M
        CPU: 18min 12.301s

Значення: «Active (running)» необхідно, але недостатньо. Важливо, чи дочірні процеси зависли або перезапускаються.

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

Завдання 9: Шукайте завислі smtp-процеси та довгі часи виконання

cr0x@server:~$ ps -eo pid,etime,cmd | grep -E "postfix/smtp|postfix/local" | head
21944 00:10:12 postfix/smtp -t unix -u -c
21947 00:09:58 postfix/smtp -t unix -u -c
21950 00:00:03 postfix/local -t unix -u

Значення: Багато smtp-процесів з довгим часом виконання свідчать про зависання при підключенні/TLS або про те, що віддалені сервіси «тарт-піттять» (tar-pitting).

Рішення: Перевірте розбиття затримок у логах (Завдання 3) і протестуйте TCP/TLS із цього хоста (Завдання 11, Завдання 12).

Завдання 10: Перевірте швидкість і правильність DNS-розв’язування

cr0x@server:~$ dig +tries=1 +time=2 mx remote.tld
;; ANSWER SECTION:
remote.tld.          300     IN      MX      10 mx.remote.tld.
remote.tld.          300     IN      MX      20 mx2.remote.tld.

;; Query time: 1789 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Jan 03 10:25:55 UTC 2026

Значення: Майже 2 секунди для простого MX-запиту — погано. Помножте це на тисячі доставок — отримаєте чергу.

Рішення: Виправте затримки резольвера: перевірте systemd-resolved/unbound, upstream DNS, втрату пакетів або неправильно налаштовані search-домени.

Завдання 11: Перевірте вихідну TCP-з’єднуваність по порту 25 (не гадати)

cr0x@server:~$ nc -vz -w 3 mx.remote.tld 25
Connection to mx.remote.tld (203.0.113.7) 25 port [tcp/smtp] succeeded!

Значення: TCP працює. Якщо ви все ще отримуєте тайм-аути в Postfix, підозрюйте переривчасту втрату пакетів, stateful firewall або виснаження таблиці NAT.

Рішення: Якщо TCP не вдається, ескалюйте до мережі: egress ACL, блокування SMTP у провайдера, виснаження NAT або upstream-фільтрація.

Завдання 12: Перевірте STARTTLS-рукопотискання до віддаленого MX

cr0x@server:~$ openssl s_client -starttls smtp -connect mx.remote.tld:25 -servername mx.remote.tld -brief < /dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx.remote.tld
Verification: OK
250 SMTPUTF8

Значення: TLS-рукопотискання здорове. Якщо в логах Postfix є помилки TLS, підозрюйте проблеми з локальним CA-бандлом, невідповідність SNI або старий OpenSSL.

Рішення: Якщо рукопотискання зависає, тимчасово зменшіть тайм-аути DNS/TLS і розслідуйте проміжні пристрої, що ламають STARTTLS.

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

cr0x@server:~$ postqueue -p | awk 'NR%2==1{print $7}' | sed 's/[<>]//g' | sort | uniq -c | sort -nr | head
  8123 noreply@app.internal
  1432 alerts@example.com
   611 billing@example.com

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

Рішення: Тимчасово обмежте або заблокуйте головного порушника, і зв’яжіться з відповідальною командою. Стабілізуйте пропускну здатність перед тим, як «виправляти пошту».

Завдання 14: Визначте топ-призначення (хто відхиляє вас)

cr0x@server:~$ postqueue -p | awk 'NR%2==0{print $1}' | sed 's/[<>]//g' | awk -F@ '{print $2}' | sort | uniq -c | sort -nr | head
  9321 remote.tld
  2210 other.tld
   809 bigmail.example

Значення: Якщо один домен домінує, ви можете сфокусуватися: перевірте доступність їхніх MX, вашу репутацію, їхні повідомлення про відкладення і швидкість відправлення до них.

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

Завдання 15: Проінспектуйте конкретне повідомлення в черзі (Postfix)

cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,30p'
*** ENVELOPE RECORDS ***
message_size:            1487             1487
message_arrival_time: Thu Jan  3 10:21:52 2026
sender: alerts@example.com
*** MESSAGE CONTENTS ***
Received: from app.internal (app.internal [10.0.10.5])
	by server with ESMTP id A1B2C3D4E5
	for <user@remote.tld>; Thu, 03 Jan 2026 10:21:52 +0000 (UTC)
Subject: Alert: backend latency

Значення: Підтверджує відправника, отримувача та внутрішню передачу. Корисно для виявлення петлів пошти, підробки або конкретного орендаря, що створює навантаження.

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

Завдання 16: Підтвердіть розмір директорії черги та кількість файлів

cr0x@server:~$ sudo du -sh /var/spool/postfix/deferred /var/spool/postfix/active
3.8G	/var/spool/postfix/deferred
126M	/var/spool/postfix/active

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

Значення: Домінування deferred означає, що ви в більшості чекаєте на віддалені умови (або DNS/TLS/egress). Кількість файлів важлива для inode і накладних витрат на обходи директорій.

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

Завдання 17: Слідкуйте за швидкістю очищення черги в реальному часі

cr0x@server:~$ watch -n 5 "postqueue -p | tail -n 1"
Every 5.0s: postqueue -p | tail -n 1

-- 23686 Kbytes in 2335 Requests.

Значення: Вам важливий нахил (slope), а не одне число. Якщо це число не падає після вашої правки, ви не виправили вузьке місце.

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

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

cr0x@server:~$ sudo grep "said: 4" /var/log/mail.log | tail -n 20
Jan  3 10:24:01 server postfix/smtp[21947]: F6G7H8I9J0: to=<finance@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=90, dsn=4.7.0, status=deferred (host mx.remote.tld[203.0.113.7] said: 421 4.7.0 Try again later)

Значення: 4xx — тимчасове відхилення; віддалений бік явно просить вас зменшити швидкість або повернутися пізніше.

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

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

Поширені вузькі місця та режими відмов

1) Диск і файлові системи (класика)

Поштова черга — фабрика дрібних файлів. Багато операцій метаданих, fsync, пошуки в директоріях і багато «записати трохи, перейменувати, unlink».
Якщо ваша черга на повільному мережевому сховищі, переповнених дисках VM або майже повній файловій системі, доставки сповільняться, навіть якщо CPU простий.

Ознаки, специфічні для сховища:

Високий iowait, високий await, помірний пропуск.
Процеси менеджера черги блокуються на I/O; «active» зростає і залишається високим.
Записи логів відстають; часові мітки в логах стрибкоподібні.

Що робити:

Перемістіть спул на локальний SSD, де можливо.
Тримайте /var з достатнім запасом; 20% вільного — не розкіш, а операційна необхідність.
Не розміщуйте поштові спули разом із системами з інтенсивними логами, етапами резервного копіювання або будь-чим, що робить великі послідовні записи.

2) Повільний DNS-резольвер (смерть від тисячі запитів)

Кожна вихідна доставка включає DNS: MX-запит, A/AAAA, іноді TLSA, іноді перевірки SPF/DMARC залежно від конфігурації.
Якщо ваш резольвер повільний, ви фактично послідовно виконуєте доставки.

Типові корінні причини:

systemd-resolved, що пересилає на ненадійний upstream DNS.
Firewall, що відкидає фрагменти або UDP-відповіді (проблеми EDNS).
Search-домени викликають повторний churn NXDOMAIN.
Поведінка IPv6: AAAA-запити проходять, але реальна v6-мережа не працює.

3) Блокування виходу в мережі та обмеження SMTP від провайдера

Багато хмарних мереж блокують вихідний порт 25 за замовчуванням. Деякі корпоративні фаєрволи «дружньо» перехоплюють SMTP і роблять що-знає-що.
Ознаки: тайм-аути при підключенні, спорадичні успіхи або «No route to host».

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

4) Помилки TLS та невідповідність політик

STARTTLS у багатьох конфігураціях опортуністичний, але в деяких середовищах дедалі обов’язковий. TLS приносить:
помилки верифікації сертифікатів, тайм-аути рукопотискань, невідповідність наборів шифрів і навіть баги в старих бібліотеках.

Слідкуйте за:

TLS is required, but our TLS engine is unavailable
SSL_accept error, no shared cipher
Довгі затримки під час фази підключення/рукопотискання в логах.

5) Віддалені ліміти швидкості та відмови через репутацію

Віддалий бік може бути працездатним. Просто він наразі вас не любить.
Масові сплески, нові IP для відправлення, неправильно налаштовані SPF/DKIM/DMARC або незвичні патерни bounce’ів можуть викликати тротлінг.

Операційний підхід:

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

6) Фільтрація вмісту та milters (прихована серіалізація)

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

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

7) Неправильний графік повторів і тривалість життя черги

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

Жарт №2: Поштова черга — як ваш абонемент у спортзал — якщо ігнорувати її довго, вона все одно залишиться, тихо засуджуючи вас.

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

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

Середня компанія запускала Postfix на парі VM за балансиром навантаження. У них було «просте» припущення:
вихідна пошта не критична інфраструктура, бо «ми завжди можемо надіслати знову». Це припущення трималося до тижня виплат.

Черга почала повільно зростати після зміни мережі. Логи показували тайм-аути підключень до кількох доменів, але не до всіх.
Інженер на чергуванні припустив, що віддалені домени нестабільні, і чекав. До ранку deferred-черга була величезною, диск майже заповнений.
Потім Postfix почав викидати помилки, пов’язані зі створенням файлів та очищенням.

Справжня причина була соромно локальна: вихідний порт 25 був заблокований для одного з NAT-шлюзів під час розгортання правил фаєрволу.
Частина трафіку проходила; частина тайм-аутилась. «Частковий успіх» збив усіх з пантелику.
Через консервативні повтори відмови накопичувалися непомітно.

Виправлення не було героїчним: поправили правила фаєрволу, спорожнили чергу і додали синтетичну перевірку виходу TCP/25 з кожного вузла щохвилини.
Урок цінніший за сам інцидент: ніколи не припускайте, що «деяка пошта працює» означає «пошта в порядку».

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

Інша організація мала реальні проблеми з пропускною здатністю. Маркетинг хотів швидшої доставки кампаній; інженерія — менше скарг.
Хтось підняв налаштування паралельності Postfix по всьому середовищу. Черга дійсно спала швидше — приблизно годину.

Потім почалися віддалені відхилення: багато 421 і 4.7.x «try again later». Основні отримувачі почали тарпітити з’єднання.
MTA утримував багато smtp-процесів відкритими, кожен чекав на привітання або повільну відповідь.
CPU піднявся, а ще гірше — використання дескрипторів файлів зросло і машина почала поводитися дивно.

Тим часом фільтр вмісту (milter) отримував сплески, на які він не розрахований.
Він почав тайм-аутитися, що викликало нові відхилення, які породжували ще більше повторів, що збільшувало сплески.
Так будується зворотний зв’язок: взяти систему під навантаження і «оптимізувати» її у самонашкодження.

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

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

Фінансова компанія мала невеликий флот вихідних MTA. Нічого надзвичайного — лише дисципліновано.
Вони тримали поштові спули на локальних SSD, агресивно обертали логи, закріпили резольвери на відомих коректних інстансах і моніторили розподіл віку черги.

Одного дня один upstream-резольвер почав періодично відмовляти. У багатьох систем компанії виникли проблеми, але поштовий флот не впав.
Їхні панелі показували зростання затримки DNS-запитів, але черга залишалася стабільною.

Чому? У кожного поштового хоста був локальний кешуючий резольвер із розумними тайм-аутами і «теплим» кешем.
Вони також мали алерти не лише на розмір черги, а й на «вік найстарішого deferred-повідомлення» і «кількість різних причин відкладень».
Ці оповіщення спрацювали рано, поки черга була ще керованою.

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

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

Симптом: Черга росте, переважно deferred, з «connect timed out».
Корінна причина: Вихідний TCP/25 заблокований, переривчаста маршрутизація або виснаження таблиці NAT.
Виправлення: Перевірте TCP/25 за допомогою nc; перевірте політику фаєрволу/egress; підтвердіть місткість NAT; розгляньте relay-smarthost.
Симптом: Черга росте, домінує «Try again later» (421/4.7.0).
Корінна причина: Віддалене обмеження або тротлінг через репутацію; вибухоподібні шаблони відправлень.
Виправлення: Розподіл по доменах, сегментація трафіку, зменшення паралельності, виправлення SPF/DKIM/DMARC та обробки bounce.
Симптом: Active-черга висока, CPU низький, iowait високий.
Корінна причина: Затримка диска на томі спула; переповнене сховище; майже повна файлова система.
Виправлення: Перемістіть спул на швидше сховище; звільніть місце/inode; ізолюйте від іншого I/O; підтвердіть за допомогою iostat.
Симптом: Спорадичні відмови, довгі затримки перед підключенням, високий час DNS-запиту.
Корінна причина: Затримки резольвера, EDNS/фрагментація, неправильно налаштовані search-домени.
Виправлення: Виправте шлях DNS; запустіть локальний кеш; зменшіть тайм-аути резольвера; перевірте часи dig.
Симптом: TLS-пов’язані відкладення з’явилися після оновлення ОС або зміни сертифіката.
Корінна причина: Невідповідність CA-бандлу, зміни OpenSSL, застосування політики TLS без підтримки.
Виправлення: Перевірте за допомогою openssl s_client; підтвердіть CA-store; обережно коригуйте TLS-політику.
Симптом: Черга величезна, але домінує лише один внутрішній відправник.
Корінна причина: Шторм повторів застосунку, погана логіка чергування або скомпрометований обліковий запис.
Виправлення: Обмежте відправника на MTA; тимчасово заблокуйте; виправте поведінку застосунку; оновіть облікові дані.
Симптом: Черга росте і в логах з’являється «warning: database is locked» або подібне для карт.
Корінна причина: Суперечливі пошукові карти (наприклад, локальні БД), карти на NFS або повільний LDAP.
Виправлення: Перенесіть карти локально, змініть бекенд карт, кешуйте запити і ізолюйте залежності.
Симптом: Черга спадає надто повільно навіть після виправлення мережі.
Корінна причина: Занадто консервативний графік повторів; занадто мало smtp-воркерів; надто тісні обмеження per-domain.
Виправлення: Тимчасово підвищте паралельність і швидкість доставки після усунення вузького місця; стежте за рівнем помилок і відхилень.

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

Чек-лист A: Перші 10 хвилин (утримання і збір сигналів)

Зробіть знімок ситуації. Зафіксуйте розмір черги, вік найстарішого повідомлення (якщо відстежуєте) та топ причин відкладень (Завдання 1–4).
Підтвердіть локальний диск та inode. Якщо щось критичне, виправте це спочатку (Завдання 5–6). Повний диск перетворює проблему доставки на проблему втрати даних.
Перевірте затримку DNS і вихідний TCP/25. Валідируйте з хоста MTA, а не з вашого ноутбука (Завдання 10–12).
Визначте топ-відправника і топ-домени призначення. Обмежте потік рано (Завдання 13–14).
Комунікуйте. Повідомте зацікавленим особам: «Вихідна доставка затримується; вхідний прийом поки працює (або ні). Наступне оновлення через 30 хвилин.»

Чек-лист B: Стабілізація пропускної здатності (зупинити кровотечу)

Зменшіть вхідний потік за потреби. Якщо один застосунок зливає чергу, обмежте його на рівні MTA або фаєрволу. Так, вас будуть сварити; зробіть це.
Виправте головну причину відкладень. Не ганяйтеся за десятьма дрібними проблемами, коли одна домінує (Завдання 4).
Віддавайте перевагу налаштуванню по домену перед глобальною зміною. Якщо один домен вас тротлить, не карайте всіх інших.
Переконайтеся, що I/O спула здоровий. Перемістіть черги на швидке сховище, якщо треба; черги — не місце економії.
Перевірте швидкість спорожнення. Слідкуйте за нахилом (Завдання 17). Якщо нахил покращується — не чіпайте систему.

Чек-лист C: Відновлення та очищення (після того, як черга почала спадати)

Підтвердіть поведінку bounce. Переконайтеся, що ви не генеруєте backscatter або петлі bounce.
Перевірте політику повторів. Переконайтеся, що ви не будете тримати повідомлення днями, коли бізнес вже не потребує їх.
Контроль після інциденту. Додайте алерти на вік черги і причини відкладень, а не лише на розмір черги.
Зробіть невеликий навантажувальний тест. Якщо ви змінили паралельність або перемістили спули, перевірте, що ви не створили нове вузьке місце.
Документуйте «топ-3» причин і перевірок. Майбутній ви не такий розумний о 03:00.

Часті питання

1) Чи варто просто промити (flush) чергу?

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

2) Коли можна видаляти закешовану пошту?

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

3) Чому черга переважно deferred, а не active?

Deferred означає, що спроби були зроблені і тимчасово зазнали невдачі. Зазвичай це віддалена політика, DNS/TLS/egress проблеми або залежності фільтрації вмісту, які відмовили у прийомі.
Домінування active більше вказує на локальну обробку або I/O-обмеження.

4) Як зрозуміти, що DNS — вузьке місце?

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

5) Чи може майже повний диск спричинити затримки до фактичного заповнення?

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

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

Тому що вони себе захищають: ліміти швидкості, контролі репутації, greylisting або захист від перевантаження.
Сприймайте 4xx як сигнал темпу, а не як особисту образу.

7) Чи завжди погано збільшувати паралельність?

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

8) На які метрики варто ставити алерти, окрім розміру черги?

Алертуйте на вік найстарішого повідомлення, співвідношення deferred до active, кількість основних причин відкладень, затримку DNS-запитів з MTA, запас диску/inode на томі спула
і показники успішності виходу TCP/25.

9) Як зрозуміти, що фільтр вмісту сповільнює нас?

Шукайте тайм-аути або відкладення, що посилаються на milter/сервіс політики, високі лічильники підключень до фільтра або зростання затримок у частині «до менеджера черги» в логах.
Якщо фільтр серіалізує роботу, черга зростає, хоча віддалена зв’язність у порядку.

10) Чому черга продовжує рости навіть після «виправлення мережі»?

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

Наступні кроки, які варто виконати

Якщо черга електронної пошти продовжує рости, не ставтеся до неї як до загадкового об’єкта, що потребує «тонкого налаштування». Ставтеся до неї як до backlog з причиною.
Назвіть домінуючу причину відкладень. Перевірте локальний диск і DNS. Доведіть вихідну зв’язність. Визначте топ-відправника і топ-призначення.
Потім робіть одну зміну за раз і стежте за нахилом.

Практичні кроки на наступний робочий день:

Додайте алерти на вік найстарішого deferred-повідомлення і топ причин відкладень, а не лише на розмір черги.
Перенесіть або забезпечте поштовий спул на сховищі, перевіреному для I/O дрібних файлів. Якщо це звучить дорого — оцініть ціну простій.
Запустіть локальний кешуючий DNS-резольвер на поштових хостах (або використовуйте відомі хороші резольвери) і вимірюйте час запитів постійно.
Впровадьте пакетування по доменах і відокремте масову пошту від транзакційної, якщо надсилаєте великий обсяг.
Напишіть односторінковий рукопис з Швидким планом діагностики та топ-5 командами, які ви виконуватимете під навантаженням.