Почтовый ящик переполнен, хотя место есть: как проверить квоты

Сообщение mailbox full не всегда означает заполненный раздел диска. У пользователя может быть отдельная квота, доменный лимит, переполненные скрытые папки, исчерпанные inode или устаревший индекс Dovecot. Иногда панель показывает размер только INBOX, а Trash, Spam and Sent занимают большую часть лимита. Удаление случайных файлов вручную может повредить Maildir и не обновить учет.

Сохраните точный SMTP-код отказа и определите, какой компонент его вернул. Сравните filesystem space, inode, user quota, domain quota and фактический размер всех папок. Не удаляйте файлы из Maildir через проводник без понимания индексов и процесса пересчета.

Что проверить в первую очередь

Начните с одного воспроизводимого сценария. Зафиксируйте точное время, идентификатор объекта, пользователя или операции, версию приложения и последнее известное рабочее состояние. Не меняйте несколько параметров одновременно: один контролируемый шаг должен подтверждать или исключать одну гипотезу. Перед работой с данными и конфигурацией подготовьте резервную копию и проверенный способ отката.

• Проверьте df space and df inode на разделе с почтой.
• Получите фактическую квоту пользователя через Dovecot or используемый mail stack.
• Посчитайте размер всех Maildir folders, включая hidden Trash, Junk and Sent.
• Проверьте доменный лимит, резерв файловой системы и отдельный volume or container.

Почему возникает проблема

Внешний симптом часто появляется дальше по цепочке, чем первичная ошибка. Интерфейс может показывать неверное состояние из-за backend, очереди, кеша, прав доступа, фоновой задачи или внешнего API. Поэтому важно проследить данные от источника до результата и найти первую точку расхождения, а не исправлять только последнее сообщение об ошибке.

• Панель показывает общий диск, а mailbox имеет меньшую логическую квоту.
• Dovecot quota index устарел после ручного перемещения или восстановления писем.
• Свободны гигабайты, но закончились inode из-за множества мелких сообщений.
• Удаленные письма остаются в Trash и продолжают учитываться.
• LMTP or delivery process пишет на другой заполненный mount, чем тот, который проверил администратор.

Пошаговая диагностика

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

• Сохраните SMTP response and mail log для конкретного recipient and time.
• Сравните путь mailbox из конфигурации с реально проверяемым mount.
• Получите quota get and recalc на тестовом пользователе.
• Посчитайте files and bytes по папкам без чтения содержимого писем.
• Проверьте permissions, ownership and temporary delivery directory.

Какие лимиты участвуют в доставке письма

Решение принимает delivery service на основе нескольких ресурсов. Нужно проверить не только bytes основного диска, но и логическую квоту, inode, место временной записи, доменные ограничения и доступ процесса к mailbox.

• Filesystem контролирует bytes, inode and reserved blocks.
• Mail server применяет user quota and domain quota.
• Mailbox index хранит рассчитанное использование и требует согласованного обновления.
• Delivery временно создает файл, затем атомарно перемещает его в Maildir new.

Как исправить проблему

Исправление делите на небольшие обратимые изменения. Сначала устраните подтвержденную причину, затем повторите исходный сценарий и проверьте соседние функции. Массовое обновление данных запускайте на ограниченной выборке с отчетом и только после сверки расширяйте на весь объем. Не отключайте авторизацию, проверку сертификатов, валидацию или аудит ради быстрого исчезновения симптома.

• Освободите или увеличьте подтвержденный ограничивающий ресурс, а не произвольный диск.
• Очистите Trash and Spam через почтовый протокол или штатный инструмент.
• Выполните безопасный quota recalc после резервной копии и проверки ownership.
• Исправьте mount, path, permissions or container volume, если delivery смотрит не туда.
• Настройте предупреждения пользователю до достижения лимита.

Безопасный порядок внедрения

• Сохраните затрагиваемые данные, конфигурацию и текущие журналы, затем проверьте возможность реального восстановления.
• Повторите проблему на тестовом объекте без реальных списаний, рассылок и необратимых изменений клиентских данных.
• Зафиксируйте изменение в системе контроля версий или журнале работ вместе с причиной, ожидаемым эффектом и планом отката.
• Проведите тест на нормальном сценарии, ошибочном вводе, повторном запросе, параллельной операции и временной недоступности зависимости.
• После выпуска наблюдайте полный пользовательский путь, логи и метрики, а не только один успешный запрос.

Как проверить результат

Разовый успешный тест недостаточен. Повторите операцию, проверьте крайние значения, одновременные действия и восстановление после перезапуска или временного сбоя. Для важного сценария сохраните автоматический тест либо короткий регрессионный чек-лист. Итог должен подтверждаться не только интерфейсом, но и состоянием базы, очереди, внешнего сервиса и журналом действий.

• Quota tool показывает ожидаемое использование и лимит.
• Тестовое письмо доставляется, появляется в нужной папке и читается клиентом.
• Пересчет после добавления and удаления сообщения меняет usage корректно.
• Перезапуск сервиса не возвращает старое неправильное значение.

Типичные ошибки при исправлении

• Удалять случайные Maildir files при работающем сервере без backup.
• Увеличивать квоту, когда закончились inode or temporary space.
• Проверять только INBOX и игнорировать скрытые папки.
• Считать webmail единственным источником размера ящика.

Как предотвратить повторение

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

• Мониторьте filesystem bytes, inode and mailbox quota отдельно.
• Отправляйте предупреждения на нескольких порогах заполнения.
• Настройте понятную retention policy для Trash and Spam.
• После миграции or restore выполняйте контролируемую проверку and recalc индексов.

Что контролировать после выпуска

• Количество успешных и ошибочных операций в разрезе версии, канала и типа сценария.
• Возраст необработанных записей, длину очередей, число повторных попыток и долю окончательных отказов.
• Расхождение между пользовательским статусом и фактическим состоянием в базе или внешней системе.
• Появление новых кодов ошибок после релиза и изменение времени выполнения ключевой операции.
• Сигналы от поддержки и бизнес-метрики, которые могут показать скрытый частичный сбой.

Что подготовить для технического разбора

• Описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
• Фрагменты журналов до и после ошибки без секретов и персональных данных.
• Перечень последних изменений и уже выполненных проверок.
• Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Почему после удаления писем квота не уменьшилась?

Письма могли переместиться в Trash, остаться помеченными без expunge или индекс квоты не пересчитался. Проверьте папки и используйте штатную процедуру.

Может ли проблема быть при свободном диске?

Да. Частые причины — user quota, domain quota, inode, другой mount, reserved space или заполненная временная директория.

Когда нужна помощь специалиста

Если сервер сообщает о переполненном ящике при свободном диске, я могу проверить реальные квоты, inode, Maildir и Dovecot, безопасно пересчитать учет и настроить предупреждения.