Dos servidores Exim y redirecciones

Dos servidores Exim y redirecciones

Es un asunto un poco confuso que intento resolver, así que necesito pedirles ayuda.

Nuestros usuarios están divididos entre dos grandes edificios, que están lejos uno del otro, por lo que configuramos dos servidores de correo independientes para que cada servidor sirva correo para su edificio. El objetivo principal es que, en caso de pérdida de conectividad, los usuarios puedan enviar correo a sus colegas dentro de su propio edificio, incluso si el correo externo no está disponible temporalmente. Cada edificio utiliza su propio dominio de correo. La configuración es trivial y funciona bien.

Para fines de lucha contra el spam y también para fines administrativos, tenemos la misma tabla de usuarios (completa) en cada servidor, pero cada casilla está marcada como "B1" o "B2" para indicar en qué edificio se encuentra el usuario determinado. Solíamos almacenar tablas de buzones de correo y redireccionamientos en tablas SQL, por lo que no hay problema para distinguirlos agregando la condición "WHERE which_server='B1'" a las líneas de configuración exim.

Lo inesperado es la duplicación de correo cuando hablamos de redireccionamientos/alias. Aquí está el ejemplo:

digamos usuariousuario1enEdificio 1usa buzón[correo electrónico protegido], mientras que el usuariousuario2enedificio 2usa buzón[correo electrónico protegido]. Hasta el momento no hay problema, pueden enviarse correos entre sí y los usuarios externos también pueden contactar con ellos por correo.

Imaginemos ahora que agregamos algunas redirecciones en cada servidor de correo. Di así:

[correo electrónico protegido]->[correo electrónico protegido],[correo electrónico protegido],[correo electrónico protegido]

Ahora como correo de[correo electrónico protegido]va a[correo electrónico protegido], el servidor de correo en el servidor1 hará tres copias y lo enviará como tres mensajes separados (dos irán al servidor de b2.domain.com, uno irá a los servidores de Gmail). Ahora, cuando estos mensajes lleguen al servidor de b2.domain.com, realizará la redirección nuevamente (usando sus propias tablas SQL), duplicando así los mensajes.

Siento que me pierdo alguna forma elegante de resolver esto, ¿podría indicarme la manera correcta?

¡Gracias de antemano!

Respuesta1

Tiene un indicador poderoso que no está utilizando al analizar la expansión de su tabla de alias: si el correo electrónico proviene del mundo exterior o si proviene del otro edificio (uno o más nombres de host o IP). Si el problema es que la expansión de alias en B1 falla de forma duplicada cuando se envía desde B2, omita la expansión de alias si la fuente es B2. En una ACL, esto se haría con un hosts = !+B2, sin embargo, en su caso, los enrutadores son donde necesita tomar esta decisión. Para hacer esto, configuraría en la ACL de conexión o en la ACL de correo:

warn hosts = +B2
     set acl_c_other_building = 1

Luego, en el enrutador de alias, puede agregar la condición de que, si es del otro edificio, devuelva falso/no:

condition = ${if eq{$acl_c_other_building}{1} {no}{yes}}

Con esta lógica implementada, presumiblemente los siguientes enrutadores son los que manejan la entrega del buzón y entregarán ese mensaje localmente.

Si funciona como se esperaba, haga lo contrario en el otro edificio.

Respuesta2

Su principal problema parece ser un entorno de correo inconsistente. Por un lado, trata a los dos servidores como servidores internos idénticos (mismas reglas de alias), por otro lado, solo son responsables de un dominio, lo que hace que se traten entre sí como cualquier otro servidor de correo remoto, por lo que es probable que se produzcan duplicaciones de redireccionamiento. .

En lugar de intentar manejar esta configuración distribuida en el nivel de enrutamiento MTA, le sugiero que proporcione a ambos servidores la misma configuración de dominio, lo que significa que ambos servidores traten sus dominios como locales y los entreguen a buzones de correo locales y luego repliquen estos buzones entre los servidores, por ejemplo usando dovecot'sreplicación maestro-maestro

información relacionada