Postfix, VPN and a Smarthost: Queueing Is Not a Firewall

Keeping mail queued until the VPN comes up is a scheduling problem, and the usual solution is stopping Postfix, swapping main.cf and starting it again. That works and it is the wrong shape, because it mixes two requirements: when delivery should be attempted, and which network path may carry it. The second one is a firewall decision, and no Postfix directive can make it. Once the two are separated, each has a small and testable answer.

Keep the relay destination stable, block direct delivery at the network boundary, and let the queue do the waiting.

Two Requirements People Merge Into One

The relay tells Postfix where to hand mail; relayhost = [smtp.corp.example]:587 names a host and port, with brackets suppressing MX-based selection for that next hop. The path tells the kernel where packets are allowed to go. A correct relayhost with no path restriction still lets Postfix reach the internet directly when the routing table happens to allow it, and a correct firewall with a wrong relayhost sends mail to the wrong place. Neither one implies the other.

Transport maps, per-sender overrides and fallback relays each deserve the same reading. A stable relayhost is not proof that every configured delivery route uses it, and a fallback that bypasses the relay is the same failure wearing better camouflage.

What defer_transports Actually Does

defer_transports holds messages for the named transports so no delivery attempt is made until a queue run touches them. It is a scheduling control, and a queue flush overrides it; that is the design rather than a defect. Use the real transport names from master.cf, because a custom transport or a separately named relay transport is not covered just because its program also speaks SMTP. Ordinary retry is a different mechanism: with a fail-closed path, delivery attempts simply fail and stay queued, with no deferral directive involved.

Permanent failures do not wait politely. A bad recipient or a rejected credential bounces or sticks as a hard error instead of sitting until the tunnel appears, so a queue full of deferred mail is not automatically a safe queue.

Enforce the Path at the Network Layer

The restriction belongs at the local-output boundary or inside an isolated network namespace. It has to cover the relay's real addresses, transport and port, including IPv6 if enabled, because a rule blocking TCP 25 does nothing for a relay on 587 or 465. Keep loopback and local submission paths separate so the queue itself keeps working. The policy should stay closed when the tunnel route disappears or reappears under a different interface name.

An interface-up event does not prove the relay is reachable through it. That is why a hook that checks the link and then flushes is a convenience rather than a guarantee: the link can change between the check and the delivery attempt.

Prove It With One Harmless Message

Send one harmless message with the VPN down, then inspect postqueue -p for the deferred reason and the queue ID. Restore the intended path and request a controlled queue run, watching whether the message leaves through the relay rather than somewhere else. Then break the path again mid-flight and confirm the message returns to the queue. Review maximal_queue_lifetime before deciding how long an outage may last, since a zero value means one attempt rather than unlimited retention.

Monitor queue age and disk use. A policy that waits for the VPN turns into a mail outage if nobody notices the queue has been growing since Friday.

Record the relay, the transport, the firewall rule and the lifetime together. Those four describe the arrangement; any one of them alone describes a guess.