Postfix, VPN i smarthost: red nije firewall

Držanje pošte u redu dok se VPN ne podigne je problem zakazivanja, a uobičajeno rješenje je zaustaviti Postfix, zamijeniti main.cf i ponovo ga pokrenuti. To radi i pogrešnog je oblika, jer miješa dva zahtjeva: 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 donijeti. Kad se dva razdvoje, svaki ima mali i provjerljiv odgovor.

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

Dva zahtjeva koja ljudi spajaju u jedan

Relay govori Postfixu gdje predati poštu; relayhost = [smtp.corp.example]:587 imenuje host i port, a zagrade potiskuju MX-bazirani odabir za taj sljedeći hop. Put govori kernelu kuda paketi smiju 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 mjesto. Nijedno ne podrazumijeva drugo.

Transportne 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 stvarna imena 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 uspijevaju i ostaju u redu, bez uključene direktive odgađanja.

Trajne greške ne čekaju pristojno. Loš primalac ili odbijeni akreditiv vraćaju se ili zapnu kao tvrda greška umjesto da sjede dok se tunel ne pojavi, pa red pun odgođ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 provjeri vezu i zatim isprazni red pogodnost, a ne garancija: veza se može promijeniti između provjere 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 negdje drugo. Zatim ponovo prekinite put usred leta i potvrdite da se poruka vraća u red. Pregledajte maximal_queue_lifetime prije nego 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štenje diska. Politika koja čeka VPN pretvara se u poštanski prekid ako niko ne primijeti da red raste od petka.

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