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 | [email protected] |
| Trujillo | trujillo.inkacoca.org | [email protected] |
| Cuzco | cuzco.inkacoca.org | [email protected] |
| Iquitos | iquitos.inkacoca.org | [email protected] |
| Puerto Maldonado | pmaldonado.inkacoca.org | [email protected] |
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 [email protected])
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 [email protected], 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:
[email protected] [email protected]ahora 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 "[email protected]", �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:
[email protected] [email protected] [email protected] [email protected]Recu�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 "[email protected]", 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:
[email protected] usuario_x@localhost [email protected] usuario_x@localhost [email protected] usuario_x@localhost ... @incacoca.org %[email protected]Donde 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 [email protected] 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:
[email protected] [email protected] [email protected] [email protected] ... # Linea agregada: @switch.inkacoca.org %[email protected]Esto retorna las direcciones "[email protected]" a la forma "[email protected]". De no agregarse esta l�nea, el switch no sabr�a a d�nde enviar los mensajes de la forma "[email protected]" pues todas las redirecciones se han hecho a partir de la forma original "[email protected]" como se ve arriba.