Диагностика отложенной доставки в Mailcow: локальный firewall или отказ удалённого MX?
Короткий практический алгоритм, который помогает отличить локальную проблему SMTP-соединения от выборочного отказа со стороны удалённого почтового сервера.
Проверено на: Mailcow · Postfix · Linux
Контекст
Рост deferred queue часто сразу приводит к гипотезе, что исходящий TCP/25 заблокирован локально. Это легко проверить, поэтому такую версию стоит подтвердить или исключить до любых изменений firewall или NAT.
Полезная диагностика сравнивает исправные пути доставки с проблемным MX и добавляет пакетный захват как независимое подтверждение.
Начните с очереди
Определите, затрагивает ли проблема все направления или только отдельные домены и MX-хосты.
Фиксируйте фактическую причину defer в Postfix вместо того, чтобы считать все deferred messages одной и той же проблемой.
Если сбой возникает только у части получателей, это уже аргумент против полного локального блокирования TCP/25.
Сравните с заведомо рабочими направлениями
С почтового сервера проверьте TCP/25 до нескольких независимых крупных почтовых провайдеров и отдельно до проблемного MX.
Если известные внешние MX доступны, а один конкретный адрес стабильно не отвечает или сбрасывает соединение, область поиска сужается. Это уже не «исходящий SMTP полностью сломан», а проблема конкретного маршрута или удалённого узла.
Не меняйте firewall только потому, что один remote MX недоступен.
Снимите пакеты
Короткий packet capture на внешнем интерфейсе помогает понять, где именно разрывается TCP-session.
Ищите:
- SYN, уходящий с локального сервера;
- SYN/ACK или отсутствие ответа;
- TCP reset и адрес его источника;
- повторные передачи;
- промежуточные ICMP-ответы.
Reset, отправленный удалённым endpoint, принципиально отличается от локального reject или silent drop на пути.
Проверьте репутацию и политику удалённой стороны
Если только отдельные MX reject или reset соединения, а обычная SMTP connectivity работает, проверяйте:
- peer-side policy;
- репутацию исходного IP;
- blocklist;
- ограничения или фильтрацию на стороне удалённого сервера.
Локальный MTA при этом может работать корректно, даже если доставка к конкретному получателю остаётся deferred.
Проверка вывода
Обоснованный вывод должен опираться на совокупность данных:
- причина defer в очереди Postfix;
- успешные TCP/25-подключения к независимым MX;
- повторяемый отказ до проблемного MX;
- packet capture, показывающий, где соединение теряется или отклоняется;
- отсутствие соответствующего reject в локальном firewall.
Такой подход позволяет не менять production firewall для устранения проблемы, которая фактически находится на удалённой стороне.