Tutorial de Sendmail - Sitios con mas de un servidor

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.)