Повідомлення «message deferred»: розшифруйте, чому пошта зависає (і виправте це)

Що насправді означає «message deferred» (і чого це не означає)

У світі MTA (Postfix, Exim, Sendmail, SMTP-транспорту Exchange — обирайте що завгодно), «deferred» означає «ми спробували доставити, але отримали тимчасову помилку, тож повторимо пізніше». Це не відмова (bounce). Це не успіх. Це стан із прикріпленим годинником.

Більшість відкладень виникає через SMTP-відповіді 4xx (тимчасові). Подумайте: «421 — служба недоступна», «450 — поштовий ящик недоступний», «451 — локальна помилка», «452 — недостатньо місця в системі». MTA трактують це як «ще не час панікувати». Вони ставлять повідомлення в чергу й повторюють спроби за графіком. Якщо повтори постійно зазнають невдач і повідомлення перевищує максимальний час у черзі, воно перетворюється на bounce (5xx) або тихо видаляється, якщо ваша конфігурація… творчо недбала.

Відкладення — це симптом, а не діагноз

«Deferred» каже вам, де знаходиться повідомлення: все ще в вашій черзі. Воно не каже вам, чому. «Чому» завжди в деталях статусу: віддалена SMTP-відповідь, збій DNS, помилка TLS-переговорів, таймаут, локальна проблема з диском, відмова політики, ліміт швидкості або нездатність вашого MTA створити достатньо процесів доставки.

Два відкладення, що виглядають однаково, але різні за суттю

• Віддалене відкладення: ваш сервер підключився зовні, сервер одержувача сказав «спробуйте пізніше». Greylisting, обмеження швидкості, тимчасовий збій, черга сканування вмісту, системи репутації або «сьогодні ви нам не до вподоби».
• Локальне відкладення: ваш сервер навіть не зміг коректно спробувати доставку. DNS не розв’язався, мережевий шлях зламаний, диск повний, I/O черги повільний, бібліотеки TLS поводяться некоректно або ви досягли власних лімітів паралелізму.

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

Цитата, яка триматиме вас у тонусі: Надія — не стратегія. (Генерал Джеймс Н. Меттіс)

Жарт №1: Черги пошти як стопки брудної білизни — ігнорування їх не робить меншими, просто змушує уникати погляду на дашборд.

Швидка діагностика: перші/другі/треті перевірки

Це послідовність триажу з високим коефіцієнтом сигналу. Вона створена для продакшену: мінімальна перемикання контексту, максимальна ясність. Не починайте з читання 20к рядків логів. Почніть з знаходження вузького місця.

Перше: чи росте черга, і яка саме черга?

• Якщо роздувається active-черга, ваш MTA пробує, але блокується (видалений троттлінг, мережа, TLS, політика, конкуренція).
• Якщо роздувається deferred-черга, спроби зазнають невдач і відтерміновуються (таймаути, 4xx, DNS, віддалені збої).
• Якщо росте maildrop / черга подання, пошта не приймається у головну чергу (проблеми локального подання, дозволів, фільтра вмісту, диск, служба очищення).

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

Обирайте репрезентативне відкладене повідомлення (не якогось дивного одержувача). Витягніть точну SMTP-відповідь або локальну помилку. Один ряд часто дає 80% історії.

Третє: вирішіть, політика віддаленого чи ваша інфраструктура

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

Проблеми інфраструктури вимагають виправлення систем: DNS, диск, CPU, мережа, TLS, ліміти процесів або зламані залежності на кшталт фільтра вмісту.

Четверте: не робіть гірше

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

П’яте: стабілізуйте, потім виправляйте

Стабілізація означає зменшення темпу наростання беклогу: обмежте вихідний трафік, призупиніть неважливі відправники або направте через розумніше реле. Виправлення означає усунення кореневої причини: надійний DNS, I/O диска, TLS, відповідність політикам або проблеми віддалених переговорів.

Цікаві факти й контекст (чому взагалі існують deferral)

1. SMTP спроектовано для ненадійних мереж. Повторні спроби — це фіча, не хаки; store-and-forward — базова ідея.
2. 4xx vs 5xx — це операційний контракт. 4xx каже «спробуйте пізніше», 5xx каже «кінь згорів». Багато сучасних систем зловживають 4xx, щоб гальмувати вас без остаточної відмови.
3. Greylisting популяризував «відкладати як захист». Це озброїло повтори: легітимні MTA повторюють; багато спам-ботів — ні (або не чекають).
4. Тривалість життя черги за замовчуванням різниться в MTA. У Postfix часто дні; це означає, що «message deferred» може тихо перетворитися на багатоденну скаргу користувача, якщо ви не сповіщаєте про це.
5. DNS — частина транспорту пошти, не опціональні метадані. Якщо ваш резолвер поламаний, ваша пошта поламана. «Message deferred» буде вашим єдиним натяком.
6. MX-preference — це не балансування навантаження. Це пріоритет/фейловер. Люди досі «оптимізують» його в катастрофу.
7. TLS для SMTP за замовчуванням опортуністичний. Помилки STARTTLS можуть спричиняти відкладення, якщо політика вимагає шифрування або якщо після оновлення ОС з’явилися баги переговорів TLS.
8. Великі провайдери формують трафік 421. Вони можуть відкладати вас через обсяг, репутацію або раптові сплески — навіть якщо вміст вашого листа в порядку.
9. Черги пошти зберігаються на диску, бо RAM забуває. Коли сховище повільне, пошта стає повільною. Директорія черги — це залежність від продуктивності.

Основні режими відмов, що викликають відкладення

1) Віддалені тимчасові помилки (вони зайняті, обережні або дратівливі)

Поширені віддалені відповіді, що викликають відкладення:

• 421: служба недоступна (обслуговування, перевантаження, троттлінг)
• 450/451: тимчасово поштовий ящик або локальна помилка
• 452: недостатньо місця в системі (так, їхній диск — ваша проблема черги)
• 4.7.0 / 4.7.1: політика/репутація (відкладення «спробуйте пізніше», поки вирішують, чи ви спам)

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

2) Збої DNS (мовчазна залежність пошти)

Симптоми: рядки в логах типу «Host or domain name not found», «temporary lookup failure» або «no MX found». Корені часто включають:

• Зламаний / перевантажений локальний резолвер
• Фаєрвол блокує доступ до upstream DNS
• Проблеми валідації DNSSEC
• Неправильна конфігурація search domain, що викликає дивні таймаути

3) Проблеми з мережею (ви не можете до них дістатися)

Таймаути підключення, скиди, проблеми маршрутизації, MTU, зламані таблиці NAT — класичні SRE-проблеми з поштовою похідною помилкою. Якщо ви не можете завершити TCP-handshake на порт 25 (або 587 до реле), ви будете відкладати вічно.

4) Проблеми переговорів TLS/STARTTLS

Збої з’являються як «TLS handshake failed», «no shared cipher», «certificate verify failed» або «lost connection after STARTTLS». Часто спричиняють:

• Зміни криптополітики ОС після патчів
• Занадто сувора політика вихідного TLS для реального світу
• Проблемні middlebox, що виконують «корисну» TLS-інспекцію

5) Вичерпання локальних ресурсів (черзі дихати важко)

Якщо ваш диск повний, закінчилися іноди або він дуже повільний, повідомлення відкладатимуться, бо MTA не може оновлювати файли черги або коректно запускати доставки. Навантаження на CPU також може спричиняти таймаути і повільність. Так само і вичерпання лімітів процесів.

6) Фільтри вмісту та milters (ланцюжок залежностей, про який ви забули)

Антиспам/антивірус, підписування DKIM, демони політики, DLP-сканери — коли вони лукають або падають, ваш MTA може приймати пошту, але відкладати доставку або повільно пропускати все в беклог. Ви побачите тимчасові невдачі, що виглядають як віддалені проблеми, але насправді це локальні IPC-збійні.

7) Лімітування швидкості та невірні налаштування паралелізму

Postfix і Exim мають ручки для обмеження concurrency по домену, швидкості підключень і загального паралелізму. Занадто мало — ви повільні; занадто багато — вас троттлять або блокують. «Правильне» значення змінюється залежно від профілю трафіку і набору одержувачів.

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

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

Завдання 1: Підтвердьте розмір черги і яка черга зростає (Postfix)

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C12A1B8       4125 Mon Jan  4 09:01:22  alerts@example.com
(connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
                                         user@gmail.com

7D91B2F04C       2988 Mon Jan  4 09:02:10  noreply@example.com
(host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))
                                         ops@partner.tld

-- 2470 Kbytes in 312 Requests.

Значення: У вас вже є два різні класи відкладень: таймаут мережі до Google і віддалений 421 троттлінг/політика від partner.tld.

Рішення: Розділіть проблему. Досліджуйте підключення/таймаути окремо від політики домену-одержувача. Одне виправлення не вирішить обидва випадки.

Завдання 2: Швидко підсумуйте причини в черзі (стиль qshape/qgrep для Postfix)

cr0x@server:~$ postqueue -p | tail -n +2 | awk '/^[A-F0-9]/{id=$1} /connect to/{print id,$0} /said:/{print id,$0}' | head
3F2C12A1B8 (connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
7D91B2F04C (host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))
1AA09D0C11 (connect to mx.mail.yahoo.com[98.137.11.163]:25: Connection timed out)

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

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

Завдання 3: Перегляньте детальний статус одного повідомлення (Postfix)

cr0x@server:~$ postcat -q 3F2C12A1B8 | sed -n '1,40p'
*** ENVELOPE RECORDS 3F2C12A1B8 ***
message_size:            4125            236               1               0            4125
message_arrival_time: Mon Jan  4 09:01:22 2026
create_time: Mon Jan  4 09:01:22 2026
named_attribute: log_ident=3F2C12A1B8
sender: alerts@example.com
recipient: user@gmail.com
*** MESSAGE CONTENTS 3F2C12A1B8 ***
Received: from app01.example.com (app01.example.com [10.10.10.21])
        by mx01.example.com (Postfix) with ESMTPS id 3F2C12A1B8
        for <user@gmail.com>; Mon,  4 Jan 2026 09:01:22 +0000 (UTC)
Subject: Alert: latency spike

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

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

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

cr0x@server:~$ sudo journalctl -u postfix -f
Jan 04 09:06:11 mx01 postfix/smtp[22108]: 3F2C12A1B8: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=289, delays=0.1/0.01/289/0, dsn=4.4.1, status=deferred (connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
Jan 04 09:06:14 mx01 postfix/smtp[22110]: 7D91B2F04C: to=<ops@partner.tld>, relay=mx1.partner.tld[203.0.113.10]:25, delay=244, delays=0.1/0.02/30/214, dsn=4.7.0, status=deferred (host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))

Значення: Розклад delays= — золото. Тут більшість часу витрачається в третій і четвертій стадіях (мережа/TCP та час відповіді віддаленого SMTP).

Рішення: Для таймаутів — перевіряйте мережу/фаєрвол. Для 421 в кінці DATA — підозрюйте backlog сканування вмісту або троттлінг: зменшіть конкуренцію й змініть графік повторів по домену.

Завдання 5: Перевірте доступність TCP на порт 25 з хоста

cr0x@server:~$ nc -vz gmail-smtp-in.l.google.com 25
nc: connect to gmail-smtp-in.l.google.com (142.250.102.26) port 25 (tcp) timed out: Operation now in progress

Значення: Це не проблема політики SMTP. Ви навіть не можете відкрити TCP-сесію.

Рішення: Перевірте правила egress фаєрволу, блокування провайдера, перевантаження NAT або маршрутизацію. Якщо ви в хмарі, підтвердіть, що вихід на порт 25 не блокується політикою.

Завдання 6: Підтвердіть маршрутизацію й IP джерела для вихідної пошти

cr0x@server:~$ ip route get 142.250.102.26
142.250.102.26 via 198.51.100.1 dev eth0 src 198.51.100.23 uid 1000
    cache

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

Рішення: Якщо таймаути/відкладення специфічні для певних провайдерів, перевірте, чи цей IP у проблемному діапазоні або чи ваш ISP блокує 25. Якщо у вас є кілька egress-IP, подумайте про переміщення вихідного SMTP на чистий IP.

Завдання 7: Перевірте надійність розв’язування DNS (A/MX) з хоста MTA

cr0x@server:~$ dig +time=2 +tries=1 mx partner.tld
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14152
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; ANSWER SECTION:
partner.tld.     300 IN MX 10 mx1.partner.tld.
partner.tld.     300 IN MX 20 mx2.partner.tld.

;; Query time: 21 msec
;; SERVER: 10.0.0.53#53(10.0.0.53)
;; WHEN: Mon Jan 04 09:08:44 UTC 2026
;; MSG SIZE  rcvd: 132

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

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

Завдання 8: Перевірте ідентичність вашого hostname і зворотний DNS (PTR)

cr0x@server:~$ hostname -f
mx01.example.com

cr0x@server:~$ dig +short -x 198.51.100.23
mx01.example.com.

Значення: Прямий і зворотний ідентифікатори співпадають. Невідповідність PTR не завжди спричиняє відкладення, але часто є складником «421 try again later» від суворих приймачів.

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

Завдання 9: Протестуйте SMTP-діалог і подивіться на реальну віддалену поведінку

cr0x@server:~$ swaks --to ops@partner.tld --server mx1.partner.tld --timeout 20
=== Trying mx1.partner.tld:25...
=== Connected to mx1.partner.tld.
<--- 220 mx1.partner.tld ESMTP
---> EHLO mx01.example.com
<--- 250-mx1.partner.tld
<--- 250-STARTTLS
---> STARTTLS
<--- 220 2.0.0 Ready to start TLS
=== TLS started with cipher TLS_AES_256_GCM_SHA384
---> MAIL FROM:<test@example.com>
<--- 250 2.1.0 Ok
---> RCPT TO:<ops@partner.tld>
<--- 250 2.1.5 Ok
---> DATA
<--- 354 End data with <CR><LF>.<CR><LF;
---> .
<--- 421 4.7.0 Try again later

Значення: Віддалений сервер приймає конверт, але відкладає в кінці DATA. Це зазвичай вказує на backlog сканування вмісту, оцінку політики або формування швидкості, що тригериться після бачення заголовків/тіла.

Рішення: Зменшіть пропускну здатність до цього домену, переконайтеся в коректності DKIM/SPF/DMARC та в тому, що ви не надсилаєте раптових сплесків. Якщо це партнер — погодьтеся з їхньою командою пошти.

Завдання 10: Перевірте місце на диску та тиск інодів (черга живе на диску)

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   39G  900M  98% /var

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

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

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

Завдання 11: Підтвердіть, що служби Postfix працюють і не зависли

cr0x@server:~$ sudo postfix status
postfix/postfix-script: the Postfix mail system is running: PID: 1047

cr0x@server:~$ sudo postconf -n | egrep 'queue_directory|myhostname|myorigin|relayhost|default_process_limit'
queue_directory = /var/spool/postfix
myhostname = mx01.example.com
myorigin = /etc/mailname
relayhost =
default_process_limit = 100

Значення: Базова санітарна перевірка: Postfix працює, директорія черги стандартна, ліміт процесів 100.

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

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

cr0x@server:~$ sudo postconf -n | egrep 'smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_connect_timeout|smtp_helo_timeout'
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
smtp_connect_timeout = 30s
smtp_helo_timeout = 300s

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

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

Завдання 13: Перевірте активні SMTP-клієнтські підключення та локальне виснаження

cr0x@server:~$ sudo ss -tanp '( dport = :25 )' | head
State  Recv-Q Send-Q Local Address:Port    Peer Address:Port    Process
SYN-SENT 0     1     198.51.100.23:41220  142.250.102.26:25   users:(("smtp",pid=22108,fd=6))
SYN-SENT 0     1     198.51.100.23:41222  98.137.11.163:25    users:(("smtp",pid=22113,fd=6))
ESTAB    0     0     198.51.100.23:41210  203.0.113.10:25     users:(("smtp",pid=22110,fd=6))

Значення: Багато записів у стані SYN-SENT означає, що вихідні підключення не завершуються. Це або проблема upstream-мережі, або фільтрація віддаленими сторонами.

Рішення: Якщо SYN зависають до багатьох адрес — в пріоритеті перевірка мережі/egress. Якщо багато ESTAB, але відповіді повільні — зверніть увагу на троттлінг/TLS.

Завдання 14: Перевірте OS-ліміти дескрипторів файлів (черга й smtp дуже файлові)

cr0x@server:~$ sudo -u postfix sh -c 'ulimit -n'
1024

Значення: 1024 FD для користувача postfix може бути замало при великому обсязі, особливо якщо є фільтри вмісту й багато одночасних доставок.

Рішення: Якщо в логах є «too many open files» або випадкові відкладення під навантаженням — підніміть ліміти через systemd override і OS-limits. Потім перевірте, що нові ліміти дійсно застосовані до процесів Postfix.

Завдання 15: Перегляд очима Exim (якщо ви на Exim)

cr0x@server:~$ sudo exim -bp | head
1tUQz7-0004cR-7p  2.1K Mon 04 Jan 2026 09:02:10  noreply@example.com
  ops@partner.tld

1tUQz8-0004cU-9B  4.0K Mon 04 Jan 2026 09:01:22  alerts@example.com
  user@gmail.com

cr0x@server:~$ sudo exim -Mvh 1tUQz8-0004cU-9B | egrep -i 'defer|retry|error|dsn' | head
-host_address 142.250.102.26
-error_message connect to 142.250.102.26 port 25: Connection timed out

Значення: Та сама історія, інструменти інші: Exim зберігає причину в заголовках/логах для цього запису черги.

Рішення: Якщо Exim показує таймаути мережі — ідіть у мережу. Якщо він показує явні 4xx політики — працюйте з доставкою/троттлінгом.

Завдання 16: Перевірте, чи ваш резолвер не підвисає час від часу

cr0x@server:~$ for i in $(seq 1 5); do dig +time=1 +tries=1 mx gmail.com | grep 'Query time'; done
;; Query time: 19 msec
;; Query time: 21 msec
;; Query time: 1001 msec
;; Query time: 19 msec
;; Query time: 20 msec

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

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

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

1) «Все відкладається до Gmail»

Симптом: connect to gmail-smtp-in.l.google.com:25: Connection timed out

Корінь: Вихідний порт 25 заблокований провайдером/хмарою, або egress-фаєрвол/NACL, або зламане маршрутування/вичерпання NAT.

Виправлення: Підтвердіть за допомогою nc -vz і ss. Заберіть блокування або маршрутизируйте вихідну пошту через реле на 587 з автентифікацією, якщо порт 25 політично заблокований.

2) «Deferred (host said: 421 4.7.0 Try again later)» після DATA

Симптом: Віддалений приймає RCPT, потім відкладає після DATA.

Корінь: Беклог сканування вмісту, формування швидкості або система репутації, що спрацьовує по заголовках/тілу, сплеску обсягу або невідповідності ідентичності (PTR/HELO/SPF/DKIM).

Виправлення: Зменшіть конкуренцію по домену, додайте затримку, переконайтесь, що DKIM стабільно підписує, SPF включає ваш IP, вирівняйте rDNS і HELO. Якщо це партнер — узгодьте allowlisting і очікування щодо обсягу.

3) «Temporary lookup failure» / «Host not found»

Симптом: DNS-пов’язані DSN або рядки в логах, часто періодично.

Корінь: Таймаути резолвера, зламаний DNSSEC, outage upstream або неправильно налаштований /etc/resolv.conf з «мертвими» серверами.

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

4) Черга росте, диск наче в порядку, але доставки повільні

Симптом: Немає явних помилок, просто повільна пошта й зростання deferred.

Корінь: Затримка I/O диска (не ємність) або вичерпання інодів — часто на /var, який використовується і логами, і даними застосунків.

Виправлення: Заміряйте за допомогою iostat/pidstat, перемістіть spool на швидше сховище, відокремте файлову систему, збільште іноди й перестаньте коспонувати «чергу пошти» з усім іншим, що багато пише.

5) «TLS handshake failed» і раптом все відкладено після патчу

Симптом: Помилки STARTTLS до деяких доменів, не до всіх.

Корінь: Зміна криптополітики (шифри/протоколи), застарілі пірингові сервери або ваша власна надто сувора TLS-політика.

Виправлення: Вирішіть політику: опортуністичний TLS чи обов’язковий. Якщо обов’язковий — можливо потрібні пер-доменні винятки. Якщо опортуністичний — пом’якшіть локальні обмеження, які надто суворі для SMTP-реальності.

6) «Я змив чергу, і стало ще гірше»

Симптом: Більше відкладень, нові блоки, довші затримки.

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

Виправлення: Троттлінгуйте. Формуйте трафік. Дозвольте повторним спробам робити свою роботу. Змивайте лише після усунення кореня, і навіть тоді — поступово.

Три короткі історії з корпоративних «траншей» пошти

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

Середня компанія перемістила основний додаток із колокації в cloud VPC. Вони залишили VM з поштовим сервером «бо він уже працює». План міграції включав бази даних, кеші і шар додатка. Пошта була як тостер: підключив — гріє хліб.

В понеділок транзакційні листи перестали доходити до великих споживчих доменів. Черга росла. Логи показували connect to ...:25: Connection timed out. Команда аплікацій думала, що Gmail впав або «лімітує». Мережна команда думала, що поштовики неправильно налаштували Postfix. Усі помилково координували свої помилки.

Корінь був прозаїчним: вихідний TCP/25 був заблокований політикою хмарного провайдера за замовчуванням для того облікового запису. Поштовий сервер міг розв’язувати DNS і підключатися до внутрішніх сервісів, тож моніторинг виглядав нормально. Лише порт, що важливий для SMTP, тихо відмовляв.

Вони витратили години на тонке налаштування concurrency і інтервалів повторів — фактично оптимізуючи радіо в машині без двигуна. Коли хтось запустив nc -vz із хоста і побачив таймаут, діагностика стала очевидною. Тимчасово вони маршрутизували вихідну пошту через автентифіковане реле на 587, поки чекали винятку політики.

Урок: не думайте, що «мережа відкрита», бо SSH працює. SMTP залежить від конкретних egress-шляхів, а хмарні налаштування за замовчуванням можуть бути не вашими друзями.

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

Глобальна корпорація мала легітимний сплеск обсягу: квартальні виписки, скидання паролів і маркетингова кампанія, про яку ніхто не зізнавався. Їхній кластер MTA був здоровий, але кількість відкладень зростала проти кількох великих отримувачів з відповідями 421 4.7.0.

Інженер помітив, що ліміт concurrency по домену «консервативний» і підняв його. Потім підняв ще. Пропускна здатність покращилась — десь на 20 хвилин. Потім віддалені почали відкладати частіше і довше. Деякі переходили з 4xx у жорсткі блоки. Час доставки виріс з хвилин до годин.

Чому? Приймальники не були проблемно обмежені суто по пропускній здатності. Вони застосовували політики і формували трафік. Більша конкуренція виглядала як зловживання, навіть якщо вміст був нормальний. MTA став дуже ввічливим молотком, який постійно стукав по одному і тому ж цвяху, поки одержувач не пішов з кімнати.

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

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

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

Фінансова фірма запускала вихідну пошту з двох MTA в active-active режимі, попередньо через шар реле. Нічого особливого. Особливе було в дисципліні: окрема файлова система для /var/spool/postfix, алерти по використанню інодів та щоденний зразок причин відкладень (не лише лічильники).

Одного ранку відкладення піднялися, але лише для підмножини напрямків. Черга ще не вибухнула. Їхній алерт був не «черга > X», а «основна причина відкладень змінилася». Це дорослий алерт: він виявив новий режим відмов раніше, ніж обсяг став критичним.

Нова причина була TLS-переговори, що почали падати до певних старих серверів після оновлення ОС. Команда мала заздалегідь написаний плейбук: підтвердити тестом SMTP, відкотити зміну криптополітики тільки для SMTP і зберегти інші патчі без змін. Ніякої драми, ніяких all-hands.

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

Урок: нудні практики — відділені spool, алерти на іноди, моніторинг причин — не здаються героїчними. Вони такими є. Вони рятують від суворих уроків у робочий час.

Чеклісти / покроковий план (стабілізувати, виправити, запобігти)

Крок 1: Стабілізуйте зону ураження (15 хвилин)

• Припиніть повторні змиви черги. Якщо хтось змиває кожні п’ять хвилин — чемно заберіть клавіатуру.
• Визначте топ-1–3 причин відкладень з логів і виводу черги. Не ганяйтеся за рідкісними винятками на початку.
• Троттлінгуйте вихідний трафік до найгіршопостраждалих доменів, якщо вони віддають 421/4.7.0.
• Підтвердіть диск/іноди на файловій системі спулу й звільніть місце, якщо потрібно.
• Підтвердіть розв’язування DNS стабільне й швидке з хоста MTA.

Крок 2: Виправте корінь (30–120 хвилин)

• Якщо таймаути: перевірте вихідний порт 25, маршрутизацію, фаєрвол, стан NAT та блокування провайдера.
• Якщо віддалений 421 троттлінг: налаштуйте concurrency/rate по домену, згладьте сплески трафіку, перевірте ідентичність відправника (PTR/HELO/SPF/DKIM).
• Якщо TLS-збої: відтворіть тестом до одного віддаленого, потім відрегулюйте SMTP TLS-політику відповідно до операційних реалій.
• Якщо вузьке місце фільтра вмісту: перевірте здоров’я milters/сервісів, черги й таймаути. Якщо він впав — вирішіть, чи тимчасово обходити (з прийняттям ризику), чи масштабувати.
• Якщо I/O диска: перемістіть spool на швидше сховище або відокремте його від «галасливих сусідів». Пошта не захоплюється спільними файловими системами.

Крок 3: Безпечно викачайте чергу (години, не хвилини)

• Дайте працювати нормальним графікам повторів, якщо у вас немає суворих SLA на доставку.
• Підвищуйте concurrency поступово тільки якщо віддалені відповіді залишаються здоровими (2xx) і ваші локальні ресурси витримують.
• Пріоритезуйте класи листів (скидання паролів > розсилки). Якщо не виходить — хоча б розділіть їх за відправником або політикою реле.

Крок 4: Запобігання повторенню (цього тижня)

• Сповіщайте про причини відкладень, а не лише про розмір черги.
• Відстежуйте пер-domain performance: які напрямки відкладалися, як часто і скільки часу триває відновлення.
• Відокремте файлову систему для спулу і ставте алерти на простір і іноди та на симптоми затримки I/O, а не тільки на %заповнення диска.
• Документуйте вашу вихідну ідентичність: PTR, HELO, SPF-записи, селектори DKIM, політика DMARC.
• Тримайте тестований резервний шлях через реле на 587 з автентифікацією для середовищ, де порт 25 крихкий або egress-IP має проблеми.

Жарт №2: Доставка пошти — це розподілена система, де «тимчасова проблема» на іншому боці триває рівно стільки, скільки тягнеться терпіння вашого керівництва.

FAQ (питання, які задають о 2:00 ночі)

1) Чи погано «message deferred»?

Не обов’язково. Відкладення — це механізм SMTP для переживання тимчасових збоїв. Це стає поганим, коли черга росте швидше, ніж спустошується, або коли причина вказує на локальну поломку (DNS, диск, блокування порту 25).

2) Як довго відкладене повідомлення залишатиметься в черзі?

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

3) Чому я бачу 421 «Try again later», хоча одержувач «up»?

Бо «up» не означає «готовий прийняти». Великі приймачі відкладають через формування трафіку, репутацію, виявлення сплесків і обмежену потужність сканування вмісту. Розглядайте 421 як сигнал до переговорів, а не як падіння сервера.

4) Чи варто змивати чергу, щоб виправити це?

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

5) У чому різниця між «deferred» і «bounced»?

Deferred — тимчасова помилка (зазвичай 4xx) і повідомлення буде повторно доставлятися. Bounced — постійна помилка (5xx) і повертається відправникові (або логуються/видаляються залежно від політики).

6) Чому DNS так важливий для доставки пошти?

SMTP-маршрутизація ґрунтується на записах MX, плюс A/AAAA-запити для цих хостів. Багато приймачів також перевіряють відповідність PTR/HELO. Якщо DNS повільний або ненадійний, доставки зупиняються й відкладення накопичуються.

7) Чи справді проблеми з диском можуть спричиняти «message deferred»?

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

8) Чому лише деякі домени відкладають, а інші доставляють?

Бо політика кожного приймача різна. Один домен може greylist, інший тротлити, інший вимагати точну відповідність rDNS, інший може бути недоступний. Email — це не одна мережа; це тисячі незалежних правил.

9) Чи можуть DKIM/SPF/DMARC викликати відкладення або відмови?

Можуть і те, і інше. Невідповідність або відсутність автентифікації може підвищити кількість 4xx відкладень (через політику/репутацію) перед остаточною відмовою. Виправлення автентифікації з часом зменшує шум «try again later».

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

Коли у вас стабільна віддалена 4xx з постійним патерном (та сама відповідь, на тій самій стадії, наприклад в кінці DATA) і ваша інфраструктура в порядку (порт 25 працює, DNS чистий, ідентичність узгоджена). Принесіть докази: часові мітки, SMTP-транскрипти, IP відправника та приклади Message-ID.

Наступні кроки, які варто виконати цього тижня

Якщо «message deferred» регулярно з’являється у ваших логах, перестаньте ставитися до нього як до погоди. Побудуйте невелику, відтворювану систему навколо цього явища.

• Інструментуйте причини відкладень (топ N за кількістю, топ N за постраждалими одержувачами/доменами). Зростаюча черга — це запізнення; зміна причини — раннє попередження.
• Відокремте файлову систему спулу і ставте алерти на іноди та симптоми латентності, а не лише на відсоток зайнятого диска.
• Зміцніть резолвінг DNS для хостів MTA. Надійні рекурсивні резолвери зі здоровими таймаутами — обов’язок.
• Встановіть розумні форми формування трафіку по доменах, щоб ви не дізнавалися про троттлінг із скарг клієнтів.
• Тримайте один протестований резервний шлях (реле на 587) на випадок, коли порт 25 нестабільний або ваш egress-IP втрачає репутацію.

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