
Tengo un escenario donde tengo:
- Servidor Postfix M (almacena correo)
- Servidor Postfix A (Retransmite correo mediante conexión a Internet IA)
- Servidor Postfix B (Retransmite correo mediante conexión a Internet IB)
- Servidor DNS interno (realiza resolución de nombres local)
Los servidores M, A y B residen en la misma red LAN, lo que significa que incluso cuando las conexiones a Internet IA e IB se caen, la comunicación entre M & A y M & B no necesariamente se cortará, por lo que no puedo usar la opción smtp_fallback_relay de Postfix. para esto.
Ahora, necesito que el servidor M envíe solo al servidor que tendrá conexión a Internet en el momento de la retransmisión.
¿Cómo podemos hacer esto mejor?
lo que intentamos
Mi colega y yo compartimos dos alternativas (no exhaustiva):
- Cree el script para desconectar los correos de retransmisión de la "LAN" en la percepción del almacén de correo (M), de modo que vuelva a su retransmisión alternativa.
- Cree un script en el servidor dns (D) {o en etc. hosts en M, lo que sea mejor, pero DNS esencial para M}, que altere mail-relay.ourdomain.com para que apunte al servidor de correo A o B que tiene Internet. acceso con un TTL lo suficientemente pequeño (digamos 5 segundos)
Ambas opciones funcionan en su mayor parte, lo que necesito es por qué no funcionarían (¿hay algún peligro al usar una de ellas)?
Respuesta1
El problema para cualquiera de los enfoques escondición de carrera, es decir, su Internet estaba funcionando. A o B reconocen la entrega exitosa pero, cuando A o B intentaron reenviarlo a Internet, la conexión se perdió.
El escenario anterior fue posible debido a la forma en que fluye el correo electrónico en Postfix.
Email from client ---> Received ---> Queued -> Sent
Postfix en el servidor A enviará un acuse de recibo a M de que A aceptó el correo electrónico cuando el correo electrónico esté en cola. Por lo tanto, es posible que cuando Postfix intente enviar un correo electrónico a Internet, la conexión se corte y su correo electrónico quede en cola hasta que se restablezca la conexión.
Nota: Este comportamiento era el esperado en un MTA típico. Recuerde que SMTP esalmacenamiento y reenvioprotocolo.