Postfix, VPN og ein smarthost: ein kø er ikkje ein brannmur

Å halde e-post i kø til VPN-et kjem opp er eit planleggingsproblem, og den vanlege løysinga er å stoppe Postfix, bytte main.cf og starte det på nytt. Det verkar, og det er feil form, fordi det blandar to krav: når levering skal prøvast, og kva nettverksveg som kan bera han. Det andre er ei brannmur-avgjerd, og inga Postfix-direktiv kan ta henne. Når dei to blir skilde, har kvar eit lite og testbart svar.

Hald relaymålet stabilt, blokker direkte levering ved nettverksgrensa, og lat køen gjere ventinga.

To krav folk smeltar saman til eitt

Relayet fortel Postfix kvar e-posten skal overleverast; relayhost = [smtp.corp.example]:587 nemner ein vert og ein port, med klammer som undertrykkjer MX-basert val for det neste hoppet. Vegen fortel kjernen kvar pakkane får gå. Ein korrekt relayhost utan vegavgrensing lèt Postfix framleis nå internett direkte når rutetabellen tilfeldigvis tillèt det, og ein korrekt brannmur med feil relayhost sender e-post til feil stad. Ingen av dei fører den andre med seg.

Transportkart, overstyringar per avsendar og reserve-relayar fortener kvar den same lesinga. Ein stabil relayhost er ikkje prov for at kvar konfigurert leveringsrute brukar han, og ei reserverute som omgår relayet er same feilen i betre kamuflasje.

Kva defer_transports faktisk gjer

defer_transports held meldingar attende for dei namngjevne transportane, slik at ingen leveringsfreistnad blir gjord før ein køyring av køen rører dei. Det er ein planleggingskontroll, og ei køtømming overstyrer han; det er designet og ikkje ein feil. Bruk dei ekte transportnamna frå master.cf, for ein tilpassa transport eller ein separat namngjeven relaytransport blir ikkje dekt berre fordi programmet også snakkar SMTP. Vanleg nytt forsøk er ein annan mekanisme: med ein fail-closed veg mislukkast leveringsfreistnadene ganske enkelt og blir i køen, utan noko utsetjingsdirektiv.

Permanente feil ventar ikkje høfleg. Ein dårleg mottakar eller ein avvist legitimasjon sprett tilbake eller blir hengande som ein hard feil i staden for å sitje til tunnelen dukkar opp, så ein kø full av utsett e-post er ikkje automatisk ein trygg kø.

Krev vegen i nettverkslaget

Avgrensinga høyrer til grensa for lokal utgang eller inne i eit isolert nettverksnamnerom. Ho må dekkje dei faktiske adressene til relayet, transporten og porten, inkludert IPv6 om det er slått på, fordi ei regel som blokkerer TCP 25 ikkje gjer noko for eit relay på 587 eller 465. Hald loopback og lokale innsendingsvegar åtskilde slik at køen sjølv held fram med å verke. Retningslinja bør halde seg lukka når tunnelruta forsvinn eller dukkar opp att under eit anna grensesnittnamn.

Ein hending der grensesnittet kjem opp provar ikkje at relayet er nåbart gjennom det. Difor er ein hook som sjekkar lenka og deretter tømmer køen ei bekvemmelegheit og ikkje ei garanti: lenka kan endre seg mellom sjekken og leveringsfreistnaden.

Prov det med éi uskuldig melding

Send éi uskuldig melding med VPN-et nede, og undersøk deretter postqueue -p for utsetjingsårsaka og kø-ID-en. Før den tiltenkte vegen attende og be om ein kontrollert køyring av køen, medan du ser om meldinga går ut gjennom relayet og ikkje ein annan stad. Bryt deretter vegen igjen midt i flukta og stadfest at meldinga kjem tilbake til køen. Gå gjennom maximal_queue_lifetime før du avgjer kor lenge ein driftsstans kan vare, fordi ein verdi på null tyder eitt forsøk og ikkje ubegrensa oppbevaring.

Overvak alderen på køen og diskbruken. Ei retningslinje som ventar på VPN-et blir eit e-postutfall om ingen merkar at køen har vorte større sidan fredag.

Registrer relayet, transporten, brannmurregelen og levetida saman. Dei fire skildrar oppsettet; kvar av dei åleine skildrar eit gjetting.