Postfix, VPN i smarthost: red nije firewall

Držanje pošte u redu dok se VPN ne podigne je problem zakazivanja, a uobičajeno rešenje je zaustaviti Postfix, zameniti main.cf i ponovo ga pokrenuti. To radi i pogrešnog je oblika, jer meša dva zahteva: kada isporuku treba pokušati i koji mrežni put je može nositi. Drugi je odluka firewalla i nijedna Postfix direktiva je ne može doneti. Kad se dva razdvoje, svaki ima mali i proverljiv odgovor.

Držite odredište relayja stabilnim, blokirajte direktnu isporuku na mrežnoj granici i pustite red da čeka.

Dva zahteva koja ljudi spajaju u jedan

Relay govori Postfixu gde predati poštu; relayhost = [smtp.corp.example]:587 imenuje host i port, a zagrade potiskuju MX-bazirani izbor za taj sledeći skok. Put govori kernelu kuda paketi smeju ići. Ispravan relayhost bez ograničenja puta i dalje pušta Postfix direktno na internet kada to routing tabela dopušta, a ispravan firewall s pogrešnim relayhostom šalje poštu na pogrešno mesto. Nijedno ne podrazumeva drugo.

Transport mape, izuzeci po pošiljaocu i rezervni relayji zaslužuju isto čitanje. Stabilan relayhost nije dokaz da svaka konfigurisana ruta isporuke koristi njega, a rezervni put koji zaobilazi relay ista je greška u boljoj kamuflaži.

Šta defer_transports zapravo radi

defer_transports zadržava poruke za imenovane transporte tako da se nijedan pokušaj isporuke ne izvodi dok ih prolaz reda ne dotakne. To je kontrola zakazivanja, a pražnjenje reda je nadjačava; to je dizajn, a ne defekt. Koristite stvarne nazive transporta iz master.cf, jer prilagođeni transport ili zasebno imenovan relay transport nije pokriven samo zato što i njegov program govori SMTP. Običan ponovni pokušaj je drugi mehanizam: uz fail-closed put, pokušaji isporuke jednostavno ne uspevaju i ostaju u redu, bez uključene direktive odgađanja.

Trajne greške ne čekaju pristojno. Loš primalac ili odbijena akreditacija vraćaju se ili zapnu kao tvrda greška umesto da sede dok se tunel ne pojavi, pa red pun odložene pošte nije automatski siguran red.

Nametnite put na mrežnom sloju

Ograničenje pripada granici lokalnog izlaza ili unutar izolovanog mrežnog namespacea. Mora pokriti stvarne adrese relayja, transport i port, uključujući IPv6 ako je omogućen, jer pravilo koje blokira TCP 25 ne čini ništa za relay na 587 ili 465. Držite loopback i lokalne puteve predaje odvojenim da sam red nastavi raditi. Politika treba ostati zatvorena kada ruta tunela nestane ili se ponovo pojavi pod drugim imenom interfejsa.

Događaj podizanja interfejsa ne dokazuje da je relay kroz njega dostupan. Zato je hook koji proveri vezu i zatim isprazni red pogodnost, a ne garancija: veza se može promeniti između provere i pokušaja isporuke.

Dokažite to jednom bezazlenom porukom

Pošaljite jednu bezazlenu poruku s isključenim VPN-om, zatim pregledajte postqueue -p za razlog odgađanja i ID reda. Vratite predviđeni put i zatražite kontrolisani prolaz reda, gledajući da li poruka odlazi kroz relay, a ne negde drugde. Zatim ponovo prekinite put usred leta i potvrdite da se poruka vraća u red. Pregledajte maximal_queue_lifetime pre nego što odlučite koliko prekid može trajati, jer nula znači jedan pokušaj, a ne neograničeno zadržavanje.

Nadzirite starost reda i korišćenje diska. Politika koja čeka VPN pretvara se u poštanski prekid ako niko ne primeti da red raste od petka.

Zabeležite relay, transport, firewall pravilo i životni vek zajedno. Ta četiri opisuju uređenje; bilo koje samo za sebe opisuje nagađanje.