Postfix queue на VDS: deferred, mailq и безопасная разборка очереди

Очередь Postfix — один из тех механизмов, о котором вспоминают в самый неудобный момент: пользователь не получил письмо восстановления пароля, рассылка из CRM зависла, мониторинг молчит, а команда mailq показывает десятки или тысячи сообщений. На VDS это особенно заметно: почтовый сервер обычно обслуживает конкретный проект, поэтому любая проблема с доставкой быстро превращается в инцидент.

Хорошая новость: Postfix queue устроена предсказуемо. Если понимать, что означают состояния active, deferred, hold, как связать ID письма с логами и когда применять postqueue или postsuper, очередь можно разобрать без паники и без удаления нужной почты.

Главное правило: сначала выясняем причину задержки, потом выполняем действие с очередью. Массовая очистка без диагностики часто скрывает проблему, но не устраняет её.

Что такое очередь Postfix и почему письма попадают в deferred

Postfix принимает письмо, проверяет правила, выбирает транспорт доставки и кладёт сообщение в одну из внутренних очередей. Для администратора чаще всего важны несколько состояний.

• incoming — письмо принято локально, но ещё не обработано менеджером очереди.
• active — Postfix прямо сейчас пытается доставить сообщение или готовит его к доставке.
• deferred — доставка временно не удалась, письмо отложено для повторной попытки.
• hold — письмо принудительно удерживается администратором или правилом.
• corrupt — повреждённое сообщение, редкий случай, обычно требует отдельного разбора.

Состояние deferred не всегда означает аварию. SMTP изначально рассчитан на повторные попытки. Например, удалённый сервер может ответить временной ошибкой 451, включить greylisting, ограничить частоту приёма или быть недоступным из-за сетевой проблемы. Postfix сохранит письмо и попробует доставить его позже.

Проблема начинается, когда очередь растёт быстрее, чем разбирается, либо одни и те же ошибки повторяются часами. Тогда нужно смотреть не только на количество сообщений, но и на причину: DNS, IPv6, обратная PTR-запись, блокировка порта 25, некорректный HELO, TLS-сбой, репутация IP, ошибка авторизации у relayhost, нехватка диска или неверный маршрут доставки.

Быстрая диагностика: сколько писем в очереди и где они находятся

Начинаем с простого: проверяем статус Postfix и общий вид очереди. Команды одинаковы для большинства Linux-дистрибутивов.

systemctl status postfix --no-pager
mailq
postqueue -p

mailq и postqueue -p в Postfix обычно дают один и тот же человекочитаемый вывод. В начале каждой записи будет ID сообщения, затем размер, время постановки в очередь, отправитель и получатели. Если после ID стоит звёздочка, сообщение находится в active. Если в конце блока показана причина в скобках, это ключ к расследованию.

3F2A812345    1542 Mon Jan 15 10:21:44  sender@example.com
(connect to mx.example.net[203.0.113.10]:25: Connection timed out)
                                         user@example.net

В этом примере Postfix не смог подключиться к MX-серверу получателя по SMTP. Это может быть проблема на стороне получателя, маршрутизации, firewall, IPv6, исходящего порта 25 или DNS. Удалять письмо пока рано: сначала нужно понять, повторяется ли ошибка для всех доменов или только для одного направления.

Подсчёт сообщений в очереди

Для грубой оценки можно посмотреть итоговую строку вывода очереди:

postqueue -p | tail -n 1

Postfix сам выводит строку вида -- 12 Kbytes in 5 Requests.. Если очередь большая, удобнее использовать qshape: он показывает распределение по возрасту и доменам, то есть помогает понять, где именно накапливается deferred.

qshape deferred
qshape active

Если qshape отсутствует, установите пакет с утилитами Postfix. Не добавляйте лишние компоненты наугад: обычно достаточно штатных пакетов дистрибутива.

Debian/Ubuntu:

apt update
apt install postfix

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux:

dnf install postfix postfix-perl

После установки повторите qshape deferred. Если в таблице один домен занимает почти всю очередь, расследуйте доставку именно к нему. Если доменов много и ошибки похожи, причина вероятнее на стороне вашего VDS или конфигурации Postfix.

Как читать mailq: ID, отправитель, получатель и текст ошибки

Каждое письмо в очереди имеет идентификатор, например 3F2A812345. Этот ID связывает вывод mailq, содержимое письма и записи в логах. В работе с очередью ID важнее, чем адрес получателя: одно письмо может иметь несколько получателей, а повторные попытки доставки будут фиксироваться в логах под тем же ID.

Пример типовой записи:

7B9D456789    4096 Tue Jan 16 12:05:11  webapp@example.com
(host mx.receiver.example[198.51.100.25] said: 450 4.2.0 Mailbox temporarily unavailable)
                                         client@receiver.example

Код 450 начинается с 4, значит ошибка временная. Postfix будет повторять доставку до истечения срока жизни письма в очереди. Этот срок задаёт параметр maximal_queue_lifetime, а для bounce-сообщений — bounce_queue_lifetime. По умолчанию это обычно несколько дней, но конкретные значения лучше проверить.

postconf maximal_queue_lifetime
postconf bounce_queue_lifetime
postconf queue_run_delay
postconf minimal_backoff_time
postconf maximal_backoff_time

Если ошибка начинается с 5, например 550 или 554, удалённый сервер считает её постоянной. В нормальной ситуации Postfix сформирует bounce отправителю. Но встречаются случаи, когда постоянная ошибка повторяется из-за некорректного маршрута, политики relayhost или локальных правил. Поэтому даже 5xx стоит смотреть в контексте логов.

Логи Postfix: где искать причину deferred

Вывод mailq показывает последнюю заметную ошибку, но полная история находится в логах. На современных системах удобнее начинать с journalctl, а затем смотреть файловый лог, если он включён.

Debian/Ubuntu:

journalctl -u postfix -n 200 --no-pager
grep postfix /var/log/mail.log | tail -n 100

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux:

journalctl -u postfix -n 200 --no-pager
grep postfix /var/log/maillog | tail -n 100

Если знаете ID сообщения, ищите именно его. Так вы увидите все попытки доставки, выбранный транспорт, ответ удалённого сервера и возможные внутренние ошибки.

grep 3F2A812345 /var/log/mail.log
grep 3F2A812345 /var/log/maillog
journalctl -u postfix --no-pager | grep 3F2A812345

Типовая строка успешной доставки выглядит так:

postfix/smtp[12345]: 3F2A812345: to=<user@example.net>, relay=mx.example.net[203.0.113.10]:25, delay=2.1, delays=0.1/0.02/0.8/1.18, dsn=2.0.0, status=sent

А вот пример временной задержки:

postfix/smtp[12345]: 3F2A812345: to=<user@example.net>, relay=none, delay=31, delays=0.1/0.01/30/0, dsn=4.4.1, status=deferred (connect to mx.example.net[203.0.113.10]:25: Connection timed out)

Поле status=deferred говорит о результате попытки, dsn=4.4.1 уточняет класс проблемы, а текст в скобках обычно даёт практическую подсказку. Например, Connection timed out ведёт к сетевой диагностике, Name service error — к DNS, Relay access denied — к настройкам релея и доменов, SASL authentication failed — к учётным данным SMTP-сервиса.

Самые частые причины роста deferred на VDS

На практике причины делятся на внешние и внутренние. Внешние — это временные отказы принимающих серверов, greylisting, проблемы у конкретного домена получателя. Внутренние — всё, что связано с вашим VDS, настройками Postfix, DNS и сетевыми ограничениями.

DNS и MX не резолвятся

Если в логах есть Name service error, Host not found, Temporary failure in name resolution, сначала проверяйте резолвер на сервере.

resolvectl status
getent hosts example.net
dig MX example.net

Если dig не установлен, поставьте пакет DNS-утилит.

Debian/Ubuntu:

apt install dnsutils

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux:

dnf install bind-utils

Недоступен порт 25 наружу

Если все исходящие SMTP-подключения завершаются таймаутом, проверьте доступность порта 25. На VDS иногда срабатывают сетевые фильтры, локальный firewall или политика провайдера. Диагностику лучше делать аккуратно: один тест к известному MX достаточно покажет, есть ли TCP-соединение.

nc -vz mx.example.net 25
openssl s_client -starttls smtp -connect mx.example.net:25 -servername mx.example.net

Если nc отсутствует, установите его.

Debian/Ubuntu:

apt install netcat-openbsd openssl

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux:

dnf install nmap-ncat openssl

Проблемы с PTR, HELO, SPF или репутацией

Удалённые серверы могут временно откладывать почту, если IP-адрес VDS не имеет корректной обратной PTR-записи, имя в myhostname не похоже на FQDN, домен не имеет SPF или сервер отправляет слишком много писем за короткое время. В логах это часто выглядит как 450, 451, 421 или текстовые сообщения о policy, rate limit, reputation, reverse DNS.

postconf myhostname
postconf myorigin
postconf mydestination
hostname -f
dig A mail.example.com
dig PTR 203.0.113.10

PTR настраивается не в зоне домена, а у владельца IP-адреса. Поэтому если команда dig PTR возвращает пусто или неподходящее имя, исправление обычно делается через панель управления VDS или обращение к провайдеру. А если домен для почтового узла ещё не выбран, заранее проверьте имя и стоимость через регистрацию доменов, чтобы потом не переделывать SPF, DKIM и PTR под новый хостнейм.

Ошибки relayhost и SMTP AUTH

Если Postfix отправляет почту через внешний SMTP-шлюз, проверьте relayhost, SASL-настройки и TLS-политику. Частый сценарий: пароль изменили, аккаунт ограничили, порт или имя сервера поменяли, а очередь продолжает копить письма с ошибкой авторизации.

postconf relayhost
postconf smtp_sasl_auth_enable
postconf smtp_sasl_password_maps
postconf smtp_tls_security_level

После правки файлов с паролями не забывайте пересобрать map-файл и перезагрузить Postfix.

postmap /etc/postfix/sasl_passwd
systemctl reload postfix

Нехватка диска, inode или прав на каталог очереди

Почтовая очередь живёт на диске. Если раздел заполнен, Postfix не сможет нормально принимать, перемещать и доставлять сообщения. Проверяйте не только гигабайты, но и inode.

df -h
df -i
postconf queue_directory
ls -ld /var/spool/postfix

Если диск заполнен логами, временными файлами или дампами, сначала освобождайте место безопасными методами. Удаление файлов из /var/spool/postfix вручную — плохая идея: для очереди есть штатные инструменты.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Как посмотреть содержимое конкретного письма

Иногда нужно понять, кто отправил письмо и что это за сообщение: уведомление сайта, системный bounce, письмо от скомпрометированного скрипта или массовая рассылка. Для этого используйте postcat.

postcat -vq 3F2A812345

Команда покажет заголовки, envelope-адреса и тело сообщения. Будьте внимательны: в письмах могут быть персональные данные, токены восстановления, внутренние адреса и служебная информация. Не копируйте полный вывод в публичные чаты и тикеты без маскирования.

Если в очереди много писем от одного локального пользователя, сайта или скрипта, проверьте источники отправки. Для веб-проектов на VDS полезно сопоставить время постановки писем в очередь с логами PHP-FPM, веб-сервера, cron и приложения. Часто рост очереди связан не с Postfix, а с тем, что приложение начало генерировать слишком много уведомлений или ретраев.

Повторная доставка: когда использовать postqueue -f

После исправления причины можно попросить Postfix немедленно пройтись по очереди. Для этого используется postqueue -f. Команда не удаляет письма, а инициирует повторную попытку доставки.

postqueue -f

Не запускайте её в цикле каждую секунду. Если удалённый сервер ограничивает частоту, агрессивные повторы могут ухудшить ситуацию. Лучше исправить DNS, PTR, firewall или авторизацию, выполнить один flush и наблюдать за логами.

journalctl -u postfix -f

Если в очереди тысячи писем, после postqueue -f нагрузка на CPU, диск и сеть может заметно вырасти. На небольшом VDS следите за load average, I/O wait, свободной памятью и количеством процессов Postfix.

uptime
free -m
iostat -xz 1
postqueue -p | tail -n 1

Если iostat не установлен, его можно добавить из пакета sysstat.

Debian/Ubuntu:

apt install sysstat

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux:

dnf install sysstat

Безопасная очистка очереди: не удаляйте всё без фильтра

Удаление из очереди выполняется командой postsuper. Она мощная и поэтому опасная. Команда postsuper -d ALL удалит всю очередь, включая письма, которые могли быть доставлены после исправления проблемы. В боевой среде это крайняя мера, а не стандартный способ лечения.

Удалить одно письмо по ID:

postsuper -d 3F2A812345

Удалить только deferred-очередь:

postsuper -d ALL deferred

Вернуть письма из hold в обычную очередь:

postsuper -H ALL

Перепоставить письма в очередь после изменения настроек маршрутизации или транспорта:

postsuper -r ALL

Перед массовым удалением сделайте хотя бы минимальный аудит: сколько писем, какие отправители, какие домены получателей, одинаковая ли причина ошибки. Если очередь забита недоставляемыми bounce-сообщениями или письмами от взломанного сайта, удаление может быть оправданным. Если там клиентские заказы, регистрации и чеки, лучше исправить доставку и выполнить повторный flush.

Практический runbook: deferred растёт прямо сейчас

Ниже — последовательность, которую можно использовать во время инцидента. Она не привязана к конкретному дистрибутиву и подходит для большинства VDS с Postfix.

1. Проверьте, запущен ли Postfix: systemctl status postfix --no-pager.
2. Оцените размер очереди: postqueue -p | tail -n 1.
3. Посмотрите несколько сообщений через mailq и выпишите ID с типичными ошибками.
4. Найдите ID в логах и определите класс причины: DNS, сеть, TLS, relayhost, политика получателя, локальная ошибка.
5. Проверьте диск и inode: df -h, df -i.
6. Если проблема исправлена, выполните postqueue -f и наблюдайте за логами.
7. Если письма явно мусорные или недоставляемые, удаляйте точечно через postsuper -d ID или осознанно очищайте deferred.

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

Настройки Postfix, которые влияют на поведение очереди

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

postconf -n > /root/postfix-current.conf
postconf maximal_queue_lifetime
postconf bounce_queue_lifetime
postconf queue_run_delay
postconf minimal_backoff_time
postconf maximal_backoff_time
postconf default_destination_rate_delay
postconf smtp_destination_concurrency_limit

maximal_queue_lifetime определяет, как долго обычное письмо может ждать доставки. queue_run_delay задаёт периодический обход очереди. minimal_backoff_time и maximal_backoff_time управляют паузами между повторными попытками. Параметры concurrency и rate delay помогают не отправлять слишком агрессивно в один домен или через один транспорт.

Не стоит бездумно уменьшать срок жизни очереди до нескольких минут: временные SMTP-ошибки нормальны, и короткий lifetime приведёт к преждевременным bounce. Также не стоит резко увеличивать параллелизм, если проблема в репутации или rate limit: получатели могут начать отклонять ещё больше писем.

Мониторинг очереди Postfix на VDS

Чтобы не узнавать о проблеме от пользователей, добавьте простую проверку очереди в мониторинг. Минимальный вариант — периодически выполнять postqueue -p и алертить по количеству сообщений. Более полезный вариант — отдельно отслеживать возраст старейших писем и размер deferred.

Для ручной проверки подойдёт такая команда:

postqueue -p | tail -n 1

Если используете Prometheus, Zabbix, Netdata или другой агент, лучше отдавать метрики через готовый exporter или textfile-collector. Но даже простая cron-проверка с уведомлением лучше, чем отсутствие контроля. Порог зависит от проекта: для небольшого сайта уже 20–50 писем в deferred могут быть тревожным сигналом, а для активного сервиса важнее не абсолютное число, а рост за последние 10–15 минут.

Отдельно следите за bounce-штормами. Если сервер массово получает недоставляемые письма и пытается отправлять отчёты о недоставке на поддельные адреса, очередь может расти очень быстро. В этом случае разбирайте источники входящей почты, ограничения на приём, антиспам-политику и правила для backscatter.

Чего лучше не делать

Есть несколько действий, которые часто усугубляют инцидент с Linux mail на VDS.

• Не удаляйте файлы из /var/spool/postfix вручную. Используйте postsuper.
• Не запускайте бесконечный цикл с postqueue -f. Это создаёт лишнюю нагрузку и может раздражать принимающие серверы.
• Не меняйте одновременно DNS, relayhost, TLS и лимиты очереди. Потом будет сложно понять, что помогло или сломало доставку.
• Не публикуйте полный вывод postcat без маскирования адресов, токенов и содержимого писем.
• Не игнорируйте PTR и HELO. Для исходящей почты с VDS это базовая гигиена доставляемости.

Короткий чек-лист восстановления

Если нужно действовать быстро, держите под рукой компактный набор команд. Он помогает пройти путь от симптома к решению: увидеть очередь, найти причину, исправить проблему и повторить доставку.

systemctl status postfix --no-pager
postqueue -p | tail -n 1
mailq
postconf -n
df -h
df -i
journalctl -u postfix -n 200 --no-pager
postqueue -f

Для Debian/Ubuntu при поиске по файловому логу:

grep postfix /var/log/mail.log | tail -n 100

Для RHEL-based систем:

grep postfix /var/log/maillog | tail -n 100

А если нужно удалить конкретное письмо после проверки:

postcat -vq 3F2A812345
postsuper -d 3F2A812345

Итоги

deferred в Postfix — это не приговор, а механизм повторной доставки. Очередь становится проблемой, когда её рост указывает на неисправность DNS, сети, TLS, relayhost, репутации IP или приложения, которое генерирует слишком много писем. Поэтому правильный порядок действий такой: посмотреть mailq, связать ID письма с логами, определить повторяющуюся причину, исправить её, затем выполнить postqueue -f и только после этого думать об очистке.

На VDS почтовая очередь хорошо поддаётся контролю, если есть базовый мониторинг, корректные DNS-записи, понятная схема отправки и аккуратная работа с postsuper. Не бойтесь очереди Postfix: она даёт достаточно информации, чтобы разложить инцидент по шагам и восстановить доставку без лишних потерь.