Postfix, VPN y un smarthost: la cola no es un cortafuegos

Mantener el correo en cola hasta que suba la VPN es un problema de programación, y la solución habitual es detener Postfix, cambiar main.cf y volver a arrancarlo. Eso funciona y es la forma equivocada, porque mezcla dos requisitos: cuándo debe intentarse la entrega y qué ruta de red puede llevarla. El segundo es una decisión del cortafuegos, y ninguna directiva de Postfix puede tomarla. Una vez separados, cada uno tiene una respuesta pequeña y comprobable.

Mantenga estable el destino del relé, bloquee la entrega directa en el límite de red y deje que la cola haga la espera.

Dos requisitos que la gente funde en uno

El relé dice a Postfix dónde entregar el correo; relayhost = [smtp.corp.example]:587 nombra un host y un puerto, con corchetes que suprimen la selección por MX para ese siguiente salto. La ruta dice al núcleo adónde pueden ir los paquetes. Un relayhost correcto sin restricción de ruta sigue dejando que Postfix llegue a internet directamente cuando la tabla de rutas lo permite, y un cortafuegos correcto con un relayhost equivocado envía el correo al lugar equivocado. Ninguno implica al otro.

Los mapas de transporte, las excepciones por remitente y los relés de respaldo merecen la misma lectura. Un relayhost estable no es prueba de que toda ruta de entrega configurada lo use, y una ruta de respaldo que evita el relé es el mismo fallo con mejor camuflaje.

Qué hace realmente defer_transports

defer_transports retiene los mensajes para los transportes nombrados, de modo que no se hace ningún intento de entrega hasta que una pasada de cola los toca. Es un control de programación, y un vaciado de cola lo anula; eso es el diseño y no un defecto. Use los nombres reales de transporte de master.cf, porque un transporte personalizado o un transporte de relé con otro nombre no queda cubierto solo porque su programa también hable SMTP. El reintento ordinario es otro mecanismo: con una ruta fail-closed, los intentos de entrega simplemente fallan y se quedan en cola, sin ninguna directiva de aplazamiento.

Los fallos permanentes no esperan con educación. Un destinatario malo o una credencial rechazada rebotan o se quedan como error duro en lugar de aguardar a que aparezca el túnel, así que una cola llena de correo aplazado no es automáticamente una cola segura.

Exija la ruta en la capa de red

La restricción pertenece al límite de salida local o al interior de un espacio de nombres de red aislado. Debe cubrir las direcciones reales del relé, el transporte y el puerto, incluido IPv6 si está activado, porque una regla que bloquea TCP 25 no hace nada para un relé en 587 o 465. Mantenga separados el loopback y las rutas de envío local para que la propia cola siga funcionando. La política debería permanecer cerrada cuando la ruta del túnel desaparece o reaparece bajo otro nombre de interfaz.

Un evento de interfaz activa no demuestra que el relé sea alcanzable a través de ella. Por eso un hook que comprueba el enlace y luego vacía la cola es una comodidad y no una garantía: el enlace puede cambiar entre la comprobación y el intento de entrega.

Demuéstrelo con un mensaje inocuo

Envíe un mensaje inocuo con la VPN caída y luego revise postqueue -p por el motivo del aplazamiento y el ID de la cola. Restaure la ruta prevista y solicite una pasada de cola controlada, observando si el mensaje sale por el relé y no por otro sitio. Después rompa la ruta otra vez en pleno vuelo y confirme que el mensaje vuelve a la cola. Revise maximal_queue_lifetime antes de decidir cuánto puede durar una interrupción, porque un valor cero significa un intento y no una retención ilimitada.

Vigile la edad de la cola y el uso de disco. Una política que espera la VPN se convierte en una interrupción de correo si nadie nota que la cola lleva creciendo desde el viernes.

Registre el relé, el transporte, la regla del cortafuegos y la vida útil juntos. Esos cuatro describen el montaje; cualquiera de ellos por separado describe una conjetura.