Postfix, VPN en in smarthost: in wachtrige is gjin firewall
In wachtrige hâldt mail fêst, in firewall beslút oer it paad. Hâld de relay stabyl, twing ôflevering allinnich oer VPN ôf op 'e netwurklaach, en behannelje útstel as planning.
Mail yn 'e wachtrige hâlde oant de VPN omheech komt is in planningsprobleem, en de gewoane oplossing is Postfix stopje, main.cf ferwikselje en it wer starte. Dat wurket, en it is de ferkearde foarm, want it mingt twa easken: wannear't ôflevering besocht wurde moat, en hokker netwurkpaad it drage mei. It twadde is in firewallbeslút, en gjin Postfix-direktive kin dat nimme. As de beide skieden binne, hat elk in lyts en testber antwurd.
Hâld de relaybestemming stabyl, blokkearje direkte ôflevering op 'e netwurkgrins, en lit de wachtrige it wachtsjen dwaan.
Twa easken dy't minsken yn ien smelte
De relay fertelt Postfix wêr't mail oerlevere wurde moat; relayhost = [smtp.corp.example]:587 neamt in host en poarte, mei heakjes dy't MX-basearre seleksje foar dy folgjende hop ûnderdrukke. It paad fertelt de kernel wêr't pakketten hinne meie. In korrekte relayhost sûnder paadbeheining lit Postfix noch altyd direkt it ynternet berikke as de routingtabel dat tafallich tastiet, en in korrekte firewall mei in ferkearde relayhost stjoert mail nei it ferkearde plak. Gjin fan beide ymplisearret it oare.
Transportkaarten, oerskriuwings per ôfstjoerder en reserve-relays fertsjinje elk deselde lêzing. In stabyle relayhost is gjin bewiis dat elk konfigurearre ôfleveringspaad it brûkt, en in reservpaad dat de relay omgiet is deselde flater yn bettere kamûflaazje.
Wat defer_transports eins docht
defer_transports hâldt berjochten foar de neamde transporten fêst, sadat gjin ôfleveringspoging dien wurdt oant in wachtrigerûn dy oanrekket. It is in planningskontrôle, en in wachtrigeflush oerhearsket it; dat is it ûntwerp en gjin defekt. Brûk de echte transportnammen út master.cf, want in oanpaste transport of in apart neamde relaytransport wurdt net dutsen allinnich om't syn programma ek SMTP praat. Gewoane werpoging is in oar meganisme: mei in fail-closed paad mislearje ôfleveringspogingen gewoan en bliuwe se yn 'e wachtrige, sûnder dat der in útsteldirektive oan te pas komt.
Permaninte flaters wachtsje net beleefd. In minne ûntfanger of in wegere bewiis stuit of bliuwt as in hurde flater hingjen ynstee fan te sitten oant de tunnel ferskynt, dus in wachtrige fol útstelde mail is net automatysk in feilige wachtrige.
Twing it paad op 'e netwurklaach
De beheining heart by de grins fan lokale útfier of binnen in isolearre netwurknammromte. It moat de echte adressen fan 'e relay, transport en poarte dekke, ynklusyf IPv6 as dat oan stiet, want in regel dy't TCP 25 blokkearret docht neat foar in relay op 587 of 465. Hâld loopback en lokale yntsjinstpaden apart sadat de wachtrige sels wurkje bliuwt. It belied moat ticht bliuwe as it tunnelpaad ferdwynt of ûnder in oare ynterfacenamme wer ferskynt.
In evenemint fan in ynterface omheech bewiist net dat de relay dertroch berikber is. Dêrom is in haak dy't de keppeling kontrolearret en dan de wachtrige leget in gemak ynstee fan in garânsje: de keppeling kin feroarje tusken de kontrôle en de ôfleveringspoging.
Bewiis it mei ien ûnskuldich berjocht
Stjoer ien ûnskuldich berjocht mei de VPN del, en besjoch dan postqueue -p foar de reden fan útstel en it wachtrige-ID. Restorearje it bedoelde paad en freegje in kontrolearre wachtrigerûn oan, en sjoch oft it berjocht troch de relay fuortgiet ynstee fan earne oars. Bruts dan it paad wer midden yn 'e flecht en befêstigje dat it berjocht weromkomt yn 'e wachtrige. Besjoch maximal_queue_lifetime foardat jo beslute hoe lang in steuring duorje mei, want in wearde fan nul betsjut ien poging ynstee fan ûnbeheind bewarjen.
Monitorje wachtrigeâlder en skiifgebrûk. In belied dat op 'e VPN wachtet wurdt in mailsteuring as nimmen merkt dat de wachtrige sûnt freed groeit.
Registrearje de relay, it transport, de firewallregel en de libbensdoer tegearre. Dy fjouwer beskriuwe de opstelling; ien fan harren allinnich beskriuwt in gissing.