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

Å holde e-post i kø inntil VPN-en er oppe er et planleggingsspørsmål, og den vanlige løsningen er å stanse Postfix, bytte ut main.cf og starte det igjen. Det fungerer, og det er den gale formen, fordi det blander to krav: når levering skal forsøkes, og hvilken nettverksvei som får bære den. Det siste er en brannmur-avgjørelse, og ingen Postfix-innstilling kan ta den. Når de to skilles, har hver av dem et lite og testbart svar.

Hold relaymålet stabilt, steng direkte levering ved nettverksgrensen, og la køen stå for ventingen.

To krav som folk smelter sammen til ett

Relayet forteller Postfix hvor e-posten skal leveres videre; relayhost = [smtp.corp.example]:587 angir en vert og en port, mens klammer undertrykker MX-basert valg for det neste hoppet. Veien forteller kjernen hvor pakkene har lov til å gå. En riktig relayhost uten veibegrensning lar Postfix likevel nå internett direkte når rutetabellen tilfeldigvis tillater det, og en riktig brannmur med gal relayhost sender e-posten til feil sted. Ingen av dem forutsetter den andre.

Transporttabeller, overstyringer per avsender og reserverelayer fortjener alle samme gjennomlesning. En stabil relayhost er ikke bevis for at hver oppsatt leveringsrute bruker den, og en reserverute som går utenom relayet er den samme feilen i bedre forkledning.

Hva defer_transports egentlig gjør

defer_transports holder meldinger tilbake for transportene som er navngitt, slik at ingen levering forsøkes før en kjøring av køen berører dem. Dette er en planleggingsstyring, og en tømming av køen overstyrer den; det er slik den er laget, ikke en feil. Bruk de virkelige transportnavnene fra master.cf, fordi en egen transport eller en relaytransport med eget navn ikke dekkes bare fordi programmet også snakker SMTP. Det vanlige nye forsøket er en annen mekanisme: med en fail-closed vei feiler leveringsforsøkene rett og slett og blir liggende i køen, uten noe utsettelsespåbud.

Varige feil venter ikke pent. En dårlig mottaker eller en avvist innlogging spretter tilbake eller blir hengende som en hard feil i stedet for å vente 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 hjemme ved grensen for lokal utgang eller inne i et isolert nettverksnavnerom. Den må dekke de faktiske adressene til relayet, transporten og porten, inkludert IPv6 dersom det er slått på, fordi en regel som stenger 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 holde seg lukket når tunnelruten forsvinner eller dukker opp igjen under et annet grensesnittnavn.

At grensesnittet kommer opp beviser ikke at relayet er nåbart gjennom det. Derfor er en krok som sjekker lenken og så 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 mens VPN-en er nede, og se deretter på postqueue -p for utsettelsesårsaken og kø-ID-en. Gjenopprett den tiltenkte veien og be om en kontrollert kjøring av køen, og se om meldingen går ut gjennom relayet og ikke et annet sted. Bryt så 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 alderen på køen og diskbruken. En retningslinje som venter på VPN-en blir et e-postutfall dersom ingen legger merke til at køen har vokst siden fredag.

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