Postfix, VPN i smarthost: red nije vatrozid

Držanje pošte u redu dok se VPN ne podigne problem je zakazivanja, a uobičajeno rješenje je zaustaviti Postfix, zamijeniti main.cf i ponovno 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 vatrozida 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 izravnu 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 skok. Put govori kernelu kamo paketi smiju ići. Ispravan relayhost bez ograničenja puta i dalje pušta Postfix izravno na internet kada to routing tablica dopušta, a ispravan vatrozid s pogrešnim relayhostom šalje poštu na pogrešno mjesto. Nijedno ne podrazumijeva drugo.

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

Što 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 kvar. 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 drugi je 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š primatelj ili odbijena vjerodajnica 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 izoliranog 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 putove predaje odvojenima da sam red nastavi raditi. Politika treba ostati zatvorena kada ruta tunela nestane ili se ponovno pojavi pod drugim imenom sučelja.

Događaj podizanja sučelja ne dokazuje da je relay kroz njega dostupan. Zato je hook koji provjeri vezu i zatim isprazni red pogodnost, a ne jamstvo: 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 kontrolirani prolaz reda, gledajući odlazi li poruka kroz relay, a ne negdje drugdje. Zatim ponovno 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 nitko ne primijeti da red raste od petka.

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