Si nuestro servidor de email de pronto sufre un desperfecto, nuestros mensajes de email no podrán salir. Esto es grave, pero se puede suplir con llamadas telefónicas u otros medios.
Sin embargo, más grave es el no responder a los mensajes que nos envían. En ciertos casos, los servidores remotos intentarán reenviarnos los mensajes (durante cierto tiempo.) En otros, puede que esto nunca ocurra y que los mensajes "reboten" inmediatamente. En cualquier caso, es muy grave el hecho de perder estos mensajes. Aquí analizaremos algunas medidas destinadas a contrarrestar estos inconvenientes.
Si nuestro servidor de email deja de operar por un problema (cualquiera) del computador, una forma de mantener el servicio consiste en disponer de un servidor de respaldo ubicado al interior de nuestra organización el cual puede continuar recibiendo los mensajes que nos envían.
Esto es relativamente sencillo de implementar añadiendo una entrada en el DNS:
@ MX 10 mailserver1 MX 20 mailserver2
Aquí mailserver1 es el servidor "normal" que recibe los mensajes, mientras que mailserver2 es el "backup". Esta configuración ocasionará que los mensajes que llegan del exterior y no pueden ser enviados a mailserver1 sean enviados a mailserver2.
Frecuentemente estos servidores guardarán los mensajes en las casillas de email de los usuarios destinatarios respectivos, a fin de que éstos los recojan vía protocolos POP o IMAP. El problema es que la mayoría de clientes de email POP/IMAP sólo se pueden configurar para acceder a un servidor a la vez.
En otras palabras, si mailserver1 deja de operar y mailserver2 toma la posta, entonces todos los usuarios de la red local deberán ser reconfigurados para que apunten a mailserver2.
Esto puede ser aceptable en ciertas circunstancias, como en el caso de tener pocos clientes.
A fin de evitar esto, es posible hacer algunos artificios asumiendo que mailserver1 está inoperativo.
Si nuestros clientes están apuntando a mailserver1 mediante su dirección IP, entonces se puede asociar temporalmente esta dirección IP a mailserver2 por medio de un "IP virtual" o "IP alias".
Si nuestros clientes están apuntando a mailserver1 mediante su nombre (vía DNS) entonces se puede modificar temporalmente la configuración del DNS para que mailserver1 apunte al IP de mailserver2 (cambiar el registro A.)
Con esto los clientes accederán a mailserver2 de modo casi transparente... sin embargo, si usan IMAP y han creado carpetas en el servidor, obviamente estas carpetas no podrán verse (pues se quedaron en mailserver1.) Informe a sus usuarios de esta situación.
Otro inconveniente radica en el restablecimiento de mailserver1. Ciertos usuarios pueden haber dejado mensajes sin leer en mailserver2 que deberán ser trasladados manualmente a mailserver1 para que estén disponibles en su INBOX. Herramientas como fetchmail pueden ayudar en estos casos.
En general, si mailserver1 va a ser interrumpido por sólo unos minutos, es mejor que mailserver2 NO se haga cargo del email entrante por los inconvenientes señalados. Una solución más adecuada (y costosa) consiste en que ambos servidores compartan un área de almacenamiento externo compartido.
En el caso de que nuestra conexión a Internet se interrumpa, o en caso de un desastre general en nuestra organización, conviene disponder de un servidor ubicado en un lugar geográficamente distante y accesible mediante proveedores distintos (a fin de aumentar la redundancia.) En algunos casos, este servidor puede ser el de otra organización, con la que pactaremos este servicio.
A la configuración anterior del DNS, añadiremos otra línea:
@ MX 10 mailserver1 MX 20 mailserver2 MX 30 email-friend-store.com.Como se ve, una última opción de envío consiste en que los mensajes lleguen al servidor "email-friend-store.com". Normalmente este servidor rechazaría nuestros mensajes (pues nuestras direcciones terminan en @laorganizacion.org.) Pero, puesto que hemos hecho un acuerdo previo, en "email-friend-store.com" han añadido la siguiente línea en su archivo access:
laorganizacion.org RELAYAhora, en caso de que nuestra conexión se interrumpa, los MTA's remotos intentarán como última opción a email-friend-store.com, el cual recibirá nuestros mensajes y tratará (infructuosamente) de reenviarlos a nuestros servidores mailserver1 y mailserver2. Como no puede, los encolará y los intentará reenviar posteriormente (ver la sección dedicada al encolamiento para más información.)
En organizaciones muy grandes es frecuente que se establezcan áreas relativamente interdependientes pero separadas. Por ejemplo, geográficamente.
A fin de optimizar el rendimiento, el diseño de la configuración de email debe aprovechar estas características.
Supondremos que nuestra organización se llama "inkacoca" y que tiene sucursales en las ciudades de Lima, Trujillo, Cuzco, Iquitos y Puerto Maldonado. Asumimos que la organización ha adquirido la autoridad del dominio "inkacoca.org".
En ese sentido, una manera de operar sería crear los siguientes subdominios, que corresponderían a las direcciones email respectivas:
Tabla 1.
| Ciudad | Dominio | Dirección email |
|---|---|---|
| Lima | lima.inkacoca.org | usuario@lima.inkacoca.org |
| Trujillo | trujillo.inkacoca.org | usuario@trujillo.inkacoca.org |
| Cuzco | cuzco.inkacoca.org | usuario@cuzco.inkacoca.org |
| Iquitos | iquitos.inkacoca.org | usuario@iquitos.inkacoca.org |
| Puerto Maldonado | pmaldonado.inkacoca.org | usuarios@pmaldonado.inkacoca.org |
Luego se configurarían servidores de email independientes para cada ciudad. Desde el punto de vista del email, cada subdominio viene a ser una organización independiente. En cada servidor (en cada ciudad) el administrador crea sus propias cuentas independientes.
El DNS deberá contener entradas independientes para cada uno de estos servidores (aquí llamados lima-mail, tru-mail, cuzco-mail, iqui-mail, pto-mail.)
; archivo de zona de inkacoca.org lima IN MX 10 lima-mail lima-mail IN A 18.1.3.40 trujillo IN MX 10 tru-mail tru-mail IN A 18.1.4.40 cuzco IN MX 10 cuzco-mail cuzco-mail IN A 18.1.5.40 iquitos IN MX 10 iqui-mail iqui-mail IN A 18.1.6.40 pmaldonado IN MX 10 pto-mail pto-mail IN A 18.1.7.40
Los problemas de este esquema son:
No se está reflejando el dominio único de la organización (nadie tiene cuenta de la forma usuario@inkacoca.org)
Las direcciones de email son muy largas y difíciles de recordar
Tratemos de mejorar el esquema anterior. Intentemos que todas las direcciones sean de la forma usuario@inkacoca.org, manteniendo los cinco servidores en cada ciudad. El primer inconveniente de este esquema es que si tenemos dos usuarios llamados "diego" en Lima y Cuzco, y ambos originalmente tenían direcciones:
diego@lima.inkacoca.org diego@cuzco.inkacoca.orgahora habrá que buscar una forma de diferenciarlos. Por ejemplo, podríamos usar "diego1" y "diego2". Esto, si bien no es estéticamente agradable, puede ser mejorado con el uso de aliases u otra convención más creativa.
Ahora bien, si un mensaje llega desde el exterior a "usuario@inkacoca.org", ¿qué servidor lo recibe?
Una posibilidad es designar un servidor adicional (ubicado en cualquier ciudad) para que sirva como "switch", aunque podría ser cualquiera de los otros.
Este servidor deberá ser capaz de redirigir el mensaje al servidor adecuado. Es decir, deberá disponer de una tabla similar a:
Esto es precísamente lo que hace el archivo virtusertable que se discutió anteriormente en la sección "dominios virtuales".
Para esto, el archivo /etc/mail/virtusertable contendrá algo como:
diego1@incakoca.com diego1@lima.inkacoca.org diego2@incakoca.com diego2@cuzco.inkacoca.orgRecuérdese que se debe generar la versión "compilada" como se vio anteriormente.
Adicionalmente se requieren registros en el DNS para el "mail switch":
; archivo de zona de inkacoca.org @ IN MX 10 switch switch IN A 18.1.3.41 lima IN MX 10 lima-mail lima-mail IN A 18.1.3.40 trujillo IN MX 10 tru-mail tru-mail IN A 18.1.4.40 cuzco IN MX 10 cuzco-mail cuzco-mail IN A 18.1.5.40 iquitos IN MX 10 iqui-mail iqui-mail IN A 18.1.6.40 pmaldonado IN MX 10 pto-mail pto-mail IN A 18.1.7.40
Todo esto permite que los mensajes destinados con @incakoca.org lleguen al servidor de correo local que les corresponde.
Los problemas pendientes son:
Cada administrador local debe notificar al administrador del switch de que se ha creado un usuario local a fin de que se le registre en virtusertable; se pierde independencia y no hay una forma sencilla de evitar esto, salvo quizá desarrollando un aplicativo adicional para automatizar el proceso.
Si se envía un mensaje desde Iquitos a otro usuario en Iquitos usando su dirección email "usuario@inkacoca.org", el mensaje (de acuerdo al DNS) irá primero al switch central de la organización y luego retornará a Iquitos. Esto es correcto pero ineficiente.
Sería deseable que si el usuario destinatario es local al remitente, entonces el mensaje no tenga que viajar hasta el switch. Esto se puede conseguir operando en la configuración de virtusertable de los servidores regionales. El contenido deberá ser como sigue:
usuario_x@inkacoca.org usuario_x@localhost usuario_y@inkacoca.org usuario_x@localhost usuario_z@inkacoca.org usuario_x@localhost ... @incacoca.org %1@switch.incacoca.orgDonde usuario_x, usuario_y, etc. son los usuarios locales a este servidor. Esto origina que los mensajes dirigidos a éstos sean tratados como locales (el dominio @localhost corresponde al propio computador.) El resto de mensajes con destino de la forma X@inkacoca.org se envía al switch central para su posterior procesamiento.
Para que esto funcione, el servidor local deberá reconocer como suyo el dominio "inkacoca.org" (agregarlo en /etc/local-host-names.)
El inconveniente que surge ahora es que los mensajes no locales se redirigen al switch ya no con "@inkacoca.org" sino con "@switch.inkacoca.org", por lo que esto debe configurarse en el /etc/local-host-names del switch. Asimismo se requiere agregar una línea a su archivo virtusertable con lo que quedará del siguiente modo:
diego1@incakoca.com diego1@lima.inkacoca.org diego2@incakoca.com diego2@cuzco.inkacoca.org ... # Linea agregada: @switch.inkacoca.org %1@inkacoca.orgEsto retorna las direcciones "X@switch.inkacoca.org" a la forma "X@inkacoca.org". De no agregarse esta línea, el switch no sabría a dónde enviar los mensajes de la forma "X@swith.inkacoca.org" pues todas las redirecciones se han hecho a partir de la forma original "X@inkacoca.org" como se ve arriba.