Postfix, VPN at smarthost: ang pila ay hindi firewall

Ang pag-iingat ng mail sa pila hanggang bumangon ang VPN ay problema sa iskedyul, at ang karaniwang solusyon ay ihinto ang Postfix, palitan ang main.cf at simulan muli. Gumagana iyon, at ito ang maling anyo, dahil pinagsasama nito ang dalawang pangangailangan: kung kailan dapat subukan ang paghahatid, at kung aling ruta ng network ang makakadala nito. Ang pangalawa ay desisyon ng firewall, at walang direktiba ng Postfix ang makagawa nito. Kapag nahiwalay ang dalawa, may maliit at nasusubok na sagot ang bawat isa.

Panatilihing matatag ang destinasyon ng relay, harangan ang direktang paghahatid sa hangganan ng network, at hayaang ang pila ang maghintay.

Dalawang pangangailangan na pinagsasama ng mga tao sa isa

Sinasabi ng relay sa Postfix kung saan ipapasa ang mail; tinutukoy ng relayhost = [smtp.corp.example]:587 ang isang host at port, at pinipigilan ng mga bracket ang pagpiling batay sa MX para sa susunod na hop. Sinasabi ng ruta sa kernel kung saan maaaring pumunta ang mga packet. Ang tamang relayhost na walang paghihigpit sa ruta ay hinahayaan pa ring maabot ng Postfix ang internet nang direkta kapag pinapayagan ito ng routing table, at ang tamang firewall na may maling relayhost ay nagpapadala ng mail sa maling lugar. Wala sa dalawa ang nangangahulugan ng isa pa.

Ang mga mapa ng transport, mga override kada nagpadala at mga backup na relay ay bawat isa ay karapat-dapat sa parehong pagbasa. Ang matatag na relayhost ay hindi patunay na ginagamit ito ng bawat naka-configure na ruta ng paghahatid, at ang backup na rutang lumalampas sa relay ay parehong kabiguan sa mas magandang pagkukunwari.

Ano ang talagang ginagawa ng defer_transports

Ang defer_transports ay nag-iingat ng mga mensahe para sa mga pinangalanang transport, kaya walang pagtatangkang maghatid hanggang may pag-ikot ng pila na humawak sa mga ito. Ito ay kontrol sa iskedyul, at ang flush ng pila ay nananaig dito; iyon ang disenyo at hindi depekto. Gamitin ang tunay na mga pangalan ng transport mula sa master.cf, dahil ang pasadyang transport o hiwalay na pinangalanang relay transport ay hindi saklaw dahil lamang nagsasalita rin ng SMTP ang programa nito. Ang karaniwang muling pagsubok ay ibang mekanismo: sa rutang fail-closed, ang mga pagtatangkang maghatid ay nabibigo lamang at nananatili sa pila, nang walang direktiba sa pagkaantala.

Ang mga permanenteng kabiguan ay hindi naghihintay nang may modo. Ang masamang tatanggap o tinanggihang kredensyal ay bumabalik o nananatili bilang matigas na error sa halip na maghintay hanggang lumitaw ang tunel, kaya ang pila na puno ng naantalang mail ay hindi awtomatikong ligtas na pila.

Ipatupad ang ruta sa antas ng network

Ang paghihigpit ay kabilang sa hangganan ng lokal na output o sa loob ng isyoladong namespace ng network. Dapat itong sumaklaw sa tunay na mga address ng relay, transport at port, kasama ang IPv6 kung naka-enable, dahil ang patakarang humaharang sa TCP 25 ay walang ginagawa para sa relay sa 587 o 465. Panatilihing hiwalay ang loopback at mga lokal na ruta ng pagsusumite upang ang pila mismo ay patuloy na gumana. Dapat manatiling sarado ang patakaran kapag naglaho o muling lumitaw ang ruta ng tunel sa ilalim ng ibang pangalan ng interface.

Ang pangyayaring bumangon ang interface ay hindi nagpapatunay na naaabot ang relay sa pamamagitan nito. Iyon ang dahilan kung bakit ang hook na sumusuri sa link at pagkatapos ay nag-flush ay kaginhawahan at hindi garantiya: maaaring magbago ang link sa pagitan ng pagsusuri at ng pagtatangkang maghatid.

Patunayan ito sa isang hindi nakakapinsalang mensahe

Magpadala ng isang hindi nakakapinsalang mensahe habang nakababa ang VPN, pagkatapos suriin ang postqueue -p para sa dahilan ng pagkaantala at ID ng pila. Ibalik ang inilaan na ruta at humiling ng kontroladong pag-ikot ng pila, pinapanood kung lumalabas ang mensahe sa relay at hindi sa ibang lugar. Pagkatapos putulin muli ang ruta sa kalagitnaan ng lipad at tiyakin na bumabalik ang mensahe sa pila. Suriin ang maximal_queue_lifetime bago magpasya kung gaano katagal maaaring tumagal ang pagkawala ng serbisyo, dahil ang halagang sero ay nangangahulugang isang pagtatangka at hindi walang hanggang pag-iingat.

Subaybayan ang edad ng pila at paggamit ng disk. Ang patakarang naghihintay sa VPN ay nagiging pagkawala ng serbisyo ng mail kung walang makapansin na lumalaki ang pila mula noong Biyernes.

Itala nang sama-sama ang relay, transport, patakaran ng firewall at tagal. Ang apat na iyon ang naglalarawan ng kaayusan; alinman sa kanila nang nag-iisa ay naglalarawan ng haka-haka.