Postfix, VPN ir smarthost: eilė nėra ugniasienė

Laiškų laikymas eilėje, kol pakils VPN, yra planavimo problema, o įprastas sprendimas – sustabdyti Postfix, pakeisti main.cf ir vėl jį paleisti. Tai veikia, ir tai yra netinkama forma, nes sumaišo du reikalavimus: kada reikia bandyti pristatyti ir kuris tinklo kelias gali jį nešti. Antrasis yra ugniasienės sprendimas, ir jokia Postfix direktyva negali jo priimti. Kai abu atskiriami, kiekvienas turi mažą ir patikrinamą atsakymą.

Laikykite relay paskirties vietą stabilią, užblokuokite tiesioginį pristatymą tinklo riboje ir leiskite eilei laukti.

Du reikalavimai, kuriuos žmonės sujungia į vieną

Relay nurodo Postfix, kur perduoti laišką; relayhost = [smtp.corp.example]:587 nurodo hostą ir prievadą, o laužtiniai skliaustai slopina MX pagrįstą pasirinkimą tam kitam šuoliui. Kelias nurodo branduoliui, kur paketams leidžiama eiti. Teisingas relayhost be kelio apribojimo vis tiek leidžia Postfix pasiekti internetą tiesiogiai, kai maršrutų lentelė tai leidžia, o teisinga ugniasienė su neteisingu relayhost siunčia laišką ne ten. Nė vienas neimplikuoja kito.

Transporto žemėlapiai, per siuntėją taikomi pakeitimai ir atsarginiai relayai kiekvienas nusipelno to paties skaitymo. Stabilus relayhost nėra įrodymas, kad kiekvienas sukonfigūruotas pristatymo maršrutas jį naudoja, o atsarginis kelias, apeinantis relay, yra ta pati klaida geresnėje kamufliaže.

Ką defer_transports iš tikrųjų daro

defer_transports sulaiko pranešimus nurodytiems transportams, todėl joks pristatymo bandymas neatliekamas, kol eilės ėjimas jų nepaliečia. Tai planavimo valdymas, ir eilės išvalymas jį nustelbia; tai yra dizainas, o ne defektas. Naudokite tikrus transportų pavadinimus iš master.cf, nes pasirinktinis transportas ar atskirai pavadintas relay transportas nėra apimamas vien todėl, kad jo programa taip pat kalba SMTP. Įprastas pakartotinis bandymas yra kitas mechanizmas: su fail-closed keliu pristatymo bandymai tiesiog nepavyksta ir lieka eilėje, be jokios atidėjimo direktyvos.

Nuolatinės klaidos laukia ne mandagiai. Blogas gavėjas arba atmesti prisijungimo duomenys grįžta arba įstringa kaip kieta klaida, o ne sėdi, kol atsiras tunelis, todėl eilė, pilna atidėtų laiškų, nėra automatiškai saugi eilė.

Reikalaukite kelio tinklo sluoksnyje

Apribojimas priklauso vietinės išvesties ribai arba izoliuotai tinklo vardų erdvei. Jis turi apimti tikruosius relay adresus, transportą ir prievadą, įskaitant IPv6, jei jis įjungtas, nes taisyklė, blokuojanti TCP 25, nieko nedaro relayui, veikiančiam 587 arba 465 prievadu. Laikykite loopback ir vietinius pateikimo kelius atskirai, kad pati eilė toliau veiktų. Politika turėtų likti uždaryta, kai tunelio maršrutas išnyksta arba vėl pasirodo kitu sąsajos vardu.

Sąsajos pakilimo įvykis neįrodo, kad relay pasiekiamas per ją. Todėl kabliukas, kuris patikrina ryšį ir tada išvalo eilę, yra patogumas, o ne garantija: ryšys gali pasikeisti tarp patikros ir pristatymo bandymo.

Įrodykite tai vienu nekenksmingu pranešimu

Išsiųskite vieną nekenksmingą pranešimą, kai VPN išjungtas, tada patikrinkite postqueue -p dėl atidėjimo priežasties ir eilės ID. Atkurkite numatytą kelią ir paprašykite kontroliuojamo eilės ėjimo, stebėdami, ar pranešimas išeina per relay, o ne kur nors kitur. Tada vėl nutraukite kelią skrydžio viduryje ir patvirtinkite, kad pranešimas grįžta į eilę. Peržiūrėkite maximal_queue_lifetime, prieš nuspręsdami, kiek gali trukti sutrikimas, nes nulinė reikšmė reiškia vieną bandymą, o ne neribotą saugojimą.

Stebėkite eilės amžių ir disko naudojimą. Politika, kuri laukia VPN, virsta pašto sutrikimu, jei niekas nepastebi, kad eilė auga nuo penktadienio.

Užrašykite relay, transportą, ugniasienės taisyklę ir galiojimo laiką kartu. Tie keturi apibūdina išdėstymą; bet kuris iš jų atskirai apibūdina spėjimą.