Застрягла черга Postfix: безпечний порядок очищення (без втрати даних)

Правила: не «очищуйте», відновлюйте

Коли люди говорять «очистіть чергу Postfix», вони зазвичай мають на увазі «приберіть біль». Саме так пошту видаляють, масово генерують bounce-повідомлення, і ваш канал інцидентів заповнюється скрінами від юридичного відділу.

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

• DNS повільний або зламаний (запити тайм-аутяться; доставки зависають).
• Блокований вихідний трафік (правила фаєрволу, маршрутизація, вичерпання NAT).
• Віддалені сайти троттлять або застосовують tarpitting (відповіді 421/450/451, greylisting, ліміти швидкості).
• Локальні політики/сервіси недоступні (milter, postscreen, rspamd, opendkim, policy daemon).
• Тиск на диск або inode (файли черги не можуть бути створені/перейменовані).
• Контент-фільтр повільний (amavis, антивірус, DLP), що викликає зворотний тиск.
• Неправильна конфігурація (relayhost, TLS-політики, sender restrictions, SASL auth, некоректні транспорти).
• Файлова корупція черги (рідше, ніж думають, але трапляється після проблем зі зберіганням).

Безпечна позиція така:

1. Заміорозьте сцену настільки, щоб не погіршувати ситуацію.
2. Виміряйте, що саме застрягло (яка черга, який напрямок, яка помилка).
3. Виправте причину (DNS/мережа/сервіс/зберігання).
4. Повторно відправляйте поступово (тротлінг, requeue, цілеспрямоване очищення).
5. Тільки потім видаляйте щось — і лише з письмовим обґрунтуванням.

Цитата, яку я тримаю в голові: Надія — не стратегія. — Джеймс Кемерон. Робота над надійністю — це те, що ви робите замість надії.

Короткий жарт №1: Черги Postfix схожі на купу білизни: ігнорування не робить їх меншими, просто робить вас творчо сліпими.

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

Перший: підтвердіть, що «застрягла» означає у вашій реальності

• Чи велика черга active (пошта постійно намагається відправлятися), або все у deferred (Postfix тимчасово відмовився пробувати)?
• Чи повідомлення від одного відправника/домену застрягли, чи проблема глобальна?
• Чи нові повідомлення потрапляють у чергу швидше, ніж виходять?

Другий: ізолюйте клас вузького місця

• Затримка DNS: довгі тайм-аути резолвера в логах, сплески системного навантаження, багато «Host not found», які пізніше проходять.
• Віддалене тротлінг: багато відповідей 4xx, «try again later», «rate limited», greylisting.
• Локальні сервіси: тайм-аути milter, policy daemon не відповідає, backlog контент-фільтра.
• Зберігання: «No space left on device», «File too large», забагато файлів або повільні директорії черги (високий iowait).
• Мережа: connect() тайм-аути, «Network is unreachable», невдалі TLS handshake через MITM/проксі.

Третій: оберіть найбезпечніший важіль

• Якщо корінна причина не усунута, не робіть повний flush. Ви посилите навантаження і зіпсуєте логи.
• Якщо один напрямок токсичний (домен тайм-аутиться), ізолюйте його за допомогою transport maps або обмежень по concurency.
• Якщо сервер плавиться (load, диск), уповільніть: зменшіть concurency, призупиніть неважливий трафік, захистіть хост.

Цікаві факти та історія (бо це пояснює дивні моменти)

• Postfix був спроектований як безпечніша альтернатива Sendmail наприкінці 1990-х, із наголосом на найменші привілеї й кілька маленьких демонів замість одного моноліту.
• Черга за замовчуванням файло-орієнтована. Це нудно, але чудово: повідомлення переживають рестарт демонів і деякі часткові відмови.
• «Deferred» — це не стан помилки; це рішення планувальника. Postfix навмисно відступає, аби не бити по поламаному напрямку.
• Postfix розділяє обов’язки (pickup, cleanup, qmgr, smtp, local). Коли один з них застрягає, черга стає вашим раннім попереджувальним сигналом.
• Ідентифікатори черги не декоративні. Це стабільні маркери, за допомогою яких можна відстежити лист у логах та операціях з чергою.
• Поведінка backoff — частина ввічливості в інтернеті. SMTP-екосистема карає агресивних повторювачів тротлінгом і блокуванням.
• Історично поштові системи навчали команд оперувати надійністю ще до популярності «event sourcing»: прийняти, зберегти, повторити, і лише з доказами відмовитися.
• Maildir vs mbox навчив індустрію про корупцію та блокування; формат черги Postfix успадкував філософію «не ставити ставку на один великий файл».

Операції в продакшні: команди, що означає вивід і наступне рішення

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

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

cr0x@server:~$ postqueue -p | tail -n 20
-- 18451 Kbytes in 392 Requests.
A1B2C3D4E5*     1234 Fri Jan  3 10:41:22 sender@example.com
                                         (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
                                         recipient@remote.tld
...

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

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

Завдання 2: Розділіть кількість active та deferred

cr0x@server:~$ find /var/spool/postfix/active -type f | wc -l
128
cr0x@server:~$ find /var/spool/postfix/deferred -type f | wc -l
9412

Що це означає: Переважно deferred. Postfix намагався і відступив. Це зазвичай вказує на віддалені проблеми, DNS або тайм-аути політик — не на локальний цикл відправки.

Рішення: Зосередьтесь на причині, чому доставки відкладаються. Не перезавантажуйте Postfix по кілька разів; це не змусить віддалені MTA відповісти швидше.

Завдання 3: Перевірте, чи Postfix здоровий як сервіс

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (running) since Fri 2026-01-03 10:12:01 UTC; 42min ago
   Main PID: 1123 (master)
      Tasks: 6 (limit: 4672)
     Memory: 34.2M
        CPU: 1min 12s

Що це означає: Майстер-процес запущено. Це не означає, що пошта тече, але виключає стан «помер».

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

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

cr0x@server:~$ journalctl -u postfix -S "1 hour ago" | egrep -i "deferred|timed out|refused|4[0-9][0-9]" | tail -n 20
Jan 03 10:43:10 server postfix/smtp[2451]: A1B2C3D4E5: to=, relay=mx.remote.tld[203.0.113.10]:25, delay=120, delays=0.1/0/120/0, dsn=4.4.1, status=deferred (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
Jan 03 10:43:22 server postfix/smtp[2454]: F6E7D8C9B0: to=, relay=none, delay=4, delays=0.1/0.1/3.8/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=mx.other.tld type=MX: Host not found)

Що це означає: Є і тайм-аути з’єднання (мережа/віддалений), і помилки DNS (резолвер/шлях). Цього достатньо, щоб обрати наступні два дослідження: DNS і мережа.

Рішення: Якщо помилки переважно 4.4.3 (DNS), виправляйте резолвер першим. Якщо переважно тайм-аути з’єднання — перевіряйте фаєрвол/egress і доступність віддалених хостів.

Завдання 5: Перевірте затримку та коректність DNS

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

Що це означає: DNS для цього домену швидкий принаймні. Якщо ви бачите 2000 msec і SERVFAIL/тайм-аути — це ваша «застрягла» черга.

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

Завдання 6: Перевірте вихідні TCP/25 та TLS доступність

cr0x@server:~$ nc -vz -w 3 203.0.113.10 25
nc: connect to 203.0.113.10 port 25 (tcp) timed out: Operation now in progress

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

Рішення: Ескалюйте до мережевої команди/фаєрволу. Якщо вихідний 25 блокований політикою, вам потрібен relayhost (submission/587) або затверджений smart host.

Завдання 7: Перегляньте concurency та контролі швидкості Postfix

cr0x@server:~$ postconf | egrep "default_destination_concurrency_limit|smtp_destination_concurrency_limit|qmgr_message_active_limit|default_process_limit"
default_destination_concurrency_limit = 20
default_process_limit = 100
qmgr_message_active_limit = 20000
smtp_destination_concurrency_limit = 20

Що це означає: Ці числа визначають, наскільки інтенсивно ви б’єте по зовнішньому світу. Якщо ви промете велику deferred чергу з високою concurency, можете самі себе DDoSити або отримати блокування.

Рішення: Під час відновлення тимчасово зменшіть concurency (особливо на напрямок), якщо має місце віддалене тротлінгування.

Завдання 8: Шукайте тайм-аути milter/policy (невидимий ручник)

cr0x@server:~$ journalctl -u postfix -S "1 hour ago" | egrep -i "milter|policy|timeout" | tail -n 20
Jan 03 10:31:07 server postfix/cleanup[1881]: warning: milter inet:127.0.0.1:8891: connect to Milter service: Connection refused
Jan 03 10:31:08 server postfix/smtpd[1876]: warning: problem talking to server 127.0.0.1:8891: Connection refused

Що це означає: Postfix блокує прийняття або обробку, бо налаштований milter не відповідає. Пошта може накопичуватись у incoming, active або hold залежно від конфігурації.

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

Завдання 9: Перевірте вільне місце на диску та inodes (черга — це файли)

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G   19G  600M  97% /
cr0x@server:~$ df -i /var/spool/postfix
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2       1310720 1299000  11720   100% /

Що це означає: У вас закінчилися inodes. Це катастрофічно для файло-орієнтованої черги: Postfix не може створювати файли черги, навіть якщо байтів ще трохи залишається.

Рішення: Безпечно звільніть inodes (логи, кеші), розширте файлову систему або перемістіть spool на більший том. Не запускайте «скрипти очищення», що rm випадкові файли черги.

Завдання 10: Визначте топ напрямків у deferred

cr0x@server:~$ postqueue -p | awk '/\(.+\)/{print}' | sed -E 's/.*\((.*)\).*/\1/' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  812 connect to mx.remote.tld[203.0.113.10]
  503 Host or domain name not found. Name service error for name=mx.other.tld type=MX
  221 451 4.7.1 Try again later

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

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

Завдання 11: Безпечно перегляньте конкретне повідомлення

cr0x@server:~$ postcat -q A1B2C3D4E5 | sed -n '1,40p'
*** ENVELOPE RECORDS active ***
message_size:           1234             1234
message_arrival_time: Fri Jan  3 10:41:22 2026
sender: sender@example.com
recipient: recipient@remote.tld
*** MESSAGE CONTENTS active ***
Received: from app01.internal (app01.internal [10.0.0.12])
        by server with ESMTP id A1B2C3D4E5
        for ; Fri, 03 Jan 2026 10:41:22 +0000 (UTC)
Subject: Password reset

Що це означає: Ви можете перевірити відправника/одержувача/заголовки без здогадок. Це допомагає уникнути видалення «сміття», яке насправді критично для бізнесу.

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

Завдання 12: Помістіть повідомлення на hold замість видалення

cr0x@server:~$ postsuper -h A1B2C3D4E5
postsuper: A1B2C3D4E5: placed on hold

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

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

Завдання 13: Звільніть утримувану пошту після виправлення причини

cr0x@server:~$ postsuper -H A1B2C3D4E5
postsuper: A1B2C3D4E5: released from hold

Що це означає: Повідомлення знову стає допустимим для доставки. Якщо базова помилка виправлена — воно доставиться під час наступного планового прогону черги.

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

Завдання 14: Запустіть контрольовану спробу черги (не давіть)

cr0x@server:~$ postqueue -i A1B2C3D4E5

Що це означає: Це просить Postfix запланувати конкретний ID черги для негайної спроби доставки.

Рішення: Використовуйте це для прицільної перевірки («чи спрацював фікс?»), а не для промивання всього беклогу одразу.

Завдання 15: Безпечно переукладіть пошту у чергу (після зміни конфігурації)

cr0x@server:~$ postsuper -r ALL
postsuper: Requeued: 392 messages

Що це означає: Postfix переписує файли черги у свіжий стан для планування. Це корисно після зміни transport maps, relayhost або виправлення тимчасової корупції.

Рішення: Requeue безпечніший, ніж delete-and-resend. Однак робіть це лише після виправлення причини і зниження concurency, якщо потрібно.

Завдання 16: Перевірте, чи qmgr не застряг

cr0x@server:~$ ps -eo pid,comm,args | egrep "postfix/qmgr|postfix/master" | grep -v egrep
1123 master  /usr/lib/postfix/sbin/master -w
1388 qmgr    qmgr -l -t unix -u

Що це означає: qmgr існує. Якщо qmgr відсутній або постійно перезапускається, черга не буде спорожнюватись незалежно від доступності віддалених хостів.

Рішення: Якщо він відсутній — перевірте помилки master.cf і логи; виправте конфігурацію перед тим, як торкатися вмісту черги.

Безпечний порядок очищення: крок за кроком (без втрати даних)

Крок 0: Визначте, що «без втрати даних» означає для вашої організації

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

Крок 1: Перестаньте погіршувати ситуацію (не зупиняючи світ)

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

• Тимчасово заблокуйте винного відправника на межі (smtpd restrictions).
• Обмежте швидкість або застосуйте tarpitting для конкретної клієнтської мережі.
• Якщо ви під атакаю, тимчасово відмовляйте з 4xx неважливим джерелам, щоб легітимні відправники могли повторити спробу.

Уникайте reflex-реакції «postfix stop» як першої дії. Зупинка може бути прийнятною, але вона також припиняє легітимні доставки і може викликати в додатках повторні спроби, що створять навантаження десь іще.

Крок 2: Зробіть знімок ситуації (дешеві докази)

Перед тим як «виправляти», зафіксуйте кілька швидких фактів, щоб підтвердити покращення і написати пристойний постмортем:

• Розмір черги зараз і через 15 хвилин.
• Топ-3 причин відкладення.
• Топ-3 напрямки за обсягом.
• Стан диску/inode.
• CPU/iowait і мережеві помилки.

Це не бюрократія. Це як не ганятися за примарами.

Крок 3: Виправляйте вузьке місце, а не чергу

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

• Ремонт DNS: виправити resolv.conf, полагодити upstream, додати локальний кешуючий резолвер.
• Відкрити вихідний TCP/25 або налаштувати relayhost на 587 з автентифікацією.
• Перезапустити/відновити milters і контент-фільтри; збільшити їхню потужність, якщо вони є точкою гальмування.
• Вирішити проблему з диском/inode; перемістити spool на виділену файлову систему при необхідності.
• Робота з віддаленим тротлінгом: зменшити concurency і дотримуватися backoff для 4xx.

Крок 4: Повторно відправляйте пошту у контрольований спосіб

Після виправлення причини ви хочете рівномірне спорожнення, а не натовп.

• Почніть з доставки кількох відомих ID черги (postqueue -i) щоб підтвердити успіх.
• Тимчасово зменшіть concurency на напрямок, якщо вас тротлять.
• Використовуйте postsuper -r ALL після зміни transport/relayhost для перепланування.
• Слідкуйте за глибиною черги і частотою відкладень під час нарощування.

Крок 5: Видаляйте пошту лише з обґрунтованою, документованою причиною

Іноді видалення черги виправдане. Приклади:

• Підтверджений спам-флуд з скомпрометованого акаунта, який не можна доставляти.
• Поштовий цикл, який ви можете довести, що ніколи не вдасться (помилкова експансія адрес).
• Шкідливий вміст, який не можна ретранслювати.

Коли видаляєте — робіть це вузько: за ID черги, відправником або часовим вікном. І зберігайте запис.

Короткий жарт №2: Якщо хтось пропонує «просто видалити чергу», поцікавтеся, яку кінцівку вони готові відрізати, щоб вилікувати вивих.

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

DNS: мовчазний вбивця черги

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

• Багато відкладень з «Name service error» або «Host not found», які згодом проходять.
• Високе навантаження з низьким використанням CPU (процеси в IO wait / blocked станах).
• dig-запити з хоста почуваються повільними або непослідовними.

Виправляйте DNS першим. Потім делікатно повторно відправляйте чергу. Промивання черги з поламаним DNS створить гуркіт тайм-аутів.

Вихідна мережа: фаєрвол, що з’їв вашу пошту

Блокування вихідного TCP/25 — поширене в корпоративних і хмарних середовищах. Іноді це зроблено навмисно. Іноді зміна правила пішла не так. Postfix може чергувати вічно, але користувачі не перейматимуться, що це «за замовчуванням».

Якщо не можете доставляти напряму до MX, використайте relayhost. Безпечне відновлення — налаштувати relayhost, протестувати одним ID черги, потім requeue і злити.

Віддалене тротлінг та greylisting: не зламано, просто недружньо

Віддалені MTA повертають 4xx з різних причин: ліміти швидкості, репутація, тимчасові ресурси, greylisting. Postfix трактує це як тимчасове і відкладає.

Не «вирішуйте» greylisting грубими повторними спробами. Дотримуйтеся backoff, знижуйте concurency і переконайтеся, що ваша IP-репутація та зворотний DNS в порядку. Черга може бути симптомом репутації, а не проблемою Postfix.

Milters і контент-фільтри: дорогі проміжні сервіси

Milter-и чудові, поки не перестануть працювати. Падаючий milter може блокувати прийом пошти або уповільнювати обробку cleanup. Повільне сканування AV може перетворитись у загальносистемну проблему пропускної здатності.

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

Зберігання: здоров’я черги — здоров’я зберігання

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

Корупція черги рідкісна, але трапляється після раптового вимкнення живлення, багів файлової системи або проблем з віртуалізованим сховищем. Коли це відбувається — зберігайте spool, ремонтуйте файлову систему і робіть requeue, а не rm -rf у спробі заглушити логи.

Три корпоративні історії-уроки (помилки, якими можна скористатися)

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

Середня компанія мала релей, який «ніколи не торкався листів користувачів», тільки сповіщення додатків. Цей вислів повторювався так часто, що став фольклором. Одного ранку черга досягла десятків тисяч повідомлень, і інженер on-call зробив те, що підказував фольклор: видалив deferred чергу, щоб «дозволити новій пошті проходити».

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

Технічно, справжня проблема була у блокуванні вихідного TCP/25 після зміни правила фаєрволу. Postfix працював правильно: чергував і повторював спроби. Видалення черги знищило єдину копію тих сповіщень. Не було upstream-повтору, бо додатки вже успішно передали повідомлення.

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

Урок: ставтесь до Postfix як до надійного буфера. Поки додаток передав повідомлення, черга — це система обліку, поки доставка не пройде або ви свідомо не відскочите.

2) Оптимізація, що обернулась проти

Інша організація управляла завантаженим вихідним релеєм і захотіла прискорити пропускну здатність. Хтось підвищив ліміти concurency — глобально і на напрямок — бо черга «виглядала занадто повільною». Це працювало день чи два. Потім віддалені провайдери почали повертати більше відповідей 421/451, і greylisting став постійним.

Що сталося під капотом: їхній релей почав виглядати як агресивний відправник. Більше паралельних підключень, одночасні доставки і часті повторні спроби під час тимчасових відмов. Деякі великі поштові провайдери трактують таку поведінку як підозрілу або зловживальну, незалежно від вмісту.

Черга стала гіршою, а не кращою. Кожна невдала спроба породжувала більше логів, більше DNS-запитів і більше сокетового шуму. Система більше часу витрачала на швидші невдачі, ніж би витратила на повільніші успіхи.

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

Урок: не налаштовуйте Postfix як вебсервер. Пошта — це довга гра, і віддалені MTA мають право голосу.

3) Нудна, але правильна практика, яка врятувала день

Фінансова компанія ставилася до релею як до інфраструктури, а не до улюбленого проекту. Конфігурація була під контролем, зміни переглядалися, і — найголовніше — spool жив на виділеній файловій системі з моніторингом inode і латентності.

Під час не пов’язаного інциденту їхній обсяг логів різко зріс, і окремий додаток почав генерувати великі тимчасові файли на кореневій файловій системі. На багатьох серверах це тихо заповнило б диск, поки Postfix не почав би відмовляти. Тут же спул мав власний запас місця і inodes.

Черга росла, але не впала. Postfix продовжував приймати пошту, надійно її зберігати і повторювати доставки. On-call отримав оповіщення про inodes для кореневого файлу, але не для спулу. Це дало критичну інформацію: стійкість пошти збережена; вузьке місце — не прийняття/збереження, а ємність доставки.

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

Урок: виділена файловий система для spool і моніторинг inode — найскучніша, але найкорисніша страхівка.

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

1) «mailq показує тисячі deferred повідомлень»

Корінна причина: Віддалене тротлінгування, проблеми DNS або блокування вихідної мережі.

Виправлення: Визначте топ-рядки причин і напрямків; виправте DNS/мережу; зменшіть concurency; requeue і дренуйте. Не перезавантажуйте Postfix як терапію.

2) «Черга ніколи не спорожняється, хоча віддалений доступний»

Корінна причина: qmgr не працює, помилки master.cf або застряглий шлях cleanup/content filter.

Виправлення: Перевірте процеси qmgr/master; огляньте логи на тайм-аути cleanup/milter; відновіть залежності; потім прогонуйте одне повідомлення для валідації.

3) «Після виправлення фаєрволу нічого не сталося»

Корінна причина: Повідомлення відкладені з таймерами backoff; Postfix не буде миттєво повторювати все.

Виправлення: Викличте контрольовані повтори: postqueue -i для тестового ID; потім postsuper -r ALL за потреби. Уникайте масових промивок.

4) «Postfix відмовляє нову пошту тимчасовими помилками»

Корінна причина: Контент-фільтр/milter впав, або диск/inodes вичерпані, або забагато активних процесів.

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

5) «Файли черги відсутні / дивні ID черги / помилки postsuper»

Корінна причина: Файлова корупція, ручне видалення або зламана шар зберігання.

Виправлення: Утримайтеся від спонтанних скриптів очищення. Перевірте цілісність файлової системи, збережіть spool і використовуйте requeue після стабілізації зберігання.

6) «Тільки один домен застряг; все інше в порядку»

Корінна причина: MX того домену впав, він вас тротлить або у вас проблема маршрутизації до тієї мережі.

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

7) «Бум бонcів; користувачі отримують backscatter»

Корінна причина: Ви генеруєте NDR для підроблених відправників або тимчасові помилки обробляєте як постійні.

Виправлення: Завжди відхиляйте погану пошту на етапі SMTP, коли це можливо; уникайте bounce для спаму, прийнятого від незаверефікованих джерел; перегляньте політику 4xx vs 5xx.

Контрольні списки / покроковий план

Контрольний список A: Перші 10 хвилин (тріаж без жалю)

1. Отримайте розмір черги і топ-помилку: postqueue -p, grep логів на «deferred».
2. Розділіть кількість файлів active vs deferred.
3. Перевірте диск і inodes для /var/spool/postfix.
4. Підтвердіть існування процесів Postfix (master/qmgr).
5. Перевірте швидкість DNS за допомогою dig для проблемного домену.
6. Перевірте вихідну доступність nc до проблемного MX.
7. Вирішіть, чи джерело прийому посилає занадто багато (внутрішні додатки). Якщо так — тимчасово обмежте або заблокуйте.

Контрольний список B: Безпечне відновлення (виправлення + повтор)

1. Виправте корінну причину (DNS/мережа/фільтр/зберігання).
2. Протестуйте доставку одним повідомленням: postqueue -i QUEUEID.
3. Тимчасово зменшіть concurency, якщо очікується тротлінг.
4. Якщо змінились маршрути/конфіг — requeue: postsuper -r ALL.
5. Спостерігайте за глибиною черги і частотою помилок 15–30 хвилин.
6. Випускайте утримувані повідомлення партіями, якщо ви їх ізолювали.
7. Тільки потім розгляньте вузьке видалення небажаної пошти.

Контрольний список C: Коли потрібно видаляти (контролювано, з аудиторією)

1. Доведіть, що пошта небажана або шкідлива (перегляньте postcat -q).
2. Спочатку зупиніть джерело (скомпрометований акаунт/додаток).
3. Якщо є невизначеність — надавайте перевагу hold над delete.
4. Видаляйте по ID черги або відправнику з номером інциденту в тикеті.
5. Запишіть, що було видалено і чому. Майбутній ви запитає про це.

Питання та відповіді

1) Чи безпечно запускати postsuper -d ALL?

Це «безпечно» в тому сенсі, як форматування диска: воно робить те, що обіцяє. Це не процес відновлення. Використовуйте hold, цілеспрямовані видалення і спочатку виправте корінну причину.

2) Чи варто перезапускати Postfix, коли черга застрягла?

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

3) Чому все у deferred навіть після виправлення мережі?

Повідомлення у deferred підпорядковуються таймерам backoff. Postfix не відразу повторить все. Використовуйте postqueue -i для перевірки і подумайте про postsuper -r ALL, коли впевнені.

4) У чому різниця між «flush» і «requeue»?

Flush (прогін черги) намагається доставити допустимі повідомлення. Requeue переписує/переплановує повідомлення в черзі. Requeue корисний після зміни конфігурації; flush відбувається нормально з часом.

5) Як уникнути ситуації, коли один поганий домен домінує спробами доставки?

Зменшіть concurency для того напрямку і розгляньте transport maps, щоб маршрутувати його інакше. Мета — не дозволити йому зупинити решту вашої пошти, поки домен відновлюється.

6) Як зрозуміти, чи проблема у локальному зберіганні черги?

Перевірте df -h і df -i для спулу і шукайте повідомлення Postfix про помилки створення/перейменування файлів. Високий iowait і вичерпання inode — класичні ознаки.

7) Чи можна перемістити spool Postfix на іншу файлову систему?

Так, і часто це добра ідея для надійності та продуктивності. Робіть це обережно: зупиніть Postfix, скопіюйте збереження прав, оновіть конфігурацію і перевірте цілісність черги перед запуском.

8) Який найбезпечніший спосіб переглянути чергову пошту на наявність чутливого вмісту?

Використовуйте postcat -q QUEUEID і обмежуйте доступ до директорій спулу. Ставтесь до доступу до спулу як до доступу до продакшн бази даних: логовано, обґрунтовано і мінімально.

9) Чому багато помилок 4xx, а майже немає 5xx?

4xx означає «тимчасово» і тригерить повтори. Багато провайдерів свідомо використовують 4xx для контролю поведінки відправника. Ваше завдання — відступити, а не сперечатись із SMTP-фізикою.

Наступні кроки (що робити після того, як ви загасили пожежу)

Як тільки черга спадає і користувачі перестануть надсилати вам скріни, не йдіть просто так. Виконайте ці практичні кроки, поки все ще свіжо:

1. Додайте моніторинг глибини черги і причин відкладення (трендові оповіщення, а не лише пороги).
2. Моніторьте inode і латентність спулу, а не тільки відсоток зайнятого диску.
3. Задокументуйте правило «тримати, не видаляти» і вимагайте причину для руйнівних дій.
4. Встановіть розумні значення concurency за замовчуванням і обмеження по напрямках для вашого типового потоку пошти.
5. Явно вкажіть залежності: milters, DNS-резолвери, relayhosts. Якщо вони впадуть — ви маєте знати до того, як черга стане вашим дашбордом.
6. Проведіть вправу з відновлення: створіть тестовий беклог у staging і потренуйте безпечний порядок, щоб production не був вашим тренувальним майданчиком.

Черга — не ваш ворог. Це ваш архів доказів і амортизатор ударів. Ставтесь до неї відповідно.