Електронна пошта «451 тимчасова локальна проблема» — швидко знайдіть проблему на сервері

Що насправді означає «451 тимчасова локальна проблема»

SMTP має дві широкі категорії відмов: постійні (5xx) і тимчасові (4xx).
451 — це 4xx: відправник повинен спробувати пізніше. Фраза «тимчасова локальна проблема»
не є універсальним законом; це поширений текстовий опис, який додають MTA (або проміжні політики/фільтри), коли
сервер зараз не може прийняти повідомлення через локальний стан.

Ви також побачите варіанти на кшталт:
451 4.3.0 Temporary server error,
451 4.3.2 System not accepting network messages,
або 451 4.7.1 Try again later.
Перший номер — це статус SMTP; «покращений код стану» (наприклад 4.3.0) дає підказку про категорію.
Але ось неприємна правда: текстова частина часто загальна, а покращений код може вводити в оману,
коли говорить фільтр або демон політик.

Де помилка генерується — має значення

«451» може надходити від:

• Отримуючого MTA (Postfix, Exchange, Sendmail, Exim).
• Фільтра вмісту (антивірус, антиспам), який тимчасово відмовляє або блокує.
• Сервісу політик (лімітування швидкості, greylisting, перевірки репутації), який таймаутить.
• Верхнього релейного вузла (smart host / провайдер вихідної пошти), що повертає 451 вам.
• Вашого власного MTA під час намагання доставити вихідну пошту, відкладаючи в чергу.

Ваше перше завдання — не «виправити 451». Ваше перше завдання — відповісти на одне запитання:
Хто сказав 451, на якому етапі і через який локальний ресурс?

Одна цитата, яку варто тримати на стіні: Надія — це не стратегія. — парафраз ідеї, часто приписуваної в інженерних/опс колах.
451 за замовчуванням заснований на «надії» («спробуйте пізніше»). Ми перетворимо це на доказ.

Швидкий плейбук діагностики (першочергово/далі/глибше)

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

Спочатку: підтвердіть, звідки походить 451 (10 хвилин)

1. Вхідна чи вихідна це? Подивіться трасування повідомлення на стороні відправника або логи вашого MTA.
   Якщо ви відправник, ви побачите «deferred» доставки. Якщо ви отримувач, ви побачите відхилені/відкладені вхідні сесії.
2. Витягніть точний фрагмент SMTP-транскрипту. Потрібен повний рядок, включно з покращеним кодом стану та будь-яким причиновим текстом у дужках.
   «451 тимчасова локальна проблема» без контексту — це як «сервіс деградував» без графіка.
3. Визначте компонент, що говорить. Postfix може логувати «reject: 451», але причиною може бути «policy service unavailable».
   Exchange може відображати внутрішні помилки транспорту як 451 4.3.0.

Далі: перевірте класичні обмеження ресурсів (15 хвилин)

1. Повний диск / вичерпання inode: поштові спули, директорії черг, розділи логів.
2. Зростання черги: черга відкладених повідомлень вибухає через проблеми вниз по ланцюжку.
3. Помилки DNS: таймаути резолвера, зламане кешування, проблеми з DNSSEC або блокування UDP/53.
4. Навантаження CPU / пам’яті: фільтри вмісту таймаутять, демони політик зависають, пул потоків насичений.
5. Мережа/TLS: таймаути рукостискань, блокування вихідних портів, проблеми з сертифікатами, незвична MTU.

Глибше: перевірте політики та залежності (30–60 хвилин)

1. Greylisting або лімітування швидкості: навмисні 451, замасковані під «локальну проблему».
2. Інтеграція спаму/AV: clamd, rspamd, Amavis, milter — таймаути цих компонентів.
3. Залежності баз даних / директорій: LDAP, SQL, Redis, сервіси репутації.
4. Зворотний тиск від upstream-релею: ваш smarthost відкладає листи (а ви звинувачуєте себе).

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

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

• SMTP передував більшості сучасних патернів надійності. Він був розроблений в епоху, коли «спробувати пізніше» було нормою через ненадійні мережі.
• 4xx — це функція, а не баг. Тимчасові відмови — частина моделі стійкості SMTP; відправники повинні чергувати та повторювати з експоненційним відступом.
• Покращені коди стану (як 4.3.0) з’явилися пізніше. Вони додавалися, щоб зменшити неоднозначність, але не всі системи їх однаково реалізують.
• Greylisting популяризував навмисні 451. Він повертає тимчасові відмови, щоб перевірити, чи повторить відправник, як це робить справжній MTA.
• Директорії черг чутливі до продуктивності. Історично MTAs використовували файлові черги; затримка диска може швидко стати «тимчасовою локальною проблемою».
• Фільтрація вмісту перемістила вузьке місце. Зі зростанням спаму MTAs почали делегувати рішення милтерам і сканерам — додавши нові режими відмов.
• DNS у критичному шляху частіше, ніж здається. Навіть при доставці по IP багато налаштувань виконують зворотні пошуки, перевірки SPF або політичні запити.
• 451 часто використовують для обмеження через репутацію. Деякі провайдери використовують 451, щоб уповільнити або «м’яко блокувати» відправників без постійного відхилення.

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

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

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

Завдання 1: Знайти 451 у логах і витягнути контекст

cr0x@server:~$ sudo grep -R --line-number -E " 451 |451 " /var/log/mail.log | tail -n 20
/var/log/mail.log:128772:Jan  4 10:03:22 mx1 postfix/smtp[24188]: 9C2A8402C5: to=<user@example.net>, relay=mx.example.net[203.0.113.25]:25, delay=12, delays=0.1/0.02/3.1/8.8, dsn=4.3.0, status=deferred (host mx.example.net[203.0.113.25] said: 451 4.3.0 Temporary local problem (in reply to end of DATA command))

Значення: Це вихідна доставка. Віддалений хост відклав після DATA (фази вмісту), а не при підключенні/HELO.
Це вказує на віддалений контент-фільтр, чергування або ресурсні проблеми — менш імовірно DNS.
Рішення: Якщо багато одержувачів на тій самій домені показують це, трактуйте як обмеження з боку віддаленої сторони і відрегулюйте повтори/обсяг;
якщо це багато доменів — підозрюйте вашу вихідну репутацію або власний фільтр вмісту, що таймаутить.

Завдання 2: Перевірити, чи ваш вхідний бік відхиляє клієнтів

cr0x@server:~$ sudo grep -E "reject:.*451|NOQUEUE: reject:.*451" /var/log/mail.log | tail -n 20
Jan  4 10:05:09 mx1 postfix/smtpd[24501]: NOQUEUE: reject: RCPT from unknown[198.51.100.44]: 451 4.3.2 Temporary local problem; from=<sender@outside.tld> to=<user@yourdomain.com> proto=ESMTP helo=<mail.outside.tld>

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

Завдання 3: Перевірити місце на диску там, де живуть черги/спули

cr0x@server:~$ df -hT
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   40G   39G  512M  99% /
/dev/sdb1      xfs   200G   45G  155G  23% /var

Значення: Файлова система root на 99%. Якщо черга Postfix знаходиться під /var/spool/postfix і /var в порядку, можливо все гаразд —
але якщо логи чи тимчасові файли на /, це може бути проблемою. Багато конфігурацій все ще розміщують критичні шляхи на /.
Рішення: Якщо будь-яка файлова система, що хостить /var/spool, /var/lib, /var/log або тимчасові директорії має >90%,
вважайте це активним інцидентом: звільніть місце, розширте диск або перемістіть спули. 451 може бути раннім попередженням перед жорсткою 5xx помилкою.

Завдання 4: Перевірити вичерпання inode (мовчазний “диск заповнений”)

cr0x@server:~$ df -ih
Filesystem    Inodes IUsed IFree IUse% Mounted on
/dev/sda2       2.6M  2.6M     0  100% /
/dev/sdb1        50M  1.2M  48.8M   3% /var

Значення: На root нуль інодів. Ви можете мати «вільне місце», але бути мертвими, бо файлова система не може створювати нові файли.
MTAs створюють багато маленьких файлів (записи черги). Вичерпання inode часто спричиняє «тимчасову локальну проблему», бо створення файлів не вдається.
Рішення: Знайдіть і видаліть inode-важкий мотлох (старі тимчасові файли, дампи аварій, неконтрольовані логи) або перебудуйте файлову систему з більшою кількістю inode
(опції mkfs ext4) якщо це хронічно.

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

cr0x@server:~$ sudo postqueue -p | head -n 40
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9C2A8402C5     3287 Thu Jan  4 10:03:21  no-reply@yourdomain.com
                                         user@example.net
                                         (host mx.example.net[203.0.113.25] said: 451 4.3.0 Temporary local problem (in reply to end of DATA command))

A1B7B40310     9121 Thu Jan  4 10:03:49  app@yourdomain.com
                                         ops@another.tld
                                         (connect to mx.another.tld[192.0.2.10]:25: Connection timed out)

-- 1245 Kbytes in 342 Requests.

Значення: У вас кілька режимів відмов: віддалений 451 і таймаути з’єднання. Це свідчить про широкі проблеми з вихідною доставкою (мережа, репутація,
upstream-провайдер), а не про одну віддалену доменну проблему.
Рішення: Якщо кількість відкладених швидко зростає, обмежте відправників, призупиніть масові кампанії і захистіть диск від заповнення.
Потім ізолюйте: чи є у вас проблеми з DNS/підключенням або вас тимчасово блокують?

Завдання 6: Перевірити стан поштової служби і недавні перезапуски

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-04 09:58:12 UTC; 12min ago
   Main PID: 1218 (master)
      Tasks: 3 (limit: 18948)
     Memory: 22.1M
        CPU: 3.912s

Значення: Postfix працює. Це не означає, що він здоровий, але виключає найпростішу ситуацію «сервіс впав».
Рішення: Якщо є повторні перезапуски, перевірте OOM kills, цикли перезавантаження конфігу, або залежності, що викликають рестарти watchdog.

Завдання 7: Шукати OOM kills або проблеми на рівні ядра з ввід/виводом

cr0x@server:~$ sudo dmesg -T | egrep -i "oom|killed process|ext4|xfs|i/o error|blk_update_request" | tail -n 30
[Thu Jan  4 10:01:12 2026] Out of memory: Killed process 22219 (clamd) total-vm:2150340kB, anon-rss:824000kB, file-rss:0kB, shmem-rss:0kB

Значення: Ваш антивірусний демон був вбито. Якщо ваш SMTP-потік залежить від clamd, milter може таймаутити або відмовити закрито,
що призводить до 451 відкладень.
Рішення: Стабілізуйте пам’ять (ліміти, swap, обмеження контейнера) і вирішіть, чи має пошта fail open (приймати, а потім сканувати асинхронно)
або fail closed (відкладати). У багатьох регульованих середовищах fail closed правильний — але його слід відповідно масштабувати.

Завдання 8: Поверити роботу DNS з поштового сервера (A/MX/PTR)

cr0x@server:~$ dig +time=2 +tries=1 mx example.net
;; ANSWER SECTION:
example.net.            300     IN      MX      10 mx.example.net.

cr0x@server:~$ dig +time=2 +tries=1 a mx.example.net
;; ANSWER SECTION:
mx.example.net.         300     IN      A       203.0.113.25

Значення: DNS працює швидко для цього домену. Якщо dig повільний або таймаутить, ваш MTA буде зависати,
черги зростуть, і деякі MTA повертатимуть 451, коли перевірки не вдаються.
Рішення: Якщо DNS повільний, спочатку виправте резолвер (локальне кешування, досяжність upstream, правила фаєрволу).
Не «налаштовуйте Postfix», щоб компенсувати зламаний DNS; це прикрашає зайнятий будинок, що горить.

Завдання 9: Перевірити зворотний DNS вашого вихідного IP (поширений тригер для лімітування)

cr0x@server:~$ dig +short -x 198.51.100.10
mail01.yourdomain.com.

Значення: PTR існує. Багато провайдерів не роблять хард-фейл через відсутність PTR, але будуть лімітувати з 4xx відповідями.
Рішення: Якщо PTR відсутній або неправильний — виправте його через ваш ISP/хмарного провайдера. Очікуйте зменшення «загадкових 451» у великих приймачів.

Завдання 10: Перевірити доступність демона політик/мілтера (socket-з’єднання)

cr0x@server:~$ sudo ss -lntp | egrep ":10023|:10024|:8891|:8892" || true
LISTEN 0      100          127.0.0.1:10024       0.0.0.0:*    users:(("master",pid=1218,fd=15))
LISTEN 0      100          127.0.0.1:8891        0.0.0.0:*    users:(("rspamd",pid=2110,fd=12))

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

Завдання 11: Виміряти локальну затримку до фільтра (швидкий тест «повільно чи ні»)

cr0x@server:~$ time (echo -e "QUIT\r\n" | nc -w 2 127.0.0.1 10024 >/dev/null)
real    0m0.006s
user    0m0.002s
sys     0m0.002s

Значення: Порт відповідає швидко. Якщо це займає секунди або таймаутить, шлях контент-фільтра затримує SMTP-транзакції,
і деякі клієнти/сервери відповідають 451, коли вичерпують внутрішні бюджети таймаутів.
Рішення: Якщо повільно — масштабувати фільтр, налаштувати таймаути або тимчасово обійти сканування для довірених джерел, поки стабілізуєтеся.

Завдання 12: Перевірити, чи ви досягаєте лімітів з’єднань або швидкостей

cr0x@server:~$ sudo postconf | egrep "smtpd_client_connection_count_limit|smtpd_client_connection_rate_limit|smtpd_client_message_rate_limit"
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 200

Значення: Агресивні ліміти можуть викликати 4xx відмови під час легітимних сплесків (скидання пароля, аварійні сповіщення, пакетні завдання).
Рішення: Якщо ви бачите сплески, що викликають 451 для внутрішніх додатків або довірених партнерів — підвищте ліміти і додайте виключення по клієнту.
Зберігайте ліміти для інтернету; просто не DDoS-те себе «безпекою».

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

cr0x@server:~$ sudo postconf | egrep "default_destination_concurrency_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay"
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s

Значення: Висока паралельність і відсутність затримки можуть виглядати як зловживання для великих провайдерів, викликаючи тимчасове 451 лімітування.
Рішення: Для відомих доменів, що лімітують, додайте transport maps з нижчою паралельністю і невеликою затримкою. Це не «поступка»;
це ввічливе співіснування, щоб ваша пошта доходила.

Завдання 14: Перевірити негайний стан файлової системи черги (латентність)

cr0x@server:~$ sudo iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              2.00   85.00    64.0  4200.0  48.12   2.10  89.50
sdb              0.00   12.00     0.0   180.0   1.20   0.35   4.20

Значення: sda має високе навантаження з великим await. Якщо ваша черга на sda — у вас IO-гітарне місце.
MTAs виконують багато операцій, схожих на fsync; затримка IO черги перетворюється на таймаути SMTP і відкладення 451.
Рішення: Перемістіть чергу на швидше сховище, зменшіть тиск на синхронізацію (обережно) або зменшіть churn черги (відключіть зайве логування,
уникайте крихітних розділів файлової системи).

Завдання 15: Підтвердити, що TLS працює і сертифікати не викликають затримок

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.yourdomain.com:25 -servername mx1.yourdomain.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.yourdomain.com
Verification: OK

Значення: STARTTLS працює і сертифікат перевіряється локально (за умови нормального trust store).
Рішення: Якщо це періодично падає — перевірте прострочені сертифікати, зламану ланцюжок або CPU-контенцію під час рукостискань.
Проблеми з TLS можуть проявлятися як «тимчасова локальна проблема» залежно від того, де обробляється помилка.

Завдання 16: Перевірити, чи ваш upstream relay відкидає вас

cr0x@server:~$ sudo grep -E "relay=.*\[.*\]:587|relay=.*:587" /var/log/mail.log | tail -n 10
Jan  4 10:04:11 mx1 postfix/smtp[24321]: 3F9B7402D2: to=<user@bigmail.tld>, relay=relay.provider.tld[192.0.2.50]:587, delay=4.2, dsn=4.7.1, status=deferred (host relay.provider.tld[192.0.2.50] said: 451 4.7.1 Rate limit exceeded, try again later)

Значення: «Локальна проблема» не локальна. Ваш relay лімітує вас.
Рішення: Припиніть сліпо налаштовувати свій MTA. Узгодьте ліміти з провайдером, впровадьте shaping виходу і перевірте, чи не тече у вас спам зкомпрометованими акаунтами.

Карта кореневих причин: звідки береться 451

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

Класифікація за етапом

• При підключенні / банері: локальний слухач перевантажений, ліміти з’єднань, черга accept повна, вичерпання conntrack ядра, проблеми з TLS-політикою.
• При HELO/EHLO: перевірки зворотного DNS, обмеження helo, запити сервісу політик, раннє рішення greylisting.
• При MAIL FROM / RCPT TO: перевірка одержувача (LDAP/SQL), обмеження відправника, перевірки SPF, лімітування, greylisting.
• При DATA / наприкінці DATA: таймаути фільтрації вмісту, антивірусне сканування, сервіси оцінки спаму, збій запису на диск/фіксації черги.
• Після прийняття (повідомлення про недоставку пізніше): це не 451; тут приходять DSN або Silent drop. Інша категорія проблем.

Класифікація за залежностями (зазвичай підозрювані)

1) Обмеження зберігання та файлової системи

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

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

2) Нестабільність DNS та резолвера

DNS не є опцією. MTAs дивляться MX-записи, валідують домени, іноді виконують PTR, а політики запитують TXT (SPF) та інші дані.
Якщо ваш резолвер таймаутить — SMTP-транзакція очікує. Якщо вона чекає занадто довго — ви відкладаєте. Якщо відкладаєте — отримуєте 451.

3) Фільтрація вмісту та милтери

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

4) Сервіси політик та перевірки директорій

Перевірка одержувача, перевірки відправника, ліміти і автентифікація можуть викликати запити до LDAP, SQL, Redis, HTTP API або локальних демонів.
Будь-який таймаут перетворюється на «тимчасову локальну проблему».

5) Віддалене лімітування та контроль репутації

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

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

Три корпоративні міні-історії (реалістичні, болісні, корисні)

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

Середня SaaS-компанія тримала свій власний Postfix релей для транзакційної пошти. У них була дисципліна інцидентів і пристойний on-call.
В одну п’ятницю сапорт повідомив про «затримки пошти» у кількох корпоративних клієнтів. Логи пошти показували багато 451 відкладень.

Інженер on-call припустив, що їх лімітять віддалені отримувачі. Це припущення було розумним: це були 451 наприкінці DATA,
і великі підприємства дійсно лімітують. Тож вони підправили паралельність по доменах і повернулися спати.

Вранці суботи відкладена черга потроїлася. Не катастрофа, але тренд був невірний. Другий інженер перевірив місце на диску
і знайшов достатньо вільного. CPU виглядав нормально. Мережа — нормально. Тоді помітили тонку річ: логи mail перестали оновлюватися кожні кілька хвилин,
а потім записувалися шматками.

Корінь проблеми: вичерпання inode на root-файловій системі, спричинене тихим накопиченням маленьких тимчасових файлів від не пов’язаного додатка.
Postfix сам жив на /var (здоровий), але syslog писав у /var/log на /, і коли syslog не міг писати, команда втратила реальний часовий моніторинг.
Тим часом фільтр вмісту писав тимчасові файли в /tmp на /, що призводило до періодичних збоїв і 451 наприкінці DATA.

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

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

Фінансова організація захотіла швидшої пропускної здатності для внутрішніх сповіщень. Хтось помітив, що черга пошти на повільніших дисках.
Пропозиція: перемістити /var/spool/postfix на мережеву файлову систему «заради відмовостійкості» і звільнити локальний IO.
Пройшло невелике тестування. Відправили.

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

Постмортем був болісним, бо нічого не було «падаючим». Мережева файлова система «працювала», затримки були «в межах SLA», бекапи «успішні».
Але SMTP не переймається вашим SLA; йому важлива хвостова латентність і поведінка fsync. Операції черги, які були суб-міллісекундні локально, стали десятки мс з періодичними секундами простоїв.
Ось як народжуються таймаути і 451.

Виправлення: повернути чергу на локальний SSD, зберігати відмовостійкість на рівні системи (реплікація, бекапи, відтворюваний конфіг),
і використовувати мережеві файлові системи для того, що не лежить у синхронному шляху SMTP. Оптимізація покращила середні числа і знищила p99. Пошта живе на p99.

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

Постачальник медичних послуг мав суворі вимоги з безпеки та комплаєнсу, отже інтенсивне сканування вхідних і консервативні політики.
Вони також мали нудну практику: кожна залежність поштового потоку мала health check і SLO, включно з DNS резолверами і сервісом антиспаму.
Ніхто про це не хвалився на вечірках.

Одного вівторка почався сплеск 451 відкладень на RCPT. Користувачі швидко помітили через затримки нагадувань про прийом на прийоми.
Інженер on-call подивився на дашборд і побачив, що графік латентності LDAP перетворився на сходи.
Одночасно сам SMTP-сервіс був у нормі.

Вони перемкнули попередньо погоджений «режим деградації»: перевірка одержувачів перейшла з жорстких LDAP-запитів на кешовані перевірки для відомих локальних доменів
на 30 хвилин, залишаючи суворі перевірки для зовнішнього релею. Це одразу зменшило відкладення.

Корінь проблеми: рутинне обслуговування директорії спричинило блокування, перетворивши швидкі запити на таймаути. Якби вони не мали SLO для залежностей,
команда ганялася б за налаштуванням Postfix, правилами фаєрволу і привидами спам-атак.

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

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

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

1) Багато 451 наприкінці DATA → таймаут сканера → масштабувати або безпечно обійти

• Симптом: 451 з’являється «у відповіді на end of DATA command», особливо під навантаженням.
• Корінь: конвеєр антивірусу/спаму повільний або недоступний; milter таймаут; OOM kills.
• Виправлення: перевірте процеси фільтрів, сокети і таймаути; додайте потужність; явно налаштуйте політику fail-open/closed; перемістіть тимчасові директорії на швидкий локальний диск.

2) 451 на RCPT → перевірка одержувача зламана → виправити LDAP/SQL/DNS

• Симптом: «NOQUEUE: reject: RCPT … 451» і корелює з латентністю директорії.
• Корінь: сервіс перевірки одержувача (LDAP/SQL) таймаутить; демон політик не може дістатися бекенду.
• Виправлення: відновіть здоров’я залежності; додайте кешування; налаштуйте таймаути; забезпечте плавну деградацію політик.

3) 451 вибухоподібно по багатьох доменах → проблеми резолвера DNS → виправте резолвери, а не Postfix

• Симптом: доставки відкладаються для різних доменів; логи показують затримки запитів або «temporary failure in name resolution».
• Корінь: локальний резолвер падає, upstream DNS заблокований, кешуючий демон перевантажений, проблеми з DNSSEC.
• Виправлення: перевірте досяжність резолвера; рестарт кешування; використайте резервні резолвери; зменшіть помилки DNSSEC; моніторьте латентність запитів.

4) Черга росте, але CPU нормальний → латентність диска → перемістіть чергу / виправте IO

• Симптом: відкладена черга зростає; середнє навантаження низьке; але доставка повільна.
• Корінь: хвостова латентність зберігання; файлова система майже повна; вичерпання inode; повільні журнальні коміти.
• Виправлення: перевірте iostat; перемістіть чергу на SSD; звільніть місце; збільште inode-ємність; уникайте мережевих файлових систем для черги.

5) Віддалені домени повертають 451 4.7.1 → лімітування/репутація → формуйте трафік і чистіть

• Симптом: віддалий або relay каже «rate limit exceeded», «try again later», «temporarily deferred».
• Корінь: занадто багато паралелізму, сплески кампаній, скомпрометований відправник, погана IP/доменна репутація, відсутній PTR.
• Виправлення: реалізуйте пер-доменні ліміти; виправте PTR і HELO; забезпечте вихідну автентифікацію; оновіть облікові дані; ізолюйте компрометовані акаунти.

6) «Ми перезапустили Postfix і все пішло» → приховані залежності → знайдіть реальний слабкий елемент

• Симптом: рестарт «вирішує» 451 тимчасово; потім повертається.
• Корінь: перезапуск скидає черги, сокети або кеш DNS; основна проблема залишається (витік пам’яті, завислий фільтр, перевантаження резолвера).
• Виправлення: корелюйте з графіками ресурсів; визначте, який підсистем відновлюється при рестарті; виправте цей компонент і додайте моніторинг.

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

Коли вас піднімають по пейджу: 15-хвилинний чекліст триажу

1. Отримайте один конкретний приклад: один відправник, один одержувач, один час, один повний SMTP-рядок помилки.
2. Визначте напрям: вхідні відкладення проти вихідних відкладень.
3. Перевірте диск + inode на будь-яких файлових системах, що беруть участь у черзі, логах, тимчасових і фільтрах.
4. Перевірте швидкість DNS з хоста MTA, а не з вашого ноутбука.
5. Перевірте ріст черги: чи зростає кількість deferred? чи застрягла активна черга?
6. Перевірте здоров’я фільтрів/політик: сокети слухають, процеси живі, недавні OOM kills.
7. Перевірте відповіді upstream relay: чи вас лімітують?
8. Виберіть дії ізоляції: обмежте відправників, призупиніть масову пошту, увімкніть деградований режим для некритичних перевірок.

Дії з ізоляції (зробіть їх до «глибокого налаштування»)

• Захистіть диск: якщо розділ черги під загрозою, зупиніть неважливі джерела пошти (маркетинг, звіти), перш ніж він заповниться.
• Зменшіть паралельність: сформуйте outbound для уражених доменів або relay, щоб перестати викликати ліміти.
• Fail open vs fail closed: прийміть рішення явно для фільтрів. Якщо мусите fail closed — масштабируйте їх зараз, не потім.
• Обережно подовжіть інтервали повторів: не створюйте шторм повторів. Backoff — інструмент, не сховок.

План стабілізації (той же день)

1. Виправте реальну залежність: диск, DNS, фільтр, директорія або мережа.
2. Безпечно осушіть чергу: перевірте пропускну здатність і спостерігайте IO та латентність під час зливу.
3. Підтвердіть за допомогою зовнішніх тестів доставки: оберіть кілька репрезентативних доменів-одержувачів і перевірте повний шлях.
4. Встановіть обмеження і спостереження: моніторинг inode, латентності резолвера, часу відповіді фільтрів та глибини черги.

План загартування (цього тижня)

• Розділені файлові системи: черга, логи і тимчасові не повинні конкурувати на одному маленькому розділі.
• Встановіть розумні таймаути: демони політик повинні відмовляти швидко, а не зависати SMTP-сесії безкінечно.
• Впровадьте per-domain shaping: особливо для відомих доменів, що лімітують.
• Аудит, хто може відправляти: вихідна автентифікація і лімітування по акаунту запобігають одному компроментованому відправнику знищити репутацію.
• Щоквартальна «пожежна вправа пошти»: симулюйте відмову DNS, майже повний диск і відмову фільтра; підтвердіть, що поведінка відповідає вашим намірам.

ЧаПи

1) Чи завжди 451 — це вина приймаючого сервера?

Ні. Якщо ви надсилаєте, приймаючий сервер може відкладати вас. Але ваш власний relay, сервіси політик, сканери, DNS або сховище також можуть генерувати 451.
Рядок логу підкаже, хто це сказав — уважно читайте частину host ... said:.

2) Чому деякі сервери використовують 451 замість чіткої помилки?

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

3) У чому різниця між 451 і 421?

Обидва тимчасові. 421 зазвичай означає «сервіс недоступний» і часто завершує з’єднання.
451 більше як «локальна помилка обробки» і може виникати на конкретних етапах (RCPT/DATA).

4) Ми бачимо 451 тільки для одного домену-одержувача. Що робити?

Спочатку припускайте лімітування або віддалену проблему, але перевірте базові речі: ваша вихідна IP-репутація, PTR, ім’я HELO і чи ви надсилаєте сплески.
Впровадьте пер-доменні обмеження паралельності і rate delay. Якщо проблема триває — зв’яжіться з адміністраторами одержувача з часовими мітками і ID черги.

5) Чи може greylisting бути причиною?

Так. Greylisting навмисно повертає тимчасові помилки (часто 451 або варіанти 4.7.1) для невідомих відправників.
Якщо ви використовуєте greylisting — перевірте, чи він не некоректно налаштований або не перевантажений. Якщо ви відправник — переконайтеся, що ваша система правильно повторює спроби і не змінює IP.

6) Чому латентність диска викликає 451 замість явного «диск повний»?

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

7) Як довго відправники повторюватимуть після 451?

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

8) Чи можуть SPF/DKIM/DMARC викликати 451?

Зазвичай вони призводять до постійних відхилень (5xx) або прийняття з оцінкою спаму. Але в реальних системах політики, що виконують ці перевірки, можуть таймаутити.
Коли політика таймаутить, сервер може повернути 451, хоча фактична «причина» — повільний DNS-запит для TXT-записів.

9) Ми перезапустили фільтр і 451 зник. Чи все гаразд?

Для тепер усе гаразд. З’ясуйте, чому потрібен був рестарт: витік пам’яті, OOM kills, оновлення правил, IO диска або таймаути залежностей.
Додайте моніторинг процесу фільтра і часу відповіді, щоб наступний збій не був сюрпризом.

10) Чи варто збільшувати таймаути Postfix, щоб уникнути 451?

Лише якщо ви впевнені, що залежність повільна, але коректна, і у вас є ресурси утримувати з’єднання.
Збільшення таймаутів може перетворити «тимчасову помилку» на «завислі сесії», що гірше під навантаженням. Виправте залежність перш за все.

Висновок: кроки, що запобігають повторним інцидентам

«451 тимчасова локальна проблема» — це не діагноз; це запрошення бути системним.
Найшвидші перемоги приходять від ставлення до пошти як до будь-якого іншого продакшен-пайплайна: ідентифікуйте компонент, що говорить,
потім перевірте обмеження, які спричиняють відкладення — зберігання, DNS, фільтри, бекенди політик і upstream-ліміти.

Практичні кроки:

1. Додайте моніторинг inode на файлових системах черги/логів/тимчасових, а не лише відсоток диска.
2. Вимірюйте латентність резолвера з хоста MTA і сигналізуйте про таймаути.
3. Слідкуйте за глибиною та віком черги: кількість deferred і найстаріше повідомлення важливіші за «сервіс працює».
4. Інструментуйте фільтри та демони політик: час відповіді, частота помилок, OOM kills.
5. Впровадьте outbound shaping для основних доменів-одержувачів і upstream-relay.
6. Запишіть ваші рішення fail-open/closed для сканування та перевірок політик, а потім протестуйте їх під час вправи.

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