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

Å holde e-post i kø til VPN-et kommer opp er et planleggingsproblem, og den vanlige løsningen er å stoppe Postfix, bytte main.cf og starte det på nytt. Det virker, og det er feil form, fordi det blander to krav: når levering skal forsøkes, og hvilken nettverksvei som kan bære den. Det andre er en brannmurbeslutning, og ingen Postfix-direktiv kan ta den. Når de to skilles, har hver et lite og testbart svar.

Hold relaymålet stabilt, blokker direkte levering ved nettverksgrensen, og la køen gjøre ventingen.

To krav folk smelter sammen til ett

Relayet forteller Postfix hvor e-posten skal overleveres; relayhost = [smtp.corp.example]:587 navngir en vert og en port, med klammeparenteser som undertrykker MX-basert valg for det neste hoppet. Veien forteller kjernen hvor pakkene får gå. En korrekt relayhost uten veibegrensning lar Postfix fortsatt nå internett direkte når rutetabellen tilfeldigvis tillater det, og en korrekt brannmur med feil relayhost sender e-post til feil sted. Ingen av dem forutsetter den andre.

Transportkart, overstyringer per avsender og reserverelayer fortjener hver samme lesning. En stabil relayhost er ikke bevis for at hver konfigurert leveringsrute bruker den, og en reserverute som omgår relayet er samme feil i bedre kamuflasje.

Hva defer_transports faktisk gjør

defer_transports holder meldinger tilbake for de navngitte transportene, slik at ingen leveringsforsøk gjøres før en kjøring av køen berører dem. Det er en planleggingskontroll, og en køtømming overstyrer den; det er designet og ikke en feil. Bruk de ekte transportnavnene fra master.cf, for en tilpasset transport eller en separat navngitt relaytransport dekkes ikke bare fordi programmet også snakker SMTP. Vanlig nytt forsøk er en annen mekanisme: med en fail-closed vei mislykkes leveringsforsøk ganske enkelt og blir i køen, uten noen utsettelsesdirektiv.

Permanente feil venter ikke høflig. En dårlig mottaker eller en avvist legitimasjon spretter tilbake eller blir hengende som en hard feil i stedet for å sitte til tunnelen dukker opp, så en kø full av utsatt e-post er ikke automatisk en trygg kø.

Håndhev veien i nettverkslaget

Begrensningen hører til grensen for lokal utgang eller inne i et isolert nettverksnavnerom. Den må dekke relayets faktiske adresser, transport og port, inkludert IPv6 hvis det er aktivert, fordi en regel som blokkerer TCP 25 ikke gjør noe for et relay på 587 eller 465. Hold loopback og lokale innsendingsveier atskilt slik at køen selv fortsetter å virke. Retningslinjen bør forbli lukket når tunnelruten forsvinner eller dukker opp igjen under et annet grensesnittnavn.

En hendelse der grensesnittet kommer opp beviser ikke at relayet er nåbart gjennom det. Derfor er en hook som sjekker lenken og deretter tømmer køen en bekvemmelighet og ikke en garanti: lenken kan endre seg mellom sjekken og leveringsforsøket.

Bevis det med én uskyldig melding

Send én uskyldig melding med VPN-et nede, og undersøk deretter postqueue -p for utsettelsesårsaken og kø-ID-en. Gjenopprett den tiltenkte veien og be om en kontrollert kjøring av køen, mens du ser om meldingen går ut gjennom relayet og ikke et annet sted. Bryt deretter veien igjen midt i flukten og bekreft at meldingen kommer tilbake til køen. Gå gjennom maximal_queue_lifetime før du bestemmer hvor lenge en driftsstans kan vare, fordi en verdi på null betyr ett forsøk og ikke ubegrenset oppbevaring.

Overvåk køens alder og diskbruk. En retningslinje som venter på VPN-et blir et e-postutfall hvis ingen merker at køen har vokst siden fredag.

Registrer relayet, transporten, brannmurregelen og levetiden sammen. De fire beskriver oppsettet; enhver av dem alene beskriver en gjetning.