Что делать, если почта застряла в очереди

Если письма застряли в очереди, сначала выясните причину и оцените последствия, затем удаляйте только те сообщения, которые точно не нужны. Я покажу команды Postfix для просмотра, повторной доставки и адресного удаления, а для mailcow — как запускать их в правильном контейнере. Перезагрузка всей машины для этого обычно не нужна.

Сначала проверьте очередь и её состояние

В Postfix для просмотра очереди я использую postqueue -p или его совместимую команду mailq. Вывод показывает идентификатор сообщения, размер, дату, отправителя и получателей, а после записей — краткую причину последней неудачной попытки. Если сообщений много, не пытайтесь прокручивать весь список вручную: начните со сводки по количеству, затем изучите несколько старых записей и причины отказа. Большое число само по себе не диагноз. Очередь может расти из-за временного сбоя у получателя, DNS, сети, TLS, ошибки маршрутизации или слишком медленной обработки; удаление не исправит ни одну из этих причин.

У Postfix есть несколько состояний сообщений: incoming, active, deferred и hold, а также отдельная corrupt-область для повреждённых файлов очереди. postqueue -p показывает сообщения в очереди, включая отложенные; не следует представлять это как пять равноправных списков, которые команда всегда выводит отдельными таблицами. Deferred обычно означает, что доставка временно не состоялась и будет повторена по расписанию. Hold — это удержанные администратором сообщения, они не отправляются, пока их не освободят. Сначала выясните, в каком состоянии находится нужное письмо, и не делайте вывод по одному слову в статусе.

Проверьте место на диске и inode на том разделе, где расположен каталог очереди. Путь /var/spool/postfix часто встречается в стандартной установке, но в контейнеризированной системе и нестандартной конфигурации путь может отличаться. Поэтому команда du -sh /var/spool/postfix/* не универсальный способ найти виновника: она может показать внутреннюю структуру, а не понятный объём сообщений, и дать ошибку доступа. Сначала выясните фактический queue_directory в конфигурации своего экземпляра и смотрите свободное место на соответствующей файловой системе.

Заодно сравните число писем с обычной нагрузкой и посмотрите возраст старейших сообщений. Порог «старше суток — авария» не существует: срок доставки зависит от политики организации и причины отказа. Почта к недоступному MX может законно оставаться в deferred и повторяться позже. Нужны динамика и текст ошибки, а не магическое число в часах. Иначе можно очистить очередь только потому, что письмо пережило выходные.

• Посмотреть список: `postqueue -p` или `mailq`.
• Проверить свободное место и inode на разделе очереди.
• Зафиксировать queue ID и текст последней ошибки.

Найдите причину по статусу и журналу

Откройте системный журнал почтовой службы и сопоставьте ошибки с queue ID и временем попытки доставки. В Debian и Ubuntu записи часто попадают в /var/log/mail.log, в других системах — в журнал systemd или отдельный файл. В mailcow смотрите журналы контейнера Postfix; конкретный способ зависит от версии Docker Compose и каталога установки. Не ищите только буквальную фразу «connect to remote host failed»: Postfix и удалённый сервер могут сообщить конкретную причину — DNS lookup failure, timeout, TLS negotiation, отказ политики или неверный маршрут. Текст ответа важнее догадки по одному коду.

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

Коды SMTP 4xx означают временный отказ: отправитель обычно повторяет попытку позднее. Но конкретный код нельзя трактовать как готовый диагноз. По RFC 5321 код 450 описывает отказ по причине недоступности ящика, например из-за временной блокировки или занятого ящика; 452 означает недостаток системного ресурса, а также применяется при достижении лимита получателей в транзакции. Ни один из них сам по себе не доказывает, что заполнен именно диск вашего сервера. Читайте полный ответ в логе, включая текст после кода.

До очистки сохраните нужные диагностические строки и список ID. Очередь — не журнал аудита, а удаление может убрать возможность изучить содержимое конкретного сообщения. Если видите подозрительную массовую рассылку, сначала установите источник отправки и остановите генерацию новых писем; иначе после очистки очередь снова наполнится. Не обвиняйте получателя и не блокируйте домен только по тому, что его MX временно отвечает ошибкой: это может остановить нормальную деловую переписку.

Удаляйте только подтверждённые сообщения

Для ручного удаления отдельного сообщения Postfix предназначена команда postsuper -d QUEUE_ID. Перед запуском перепроверьте ID, отправителя, получателя и причину задержки. Команда postsuper -d ALL удаляет все сообщения из очереди — без разбора по возрасту или домену. Это аварийная операция с прямой потерей недоставленной почты, а не безопасная очистка «мусора». Если есть сомнение, не удаляйте: сначала уточните владельца письма и можно ли его отправить повторно. Учтите и гонку доставки: Postfix предупреждает, что queue ID могут повторно использоваться, поэтому не запускайте массовое удаление по устаревшему списку во время активной обработки. Сверяйте ID непосредственно перед операцией.

Для массовой адресной обработки соберите queue ID надёжным способом и покажите список на проверку до удаления. Не полагайтесь на mailq | grep адрес: адрес может встретиться в строке отправителя, получателя или диагностическом тексте, а формат вывода не является удобным API для произвольного фильтра. Слепое копирование найденных строк может захватить не те ID. Утилита postqueue -j в поддерживаемых версиях выдаёт JSON, который можно разбирать программно, однако прежде проверьте версию Postfix и корректность фильтра; если нет уверенного скрипта, удаляйте по проверенным ID вручную.

Для размораживания ранее удержанных сообщений существует отдельное действие postsuper -H QUEUE_ID; это не то же самое, что удаление. Повторную доставку всей очереди инициирует postqueue -f. Flush не исправляет DNS, TLS или отказ MX и может создать дополнительную нагрузку, если причина не устранена. Не запускайте его как универсальную кнопку «починить почту». Сначала восстановите условие доставки, затем решите, нужна ли ручная попытка немедленно.

В mailcow команды запускают в контейнере postfix-mailcow, например из каталога установки: docker compose exec postfix-mailcow postqueue -p. Для удаления команда будет такой: docker compose exec postfix-mailcow postsuper -d QUEUE_ID. В некоторых установках используется отдельная команда docker-compose; проверьте, какая доступна на вашем сервере. Ошибка исходной статьи docker exec -it mailcow-dockerized postfix-mailq неверна: mailcow-dockerized обычно обозначает каталог проекта, а не имя контейнера, и postfix-mailq не является корректной командой входа. Перед изменением состояния очереди сделайте резервную копию или хотя бы сохраните нужные ID и логи.

• Один ID: `postsuper -d QUEUE_ID`.
• Вся очередь: `postsuper -d ALL` — удаляет всё.
• Повторить доставку: `postqueue -f` — только после устранения причины.

Условный пример: выборочная очистка

Возьмём условный пример «Импульс-Трейд» из этой статьи. Это иллюстрация порядка действий, а не подтверждённый разбор реального инцидента: исходные цифры о заполнении диска, количестве сообщений и сроке восстановления ничем не подтверждены, поэтому я их не выдаю за факт. Допустим, администратор видит рост deferred и повторяющуюся ошибку доставки к одному домену. Он фиксирует время, несколько queue ID и полный ответ удалённой стороны, а затем проверяет, продолжают ли создаваться новые сообщения.

Далее он выясняет, влияет ли ошибка на один транспорт или на всех получателей, проверяет резолвинг MX, исходящие соединения и свежие записи журнала. Если причина на удалённой стороне и сообщения обычные, удалять их не требуется: Postfix продолжит попытки в пределах настроенного срока хранения. Если же обнаружена ненужная рассылка, владелец потока останавливает приложение или правило, которое её создаёт. Только после этого можно составить перечень ненужных ID и сравнить его с очередью, чтобы случайно не задеть сообщения другим адресатам.

Перед удалением администратор сохраняет список выбранных ID и получает подтверждение, что эти письма можно потерять. Затем выполняет postsuper -d для каждого подтверждённого ID и снова запускает просмотр очереди. Если после удаления диск не освободился, он проверяет фактический каталог очереди, открытые удалённые файлы и другие потребители места — удаление части писем не гарантирует освобождение заранее обещанного объёма. Любые точные цифры результата в таком примере были бы выдумкой.

Когда причина устранена, оставшиеся сообщения обычно обрабатываются штатно. Если необходимо ускорить повторную попытку, администратор сначала оценивает нагрузку и применяет postqueue -f, после чего смотрит, исчезла ли повторяющаяся ошибка. Перезагрузка сервера не является обязательным этапом удаления: postsuper и postqueue работают с очередью через штатный интерфейс Postfix. Но обещать «без простоя» для любой конфигурации нельзя — при нехватке места, повреждении очереди или отказе компонентов возможны отдельные последствия и нужен план восстановления.

Настройте сроки и наблюдение без опасных рецептов

Параметр maximal_queue_lifetime задаёт срок, в течение которого обычное сообщение может оставаться в очереди до возврата отправителю; bounce_queue_lifetime задаёт срок для сообщений-уведомлений о недоставке. Это не настройка «очистить очередь через N дней»: слишком короткое значение ускорит возврат и может привести к потере нормальных попыток доставки при длительном сбое у адресата. Не меняйте срок на пять дней или сутки только потому, что такое число прозвучало в чужой статье. Сверьте текущую политику, документацию установленной версии Postfix и требования бизнеса.

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

Мониторинг должен показывать не только число писем, но и скорость его изменения, возраст старейшей записи, долю deferred, свободное место и inode. Порог вроде «1000 писем» нельзя переносить между организациями: тысяча сообщений может быть штатной для одного сервера и тревожной для другого. Подберите предупреждения относительно обычной нагрузки и объёма диска, затем проверьте, что уведомление действительно приходит ответственному сотруднику. Zabbix, Prometheus и другие системы могут собирать такие показатели, если для конкретной установки настроен подходящий сборщик.

Полезно регулярно проверять, что журналы сохраняются, время на сервере синхронизировано, а резервная копия конфигурации доступна. Отдельно документируйте, кто вправе удалять сообщения и как подтверждается перечень ID. Это простые меры, но именно они отделяют аварийную работу от угадывания. И пусть никто не называет postsuper -d ALL профилактикой: это просто удаление всей почты, которая ещё не доставлена.

• Сверьте `maximal_queue_lifetime` и `bounce_queue_lifetime` с политикой компании.
• Следите за динамикой очереди, возрастом писем и диском.
• Проверьте процедуру отката до изменения конфигурации.

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