Postfix: переполнена очередь — причины и решение

MAATRIX

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

Как устроена очередь Postfix

Прежде чем чистить, поймите структуру. Очередь — это не одна папка, а несколько, и письмо в каждой означает разное. incoming — только что принятые письма. active — те, что Postfix прямо сейчас пытается доставить. deferred — письма, доставка которых временно не удалась, они ждут повторной попытки. hold — придержанные вручную. corrupt — битые.

Практически всегда «переполнение» — это разбухший deferred. Туда падает всё, что не удалось отправить с первого раза: недоступные получатели, отвергнутые спам-фильтром письма, битые адреса. Postfix повторяет попытки по нарастающему интервалу до maximal_queue_lifetime (по умолчанию 5 дней), и всё это время письма лежат на диске. Понимание, что перегружен именно deferred, направляет диагностику: надо не «ускорять сервер», а разобраться, почему письма не уходят.

Смотрим, чем забита очередь

Начните с общей картины: сколько писем и в каком состоянии.

mailq | tail -1              # итоговая строка с количеством
postqueue -p | wc -l
qshape deferred | head        # распределение по доменам-получателям
qshape -s deferred | head     # по доменам-отправителям

Утилита qshape бесценна: она показывает, на какие домены копятся письма и как давно. Если 90% очереди — это письма на один несуществующий домен или от одного вашего аккаунта, диагноз почти готов. Загляните и в содержимое подозрительного письма:

postcat -q ID_ПИСЬМА

Чаще всего вы увидите одну из трёх картин: массовая рассылка с одного скомпрометированного аккаунта (взлом), тысячи писем на битые адреса (утёкшая база или ошибка приложения), либо легитимная почта, застрявшая из-за проблем с доставкой (закрытый порт, DNS, репутация IP). Не переходите к удалению, пока не определили, какая из трёх картин перед вами — стратегия чистки в каждом случае разная, и слепое удаление одинаково опасно во всех трёх. От верного диагноза на этом шаге зависит, вернётся очередь через десять минут или нет.

Причина первая: сервер взломан и рассылает спам

Если в очереди десятки тысяч однотипных писем на случайные внешние адреса, а вы такого не отправляли — почти наверняка кто-то использует ваш сервер для спама. Это самый опасный сценарий: помимо забитой очереди вы получаете попадание IP в чёрные списки.

Найдите источник — через какой аккаунт или скрипт идёт рассылка:

grep "sasl_username" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -rn
postqueue -p | grep -A1 "^[A-F0-9]" | grep -oE '[a-z0-9._-]+@[a-z0-9.-]+' | sort | uniq -c | sort -rn | head

Если виден скомпрометированный SASL-аккаунт — немедленно смените ему пароль. Если рассылка идёт от веб-приложения (PHP mail()), ищите уязвимый скрипт по X-PHP-Originating-Script в заголовках писем очереди. После устранения источника чистите спам из очереди (см. ниже) и проверяйте IP в спам-листах. Пока источник не закрыт, чистить очередь бесполезно — она наполнится снова за минуты.

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

Если очередь растёт из легитимных писем, значит, доставка сломана. Загляните в причину отсрочки — Postfix пишет её прямо в очереди:

postqueue -p | grep -i -E 'connect|timed out|refused|denied|not found' | head

Типичные виновники и их лечение: Connection timed out на порт 25 — провайдер блокирует исходящий 25, нужен релей или разблокировка; Host not found — сломан DNS-резолвинг на сервере; Relay access denied или 550 от получателей — проблема с репутацией IP, отсутствием PTR и SPF. Разберитесь с корневой причиной доставки, и после postqueue -f очередь начнёт таять сама. Форсировать доставку всей очереди:

postqueue -f

Не форсируйте очередь бесконечно, если письма всё равно возвращаются в deferred — вы только нагружаете сервер и множите записи в логе. Каждая форсированная попытка на сломанной доставке — это лишняя нагрузка на процессор и диск без результата. Сначала добейтесь, чтобы хотя бы одно тестовое письмо ушло со status=sent, и только потом форсируйте всю очередь разом. Так вы отправите накопившееся за один проход, а не будете гонять сервер вхолостую.

Безопасная чистка очереди

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

# удалить письма конкретного отправителя (спамера)
mailq | awk '/spammer@domain/ {print 
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Арендовать сервер для почты
Причина первая: сервер взломан и рассылает спам
Если в очереди десятки тысяч однотипных писем на случайные внешние адреса, а вы такого не отправляли — почти наверняка кто-то использует ваш сервер для спама. Это самый опасный сценарий: помимо забитой очереди вы получаете попадание IP в чёрные списки.
Найдите источник — через какой аккаунт или скрипт идёт рассылка:
grep "sasl_username" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -rn
postqueue -p | grep -A1 "^[A-F0-9]" | grep -oE '[a-z0-9._-]+@[a-z0-9.-]+' | sort | uniq -c | sort -rn | head
Если виден скомпрометированный SASL-аккаунт — немедленно смените ему пароль. Если рассылка идёт от веб-приложения (PHP mail()), ищите уязвимый скрипт по X-PHP-Originating-Script в заголовках писем очереди. После устранения источника чистите спам из очереди (см. ниже) и проверяйте IP в спам-листах. Пока источник не закрыт, чистить очередь бесполезно — она наполнится снова за минуты.
Причина вторая: письма не уходят из-за доставки
Если очередь растёт из легитимных писем, значит, доставка сломана. Загляните в причину отсрочки — Postfix пишет её прямо в очереди:
postqueue -p | grep -i -E 'connect|timed out|refused|denied|not found' | head
Типичные виновники и их лечение: Connection timed out на порт 25 — провайдер блокирует исходящий 25, нужен релей или разблокировка; Host not found — сломан DNS-резолвинг на сервере; Relay access denied или 550 от получателей — проблема с репутацией IP, отсутствием PTR и SPF. Разберитесь с корневой причиной доставки, и после postqueue -f очередь начнёт таять сама. Форсировать доставку всей очереди:
postqueue -f
Не форсируйте очередь бесконечно, если письма всё равно возвращаются в deferred — вы только нагружаете сервер и множите записи в логе. Каждая форсированная попытка на сломанной доставке — это лишняя нагрузка на процессор и диск без результата. Сначала добейтесь, чтобы хотя бы одно тестовое письмо ушло со status=sent, и только потом форсируйте всю очередь разом. Так вы отправите накопившееся за один проход, а не будете гонять сервер вхолостую.
Безопасная чистка очереди
Разобравшись, что есть что, чистим прицельно. Полное удаление всего — крайняя мера, потому что вместе со спамом улетят и легитимные письма. Правильнее удалять по признаку.
# удалить письма конкретного отправителя (спамера)
mailq | awk '/spammer@domain/ {print $1}' | tr -d '*!' | postsuper -d -
# удалить все отложенные (осторожно, только если уверены)
postsuper -d ALL deferred
# удалить одно письмо по ID
postsuper -d ID_ПИСЬМА
Есть готовые скрипты для выборочного удаления по любому шаблону — отправителю, получателю, теме. Перед postsuper -d ALL трижды подумайте: это необратимо. Если сомневаетесь, лучше сначала переведите подозрительные письма в hold (postsuper -h), разберите вручную, а потом решайте. Легитимные застрявшие письма после починки доставки уйдут сами — их удалять не нужно.
Ускоряем разбор большой очереди
Когда в очереди сотни тысяч писем, сам Postfix начинает тормозить: обход active идёт медленно. Помогает временная настройка параллелизма и лимитов в main.cf.
default_destination_concurrency_limit = 20
default_process_limit = 100
maximal_queue_lifetime = 2d
bounce_queue_lifetime = 1d
Уменьшение maximal_queue_lifetime заставит Postfix быстрее сдаваться на безнадёжных письмах и возвращать их отправителю, а не держать пять дней. После разбора завала верните значения к разумным. Если очередь распухла до миллионов файлов, файловая система с их inode тоже страдает — иногда быстрее и безопаснее остановить Postfix, разобрать каталоги через find по времени модификации и запустить заново, чем ждать штатной обработки.
Профилактика: чтобы не повторялось
Разовая чистка не поможет, если причина осталась. Настройте защиту, чтобы очередь не переполнялась снова. Ограничьте частоту отправки на один аккаунт, чтобы взлом не превратился в лавину. Мониторьте размер очереди и место на диске — простой алерт при превышении порога предупредит вас раньше, чем сервер встанет.
# размер очереди одной строкой — в мониторинг
mailq | grep -c '^[A-F0-9]'
# место на диске под очередью
du -sh /var/spool/postfix/
Держите SASL-аккаунты с сильными паролями, обновляйте веб-приложения, закрывайте mail() в PHP там, где он не нужен. И следите за репутацией IP: если письма стабильно уходят в deferred из-за отбоя получателями, проблема не в объёме, а в чистоте адреса и корректности PTR/SPF/DKIM. На сервере с чистым IP и выданным провайдером PTR очередь ведёт себя спокойно.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Арендовать сервер для почты
}' | tr -d '*!' | postsuper -d -
# удалить все отложенные (осторожно, только если уверены)
postsuper -d ALL deferred
# удалить одно письмо по ID
postsuper -d ID_ПИСЬМА

Есть готовые скрипты для выборочного удаления по любому шаблону — отправителю, получателю, теме. Перед postsuper -d ALL трижды подумайте: это необратимо. Если сомневаетесь, лучше сначала переведите подозрительные письма в hold (postsuper -h), разберите вручную, а потом решайте. Легитимные застрявшие письма после починки доставки уйдут сами — их удалять не нужно.

Ускоряем разбор большой очереди

Когда в очереди сотни тысяч писем, сам Postfix начинает тормозить: обход active идёт медленно. Помогает временная настройка параллелизма и лимитов в main.cf.

default_destination_concurrency_limit = 20
default_process_limit = 100
maximal_queue_lifetime = 2d
bounce_queue_lifetime = 1d

Уменьшение maximal_queue_lifetime заставит Postfix быстрее сдаваться на безнадёжных письмах и возвращать их отправителю, а не держать пять дней. После разбора завала верните значения к разумным. Если очередь распухла до миллионов файлов, файловая система с их inode тоже страдает — иногда быстрее и безопаснее остановить Postfix, разобрать каталоги через find по времени модификации и запустить заново, чем ждать штатной обработки.

Профилактика: чтобы не повторялось

Разовая чистка не поможет, если причина осталась. Настройте защиту, чтобы очередь не переполнялась снова. Ограничьте частоту отправки на один аккаунт, чтобы взлом не превратился в лавину. Мониторьте размер очереди и место на диске — простой алерт при превышении порога предупредит вас раньше, чем сервер встанет.

# размер очереди одной строкой — в мониторинг
mailq | grep -c '^[A-F0-9]'
# место на диске под очередью
du -sh /var/spool/postfix/

Держите SASL-аккаунты с сильными паролями, обновляйте веб-приложения, закрывайте mail() в PHP там, где он не нужен. И следите за репутацией IP: если письма стабильно уходят в deferred из-за отбоя получателями, проблема не в объёме, а в чистоте адреса и корректности PTR/SPF/DKIM. На сервере с чистым IP и выданным провайдером PTR очередь ведёт себя спокойно.

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