Un MX secundario es un servidor de correo (MTA) de respaldo que entra en funcionamiento cuando el MTA principal está caído, inaccesible o fuera de servicio. A diferencia de un servidor de DNS secundario, que es imprescindible, muchos dominios carecen de registro MX secundario, confiando en el buen funcionamiento de los servidores de correo que, si no encuentran disponible el servidor de destino, seguirán reintentándolo durante un periodo de tiempo. Transcurrido ese periodo de tiempo (que puede variar mucho en función de la configuración), devolverán el correo al usuario remitente con un error.
En nuestro caso, en lugar de confiar en que otros MTAs estén bien configurados y lo reintenten durante el tiempo suficiente, montaremos un MTA secundario para que, en caso de que nuestro MTA principal esté inaccesible (por las razones que sean), acepte correos destinados a dominios del MTA principal y los mantenga en su cola todo el tiempo que sea necesario hasta que el MTA principal esté de nuevo operativo. Cuando esté de nuevo operativo, el MTA secundario se los entregará al MTA principal para que los haga llegar al destinatario de forma transparente.
Este servidor secundario NO proporciona alta disponibilidad, pues los usuarios de nuestro servicio de correo no podrán ni enviar ni recibir hasta que el servidor principal esté de nuevo funcionando.
Para asegurarnos de que una posible caída de red o avería del CPD no afecta a los dos MTA a la vez (pues entonces de nada nos serviría tener un secundario), es conveniente que el MTA secundario se encuentre en otro CPD. ¿Y cómo saben entonces los MTAs remitentes que deben enviar el correo a nuestro MTA secundario? Mediante la resolución DNS. Por tanto, el primer paso es añadir un nuevo registro MX a nuestro servidor DNS. Así:
somewhere.com. 86400 IN MX 5 mail.somewhere.com. somewhere.com. 86400 IN MX 10 mail-bck.somewhere.com.
Es fundamental que demos a nuestro MX principal una prioridad mayor (5) que el MX secundario (10).
El resultado de la resolución DNS deberá ser algo como esto:
$ host -t MX somewhere.com somewhere.com mail is handled by 5 mail.somewhere.com. somewhere.com mail is handled by 10 mail-bck.somewhere.com.
Al enviar alguien un correo a una cuenta de nuestro dominio, el MTA del remitente tratará de hacerlo al MX del destinatario con mayor prioridad ('mail.somewhere.com'). Si este no se encuentra disponible, lo intentará con el que se indica como secundario ('mail-bck.somewhere.com').
Una vez entendido el propósito del MX secundario, el proceso de configuración es sencillo y solo afecta al MTA secundario, en nuestro caso Postfix. Simplemente tendremos que configurarlo de modo que acepte como destino el dominio o dominios respaldados (esto se logra añadiéndolo(s) a la directiva relay_domains). Para ello, nos aseguramos de incluir las siguientes directivas en /etc/postfix/main.cf:
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination relay_domains = $mydestination, somewhere.com relay_recipient_maps =
Es fundamental que nuestro dominio respaldado (“somewhere.com”) NO aparezca en las directivas mydestination virtual_alias_domains o virtual_mailbox_domains.
Una vez efectuados los cambios reiniciamos Postfix y ya deberíamos tenerlo listo.
En nuestro caso usamos spamd(8) en nuestro MTA principal. Se trata de un proxy SMTP que, usando reglas de PF (el potente firewall de OpenBSD), usa diferentes estrategias para evitar el email falso (tarpitting, listas grises, spamtrap, etc.). Si no pasa los filtros, los servidores ilegítimos ni siquiera llegarán a hablar nunca con el MTA, lo cual le descarga enormemente de trabajo y aligera el uso de costosos chequeos en el nivel de aplicación (spamd en cambio es ligero, trabaja a bajo nivel, sin apenas repercutir en el rendimiento de la máquina). spamd es una joya para cualquier administrador de sistemas que deba lidiar con un servidor de correo en producción. Una de sus funcionalidades es que permite sincronizarse en tiempo real con otros servidores, transfiriéndose entre sí las base de datos de listas grises y entradas greytrapped (conexiones listadas en la lista gris que envían a direcciones-trampa creadas para atrapar a spammers, que son enviados temporalmente a la lista negra y nunca podrán alcanzar el MTA). Para ello, como indica la completísima página ''man'', se usan los parámetros -Y o -y con los que invocamos a spamd. Se puede usar multicast o unicast. Este ejemplo, envía mensajes multicast a través del interfaz de red em0:
# /usr/libexec/spamd -y em0 -Y em0
En nuestro caso utilizaremos unicast hacia un único target (nuestro secundario):
# /usr/libexec/spamd -y em0 -Y mail-bck.somewhere.com
Para que el cambio pase a producción (en el arranque), modificamos nuestro /etc/rc.conf.local añadiendo los nuevos flags:
En el servidor primario:
spamd_flags="-4 -G 15:4:864 -h mail.somewhere.com -l127.0.0.1 -n \"Sendmail 8.11.4/8.11.1\" -S10 -s1 -v -w1 -Y mx-bck.somewhere.com"
con -Y indicamos el demonio spamd asociado (pueden ser varios). La opción -G es muy importante pues define el comportamiento del greylisting: passtime:greyexp:whiteexp (en este ejemplo, 15 minutos para que una IP pueda pasar el greylisting, con independencia de los reintentos, 4 horas para que expire de la lista gris y 864 horas para que expire de la lista blanca).
En el servidor secundario:
spamd_flags="-v -G 15:4:864 -w 1 -y em0 -Y mail.somewhere.com"
Nota: las entradas blanqueadas (whitelisted) o las que hemos introducido a mano en la base de datos con spamdb(8) no se sincronizarán.
Un conocido truco de los spammers es dirigirse directamente al MX secundario, en lugar de tratarlo de hacerlo en primer lugar al MX principal. spamd tiene la capacidad de detectarlo. Si un MTA intenta conectarse con nuestro MX en el orden equivocado (out-of-order), podemos estar bastante seguros de que están tratando de entregar correo no deseado.
Basta con utilizar el parámetro -M en las opciones de inicio de spamd, indicando la IP de un servidor MX secundario (el de menos prioridad). Cualquier host que intente entregar correo y no cumpla la tupla (o no esté en las listas grises sincronizadas) será atrapado durante las 24 horas siguientes por spamd.
Y eso es todo. Ahora, para testearlo, detenemos el MTA principal y a continuación enviamos un correo (foobar@gmail.com en este ejemplo) a nuestro dominio (usuario@somewhere.com). En los logs del MTA secundario deberíamos ver que recibe el correo, lo encola e intenta reenviárselo a nuestro primario:
Feb 1 13:06:24 mail-bck postfix/smtpd[742]: 264E53D4: client=mail-bk0-f51.google.com[209.85.214.51] Feb 1 13:06:24 mail-bck postfix/cleanup[32755]: 264E53D4: message-id=<CALGNg1eQv_1wJNSUhXRzzaYcyN1UeNneo8MC9ne4VaEskwtW9g@mail.gmail.com> Feb 1 13:06:24 mail-bck postfix/qmgr[31619]: 264E53D4: from=<foobar@gmail.com>, size=1535, nrcpt=1 (queue active) Feb 1 13:06:24 mail-bck postfix/smtpd[742]: disconnect from mail-bk0-f51.google.com[209.85.214.51] Feb 1 13:06:24 mail-bck postfix/smtp[5838]: connect to mail.somewhere.com[1.2.3.4]:25: Connection refused
En la última línea el MTA secundario intenta conectarse con el primario, sin éxito (no está accesible).
Así que lo guarda en su cola de correo:
Feb 1 13:06:54 mail-bck postfix/smtp[5838]: 264E53D4: to=<usuario@somewhere.com>, relay=none, delay=30, delays=0.11/0.01/30/0, dsn=4.4.1, status=deferred (connect to mail.somewhere.com[1.2.3.4]:25: Operation timed out)
Cuando de nuevo levantemos el MTA primario, el secundario le entregará el correo (“relay”):
Feb 1 13:08:17 mail-bck postfix/qmgr[31619]: 264E53D4: from=<foobar@gmail.com>, size=1535, nrcpt=1 (queue active) Feb 1 13:08:18 mail-bck postfix/smtp[5838]: 264E53D4: to=<usuario@somewhere.com>, relay=mail.somewhere.com[1.2.3.4]:25, delay=114, delays=114/0.01/0.09/0.18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D380542F044) Feb 1 13:08:18 mail-bck postfix/qmgr[31619]: 264E53D4: removed
Con un MTA secundario configurado como respaldo del primario y situado en una ubicación física distinta, no dependeremos en caso de caída o problemas de red de los reintentos del MTA remoto, ni por tanto perderemos ningún correo.
Conviene aclarar que el papel de este servidor secundario NO es dotar al servicio de correo de alta disponibilidad, pues los usuarios de nuestro servicio de correo no podrán ni enviar ni recibir hasta que el servidor principal esté de nuevo funcionando. Lo que evita son rebotes o pérdidas de correo.