Postfix, VPN och en smarthost: en kö är inte en brandvägg

Att hålla post i kön tills VPN:en kommer upp är ett schemaläggningsproblem, och den vanliga lösningen är att stoppa Postfix, byta main.cf och starta det igen. Det fungerar, och det är fel form, eftersom det blandar två krav: när leverans ska försökas, och vilken nätverksväg som får bära den. Det andra är ett brandväggsbeslut, och ingen Postfix-direktiv kan fatta det. När de två skiljs har var och en ett litet och testbart svar.

Håll relaymålet stabilt, blockera direkt leverans vid nätverksgränsen och låt kön göra väntan.

Två krav som människor smälter samman till ett

Relayn berättar för Postfix vart posten ska lämnas; relayhost = [smtp.corp.example]:587 anger en värd och en port, där hakparenteser undertrycker MX-baserat val för det nästa hoppet. Vägen berättar för kärnan vart paketen får gå. En korrekt relayhost utan vägbegränsning låter ändå Postfix nå internet direkt när routingtabellen råkar tillåta det, och en korrekt brandvägg med fel relayhost skickar posten till fel ställe. Ingen av dem förutsätter den andra.

Transportkartor, åsidosättningar per avsändare och reservrelayer förtjänar alla samma läsning. En stabil relayhost är inte bevis för att varje konfigurerad leveransväg använder den, och en reservväg som kringgår relayn är samma fel i bättre kamouflage.

Vad defer_transports faktiskt gör

defer_transports håller kvar meddelanden för de namngivna transporterna, så inget leveransförsök görs förrän en körning av kön rör dem. Det är en schemaläggningskontroll, och en kötömning åsidosätter den; det är designen och inte en defekt. Använd de riktiga transportnamnen från master.cf, för en anpassad transport eller en separat namngiven relaytransport täcks inte bara för att programmet också talar SMTP. Vanligt nytt försök är en annan mekanism: med en fail-closed väg misslyckas leveransförsöken helt enkelt och stannar i kön, utan något uppskjutningsdirektiv.

Permanenta fel väntar inte artigt. En dålig mottagare eller en avvisad inloggning studsar eller fastnar som ett hårt fel i stället för att sitta till tunneln dyker upp, så en kö full av uppskjuten post är inte automatiskt en säker kö.

Tvinga fram vägen i nätverkslagret

Begränsningen hör hemma vid gränsen för lokalt utflöde eller inne i ett isolerat nätverksnamnrum. Den måste täcka relayns verkliga adresser, transport och port, inklusive IPv6 om det är aktiverat, eftersom en regel som blockerar TCP 25 inte gör något för en relay på 587 eller 465. Håll loopback och lokala insändningsvägar åtskilda så att kön själv fortsätter att fungera. Policyn bör förbli stängd när tunnelvägen försvinner eller dyker upp igen under ett annat gränssnittsnamn.

En händelse där gränssnittet kommer upp bevisar inte att relayn går att nå genom det. Därför är en hook som kontrollerar länken och sedan tömmer kön en bekvämlighet och inte en garanti: länken kan ändras mellan kontrollen och leveransförsöket.

Bevisa det med ett enda ofarligt meddelande

Skicka ett ofarligt meddelande med VPN:en nere och undersök sedan postqueue -p för uppskjutningsorsaken och kö-ID:t. Återställ den avsedda vägen och begär en kontrollerad körning av kön, och se om meddelandet går ut genom relayn och inte någon annanstans. Bryt sedan vägen igen mitt i flykten och bekräfta att meddelandet återvänder till kön. Gå igenom maximal_queue_lifetime innan du bestämmer hur länge ett avbrott får vara, eftersom ett värde på noll betyder ett försök och inte obegränsat bevarande.

Övervaka köns ålder och diskanvändning. En policy som väntar på VPN:en blir ett postavbrott om ingen märker att kön har vuxit sedan fredag.

Registrera relayn, transporten, brandväggsregeln och livslängden tillsammans. De fyra beskriver arrangemanget; var och en av dem för sig beskriver en gissning.