.png)
Estoy intentando configurar un servidor de correo para un dominio compartido: la mitad de los buzones de correo están alojados en Gmail y la otra mitad en un servidor local.
Instalé iRedMail 1.6.0 y configuré Gmail para enviar todos los usuarios de @example.com no resueltos al servidor local. Funcionó cuando el remitente no era @example.com... si lo era, el correo era rechazado debido a la conexión no autenticada. Agregar todas las subredes de Gmail a mynetworks (tanto en main.cf como en settings.py) resolvió este problema (¿alguna solución mejor?).
El verdadero problema era hacer que los correos salieran del sufijo local cuando el buzón estaba alojado de forma remota.
Tuve que crear un mapa de buzones de correo virtual con la lista de buzones de correo remotos (solución terrible) para pasar el comando "rcpt to:". Aún así, después de un tiempo recibí un informe que no se pudo entregar:
Acción: fallido Estado: 5.1.1 Código de diagnóstico: x-unix; usuario desconocido
Después de algunas dificultades, descubrí que agregar también un mapa de transporte con aproximadamente los mismos datos del mapa del buzón virtual (en el mapa de transporte también tengo la regla de transporte local) hizo que el problema desapareciera y los correos fluyeran correctamente.
Ahora, usar 2 listas de direcciones diferentes para el mismo trabajo es aún más terrible. Estoy buscando una solución más elegante como "reenviar cualquier correo electrónico @example.com no resuelto a ...", como lo hice en Gmail. ¿Cualquier sugerencia?
gracias dario
Respuesta1
Si configuró el dominio comolocaldominio local (novirtual), puedes intentar usarfallback_transporto fallback_transport_maps. Configúrelo así (en main.cf):
fallback_transport = smtp:gmail.com
(Hará la búsqueda MX para gmail.com y utilizará el resultado de esa búsqueda; supongo que las listas de servidores MX para su dominio alojado en Gmail y para las direcciones de gmail.com son las mismas). Considere leerhombre 5 transportesi desea explorar más el formato de la parte derecha de esto.
Su idea de "enviar todo lo no resuelto a Gmail" en las instalaciones y "todo lo no resuelto a las instalaciones" en el lado de Gmail es muy mala. Si algún mensaje no se resuelve en ambos lados, hará ping-pong indefinidamente y, finalmente, su servidor será prohibido en Gmail. Para evitar esto, debe mantener dos listas: en Gmail necesita conocer la lista exacta de direcciones de correo que residen en las instalaciones, y en las instalaciones necesita conocer la lista exacta de direcciones de correo que residen en Gmail. Úselo fallback_transport_mapsde tal manera que para los buzones de correo remotos conocidos devolverá lo mismo que sugerí anteriormente, y los desconocidos no devolverán nada, lo que hará que Postfix rechace el correo antes de tiempo. Siempre debes rechazar lo antes posible, esto es lo bueno del correo electrónico. Y es mejor que Gmail solo reenvíe el correo que realmente tiene en sus instalaciones, por la misma razón. No te quejes, este es el precio por tener una configuración así.
Si tienes unvirtualsetup, puede intentar utilizarlo transport_mapspara este propósito, pero debe hacerlo con mucha precaución. No cree un relé abierto.
Otro problema con esta solución es que algunos de sus remitentes pueden tener una política DMARC restrictiva (que esbien, Ojalá más remitentes hicieran eso; habrá mucho menos correo no deseado en Internet). Es poco probable que incluyan su servidor como autorizado para enviar correo en su nombre en el registro SPF, por lo que si dicho correo ingresa a su servidor y decide redirigirlo a Gmail, Gmailvoluntadrecházalo y no podrás hacer nada con eso y punto. Esto no tiene solución, que yo sepa.