Postfix, VPN e un smarthost: a cola non é un cortalumes

Manter o correo en cola ata que suba a VPN é un problema de planificación, e a solución habitual é deter Postfix, cambiar main.cf e volver arrincalo. Iso funciona e é a forma equivocada, porque mestura dous requisitos: cando se debe tentar a entrega e que ruta de rede pode levala. O segundo é unha decisión do cortalumes, e ningunha directiva de Postfix pode tomala. Unha vez separados, cada un ten unha resposta pequena e comprobable.

Manteña estable o destino do relé, bloquee a entrega directa na fronteira de rede e deixe que a cola faga a espera.

Dous requisitos que a xente funde nun

O relé di a Postfix onde entregar o correo; relayhost = [smtp.corp.example]:587 nomea un host e un porto, con corchetes que suprimen a selección por MX para ese seguinte salto. A ruta di ao núcleo onde poden ir os paquetes. Un relayhost correcto sen restrición de ruta segue deixando que Postfix chegue a internet directamente cando a táboa de rutas o permite, e un cortalumes correcto cun relayhost errado envía o correo ao lugar errado. Ningún implica o outro.

Os mapas de transporte, as excepcións por remitente e os relés de reserva merecen a mesma lectura. Un relayhost estable non é proba de que toda ruta de entrega configurada o use, e unha ruta de reserva que evita o relé é o mesmo fallo con mellor camuflaxe.

Que fai realmente defer_transports

defer_transports retén as mensaxes para os transportes nomeados, de xeito que non se fai ningún intento de entrega ata que unha pasada de cola os toca. É un control de planificación, e un baleirado de cola supérnao; iso é o deseño e non un defecto. Use os nomes reais de transporte de master.cf, porque un transporte personalizado ou un transporte de relé con outro nome non queda cuberto só porque o seu programa tamén fala SMTP. O reintento ordinario é outro mecanismo: cunha ruta fail-closed, os intentos de entrega simplemente fallan e quedan en cola, sen ningunha directiva de aprazamento.

Os fallos permanentes non esperan con educación. Un destinatario malo ou unha credencial rexeitada rebotan ou quedan como erro duro en lugar de agardar a que apareza o túnel, así que unha cola chea de correo aprazado non é automaticamente unha cola segura.

Impoña a ruta na capa de rede

A restrición pertence á fronteira de saída local ou ao interior dun espazo de nomes de rede illado. Debe cubrir os enderezos reais do relé, o transporte e o porto, incluído IPv6 se está activado, porque unha regra que bloquea TCP 25 non fai nada para un relé en 587 ou 465. Manteña separados o loopback e as rutas de envío local para que a propia cola siga funcionando. A política debería permanecer pechada cando a ruta do túnel desaparece ou reaparece baixo outro nome de interface.

Un evento de interface activa non demostra que o relé sexa alcanzable a través dela. Por iso un hook que comproba a ligazón e despois baleira a cola é unha comodidade e non unha garantía: a ligazón pode cambiar entre a comprobación e o intento de entrega.

Demóstroo cunha soa mensaxe inocua

Envíe unha mensaxe inocua coa VPN baixa e despois revise postqueue -p polo motivo do aprazamento e o ID da cola. Restaure a ruta prevista e solicite unha pasada de cola controlada, observando se a mensaxe sae polo relé e non por outro sitio. Despois rompa a ruta outra vez en pleno voo e confirme que a mensaxe volve á cola. Revise maximal_queue_lifetime antes de decidir canto pode durar unha interrupción, porque un valor cero significa un intento e non unha retención ilimitada.

Vixíe a idade da cola e o uso de disco. Unha política que agarda a VPN convértese nunha interrupción de correo se ninguén nota que a cola leva medrando desde o venres.

Rexistre o relé, o transporte, a regra do cortalumes e a vida útil xuntos. Eses catro describen a disposición; calquera deles por separado describe unha conxectura.