Postfix, VPN i un smarthost: la cua no és un tallafoc

Mantenir el correu en cua fins que pugi la VPN és un problema de planificació, i la solució habitual és aturar Postfix, canviar main.cf i tornar-lo a engegar. Això funciona i és la forma equivocada, perquè barreja dos requisits: quan s’ha d’intentar el lliurament i quin camí de xarxa el pot portar. El segon és una decisió del tallafoc, i cap directiva de Postfix la pot prendre. Un cop separats, cadascun té una resposta petita i comprovable.

Mantingueu estable la destinació del relé, bloquegeu el lliurament directe a la frontera de xarxa i deixeu que la cua faci l’espera.

Dos requisits que la gent fusiona en un

El relé diu a Postfix on ha de lliurar el correu; relayhost = [smtp.corp.example]:587 anomena un host i un port, amb claudàtors que suprimeixen la selecció per MX per a aquest salt següent. El camí diu al nucli on es permet que vagin els paquets. Un relayhost correcte sense restricció de camí encara deixa que Postfix arribi directament a internet quan la taula d’encaminament ho permet, i un tallafoc correcte amb un relayhost equivocat envia el correu al lloc equivocat. Cap dels dos implica l’altre.

Els mapes de transport, les excepcions per remitent i els relés de reserva mereixen la mateixa lectura. Un relayhost estable no és prova que tota ruta de lliurament configurada l’utilitzi, i una ruta de reserva que evita el relé és la mateixa fallada amb un millor camuflatge.

Què fa realment defer_transports

defer_transports reté els missatges per als transports anomenats, de manera que no es fa cap intent de lliurament fins que una passada de cua els toca. És un control de planificació, i un buidatge de cua el passa per sobre; això és el disseny, no un defecte. Feu servir els noms reals de transport de master.cf, perquè un transport personalitzat o un transport de relé amb un altre nom no queda cobert només perquè el seu programa també parla SMTP. El reintent ordinari és un mecanisme diferent: amb un camí fail-closed, els intents de lliurament simplement fallen i queden en cua, sense cap directiva d’ajornament implicada.

Les fallades permanents no esperen amb educació. Un destinatari dolent o una credencial rebutjada reboten o es queden com a error dur en lloc d’esperar que aparegui el túnel, així que una cua plena de correu ajornat no és automàticament una cua segura.

Forceu el camí a la capa de xarxa

La restricció pertany a la frontera de sortida local o dins d’un espai de noms de xarxa aïllat. Ha de cobrir les adreces reals del relé, el transport i el port, incloent-hi IPv6 si està activat, perquè una regla que bloqueja TCP 25 no fa res per a un relé al 587 o al 465. Mantingueu separats el loopback i els camins de submissió local perquè la cua mateixa segueixi funcionant. La política hauria de romandre tancada quan la ruta del túnel desapareix o reapareix sota un altre nom d’interfície.

Un esdeveniment d’interfície activa no demostra que el relé sigui abastable a través d’ella. Per això un hook que comprova l’enllaç i després buida la cua és una comoditat i no una garantia: l’enllaç pot canviar entre la comprovació i l’intent de lliurament.

Demostreu-ho amb un sol missatge innocu

Envieu un missatge innocu amb la VPN baixada, i després reviseu postqueue -p per la raó de l’ajornament i l’ID de la cua. Restabliu el camí previst i demaneu una passada de cua controlada, observant si el missatge surt pel relé i no per un altre lloc. Després trenqueu el camí de nou en ple vol i confirmeu que el missatge torna a la cua. Reviseu maximal_queue_lifetime abans de decidir quant pot durar una interrupció, perquè un valor zero significa un intent i no una retenció il·limitada.

Superviseu l’edat de la cua i l’ús de disc. Una política que espera la VPN es converteix en una interrupció de correu si ningú nota que la cua creix des de divendres.

Enregistreu el relé, el transport, la regla del tallafoc i la vida útil junts. Aquests quatre descriuen el muntatge; qualsevol d’ells sol descriu una conjectura.