Postfix, VPN og en smarthost: en kø er ikke en firewall

At holde mail i kø, indtil VPN'et kommer op, er et planlægningsproblem, og den sædvanlige løsning er at stoppe Postfix, udskifte main.cf og starte det igen. Det virker, og det er den forkerte facon, fordi det blander to krav: hvornår levering skal forsøges, og hvilken netværksvej der må bære den. Det andet er en firewall-beslutning, og ingen Postfix-direktiv kan træffe den. Når de to skilles, har hver især et lille og testbart svar.

Hold relayets destination stabil, bloker direkte levering ved netværksgrænsen, og lad køen gøre ventetiden.

To krav, som folk smelter sammen til ét

Relayet fortæller Postfix, hvor mailen skal afleveres; relayhost = [smtp.corp.example]:587 angiver en vært og en port, og parenteserne undertrykker MX-baseret valg for det næste hop. Vejen fortæller kernen, hvor pakker må gå hen. En korrekt relayhost uden vejbegrænsning lader stadig Postfix nå internettet direkte, når routingtabellen tilfældigvis tillader det, og en korrekt firewall med en forkert relayhost sender mail til det forkerte sted. Ingen af dem forudsætter den anden.

Transportkort, tilsidesættelser per afsender og reserve-relayere fortjener hver især den samme læsning. En stabil relayhost er ikke bevis for, at hver konfigureret leveringsrute bruger den, og en reservevej, der omgår relayet, er samme fejl i bedre camouflage.

Hvad defer_transports faktisk gør

defer_transports holder meddelelser tilbage for de navngivne transporter, så der ikke gøres noget leveringsforsøg, før et køløb rører dem. Det er en planlægningskontrol, og en køudtømning tilsidesætter den; det er designet, ikke en fejl. Brug de rigtige transportnavne fra master.cf, for en tilpasset transport eller en separat navngivet relaytransport er ikke dækket, bare fordi dens program også taler SMTP. Almindelig genforsøg er en anden mekanisme: med en fail-closed vej fejler leveringsforsøg ganske enkelt og bliver i køen, uden nogen udsættelsesdirektiv.

Permanente fejl venter ikke høfligt. En dårlig modtager eller en afvist legitimationsoplysning bouncer eller hænger som en hård fejl i stedet for at sidde, indtil tunnelen dukker op, så en kø fuld af udsat mail er ikke automatisk en sikker kø.

Håndhæv vejen i netværkslaget

Begrænsningen hører ved grænsen for lokalt output eller inde i et isoleret netværksnavnerum. Den skal dække relayets faktiske adresser, transport og port, inklusive IPv6 hvis det er aktiveret, fordi en regel, der blokerer TCP 25, intet gør for et relay på 587 eller 465. Hold loopback og lokale indsendelsesveje adskilt, så køen selv bliver ved med at virke. Politikken bør forblive lukket, når tunnelruten forsvinder eller dukker op igen under et andet interfacenavn.

En interface-up-hændelse beviser ikke, at relayet kan nås gennem den. Derfor er en hook, der tjekker linket og derefter tømmer køen, en bekvemmelighed snarere end en garanti: linket kan ændre sig mellem tjekket og leveringsforsøget.

Bevis det med én uskadelig meddelelse

Send én uskadelig meddelelse med VPN'et nede, og undersøg derefter postqueue -p for udsættelsesårsagen og kø-ID'en. Gendan den tilsigtede vej, og anmod om et kontrolleret køløb, mens du ser, om meddelelsen forlader gennem relayet i stedet for et andet sted. Bryd derefter vejen igen midt i flugten, og bekræft, at meddelelsen vender tilbage til køen. Gennemgå maximal_queue_lifetime, før du beslutter, hvor længe et udfald må vare, fordi en værdi på nul betyder ét forsøg snarere end ubegrænset opbevaring.

Overvåg køens alder og diskforbruget. En politik, der venter på VPN'et, bliver til et mailudfald, hvis ingen opdager, at køen er vokset siden fredag.

Registrér relayet, transporten, firewall-reglen og levetiden sammen. De fire beskriver arrangementet; enhver af dem alene beskriver et gæt.