#Симптомы и область применимости
При задержке писем не нужно удалять очередь или включать слишком подробные журналы с личными данными. На Postfix можно безопасно проверить размер очереди, причины ошибок и маршрут отдельных писем только на чтение, сохранив доказательства для дальнейшей диагностики.
#Причины и диагностические признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Очередь растёт из-за временных отказовУдалённые серверы или DNS задерживают сообщения, Postfix ожидает повтора. | В списке много deferred, но служба запущена | Читайте причины по одному ID. |
| Письмо отправлено, но получатель жалуетсяЭто передача следующему SMTP, не подтверждение попадания во входящие. | В журнале status=sent, а у получателя письма нет | Проверьте следующий сервер и получателя. |
| Не тот журнал или периодСистема пишет в /var/log/mail.log, в контейнерный журнал или в панель. | В journalctl почтовых строк нет | Найдите фактический путь журнала. |
#Пошаговая диагностика и исправление
- 1. Определите период и границы доступаЗапишите время тестовой отправки и свой тестовый адрес. Для общего сервера журнал может содержать персональные адреса других клиентов: убедитесь, что у вас есть административное разрешение и не копируйте весь файл за пределы сервера.
- 2. Снимите общую картину очередиВ терминале Linux с Postfix прочитайте список очереди. Команда postqueue -p не удаляет и не переотправляет письма. Укажите, сколько сообщений в очереди и есть ли повторяющийся текст ошибки; при большой очереди не сохраняйте личные данные в публичный отчёт.Linux · Терминал (Bash)КомандаНужен sudoТолько чтение Postfix. Не используйте postsuper -d ALL или postqueue -f без отдельного решения.
sudo postqueue -p
- 3. Найдите нужное письмо по queue IDВыберите ID тестового письма из почтового журнала. В postqueue -p найдите его состояние и текст задержки; для просмотра заголовков/метаданных при разрешении используйте postcat -q ID. Не выводите тело чужого сообщения.Linux · Терминал (Bash)КомандаНужен sudoPostfix: замените QUEUE_ID; вывод может содержать текст письма и личные данные, запускайте только для своего теста.
sudo postcat -q QUEUE_ID
- 4. Прочитайте журнал службы только за короткое времяПри systemd запустите journalctl -u postfix за выбранный интервал. Если журнал пуст, найдите путь в /var/log/mail.log или панели. Не включайте глобальную отладку на весь день: это увеличивает нагрузку и объём секретных метаданных.Linux · Терминал (Bash)КомандаНужен sudoТолько чтение. Имя службы и место хранения журналов зависит от дистрибутива.
sudo journalctl -u postfix --since "30 minutes ago" --no-pager
- 5. Различайте статус отправкиДля одного ID сопоставьте from, to, relay, status, dsn. «deferred» — временная задержка; «bounced» — окончательный возврат; «sent» — успешная передача следующему участнику. Не делайте вывод о доставке в «Входящие» только по sent.
- 6. Проверьте отсутствие бесконечных повторов приложенияСопоставьте несколько ID с одинаковой темой теста: если приложение создаёт новое письмо каждую минуту, очередь может расти даже при штатных повторах Postfix. Исключите повторную постановку в очередь на стороне сайта, сохранив недоставленные сообщения.
- 7. Защитите содержимое диагностикиЕсли нужно передать журнал специалисту, оставьте время, код ошибки и техническую причину, удалите адреса клиентов, локальные секреты и полные идентификаторы авторизации. Обратите внимание, что даже заголовки письма могут содержать персональные сведения.
- 8. После исправления подтвердите естественный выход письмаУстраните установленную причину (DNS, соединение, авторизация шлюза, квота), затем повторно посмотрите выбранный ID через postqueue -p и журнал. Postfix выполняет штатные повторы сам. Принудительное удаление или массовая переотправка не нужны для подтверждения исправления.
#Как убедиться, что проблема устранена
Очередь диагностирована без потери писем, по одному тестовому ID виден полный маршрут и код исхода, задержка устраняется штатной доставкой; журнал и содержимое чужих писем не раскрыты.
#Если проблема осталась
При постоянном росте очереди сохраните обезличенную сводку по категориям отказов и разберите наиболее массовый тип причины. Если есть подозрение на злоупотребление SMTP, ограничьте скомпрометированный источник до любых массовых действий с очередью.