Postfix, VPN und ein Smarthost: Eine Warteschlange ist keine Firewall

Mail in der Warteschlange zu halten, bis das VPN steht, ist ein Planungsproblem, und die übliche Lösung ist, Postfix zu stoppen, main.cf zu tauschen und es neu zu starten. Das funktioniert, und es ist die falsche Form, weil es zwei Anforderungen vermischt: wann die Zustellung versucht werden soll und welcher Netzwerkpfad sie tragen darf. Die zweite ist eine Firewall-Entscheidung, und keine Postfix-Direktive kann sie treffen. Sobald beide getrennt sind, hat jede eine kleine und prüfbare Antwort.

Halten Sie das Relay-Ziel stabil, blockieren Sie die direkte Zustellung an der Netzwerkgrenze, und lassen Sie die Warteschlange das Warten übernehmen.

Zwei Anforderungen, die Menschen zu einer verschmelzen

Das Relay sagt Postfix, wohin die Mail zu übergeben ist; relayhost = [smtp.corp.example]:587 nennt Host und Port, wobei Klammern die MX-basierte Auswahl für diesen nächsten Hop unterdrücken. Der Pfad sagt dem Kernel, wohin Pakete gehen dürfen. Ein korrekter relayhost ohne Pfadbeschränkung lässt Postfix trotzdem direkt ins Internet, wenn die Routing-Tabelle es zufällig erlaubt, und eine korrekte Firewall mit falschem relayhost schickt Mail an die falsche Stelle. Keines bedingt das andere.

Transport-Maps, Overrides pro Absender und Ausweich-Relays verdienen jeweils dieselbe Lesart. Ein stabiles relayhost ist kein Beweis, dass jede konfigurierte Zustellroute es nutzt, und ein Ausweichweg, der das Relay umgeht, ist derselbe Fehler in besserer Tarnung.

Was defer_transports tatsächlich tut

defer_transports hält Nachrichten für die genannten Transporte zurück, sodass kein Zustellversuch unternommen wird, bis ein Warteschlangenlauf sie berührt. Es ist eine Planungssteuerung, und ein Queue-Flush überschreibt sie; das ist das Design und kein Defekt. Verwenden Sie die echten Transportnamen aus master.cf, denn ein eigener Transport oder ein separat benannter Relay-Transport ist nicht dadurch abgedeckt, dass sein Programm auch SMTP spricht. Der gewöhnliche Wiederholungsversuch ist ein anderer Mechanismus: Bei einem fail-closed Pfad schlagen Zustellversuche einfach fehl und bleiben in der Warteschlange, ohne dass eine Aufschub-Direktive beteiligt ist.

Permanente Fehler warten nicht höflich. Ein schlechter Empfänger oder ein abgelehnter Zugangsdatensatz springt zurück oder bleibt als harter Fehler hängen, statt zu warten, bis der Tunnel erscheint, sodass eine Warteschlange voll aufgeschobener Mail nicht automatisch eine sichere Warteschlange ist.

Erzwingen Sie den Pfad auf der Netzwerkschicht

Die Beschränkung gehört an die Grenze der lokalen Ausgabe oder in einen isolierten Netzwerk-Namespace. Sie muss die echten Adressen des Relays, Transport und Port abdecken, einschließlich IPv6, falls aktiviert, denn eine Regel, die TCP 25 blockiert, bewirkt nichts für ein Relay auf 587 oder 465. Halten Sie Loopback und lokale Einlieferungswege getrennt, damit die Warteschlange selbst weiterläuft. Die Richtlinie sollte geschlossen bleiben, wenn die Tunnelroute verschwindet oder unter einem anderen Schnittstellennamen wieder auftaucht.

Ein Interface-Up-Ereignis beweist nicht, dass das Relay darüber erreichbar ist. Deshalb ist ein Hook, der den Link prüft und dann die Warteschlange leert, eine Bequemlichkeit und keine Garantie: Der Link kann sich zwischen Prüfung und Zustellversuch ändern.

Beweisen Sie es mit einer harmlosen Nachricht

Senden Sie eine harmlose Nachricht bei ausgeschaltetem VPN und prüfen Sie dann postqueue -p auf den Aufschubgrund und die Queue-ID. Stellen Sie den vorgesehenen Pfad wieder her und fordern Sie einen kontrollierten Warteschlangenlauf an, wobei Sie beobachten, ob die Nachricht über das Relay und nicht woanders hinausgeht. Unterbrechen Sie dann den Pfad erneut mitten im Flug und bestätigen Sie, dass die Nachricht in die Warteschlange zurückkehrt. Prüfen Sie maximal_queue_lifetime, bevor Sie entscheiden, wie lange ein Ausfall dauern darf, denn ein Wert von null bedeutet einen Versuch und keine unbegrenzte Aufbewahrung.

Überwachen Sie Alter der Warteschlange und Plattenverbrauch. Eine Richtlinie, die auf das VPN wartet, wird zum Mailausfall, wenn niemand bemerkt, dass die Warteschlange seit Freitag wächst.

Halten Sie Relay, Transport, Firewall-Regel und Lebensdauer zusammen fest. Diese vier beschreiben die Anordnung; jede für sich beschreibt eine Vermutung.