===== Redundancia =====
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.
=== Un servidor local adicional ===
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.
=== Un servidor remoto ===
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 RELAY ||
Ahora, 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.)
