Postfix, VPN és smarthost: a sor nem tűzfal

A levél sorban tartása addig, amíg a VPN fel nem jön, ütemezési probléma, és a szokásos megoldás a Postfix leállítása, a main.cf cseréje és újraindítása. Ez működik, és ez a rossz forma, mert két követelményt kever: mikor kell megkísérelni a kézbesítést, és melyik hálózati útvonal viheti. A második tűzfal-döntés, és egyetlen Postfix-direktíva sem hozhatja meg. Ha a kettő elválik, mindegyiknek kicsi és tesztelhető válasza lesz.

Tartsa stabilan a relay célját, blokkolja a közvetlen kézbesítést a hálózati határon, és hagyja, hogy a sor várjon.

Két követelmény, amit az emberek egybe olvasztanak

A relay megmondja a Postfixnek, hova adja a levelet; relayhost = [smtp.corp.example]:587 gazdagépet és portot nevez meg, a szögletes zárójelek pedig elnyomják az MX-alapú választást ehhez a következő ugráshoz. Az útvonal megmondja a kernelnek, hova mehetnek a csomagok. A helyes relayhost útvonal-korlátozás nélkül is engedi a Postfixet közvetlenül az internetre, amikor az útválasztási tábla éppen engedi, a helyes tűzfal pedig rossz relayhosttal rossz helyre küldi a levelet. Egyik sem feltételezi a másikat.

A szállítási térképek, a feladónkénti felülbírálások és a tartalék relayek mind ugyanazt az olvasást érdemlik. A stabil relayhost nem bizonyíték arra, hogy minden beállított kézbesítési útvonal használja, és a relayt megkerülő tartalék útvonal ugyanaz a hiba jobb álcázásban.

Mit tesz valójában a defer_transports

A defer_transports visszatartja az üzeneteket a megnevezett szállításokhoz, így nem történik kézbesítési kísérlet, amíg egy sorkör nem érinti őket. Ez ütemezés-vezérlés, és a sor kiürítése felülírja; ez a tervezés, nem hiba. Használja a master.cf valódi szállításneveit, mert az egyéni szállítás vagy a külön megnevezett relay-szállítás nem attól lesz lefedett, hogy a programja SMTP-t is beszél. A szokásos újrapróbálkozás más mechanizmus: fail-closed útvonal esetén a kézbesítési kísérletek egyszerűen meghiúsulnak és a sorban maradnak, elhalasztási direktíva nélkül.

A tartós hibák nem várnak udvariasan. A rossz címzett vagy az elutasított hitelesítő adat visszapattan vagy kemény hibaként ragad, ahelyett hogy ülne, amíg az alagút megjelenik, ezért a halasztott levelekkel teli sor nem automatikusan biztonságos sor.

Kényszerítse az útvonalat a hálózati rétegben

A korlátozás a helyi kimenet határára vagy egy elkülönített hálózati névtér belsejébe tartozik. Le kell fednie a relay valódi címeit, a szállítást és a portot, beleértve az IPv6-ot, ha engedélyezett, mert a TCP 25-öt blokkoló szabály semmit nem tesz az 587-es vagy 465-ös relayért. Tartsa külön a loopbacket és a helyi beküldési útvonalakat, hogy maga a sor tovább működjön. A szabályzatnak zárva kell maradnia, amikor az alagút útvonala eltűnik vagy más interfésznév alatt újra megjelenik.

Az interfész feljövési eseménye nem bizonyítja, hogy a relay azon keresztül elérhető. Ezért a kapcsolatot ellenőrző, majd a sort kiürítő hook kényelem, nem garancia: a kapcsolat megváltozhat az ellenőrzés és a kézbesítési kísérlet között.

Bizonyítsa egyetlen ártalmatlan üzenettel

Küldjön egy ártalmatlan üzenetet kikapcsolt VPN mellett, majd nézze meg a postqueue -p kimenetében a halasztás okát és a sorazonosítót. Állítsa vissza a szándékolt útvonalat, és kérjen ellenőrzött sorkört, figyelve, hogy az üzenet a relayen keresztül távozik-e, nem máshol. Utána szakítsa meg újra az útvonalat repülés közben, és erősítse meg, hogy az üzenet visszatér a sorba. Mielőtt eldönti, meddig tarthat egy kiesés, nézze át a maximal_queue_lifetime értékét, mert a nulla érték egy kísérletet jelent, nem korlátlan megőrzést.

Figyelje a sor korát és a lemezhasználatot. A VPN-re váró szabályzat levélkieséssé válik, ha senki nem veszi észre, hogy a sor péntek óta nő.

Rögzítse együtt a relayt, a szállítást, a tűzfalszabályt és az élettartamot. Az a négy együtt írja le az elrendezést; bármelyikük önmagában csak egy találgatást ír le.