Postfix, VPN и smarthost: очередь — не межсетевой экран

Держать почту в очереди до поднятия VPN — это задача планирования, и обычное решение — остановить Postfix, заменить main.cf и запустить его снова. Это работает, и это неправильная форма, потому что смешивает два требования: когда пытаться доставить и какой сетевой путь может это нести. Второе — решение межсетевого экрана, и никакая директива Postfix не может его принять. Как только их разделить, у каждого появится небольшой и проверяемый ответ.

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

Два требования, которые люди сливают в одно

Релей сообщает Postfix, куда передавать почту; relayhost = [smtp.corp.example]:587 задаёт хост и порт, а квадратные скобки подавляют выбор по MX для этого следующего перехода. Путь сообщает ядру, куда пакетам разрешено идти. Правильный relayhost без ограничения пути всё равно позволяет Postfix выходить в интернет напрямую, когда таблица маршрутизации это разрешает, а правильный межсетевой экран с неверным relayhost отправляет почту не туда. Ни одно не вытекает из другого.

Карты транспорта, переопределения для отдельных отправителей и резервные релеи заслуживают такого же прочтения. Стабильный relayhost не доказывает, что каждый настроенный маршрут доставки его использует, а резервный путь в обход релея — та же ошибка в лучшей маскировке.

Что на самом деле делает defer_transports

defer_transports удерживает сообщения для указанных транспортов, поэтому попытка доставки не делается, пока их не коснётся один проход очереди. Это управление планированием, и очистка очереди его перекрывает; такова задумка, а не дефект. Используйте настоящие имена транспортов из master.cf, потому что собственный транспорт или отдельно названный транспорт релея не покрывается только потому, что его программа тоже говорит на SMTP. Обычная повторная попытка — другой механизм: при пути fail-closed попытки доставки просто не удаются и остаются в очереди, без всякой директивы отсрочки.

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

Обеспечьте путь на сетевом уровне

Ограничение относится к границе локального вывода или внутрь изолированного сетевого пространства имён. Оно должно охватывать реальные адреса релея, транспорт и порт, включая IPv6, если он включён, потому что правило, блокирующее TCP 25, ничего не делает для релея на 587 или 465. Держите loopback и локальные пути отправки отдельно, чтобы сама очередь продолжала работать. Политика должна оставаться закрытой, когда маршрут туннеля исчезает или снова появляется под другим именем интерфейса.

Событие поднятия интерфейса не доказывает, что релей доступен через него. Поэтому перехватчик, который проверяет связь и затем очищает очередь, — удобство, а не гарантия: связь может измениться между проверкой и попыткой доставки.

Докажите это одним безобидным сообщением

Отправьте одно безобидное сообщение при опущенном VPN, затем проверьте postqueue -p на причину отсрочки и ID очереди. Восстановите нужный путь и запросите контролируемый проход очереди, наблюдая, выходит ли сообщение через релей, а не куда-то ещё. Затем снова разорвите путь в середине полёта и подтвердите, что сообщение возвращается в очередь. Просмотрите maximal_queue_lifetime, прежде чем решать, сколько может длиться сбой, потому что нулевое значение означает одну попытку, а не неограниченное хранение.

Следите за возрастом очереди и использованием диска. Политика, ждущая VPN, превращается в сбой почты, если никто не замечает, что очередь растёт с пятницы.

Записывайте релей, транспорт, правило межсетевого экрана и срок жизни вместе. Эти четыре описывают устройство; любое из них в отдельности описывает догадку.