Postfix, VPN un smarthost: rinda nav ugunsmūris

E-pasta turēšana rindā, līdz paceļas VPN, ir plānošanas problēma, un ierastais risinājums ir apturēt Postfix, nomainīt main.cf un palaist to no jauna. Tas darbojas, un tā ir nepareizā forma, jo tā sajauc divas prasības: kad jāmēģina piegāde un kurš tīkla ceļš to drīkst nest. Otrā ir ugunsmūra lēmums, un neviena Postfix direktīva to nevar pieņemt. Kad abas ir atdalītas, katrai ir maza un pārbaudāma atbilde.

Turiet relay galamērķi stabilu, bloķējiet tiešu piegādi tīkla robežā un ļaujiet rindai gaidīt.

Divas prasības, ko cilvēki sapludina vienā

Relay pasaka Postfix, kur nodot e-pastu; relayhost = [smtp.corp.example]:587 norāda resursdatoru un portu, un iekavas nomāc MX balstītu izvēli nākamajam lēcienam. Ceļš pasaka kodolam, kur pakešu sūtīšana atļauta. Pareizs relayhost bez ceļa ierobežojuma joprojām ļauj Postfix tieši sasniegt internetu, kad maršrutēšanas tabula to atļauj, un pareizs ugunsmūris ar nepareizu relayhost sūta e-pastu nepareizajā vietā. Neviens no tiem neizriet no otra.

Transporta kartes, pārraksti pa sūtītājiem un rezerves relay ir katra tā paša lasījuma cienīgas. Stabils relayhost nav pierādījums, ka katrs konfigurētais piegādes ceļš to izmanto, un rezerves ceļš, kas apiet relay, ir tā pati kļūda labākā maskējumā.

Ko defer_transports patiešām dara

defer_transports aiztur ziņojumus norādītajiem transportiem, tāpēc piegādes mēģinājums netiek veikts, kamēr rindas gājiens tiem nepieskaras. Tas ir plānošanas kontrole, un rindas iztukšošana to pārspēj; tas ir dizains, nevis defekts. Izmantojiet īstos transportu nosaukumus no master.cf, jo pielāgots transports vai atsevišķi nosaukts relay transports netiek ietverts tikai tāpēc, ka tā programma arī runā SMTP. Parastais atkārtotais mēģinājums ir cits mehānisms: ar fail-closed ceļu piegādes mēģinājumi vienkārši neizdodas un paliek rindā, bez atlikšanas direktīvas.

Pastāvīgas kļūdas negaida pieklājīgi. Slikts saņēmējs vai noraidīti akreditācijas dati atgriežas vai iestrēgst kā cieta kļūda, tā vietā lai sēdētu, līdz parādās tunelis, tāpēc rinda, kas pilna ar atliktu e-pastu, nav automātiski droša rinda.

Pieprasiet ceļu tīkla slānī

Ierobežojums pieder pie vietējās izvades robežas vai izolētas tīkla nosaukumvietas. Tam jāaptver īstās relay adreses, transports un ports, tostarp IPv6, ja tas ir iespējots, jo noteikums, kas bloķē TCP 25, neko nedara relay uz 587 vai 465. Turiet loopback un vietējos iesniegšanas ceļus atsevišķi, lai pati rinda turpinātu darboties. Politikai vajadzētu palikt slēgtai, kad tuneļa maršruts pazūd vai atkal parādās citā saskarnes nosaukumā.

Saskarnes pacelšanās notikums nepierāda, ka relay ir sasniedzams caur to. Tāpēc āķis, kas pārbauda saiti un pēc tam iztukšo rindu, ir ērtība, nevis garantija: saite var mainīties starp pārbaudi un piegādes mēģinājumu.

Pierādiet to ar vienu nekaitīgu ziņojumu

Nosūtiet vienu nekaitīgu ziņojumu ar izslēgtu VPN, pēc tam pārbaudiet postqueue -p attiecībā uz atlikšanas iemeslu un rindas ID. Atjaunojiet paredzēto ceļu un pieprasiet kontrolētu rindas gājienu, vērojot, vai ziņojums iziet caur relay, nevis kur citur. Pēc tam atkal pārtrauciet ceļu lidojuma vidū un apstipriniet, ka ziņojums atgriežas rindā. Pārskatiet maximal_queue_lifetime, pirms lemjat, cik ilgi pārtraukums var ilgt, jo nulles vērtība nozīmē vienu mēģinājumu, nevis neierobežotu glabāšanu.

Uzraugiet rindas vecumu un diska lietojumu. Politika, kas gaida VPN, pārvēršas pasta pārtraukumā, ja neviens nepamana, ka rinda aug kopš piektdienas.

Pierakstiet relay, transportu, ugunsmūra noteikumu un mūžu kopā. Šie četri raksturo izvietojumu; jebkurš no tiem atsevišķi raksturo minējumu.