De la mano de Oscar Mas nos llega este magnífico tutorial sobre como usar Split Domain Routing, muy útil y valioso.
Hoy tengo el gusto de explicaros, un procedimiento que he estado usando durante muchos años, llamado Split Domian Routing (SDR). El sistema nos permite tener buzones de correo distribuidos entre dos servidores de correo diferentes. Los buzones de correo se pueden mover entre los servidores independientemente, con lo cual conseguimos hacer movimientos de buzones entre dos sistemas de una manera más manejable, que cuando hemos de hacer una migración clásica. Aunque esta técnica no es muy utilizada, se suele usar cuando necesitamos mantener algunos buzones de correo en un servidor durante un tiempo indeterminado, mientras realizamos una migración hacia un nuevo servidor. Para realizar este procedimiento, es necesario tener una buena base de DNS y de cómo funciona la capa de SMTP en un sistema de correo
Funcionamiento del sistema de entrada de correo
- El mensaje llega a nuestro servidor SMTP, enviamos dos mails para poder ver el flujo de correo. Un mensaje a un buzón que está alojado en el primer servidor ([email protected]) y un segundo mensaje que está alojado en nuestro servidor de Zimbra ([email protected])
- Si el mensaje que recibe el primer servidor tiene un buzón, lo entrega a su destinatrio y se queda en el punto 2. Este sería el caso de [email protected].
- En caso de no existir el buzón en el servidor ([email protected]) , nuestro servidor hará un forwarding a un dominio ficticio (ilba.zcs) que conocen los dos servidores ([email protected]) y lo entregará a nuestro servidor de Zimbra. Esté volverá a hacer un forwarding y entregará el mensaje a [email protected]
Funcionamiento del sistema de salida de correo
Lo interesante de este sistema, es que cada servidor es independiente a la hora de enviar correos. El primer sistema enviará correos mediante su servidor de SMTP al exterior y nuestro sistema de Zimbra, enviará correos mediante su sistema de SMTP al exterior.
Inconveniente del sistema:
- Si el servidor donde está alojada la cuenta de [email protected] , le pasase alguna cosa, el servidor de Zimbra dejaría de recibir correo, ya que toda la recepción está basada en este primer servidor.
- La administración es compleja a consecuencia de los saltos que da el correo entre servidores.
Ventajas del sistema:
- Si al primer servidor donde está alojada la cuenta de [email protected] , le pasase alguna cosa, los usuarios que están en el servidor de Zimbra tardarían en enterarse, ya que el sistema de salida de correo es independiente. Ellos seguirían funcionando y solamente se darían cuenta de lo sucedido cuando intenten enviar un mail a una cuenta que esté alojada en el servidor que hace de recepción de correo (FrontEnd)
- Se reduce el coste de licencias de la plataforma de GroupWare, ya que solo pagamos por los usuarios que realmente necesitan una sincronización completa.
- En cualquier momento podemos pasar una cuenta de un sistema con POP3/IMAP simple, a un sistema avanzado de GroupWare. Y al revés lo mismo
Con este sistema conseguiremos dos cosas:
- Hacer una migración no agresiva
- Reducir el coste de implementación
Hacer una migración no agresiva
La verdadera funcionalidad de este sistema, es hacer una migración paulatina desde un servidor SMTP ya sea Exchange, Postfix, SendMail, Scalix, etc.. a otra plataforma SMTP, en nuestro caso el servidor de destino final, será Zimbra.
Reducir el coste de implementación
Imaginaros, que la migración de plataforma nunca se acabase y los dos sistemas estuvieran funcionando en perfecta armonía. Realmente cuando implementas un sistema de correo con las características de Groupware, no todo el mundo necesita sincronización de Agendas, Contactos, etc… ni tampoco todo el mundo necesita sincronizar su correo con sus dispositivos móviles. Como norma general solamente un porcentaje muy bajo necesita todas las funcionalidades que nos ofrecen estos sistemas. La idea es montar de FrontEnd un sistema totalmente gratuito como podría ser un ISPConfig, Postfix, etc… y como BackEnd un sistema de Zimbra. Con esto conseguimos que la recepcionista que simplemente necesita un sistema de correo POP3 o IMAP, pueda trabajar en una plataforma totalmente gratuita y gerencia, la cual necesita de sincronización y compartición de elementos, pueda trabajar en una plataforma que le ofrece todas las ventajas de Zimbra.
Si queréis más documentación sobre el funcionamiento y las diferentes posibilidades de configurar un Split Domain, Zimbra tiene en su wiki una documentación muy buena: http://wiki.zimbra.com/wiki/
Procedimiento
Para realizar el procedimiento, usaremos ISPConfig ( http://www.ispconfig.org ) , que es un sistema CPanel tipo Plesk, totalmente gratuito y desarrollado por HowtoForge (http://www.howtoforge.com ). El cual desde un panel web, nos permitirá gestionar las cuentas de correo, DNS, WEB, FTP, etc….. Es un sistema estable basado en sistemas opensource y totalmente modular, que permite sistemas de HA, Activo/Pasivo, etc….
En este caso, hemos usado como servidor principal un ISPConfig (FrontEnd) y de secundario un servidor de Zimbra (BackEnd), pero el procedimiento también se podría haber realizado de manera inversa; servidor principal Zimbra (FrontEnd) y de secundario el ISPConfig (BackEnd)
La capa de transporte entre los dos servidores, se usará el protocolo standard SMTP (TCP 25) , aunque lo ideal (aunque más complejo) sería usar el protocolo LMTP (TCP 7025). LMTP, es el protocolo que usan los servidores de Zimbra, cuando tenemos configurado un sistema MultiServer para entregarse los mails entre ellos, ya que es más ligero que el SMTP. 
Hemos de tener en cuenta, que todo el correo entrará por el servidor de ISPConfig, por tanto imaginemos que tenemos 100 cuentas de correo. De las cuales 75 serán POP3 o IMAP y 25 han de ser cuentas de Zimbra. Hemos de crear 75 cuentas en el servidor de ISPConfig y 25 forwardings en el servidor de ISPConfig, con esto conseguiremos que el tráfico fluya correctamente. Cabe destacar, que las 25 cuentas a las cuales les haremos el forwarding, se reeenviaran a un dominio ficticio llamado: ilba.zcs
Primero crearemos el dominio ilba.cat:
Posteriormente crearemos el buzón POP3 o IMAP, que está alojado en el servidor de ISPConfig:
Crearemos el forwarding de la cuenta de [email protected] a [email protected], para que lo entregue en nuestro servidor de Zimbra. En este paso es donde hacemos el cambio del dominio real (ilba.cat) al dominio ficticio (ilba.zcs). A consecuencia de este cambio de dominio, el sistema se vuelve complejo de administrar.
En este punto del procedimiento, muchos clientes me indican si se podría hacer un CathAll, lo que sería aceptar todas las cuentas para poder eliminar este paso. Pero esta forma de trabajar, es inviable, ya que sino cualquier mail que se entregase al servidor sería aceptado y nuestro servidor sería pasto de spammers.
Para que el servidor de ISPConfig pueda enviar los mails al servidor de Zimbra, necesitamos crear un puntero MX:
Y que este puntero resuelva la IP de nuestro servidor de Zimbra:
En nuestro panel de ISPConfig, lo haríamos de la siguiente manera:
Una vez realizadas las configuraciones en nuestro servidor de ISPConfig, necesitamos realizar el procedimiento en nuestro servidor de Zimbra, para que acepte el dominio ficticio (ilba.zcs) y lo traduzca al dominio correcto (ilba.cat)
Observamos que solamente tenemos creada la cuenta de [email protected] en nuestro servidor de Zimbra:
Creamos el alias de dominio de ilba.zcs hacia ilba.cat:
Creamos el alias, que nos aceptará la cuenta de [email protected], la cual se transformará en [email protected]:
Realizaremos la comprobación de flujo de correo, enviando un mail a [email protected] y observaremos como el mensaje llega a nuestro servidor de ISPConfig, el cual lo transforma al dominio ficticio [email protected] y es enviado al servidor de Zimbra y este lo recibe y lo vuelve a transformar en un mensaje con destino a [email protected]:
1.- Enviamos el mail a [email protected] via telnet al servidor de ISPConfig:
[root@fw ~]# telnet 192.168.100.21 25 Trying 192.168.100.21... Connected to 192.168.100.21. Escape character is '^]'. 220 opensource.ilba.cat ESMTP Postfix helo opensource.ilba.cat 250 opensource.ilba.cat mail from: [email protected] 250 2.1.0 Ok rcpt to: [email protected] 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> Prueba de SDR . 250 2.0.0 Ok: queued as 83FF7100A2D
2.- El servidor de ISPConfig, recibe el mail y lo transforma en el dominio ficticio, que es enviado a nuestro servidor de Zimbra:
Jan 7 17:29:14 opensource postfix/smtpd[3758]: connect from unknown[192.168.100.1] Jan 7 17:29:38 opensource postfix/smtpd[3758]: 83FF7100A2D: client=unknown[192.168.100.1] Jan 7 17:29:44 opensource postfix/cleanup[3769]: 83FF7100A2D: message-id=<> Jan 7 17:29:44 opensource postfix/qmgr[1599]: 83FF7100A2D: from=<[email protected]>, size=201, nrcpt=1 (queue active) Jan 7 17:29:45 opensource postfix/smtp[3771]: 83FF7100A2D: to=<[email protected]>, orig_to=<[email protected]>, relay=mail.ilba.zcs[192.168.100.20]:25, delay=15, delays=13/0.04/0.32/1.1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A312A2413BE) Jan 7 17:29:45 opensource postfix/qmgr[1599]: 83FF7100A2D: removed
3.- Y por ultimo, el servidor de Zimbra recibe el mensaje con destino a [email protected] y lo transforma en [email protected]:
Jan 7 17:29:45 zimbra postfix/smtpd[32513]: disconnect from unknown[192.168.100.21] Jan 7 17:29:46 zimbra postfix/qmgr[4527]: A312A2413BE: from=<[email protected]>, size=513, nrcpt=1 (queue active) Jan 7 17:29:46 zimbra postfix/dkimmilter/smtpd[32541]: connect from localhost.localdomain[127.0.0. 1] Jan 7 17:29:46 zimbra postfix/dkimmilter/smtpd[ 32541]: D03DB2413C8: client=localhost.localdomain[ 127.0.0.1] Jan 7 17:29:46 zimbra postfix/cleanup[32537]: D03DB2413C8: message-id=<20140107162945. [email protected]> Jan 7 17:29:47 zimbra postfix/qmgr[4527]: D03DB2413C8: from=<[email protected]>, size=978, nrcpt=1 (queue active) Jan 7 17:29:47 zimbra postfix/smtp[32538]: A312A2413BE: to=<[email protected]>, orig_to=<[email protected]>, relay=127.0.0.1[127.0.0.1]: 10026, delay=1.6, delays=0.45/0.16/0.06/0.96, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10030): 250 2.0.0 Ok: queued as D03DB2413C8) Jan 7 17:29:47 zimbra postfix/qmgr[4527]: A312A2413BE: removed Jan 7 17:29:47 zimbra postfix/amavisd/smtpd[32547]: connect from localhost.localdomain[127.0.0. 1] Jan 7 17:29:47 zimbra postfix/amavisd/smtpd[32547]: E148E2413BE: client=localhost.localdomain[ 127.0.0.1] Jan 7 17:29:47 zimbra postfix/cleanup[32537]: E148E2413BE: message-id=<20140107162945. [email protected]> Jan 7 17:29:48 zimbra postfix/qmgr[4527]: E148E2413BE: from=<[email protected]>, size=1648, nrcpt=1 (queue active) Jan 7 17:29:48 zimbra postfix/smtp[32543]: D03DB2413C8: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]: 10032, delay=1.3, delays=0.25/0.06/0.05/0.97, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as E148E2413BE) Jan 7 17:29:48 zimbra postfix/qmgr[4527]: D03DB2413C8: removed Jan 7 17:29:48 zimbra postfix/lmtp[32548]: E148E2413BE: to=<[email protected]>, relay=zimbra.ilba.cat[192.168. 100.20]:7025, delay=0.65, delays=0.19/0.05/0.01/0.4, dsn=2.1.5, status=sent (250 2.1.5 Delivery OK)
Podremos observar vía webmail que hemos recibido el mensaje:
Ahora lo que nos queda por configurar y verificar es que cuando [email protected] que está ubicado en el servidor de Zimbra, envíe un mail a la cuenta [email protected] que está en nuestro servidor de ISPConfig, el servidor de Zimbra, se dé cuenta de que no está en el sistema y lo envie al ISPConfig. Procederemos de la siguiente manera:
[root@zimbra ~]# su - zimbra [zimbra@zimbra ~]$ zmprov md ilba.zcs zimbraMailCatchAllAddress @ilba.cat [zimbra@zimbra ~]$ zmprov md ilba.zcs zimbraMailCatchAllForwardingAddress @ilba.cat [zimbra@zimbra ~]$ zmprov md ilba.cat zimbraMailTransport smtp:192.168.100.21
Ahora simplemente enviaremos un mensaje desde nuestro servidor de Zimbra desde la cuenta de [email protected] a la de [email protected], para ver como se recibe el correo en el servidor de ISPConfig, el flujo de correo sería el siguiente
Observaremos los logs que nos muestra el servidor de Zimbra al enviar el mail:
Jan 7 21:41:46 zimbra postfix/smtpd[21745]: connect from zimbra.ilba.cat[192.168.100.20] Jan 7 21:41:46 zimbra postfix/smtpd[21745]: NOQUEUE: filter: RCPT from zimbra.ilba.cat[192.168.100. 20]: <[email protected]>: Sender address triggers FILTER smtp-amavis:[127.0.0.1]:10026; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<zimbra.ilba.cat> Jan 7 21:41:46 zimbra postfix/smtpd[21745]: 48C0224142F: client=zimbra.ilba.cat[192. 168.100.20] Jan 7 21:41:46 zimbra postfix/cleanup[21759]: 48C0224142F: message-id=<1385775649.5. 1389127305905.JavaMail.zimbra@ ilba.cat> Jan 7 21:41:46 zimbra postfix/qmgr[4527]: 48C0224142F: from=<[email protected]>, size=1188, nrcpt=1 (queue active) Jan 7 21:41:46 zimbra postfix/smtpd[21745]: disconnect from zimbra.ilba.cat[192.168.100. 20] Jan 7 21:41:47 zimbra postfix/dkimmilter/smtpd[ 21763]: connect from localhost.localdomain[127.0.0. 1] Jan 7 21:41:47 zimbra postfix/dkimmilter/smtpd[ 21763]: 10AF8241430: client=localhost.localdomain[ 127.0.0.1] Jan 7 21:41:47 zimbra postfix/cleanup[21759]: 10AF8241430: message-id=<1385775649.5. 1389127305905.JavaMail.zimbra@ ilba.cat> Jan 7 21:41:47 zimbra postfix/qmgr[4527]: 10AF8241430: from=<[email protected]>, size=1653, nrcpt=1 (queue active) Jan 7 21:41:47 zimbra postfix/dkimmilter/smtpd[ 21763]: disconnect from localhost.localdomain[127.0.0. 1] Jan 7 21:41:47 zimbra postfix/smtp[21760]: 48C0224142F: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]: 10026, delay=1.1, delays=0.19/0/0.21/0.66, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10030): 250 2.0.0 Ok: queued as 10AF8241430) Jan 7 21:41:47 zimbra postfix/qmgr[4527]: 48C0224142F: removed Jan 7 21:41:48 zimbra postfix/amavisd/smtpd[21810]: connect from localhost.localdomain[127.0.0. 1] Jan 7 21:41:48 zimbra postfix/amavisd/smtpd[21810]: 8C2A324142F: client=localhost.localdomain[ 127.0.0.1] Jan 7 21:41:48 zimbra postfix/cleanup[21759]: 8C2A324142F: message-id=<1385775649.5. 1389127305905.JavaMail.zimbra@ ilba.cat> Jan 7 21:41:48 zimbra postfix/qmgr[4527]: 8C2A324142F: from=<[email protected]>, size=2221, nrcpt=1 (queue active) Jan 7 21:41:48 zimbra postfix/amavisd/smtpd[21810]: disconnect from localhost.localdomain[127.0.0. 1] Jan 7 21:41:48 zimbra postfix/smtp[21765]: 10AF8241430: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]: 10032, delay=1.7, delays=0.26/0/0.15/1.3, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8C2A324142F) Jan 7 21:41:48 zimbra postfix/qmgr[4527]: 10AF8241430: removed Jan 7 21:41:54 zimbra postfix/smtp[21942]: 8C2A324142F: to=<[email protected]>, relay=192.168.100.21[192.168. 100.21]:25, delay=5.6, delays=0.16/0.09/5.2/0.15, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D7BD81009FD) Jan 7 21:41:54 zimbra postfix/qmgr[4527]: 8C2A324142F: removed
Observamos como el servidor de ISPConfig recibe el mail:
Jan 7 21:41:51 opensource postfix/smtpd[1600]: 32CE31009FD: client=unknown[192.168.100.20] Jan 7 21:41:51 opensource postfix/cleanup[1797]: 32CE31009FD: message-id=<654436432.3.1389127241571.JavaMail.zimbra@ ilba.cat> Jan 7 21:41:51 opensource postfix/qmgr[1500]: 32CE31009FD: from=<[email protected]>, size=2408, nrcpt=1 (queue active) Jan 7 21:41:51 opensource postfix/smtpd[1600]: disconnect from unknown[192.168.100.20] Jan 7 21:41:51 opensource dovecot: auth: mysql: Connected to localhost (dbispconfig) Jan 7 21:41:52 opensource dovecot: lda([email protected]): sieve: msgid=<654436432.3. 1389127241571.JavaMail.zimbra@ ilba.cat>: stored mail into mailbox 'INBOX' Jan 7 21:41:52 opensource postfix/pipe[1798]: 32CE31009FD: to=<[email protected]>, relay=dovecot, delay=1, delays=0.33/0.07/0/0.63, dsn=2.0.0, status=sent (delivered via dovecot service) Jan 7 21:41:52 opensource postfix/qmgr[1500]: 32CE31009FD: removed Jan 7 21:41:53 opensource postfix/smtpd[1787]: connect from unknown[192.168.100.20] Jan 7 21:41:53 opensource postfix/smtpd[1787]: D7BD81009FD: client=unknown[192.168.100.20] Jan 7 21:41:53 opensource postfix/cleanup[1797]: D7BD81009FD: message-id=<1385775649.5. 1389127305905.JavaMail.zimbra@ ilba.cat> Jan 7 21:41:54 opensource postfix/qmgr[1500]: D7BD81009FD: from=<[email protected]>, size=2403, nrcpt=1 (queue active) Jan 7 21:41:54 opensource postfix/smtpd[1787]: disconnect from unknown[192.168.100.20] Jan 7 21:41:54 opensource dovecot: lda([email protected]): sieve: msgid=<1385775649.5. 1389127305905.JavaMail.zimbra@ ilba.cat>: stored mail into mailbox 'INBOX' Jan 7 21:41:54 opensource postfix/pipe[1798]: D7BD81009FD: to=<[email protected]>, relay=dovecot, delay=0.44, delays=0.14/0/0/0.3, dsn=2.0.0, status=sent (delivered via dovecot service) Jan 7 21:41:54 opensource postfix/qmgr[1500]: D7BD81009FD: removed
Nada más, espero que os sirva de ayuda y muchas gracias por leer el Blog
Hola chicos,
Buenísimo como siempre el artículo. Gracias por compartir! 🙂
Me gustaría agregar para quienes no estén familiarizados con SMTP que se trata de un protocolo “lineal” por decirlo de alguna forma. Donde existe un único servidor “autoritativo” para un dominio determinado. El servidor autoritativo es el que marca el final de la cadena y quien se encarga de decir que una determinada cuenta no existe.
Para los casos de split-domain, lo que se hace básicamente es hacer que el servidor que recibe los correos no sea autoritativo, por lo que intentará reenviar los correos de las cuentas que no conoce a otro servidor (el cual indicamos con un conector SMTP). El último servidor de la cadena, sí debe ser autoritativo para el dominio puesto que en caso de haberle llegado un mensaje, es porque la cuenta no existía en ningún otro servidor y si él mismo no tiene esa cuenta, debería ser capaz de devolver un “imposible entregar el correo: la cuenta no existe”.
Saludos!
Sebas
Muchas gracias por la aclaración Sebastián, un saludo enorme, seguro que a nuestros amigos lectores les viene perfecto 🙂
Felicidades por este artículo, está muy bien explicado.
Sabes si con Zimbra 7 funciona igual o hay grandes diferencias, hasta donde yo sé los alias de dominio no se pueden hacer desde el interfaz Web de administración pero si desde el CLI.
Por otro lado, añadir que la wiki de Zimbra recomienda usar el servidor principal como MTA Relay del secundario para evitar descartes de correo por comprobaciones de MX/SPF:
http://wiki.zimbra.com/wiki/Split_Domain#Configuring_Zimbra_as_the_Secondary_System
Hola Toni
Te agradezco el comentario. En Zimbra 7 funciona igual, de hecho aún tengo Split Domain Routing con versiones de Zimbra 7.
Puedes usar el Zimbra en primera instancia o en segunda, pero yo prefiero usar un servidor de postfix instalado por mí, delante del servidor de Zimbra, ya que la mayoría de los usuarios estarán en ese servidor y ahorras tráfico. Piensa que en el Zimbra solamente pondrás gente VIP que quiere integración total con Outlook, Movile Device, etc……
Un saludo
Estimado Jorge,
Muchas veces se usa esta configuración para migrar entre servidores de correo, como seria las instrucciones para revertir, el re envio del servidor Zimbra, me refiero específicamente:
[zimbra@zimbra ~]$ zmprov md ilba.zcs zimbraMailCatchAllAddress @ilba.cat
[zimbra@zimbra ~]$ zmprov md ilba.zcs zimbraMailCatchAllForwardingAddress @ilba.cat
[zimbra@zimbra ~]$ zmprov md ilba.cat zimbraMailTransport smtp:192.168.100.21
Como las revertimos cuando ya no las necesitemos??
gracias Excelente post. Luis
Hola Jorge, antes que nada te felicito por todos tus aportes que haces a la comunidad; quiero aprovechar para comentarte que estoy planeando una migración de un servidor de correo de Zimbra 7.2.6 a 8.6 open source y me insteresaría hacerlo con un dns split con dos servidores para no hacer una migración agresiva nada mas que no conozco esto del split dns routing, ¿Tienes alguna sugerencia?
De antemano muchas gracias!!!
Saludos David,
No hace falta Split DNS para esto, tienes la herramienta de Zimbra que funciona muy bien – http://wiki.zimbra.com/index.php?title=Zimbra_to_Zimbra_Migration lo unico que esta herramienta no migra los recursos del dominio ni los filtros de los usuarios, pero todo lo demas lo hace perfecto.
Un saludo
Muchas gracias Jorge, una disculpa por mi mala educación y no contestar a la brevedad posible, ya ando revisando eso y lo estoy probando en un laboratorio de pruebas, espero que todo salga a la perfección.
Saludos!!!
Hola a todos. El problema que le veo a esta solución (si no la he entendido mal) es que cuando la implementas es que el ISP rechaza el correo que viene de zimbra (el de [email protected]) según tu ejemplo con un: Client host rejected: Access denied (in reply to RCPT TO command)) No sé si a vosotros os funciona siempre pero yo intenté hacer una migración desde Arsys y no hubo forma.
Hola Jorge,
Antes que nada te queria agradecer todo lo que haces por la comunidad. Estoy migrando a servidores Zimbra y tus explicaciones son un gran apoyo.
Te queria consultar, una vez que migro un dominio entero, como revierto la entrega al servidor viejo?
Gracias
Saludos Diego,
Cuando todo esta ya migrado, debes apuntar el MX al nuevo server y ya estaría, quizás no te comprendí bien.
Un saludo
Jorge,
Si, eso ya lo hice, yo me referia a los siguientes comandos
[zimbra@zimbra ~]$ zmprov md ilba.zcs zimbraMailCatchAllAddress @ilba.cat
[zimbra@zimbra ~]$ zmprov md ilba.zcs zimbraMailCatchAllForwardingAddress @ilba.cat
[zimbra@zimbra ~]$ zmprov md ilba.cat zimbraMailTransport smtp:192.168.100.21
Saludos,.
Saludos. Buenos aportes.
Puedo aplicar este esquema para una migración Progresiva desde in Exchange?
Es decir, mantener un tiempo ambos servidores (Exchange y zimbra), e ir creando las cuentas en zimbra. Aqui el caso el el dominio @dominio serán idénticos.
Es decir que [email protected] al ser creado en zimbra, debe ser eliminado en exchange, pero al serl el exchange el mta principal, el debe saber que si le llega un correo buscando [email protected] el sepa que antes de rebotarlo pase al zimbra buscando la cuenta.
Hice esto hace tiempo pero entre servidores de correo linux, y todo lo hice con query de ldap.
Aqui todo gira en torno al exchange.
Aunque en zimbra tambien debe saber que cuando envie correo a una cuenta que no estan en el zimbra pero si en el exchange, pase el mensaje al exchange.
Respecto a buzones distribuido en zimbra, existe algun link que me pueda guiar.
Señores.
Es posible mantener un sistema de correo hibrido entre servidor zimbra ver 8.8.6 primario y office365 secundario y cuales son los procedimientos en zimbra para mantener esta estructura.
la versión de Zimbra ver 8.8.6 que utilizo es libre (no es licenciada).
Se agradece su orientación.
Saludos,
Si sigues los pasos aqui descritos seguramente puedas conseguir lo que necesitas. Un saludo
Estimado Jorge:
Al igual que JoseP tengo mi servidor de correos primario en Exchange 2013 (dominio.com) y quiero migrar a Zimbra de una forma NO Agresiva deberia usar esta opcion de split de dominio para que ambos coexistan? ya tengo montado mi servidor de zimbra montado (correo.dominio.com) y no se como seguir avanzando en esta tarea, por favor si puedes guiarme por el camino correcto te lo agradecería.
Muchas gracias por todos los aportes que manas realmente son valiosos.
Saludos.
Saludos Israel,
SDR es una opción sin duda, sigue los pasos y dinos que tal va.
Un saludo
Felicidades por tu Blog Jorge. Gran Aporte. Si algún día decides iniciar algo con Bacula, puedes contar comigo.
Una pregunta, es un despliegue distribuido. (mta-proxy-ldap-mailbox) por separado. Tengo un detalle donde los ultimos usuarios creados no se sincronizan. Me explico en ldap y mailbox zmprov -l gaa me enseña unos 20 usuarios. Dicho comando en mta y proxy solo me muestra 15. Esos 5 que faltan, no pueden recibir correo externo. Sin embargo funcionan sin problemas a nivel interno.
He estado buscando si existe algun comando que force la actualizacion o la lectura LDAP, pero nada que doy con el clave. Te ha ocurrido algo asi? que pudiera ser?
De antemano muchas gracias.
Saludos.
Joel Seijas
Jorge
Buen dia .. mil gracias por tus enormes aportes ..
Te escribo porque estoy algo confundido .. lo que sucede es que tengo un Zimbra Open como servidor y necesito migrar 200 cuentas con el mismo dominio a O365, comprendo el tuto .. pero mis preguntas van hacias el dns publico .. pues para poner a funcionar el dominio en O635 me pide crear unos txt y mx en dns donde tengo el dominio y temo que pueda romper la estabilidad del servicio de zimbra que ya esta implementado …
Me podrias aclarar que puedo hacer sin afectar el servicio que actualmente esta corriendo ?
Estoy verdaderamente atento ..!
Hola Jorge, soy nueva en la administración en Zimbra, no sé si me puedas dar una mano.
Actualmente llevo la administración de dos servidores de correo: aaa.com y bbb.com
desde el servidor bbb.com no puedo recibir correos de aaa.com pero si puedo hacer el envío de estos con a la recepción correcta. Por un tema de saturación se reinició el servidor aaa.com, es posible que se haya borrado alguna configuración…
Que tal Jorge, antes que todo, muchas gracias por la info…
Quizas alguien me pueda ayudar, estoy con un hibrido de o365 y zimbra, puedo enviar correos desde zimbra internos a o365 y fuera del dominio, para recibir solo zimbra interno, no recibe de o365 ni exterior.
Al generar el conector desde o365 a zimbra y validar, se conecta al servidor:
“connect from mail-cys01nam02lp2054.outbound.protection.outlook.com[104.47.37.54]”
“Anonymous TLS connection established from mail-cys01nam02lp2054.outbound.protection.outlook.com”
pero inmediatamente se desconecta
“disconnect from mail-cys01nam02lp2054.outbound.protection.outlook.com”
Y el conector en 0365 me indica:
{LED=550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient [email protected] not found by SMTP address lookup
Saludos Nacho
Buenos días @OscarMas @JorgeDeLaCruz
Tengo funcionando mi Zimbra como Relay para todos los servicios, como escaners, recibos de nomina, etc., las cuentas corporativas están en GSuite, y por razones de seguridad tengo DMARC y mi zimbra envía los correos de los servicios con cuentas autenticadas e identificadas con el dominio para firmar con su llave DKIM, todo funciona perfecto, pero ahora tengo un problema, que no es de zimbra, pero quiero saber si les ha pasado y cómo lo han resuelto.
Al hacer el split domain uso como transporte aspmx.l.google.com para los dominios en GSuite que coinciden con los de zimbra, es decir, esta configuración:
zmprov md example.com zimbraMailCatchAllAddress @example.com
$ zmprov md example.com zimbraMailCatchAllForwardingAddress @example.com
$ zmprov md example.com zimbraMailTransport smtp:aspmx.l.google.com
El problema es que por ejemplo cuando uno de mis servicios envían correo a múltiples dominios y usan la pasarela de google por el tema del split, entonces tengo un rechazo en google del estilo:
“Multiple destination domains per transaction is unsupported”
“relay=aspmx.l.google.com[74.125.141.26]:25, delay=6.1, delays=0.01/0.01/5.9/0.2, dsn=4.3.0, status=deferred (host aspmx.l.google.com[74.125.141.26] said: 451-4.3.0 Multiple destination domains per transaction is unsupported. Please 451 4.3.0 try again. n9si397918vsp.255 – gsmtp (in reply to RCPT TO command))”
Conocen alguna solución o workarround para este problema que evidentemente ocasiona Google por la configuración de su MTA.
Saludos.
Buenas noches
Me gustaría saber si se puede configurar dos servidor zimbra uno con la versión open source (S1) y el otro con la versión zimbra network edition (S2) que se comuniquen los entre los dos ademas que cuando envie el servidor (S1) sea el (S2) quien envié los correos.
Muchas gracias por su ayuda
Excelente articulo.
Tengo un caso, servidor principal es un postfix, los servidores secundarios un zimbra 6, un zimbra 8 y 3 postfix.
Los correos ya entra y salen a dominios internos, pero la falla radica que cuando envío correo a los buzones que están en otros servidores internos, rebotan.
Att.
PAUL CRIOLLO
PERU
Buenos días Jorge de la Cruz, cordial saludo.
En las empresas donde administro el departamento TICS he implementado el servidor de correo con la plataforma de zimbra, ha sido una excelente experiencia. Me gustaría saber como puedo manejar dose servidores zimbra de forma pararalela, con el mismo domino pero en dos servidores fisicamente independientes y con ips publicas dsitintas. Esta consulta en con el fin de poder garantizar el serivicio de correo en las empresas, en caso de que falle un servidor tener un secundario de respaldo y que el servicio se pueda seguir dando.
Quedo atento a su amable respuesta.
Nelson Espinosa
Colombia.