Електронна пошта: Пошта переповнена — як запобігти та відновитися без втрат

November 27, 2025 • February 3, 2026 • Читання: 4 хв • Views: 5

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

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

Найгірше: інциденти з переповненими скриньками зазвичай можна запобігти. Друге найгірше: неправильно обраний «швидкий фікс»
може перетворити проблему з диском на інцидент втрати даних. Уникнемо обох.

Що насправді означає «пошта переповнена» (протокол проти реального стану зберігання)

«Пошта переповнена» звучить просто. Насправді ні. Залежно від системи це може означати:

Перевищено квоту користувача (плагін IMAP/квоти каже «далі не можна»).
Сховище скриньки заповнене (диск, dataset, логічний том LVM, виснаження інодів).
Внутрішнє обмеження сховища повідомлень (ліміти на папку, ліміти на розмір скриньки, політики на максимальний розмір повідомлення).
Отримувач досяг ліміту у свого провайдера (ви не можете це виправити; можна лише повідомити користувача).
Тимчасові помилки неправильно повідомляються (деякі MTA повертають «пошта переповнена», коли реальна причина — збій доставки/LMTP).

Операційна відмінність, яка має значення: це відмова під час SMTP (5xx/4xx під час доставки) чи
відкладення/черга, яка накопичується? Відмова болюча для відправника, але чиста для ваших серверів.
Відкладення призводить до розростання черги, поки це не перетвориться на інцидент зі сховищем.

Де це проявляється у ланцюжку

Типовий конвеєр: SMTP прийом (Postfix/Exim/Exchange) → черга → локальна доставка (LMTP/LDA) →
сховище скриньок (Maildir/mbox/dbox, база Exchange) → доступ через IMAP.

«Пошта переповнена» може походити від локального агента доставки (квота) або від файлової системи (ENOSPC, EDQUOT, ENFILE, виснаження інодів),
а потім підніматися назад до боку SMTP як причина bounce.

Якщо ви запам’ятаєте лише одне: розглядайте «пошта переповнена» як проблему зберігання + політики, а не як проблему електронної пошти.
Частина, що стосується пошти — лише місце, де це стає видимим.

Цитата, яка збереже реалістичність

Вернер Фогельс (парафраз): Ти побудував — ти експлуатуєш; експлуатаційна відповідальність належить творцям.

Цікавинки та коротка історія (бо ця проблема старша за ваш пейджер)

Факт 1: Класичний формат mbox зберігає всю скриньку в одному файлі; один великий файл робить відмови «переповнення» більш катастрофічними і повільними для ремонту.
Факт 2: Maildir створено частково, щоб уникати проблем з блокуванням mbox, використовуючи один файл на повідомлення; це міняє проблему на кількість файлів/інодів заради безпечної конкуренції.
Факт 3: Ранні SMTP-коди помилок встановили паттерн: постійні відмови (5xx) проти тимчасових (4xx). «Пошта переповнена» часто відповідає 552 або 452 залежно від політики.
Факт 4: Виснаження інодів — це реальна «заповненість диска», навіть якщо df показує багато вільного місця — сервери з великою кількістю Maildir-файлів добре дізнаються про це важким шляхом.
Факт 5: Деякі поштові системи реалізують квоти на рівні застосунку (Dovecot, Exchange), а не на рівні файлової системи. Ось чому сховище може бути в порядку, а доставка — відмовляти.
Факт 6: Розширення IMAP QUOTA дозволяють клієнтам показувати користувачам, що вони наближаються до ліміту. Багато організацій не вмикають це, а потім дивуються, чому користувачі здивовані.
Факт 7: Маркетингове «необмежена скринька» часто приховує практичні ліміти: максимальний розмір вкладення, ретеншн або обмеження пропускної здатності. Скринька не безмежна; брошури — так.
Факт 8: Backscatter (повернення на підроблених відправників) колись був поширеним, коли MTA приймали пошту, а потім відмовляли. Відмовляти під час SMTP — чистіше й гуманніше.

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

Ви на виклику. Хтось каже: «Пошта повертається; скринька переповнена.» Не відволікайтеся. Робіть це.

Перше: визначте масштаб і чи це квота чи сховище

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

Друге: визначте, де відбувається відмова доставки

Відхилення SMTP на RCPT/DATA? Подивіться логи Postfix і коди стану (552/452 проти загального «unknown»).
Помилка LMTP/LDA? Dovecot зазвичай видає чіткі повідомлення про квоту, і ви можете перевірити це з doveadm.
Помилка файлової системи? ENOSPC/EDQUOT у логах означає, що ваша проблема — примусове обмеження зберігання, а не політика пошти.

Третє: оберіть найменш руйнівний спосіб полегшення

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

Жарт №1: Поштові скриньки як кухонні шухляди — ніхто не знає, що в них лежить, але якось завжди немає місця для ще однієї речі.

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

Команди нижче розраховані на Linux-поштовий сервер з Postfix + Dovecot та сховищем Maildir.
Якщо у вас Exchange або хостингова служба, багато ідей все одно підходять: перевірте сховище, квоти, чергу, а потім усувайте причину з найменшим ризиком для даних.

Завдання 1: Підтвердити помилку в логах пошти (і чи це по користувачу)

cr0x@server:~$ sudo grep -E "quota|mailbox full|552 |452 |over quota|EDQUOT|ENOSPC" /var/log/mail.log | tail -n 20
Jan 04 10:12:19 mx1 postfix/lmtp[28177]: 3C1A12A0B3: to=<alex@example.com>, relay=imap1[10.0.2.10]:24, delay=2.1, delays=0.2/0.01/0.3/1.6, dsn=5.2.2, status=bounced (host imap1[10.0.2.10] said: 552 5.2.2 <alex@example.com> Quota exceeded (in reply to RCPT TO command))
Jan 04 10:12:20 mx1 postfix/qmgr[1123]: 3C1A12A0B3: removed

Що це означає: DSN 5.2.2 плюс «Quota exceeded» вказує на квоту застосунку на стороні доставки (часто Dovecot).

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

Завдання 2: Перевірити використання диска на монтуванні пошти

cr0x@server:~$ df -hT /var/mail /var/vmail
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   80G   79G  1.1G  99% /
/dev/sdb1      xfs   2.0T  1.3T  700G  66% /var/vmail

Що це означає: Коренева файлова система майже повна; /var/vmail у порядку. Якщо черга Postfix або логи живуть на /, ви можете відмовляти в доставці навіть при наявності вільного місця в поштовому сховищі.

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

Завдання 3: Перевірити виснаження інодів (улюблена підстава Maildir)

cr0x@server:~$ df -ih /var/vmail
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sdb1        64M    63M   850K   99% /var/vmail

Що це означає: Функціонально у вас закінчилось місце, бо закінчилися іноди. Maildir створює багато дрібних файлів; це нормально… поки не стає проблемою.

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

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

cr0x@server:~$ mailq | tail -n 5
-- 10954 Kbytes in 1423 Requests.

Що це означає: 1423 повідомлення в черзі не обов’язково фатальні, але це тривожний знак. Якщо черга росте, ваша «одна скринька» перетворюється на «затримка всім».

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

Завдання 5: Визначити топ-одержувачів у черзі

cr0x@server:~$ sudo postqueue -p | awk '/^[A-F0-9]/{id=$1} /to=

Що це означає: Декілька отримувачів домінують. Це або проблема квоти для цих скриньок, або шаблон спаму/потоку.

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

Завдання 6: Підтвердити статус квоти Dovecot для користувача

cr0x@server:~$ sudo doveadm quota get -u alex@example.com
Quota name=User quota Type=STORAGE Value=5120M Limit=5120M %
Quota name=User quota Type=MESSAGE Value=98234 Limit=0 %

Що це означає: Квота по зберіганню точно на межі (5120M використано з 5120M). Ліміт по кількості повідомлень — необмежений (Limit=0).

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

Завдання 7: Знайти найбільші папки та файли в Maildir (швидка триаж)

cr0x@server:~$ sudo du -h --max-depth=2 /var/vmail/example.com/alex/Maildir | sort -h | tail -n 10
1.2G    /var/vmail/example.com/alex/Maildir/.Sent
2.6G    /var/vmail/example.com/alex/Maildir/.Archive
5.1G    /var/vmail/example.com/alex/Maildir

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

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

Завдання 8: Знайти незвично великі повідомлення (зазвичай вкладення)

cr0x@server:~$ sudo find /var/vmail/example.com/alex/Maildir -type f -size +50M -printf "%s %p\n" | sort -nr | head
104857612 /var/vmail/example.com/alex/Maildir/cur/1704361234.M12345P6789.mx1,S=104857612:2,
73400612  /var/vmail/example.com/alex/Maildir/.Sent/cur/1704300044.M22222P1111.mx1,S=73400612:2,

Що це означає: Є повідомлення >50MB у скриньці. Це першочергові кандидати на очищення користувачем або автоматичне архівування.

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

Завдання 9: Перерахувати та відновити квоти Dovecot (після очищення/переміщення)

cr0x@server:~$ sudo doveadm quota recalc -u alex@example.com

cr0x@server:~$ sudo doveadm quota get -u alex@example.com
Quota name=User quota Type=STORAGE Value=4032M Limit=5120M %

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

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

Завдання 10: Перевірити застосування квот файлової системи (EDQUOT) проти квот Dovecot

cr0x@server:~$ sudo dmesg | tail -n 20
[123456.789012] XFS (sdb1): Quotacheck needed: Please turn quotas off and on again.
[123457.001122] XFS (sdb1): User quota exceeded. UID: 5000

Що це означає: Квоти файлової системи активні та застосовуються. Dovecot може бути ні при чому; ядро каже «ні».

Рішення: Виправляйте політику на рівні ядра/файлової системи (підвищити, змінити мапінг або відновити стан квот), а не лише налаштування Dovecot.

Завдання 11: Перевірити шлях транспорту LMTP/LDA та коди помилок

cr0x@server:~$ sudo postconf -n | egrep "^(myhostname|mydestination|virtual_transport|mailbox_transport|home_mailbox|virtual_mailbox_domains|virtual_mailbox_base|smtpd_recipient_restrictions)"
myhostname = mx1.example.net
virtual_transport = lmtp:imap1:24
virtual_mailbox_domains = example.com
virtual_mailbox_base = /var/vmail

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

Рішення: Зосередьтеся на конфігурації квот Dovecot та здоров’ї сховища скриньок, а не на дивних mailbox_command.

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

cr0x@server:~$ sudo grep -E "Quota|quota|overquota|mailbox.*full" /var/log/dovecot.log | tail -n 30
Jan 04 10:12:19 imap1 dovecot: lmtp(alex@example.com)<28177>: Error: quota: Quota exceeded (mailbox for user is full)
Jan 04 10:13:02 imap1 dovecot: imap(alex@example.com)<29001>: Disconnected: Logged out in=512 out=2048

Що це означає: Dovecot явно відхиляє через квоту. Це визначально.

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

Завдання 13: Обережно злити або переочікувати пошту після усунення обмеження

cr0x@server:~$ sudo postqueue -f

cr0x@server:~$ sudo postqueue -p | tail -n 5
-- 842 Kbytes in 97 Requests.

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

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

Завдання 14: Підтвердити здоров’я сервісів (IMAP/LMTP) після змін

cr0x@server:~$ sudo systemctl status dovecot --no-pager
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-01-04 09:55:22 UTC; 38min ago

Що це означає: Dovecot запущено. Це не доказ, що квоти правильні, але виключає «сервіс впав» як причину.

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

Завдання 15: Перевірити, чи сховище тримає видалені листи (expunge/retention)

cr0x@server:~$ sudo doveadm mailbox status -u alex@example.com messages vsize deleted INBOX
messages=12450 vsize=3120M deleted=840

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

Рішення: Налаштуйте політику expunge або запустіть job на expunge згідно з правилами ретеншн. «Користувач видалив» не завжди означає «диск отримав назад».

Чисте відновлення (без створення безладу)

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

Випадок A: Файлова система сервера заповнена (або виснажено іноди)

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

Зупиніть кровотечу: якщо черга величезна і росте, розгляньте тимчасове обмеження вхідної пошти (ліміти швидкості, зміни greylisting або зовнішній failover MX, якщо він є). Якщо плану немає, принаймні переконайтеся, що можна записувати логи.
Безпечно звільніть місце: ротуйте/скомпресуйте логи, очистіть старі пакунки, видаліть тимчасові файли. Уникайте спочатку видалення файлів сховища пошти; це повільніше, ризикованіше і політично вибухонебезпечне.
Якщо проблема в інодах: виявте каталоги з неймовірною кількістю файлів (Maildir cur/new/tmp, карантин спаму) і застосуйте політично обґрунтоване очищення (ретеншн для junk, не для INBOX). Розширення інодів зазвичай означає перебудову файлової системи; розглядайте це як проєкт, не як героїчний крок о 3 ранку.
Підтвердіть відновлення сервісів: Postfix, Dovecot, антивірус/мітлер і будь-які політичні демони.
Обережно зливайте чергу: коли обмеження знято, злити й спостерігати за помилками. Масове злиття черги може виглядати як DDoS для ваших IMAP-вузлів, якщо не обережні.

Випадок B: Квота користувача заповнена

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

Підтвердьте автора квоти: це Dovecot, квота файлової системи, ліміт Exchange чи політика хмари?
Підтвердьте реальне використання: виміряйте розміри папок і знайдіть найбільших винуватців (Sent, Archive, «Проекти_2016_ФІНАЛ»).
Застосуйте полегшення з трасованістю: або очистіть згідно з політикою ретеншн (почніть з кошика/спаму), або підвищте квоту з тикетом і датою закінчення.
Перерахувати квоти/індекси: не пропускайте цей крок. Неправильний облік — причина дзвінків «я видалив 2ГБ, чому все ще повно?»
Доставте накопичене: злити чергу і підтвердити успішність нової вхідної пошти.

Випадок C: Віддалена скринька отримувача переповнена (не ваш сервер)

Ваше завдання — захистити інфраструктуру і поводитися як відповідальний SMTP-громадянин.

Підтвердіть віддалений DSN: якщо ви бачите 552 5.2.2 від віддаленого MX, прийміть реальність. Ви не можете зайти в їхню скриньку по SSH.
Уникайте нескінченних повторів: налаштуйте розумні терміни життя черги. Не тримайте пошту тижнями, якщо політика цього не вимагає і сховище для цього не розраховане.
Повідомляйте: сповістіть відправника, що отримувач перевищив квоту. Запропонуйте альтернативи: інша адреса, повторна відправка пізніше, використання сервісу для передачі файлів.
Якщо це повторюваний партнер: розгляньте обмеження повторів або окрему чергу/транспорт для тієї доменної зони, щоб один партнер не засмічував ваші диски.

Запобігання: квоти, моніторинг, ретеншн і архітектура зберігання

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

Усвідомлено оберіть модель квот (і документуйте її)

Є три поширені моделі:

Квоти на рівні застосунку (Dovecot, Exchange): гнучкі на користувача/групу, видимі клієнтам, гарний UX при увімкненому QUOTA.
Квоти файлової системи (XFS/ext4 project/user quotas): суворе примусове обмеження, працює навіть якщо поштовий додаток поводиться неправильно, але мапування користувачів на UID/project потребує дисципліни.
Квоти dataset’ів (ZFS datasets, LVM логічні томи на арендаря): відмінно ізоляція масштабів; все одно поєднуйте з квотами на користувача для справедливості.

Думка: використовуйте квоти на рівні застосунку для користувачів і ліміти на датасет/том для контролю blast-radius. Покладання лише на один рівень — шлях до сюрпризів.

Показуйте статус квоти користувачам (інакше вони покажуть його вам)

Якщо клієнти можуть показати «ви на 95%», користувачі самі коригують поведінку. Якщо не можуть — заповнять скриньку, поки MTA не почне відхиляти як у 1999.

Увімкніть IMAP QUOTA reporting, де підтримується, і переконайтеся, що веб-пошта явно показує це. Це не опікунство — це розвантаження навантаження.

Політики ретеншн: нудний важіль, який працює

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

Практичний підхід: впровадьте коротший ретеншн для Trash, Junk і великі вкладення в першу чергу. Ніхто не судиться за видалення спаму.

Інженерія зберігання: проєктуйте під реальність, не під надії

Поштова пам’ять росте як цвіль: повільно, потім різко, потім у місцях, про які ви не знали.
Проєктуйте сховище з урахуванням:

Ємність (очевидно) і іноди (менш очевидно, болючіше).
IOPS-патерни: багато дрібних файлів, інтенсивна робота з метаданими; сплески латентності виглядають як «IMAP повільний», а не як alert від сховища.
Snapshots/резервні копії: ваша «видалена пошта» може все ще існувати в снапшотах. Добре для відновлення, заплутано для планування ємності.
Розподіл відповідальностей: тримайте spool/чергу/логи окремо від root, якщо можете; заповнення root — це багато-сервісний інцидент.

Моніторинг, який реально запобігає інцидентам

Моніторинг «диск 95%» — це початок, не кінець. Для запобігання переповненості скриньок стежте за:

Місцем на файлових системах і інодами для поштового сховища, спула, логів.
Розміром черги Postfix і розподілом віку черги (старі відкладені листи — симптом).
Розподілом запасу квот (скільки користувачів >90%).
Швидкістю зростання топ-скриньок (компрометація акаунта, або робочий процес, що скидає вкладення).
Рівнями кодів помилок (сплеск 552/452, LMTP-невдачі, EDQUOT/ENOSPC у логах).

Жарт №2: Якщо ваш моніторинг каже лише «диск заповнений», вітаємо — ви побудували дуже голосну історичну книгу.

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

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

Компанія середнього розміру мігрувала зі старого односерверного налаштування пошти на «правильну» роздільну архітектуру: MX-сервери з Postfix, IMAP-вузли з Dovecot
і окреме NAS для /var/vmail. Міграцію робили обережно: тестували входи, відправку, прийом. Виглядало все добре.

Через два тижні почали повертатися рахунки. Не всі — лише кілька поштових скриньок з великою активністю: фінанси, sales ops і помічник керівника, який жив в пошті.
Відмови казали «Quota exceeded». Всі подумали, що заповнений том, бо «пошта переповнена» так звучить. Але сховище було на 40%.

Справжній винуватець — дефолтне правило квоти Dovecot, що лишилося у шаблоні: 5GB на користувача. На старому сервері квоти були фактично необмежені,
лише диск їх стримував. На новому — квоти стали реальними. Користувачі десятиліттями накопичували пошту, а нова політика виявилася пасткою.

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

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

Інша організація вирішила «оптимізувати сховище», ввімкнувши агресивну компресію і дедуплікацію на поштовому томі.
Ідея була непогана: вкладення повторюються, пошта текстова, і CFO любить графіки ємності, що падає.

Декілька тижнів виглядало як перемога. Потім настав понеділок: IMAP-пошук став повільним, нова пошта приходила з затримкою,
і черга пошти поступово зростала. Тригерили алерти по розміру черги, а не по диску. Команда зістріла на налаштуваннях Postfix, бо там був біль.

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

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

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

Регульована компанія тримала пошту сама. Не тому що подобалося — через комплаєнс. Стек був простий:
Postfix, Dovecot, Maildir, періодичні снапшоти і політика ретеншн на сервері.

Одного дня скринька досягла квоти під час юридичного вікна пошуку. Помічник керівника панікував, бо нова пошта поверталася, а керівник був у відрядженні.
Але команда мала дві нудні звички: квоти були видимі у веб-пошті, і щоденний звіт показував скриньки >85% з їхніми топ-папками.

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

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

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

1) Симптом: Bounces кажуть «пошта переповнена», але диск має місце

Корінь: Квота на рівні застосунку (Dovecot/Exchange) вичерпана; диск не є лімітером.
Виправлення: Перевірте статус квоти, розміри папок і правила квот. Очистіть або тимчасово підвищте квоту, потім перераховуйте квоти/індекси.

2) Симптом: Використання диска в порядку, але все відмовляє з «No space left on device»

Корінь: Виснаження інодів або інший монтувальний пункт (root, spool, logs) повний.
Виправлення: df -ih та перевірте всі релевантні точки монтування. Звільніть іноди (очистіть спам/карантин, застосуйте ретеншн). Перемістіть spool/логи з root.

3) Симптом: Користувач видаляє пошту, а квота не змінюється

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

4) Симптом: Черга швидко росте, доставки постійно повторюються

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

5) Симптом: Лише великі вкладення не доходять; малі листи доставляються

Корінь: Ліміт розміру повідомлення на SMTP або в сховищі скриньки; іноді помилково повідомляється як «переповнення».
Виправлення: Підтвердьте ліміти в MTA і агенті доставки; запропонуйте альтернативи; не підвищуйте ліміти без розгляду ризиків зберігання і зловживань.

6) Симптом: Після звільнення місця Dovecot все ще відхиляє через квоту

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

7) Симптом: Тільки один домен або орендар «повний», інші в порядку

Корінь: Квота dataset/project на рівні домену; мультиоренджа ізоляція спрацювала.
Виправлення: Перевірте ліміти dataset’ів і використання, а не лише квоти користувачів. Збільшіть виділення домену або застосуйте ретеншн/архівування для орендаря.

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

Контрольний список A: Коли спрацьовує оповіщення (15 хвилин до стабільності)

Підтвердіть, чи відмови локальні чи віддалені (логи кодів помилок і релеї).
Перевірте df -h і df -ih на root, spool і поштовому сховищі.
Перевірте розмір черги і її зростання (mailq зараз і знову через 5 хвилин).
Знайдіть топ-одержувачів у черзі; вирішіть, чи ізолювати їх.
Якщо диск/іноди критичні: спочатку звільніть безпечний простір (логи/temp), не видаленням пошти.
Якщо причина — квота: отримайте статус квоти; знайдіть топ-папки; застосуйте політично погоджене очищення або тимчасове підвищення.
Перерахувати квоти/індекси.
Злити чергу і моніторити рівень помилок; підтвердити, що нова вхідна пошта доставляється.

Контрольний список B: Чисте відновлення без втрати даних

Перед видаленням чогось: підтвердьте, що рахується для квоти (Sent/Archive/Junk/Trash).
Краще перемістити в архів, ніж видаляти, коли важливі відповідність/комплаєнс.
Документуйте зміни: зміни квот, дії ретеншн, будь-які ручні модифікації скриньок.
Після відновлення перевірте доступ користувача (IMAP вхід, список папок, надходження нової пошти).
Підтвердіть, що bounce-и припинилися і відкладена черга стікає.
Якщо повідомлення були відхилені назавжди, узгодьте стратегію повторної відправки.

Контрольний список C: Робота з профілактики, яка окуповується щомісяця

Визначте квоти скриньок за ролями (керівники, спільні скриньки, сервісні акаунти) і опублікуйте політику.
Увімкніть видимість квот у клієнтах/веб-пошті.
Впровадьте ретеншн для Junk/Trash; розробіть стратегію щодо вкладень.
Моніторьте диск, іноди і розподіл віку черги.
Відокремте spool/логи від root файлової системи.
Щоквартально тестуйте відновлення: симулюйте перевищення квоти, підтвердіть оповіщення і точність runbook.

Питання та відповіді (те, що питають одразу після фіксу)

1) Чому відправник отримав bounce замість затримки?

Тому що шлях доставки повернув постійну помилку (5xx), наприклад 552/5.2.2. Постійні помилки зазвичай генерують bounce.
Тимчасові помилки (4xx) викликають повтори і чергування.

2) «Пошта переповнена» має бути 4xx чи 5xx?

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

3) Користувачі видалили пошту, але квота не змінилася. Вони брешуть?

Не обов’язково. IMAP-видалення часто лише маркує повідомлення як видалені до expunge. Також облік квоти може бути застарілим.
Перерахуйте квоту і перевірте серверну поведінку expunge.

4) Чи безпечно видаляти файли прямо з Maildir?

Це може бути безпечно, якщо ви точно знаєте, що робите, але зазвичай це не найкращий перший крок. Віддавайте перевагу інструментам на сервері (doveadm) або контрольованим job-ам ретеншн.
Ручне видалення ризикує індексною неконсистентністю і дивною поведінкою для користувачів.

5) Чому використання інодів таке важливе на поштових серверах?

Maildir зберігає кожне повідомлення як окремий файл. Сотні тисяч листів означають сотні тисяч інодів.
Коли іноди закінчуються, система не може створити нові файли — навіть якщо гігабайти вільні.

6) Можу просто підвищити квоти і все?

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

7) Як не дозволити одній скриньці заповнити чергу Postfix?

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

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

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

9) Чому звільнення місця не виправило доставку одразу?

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

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

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

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

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

Оберіть стратегію квот (комбінація квот на рівні застосунку + обмеження на датасет — надійний варіант) і документуйте її як частину продукту.
Інструментуйте правильні сигнали: диск, іноди, вік черги, розподіл запасу квот, і коди помилок доставки.
Виробіть безпечну звичку відновлення: спочатку звільніть безпечний простір, виправте реальне обмеження, перераховуйте квоти/індекси, потім зливайте черги і перевіряйте.
Зробіть ретеншн і архівування реальними: особливо для Junk/Trash і вкладень. Саме там живе більшість «таємного росту».

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

Схожі статті

Port 25 заблоковано: як усе одно відправляти пошту (без сумнівних хаків) Postfix: ризик відкритого ретранслятора — протестуйте, доведіть, закрийте