Postfix, VPN in smarthost: čakalna vrsta ni požarni zid

Zadrževanje pošte v čakalni vrsti, dokler se VPN ne dvigne, je problem načrtovanja, običajna rešitev pa je ustaviti Postfix, zamenjati main.cf in ga znova zagnati. To deluje in je napačna oblika, ker meša dve zahtevi: kdaj naj se dostava poskusi in katera omrežna pot jo sme nositi. Druga je odločitev požarnega zidu in nobena direktiva Postfixa je ne more sprejeti. Ko se obe ločita, ima vsaka majhen in preverljiv odgovor.

Ohranite cilj relayja stabilen, blokirajte neposredno dostavo na omrežni meji in pustite čakalni vrsti, da čaka.

Dve zahtevi, ki jih ljudje zlijejo v eno

Relay pove Postfixu, kam naj preda pošto; relayhost = [smtp.corp.example]:587 navaja gostitelja in vrata, oglati oklepaji pa zatirajo izbiro na podlagi MX za ta naslednji skok. Pot pove jedru, kam smejo paketi. Pravilen relayhost brez omejitve poti še vedno omogoči Postfixu, da doseže internet neposredno, ko to usmerjevalna tabela dovoli, pravilen požarni zid z napačnim relayhostom pa pošlje pošto na napačno mesto. Nobeno ne pomeni drugega.

Transportne karte, izjeme po pošiljatelju in rezervni relayji si zaslužijo isto branje. Stabilen relayhost ni dokaz, da ga uporablja vsaka nastavljena pot dostave, in rezervna pot, ki se relayju izogne, je ista napaka v boljši preobleki.

Kaj defer_transports resnično počne

defer_transports zadrži sporočila za imenovane transporte, tako da se noben poskus dostave ne izvede, dokler se jih ne dotakne en prehod čakalne vrste. To je nadzor načrtovanja in izpraznitev čakalne vrste ga preglasi; to je zasnova, ne napaka. Uporabite prava imena transportov iz master.cf, ker lastni transport ali drugače imenovan relay transport ni pokrit samo zato, ker njegov program govori tudi SMTP. Običajni ponovni poskus je drug mehanizem: pri poti fail-closed poskusi dostave preprosto spodletijo in ostanejo v čakalni vrsti, brez kakršne koli direktive odloga.

Trajne napake ne čakajo vljudno. Slab prejemnik ali zavrnjene poverilnice se vrnejo ali obstanejo kot trda napaka, namesto da bi čakali, dokler se ne pojavi tunel, zato čakalna vrsta, polna odložene pošte, ni samodejno varna čakalna vrsta.

Zahtevajte pot v omrežni plasti

Omejitev sodi na mejo lokalnega izhoda ali v notranjost izoliranega omrežnega imenskega prostora. Pokriti mora resnične naslove relayja, transport in vrata, vključno z IPv6, če je omogočen, ker pravilo, ki blokira TCP 25, ne naredi ničesar za relay na 587 ali 465. Loopback in lokalne poti oddaje imejte ločeno, da čakalna vrsta sama deluje naprej. Politika bi morala ostati zaprta, ko pot tunela izgine ali se znova pojavi pod drugim imenom vmesnika.

Dogodek, ko vmesnik pride gor, ne dokazuje, da je relay prek njega dosegljiv. Zato je kavelj, ki preveri povezavo in nato izprazni čakalno vrsto, udobje in ne jamstvo: povezava se lahko spremeni med preverjanjem in poskusom dostave.

Dokažite to z enim nedolžnim sporočilom

Pošljite eno nedolžno sporočilo z izklopljenim VPN, nato preglejte postqueue -p zaradi razloga odloga in ID čakalne vrste. Obnovite predvideno pot in zahtevajte nadzorovan prehod čakalne vrste ter opazujte, ali sporočilo odide skozi relay in ne kam drugam. Nato pot znova prekinite sredi leta in potrdite, da se sporočilo vrne v čakalno vrsto. Preglejte maximal_queue_lifetime, preden odločite, kako dolgo lahko traja izpad, ker ničelna vrednost pomeni en poskus in ne neomejeno hrambo.

Spremljajte starost čakalne vrste in porabo diska. Politika, ki čaka na VPN, se spremeni v izpad pošte, če nihče ne opazi, da čakalna vrsta raste od petka.

Zabeležite relay, transport, pravilo požarnega zidu in življenjsko dobo skupaj. Ti štirje opisujejo ureditev; kateri koli od njih sam opisuje ugibanje.