Postfix, VPN en een smarthost: een wachtrij is geen firewall

Mail in de wachtrij houden tot de VPN omhoog komt is een planningsprobleem, en de gebruikelijke oplossing is Postfix stoppen, main.cf verwisselen en het opnieuw starten. Dat werkt, en het is de verkeerde vorm, omdat het twee eisen vermengt: wanneer aflevering geprobeerd moet worden, en welk netwerkpad het mag dragen. De tweede is een firewallbeslissing, en geen enkele Postfix-richtlijn kan die nemen. Zodra de twee gescheiden zijn, heeft elk een klein en testbaar antwoord.

Houd de relaybestemming stabiel, blokkeer directe aflevering aan de netwerkgrens, en laat de wachtrij het wachten doen.

Twee eisen die mensen tot één versmelten

De relay vertelt Postfix waar mail naartoe moet; relayhost = [smtp.corp.example]:587 noemt een host en poort, waarbij blokhaken de MX-gebaseerde selectie voor die volgende hop onderdrukken. Het pad vertelt de kernel waar pakketten heen mogen. Een correcte relayhost zonder padbeperking laat Postfix nog steeds rechtstreeks het internet bereiken wanneer de routingtabel dat toevallig toestaat, en een correcte firewall met een verkeerde relayhost stuurt mail naar de verkeerde plek. Geen van beide impliceert de andere.

Transporttabellen, overschrijvingen per afzender en reserve-relays verdienen elk dezelfde lezing. Een stabiele relayhost is geen bewijs dat elke geconfigureerde afleveringsroute hem gebruikt, en een reservepad dat de relay omzeilt is dezelfde fout in betere camouflage.

Wat defer_transports werkelijk doet

defer_transports houdt berichten vast voor de genoemde transporten, zodat geen afleveringspoging wordt gedaan tot een wachtrijrun ze raakt. Het is een planningsbeheer, en een wachtrijflush overstemt het; dat is het ontwerp en geen defect. Gebruik de echte transportnamen uit master.cf, want een aangepast transport of een apart genoemd relaytransport wordt niet gedekt alleen omdat het programma ook SMTP spreekt. Gewone herhaling is een ander mechanisme: met een fail-closed pad mislukken afleveringspogingen gewoon en blijven ze in de wachtrij, zonder enige uitstelrichtlijn.

Permanente fouten wachten niet beleefd. Een slechte ontvanger of geweigerde inloggegevens stuurt terug of blijft hangen als harde fout in plaats van te wachten tot de tunnel verschijnt, dus een wachtrij vol uitgestelde mail is niet automatisch een veilige wachtrij.

Dwing het pad af op de netwerklaag

De beperking hoort bij de grens van lokale uitvoer of binnen een geïsoleerde netwerknaamruimte. Ze moet de echte adressen van de relay, het transport en de poort dekken, inclusief IPv6 indien ingeschakeld, want een regel die TCP 25 blokkeert doet niets voor een relay op 587 of 465. Houd loopback en lokale inzendpaden gescheiden zodat de wachtrij zelf blijft werken. Het beleid zou gesloten moeten blijven wanneer de tunnelroute verdwijnt of onder een andere interfacenaam terugkeert.

Een interface-up-gebeurtenis bewijst niet dat de relay erdoor bereikbaar is. Daarom is een hook die de link controleert en dan de wachtrij leegt een gemak en geen garantie: de link kan veranderen tussen de controle en de afleveringspoging.

Bewijs het met één onschuldig bericht

Stuur één onschuldig bericht met de VPN omlaag, en bekijk dan postqueue -p voor de uitstelreden en de wachtrij-ID. Herstel het bedoelde pad en vraag een gecontroleerde wachtrijrun aan, en kijk of het bericht via de relay vertrekt en niet ergens anders. Doorbreek daarna het pad opnieuw midden in de vlucht en bevestig dat het bericht terugkeert in de wachtrij. Bekijk maximal_queue_lifetime voordat je beslist hoe lang een storing mag duren, want een waarde van nul betekent één poging en geen onbeperkte bewaring.

Monitor de leeftijd van de wachtrij en het schijfgebruik. Een beleid dat op de VPN wacht wordt een mailstoring als niemand merkt dat de wachtrij sinds vrijdag groeit.

Registreer de relay, het transport, de firewallregel en de levensduur samen. Die vier beschrijven de opzet; elk ervan alleen beschrijft een gok.