En mi anterior trabajo entre otras cosas era responsable del servidor de correo para un grupo de empresas, con unas 3000 cuentas repartidas entre unos 20 dominios y que recibía alrededor de 150.000 mails diarios, de los cuales más del 95% se desechaban por SPAM o virus (estos datos son de hace un año, no sé cómo habrá evolucionado la cantidad y tasa de SPAM desde entonces). Todo esto en un cluster que contaba por aquel entonces con siete servidores, que nos permitía escalar según las necesidades. Y basado en software libre.
Esto no es una guía de instalación con detalles técnicos y ficheros de configuración, si no más bien la historia de la evolución del servicio, los distintos problemas que fuimos encontrando, cómo se solucionaron, y las decisiones de diseño en cada caso.
Migración
La primera encarnación del servidor fue por el 2001, cuando tuvimos que migrar a un software y hardware más actual el antiguo servidor del grupo, que llevaba un tiempo dando problemas. Creo recordar que era un servidor de correo de Netscape (¡!) que almacenaba la información de las cuentas en un directorio LDAP. El servidor que elegimos para la migración fue qmail-ldap, por los buenos comentarios en cuanto a estabilidad y fiabilidad, facilidad de configuración (a mi personalmente me sigue pareciendo mucho más sencillo que p.ej. sendmail) y porque también usaba un LDAP. Puede que éste último motivo parezca una tontería, pero al final la migración se tuvo que hacer in extremis en un momento que el servidor original ni si quiera arrancaba la mayoría de las veces, y salimos airosos con un simple ldapsearch y un script que “traducía” los esquemas de un servidor a los del otro. Con el tiempo la elección de qmail-ldap demostró ser un gran acierto, ya que gracias a su diseño modular nos permitió ir evolucionando desde un único servidor hasta el cluster que comentaba en la introducción.
Este primer servidor era un enrackable con fuente redundante y RAID5 hardware, con lo que los datos estaban bien protegidos (o eso creíamos). También instalamos qmail-scanner y el anti-virus Kaspersky (no existía el ClamAV por aquel entonces, años más tarde migramos). En el mismo servidor teníamos SMTP, POP, IMAP y WebMail (SquirrelMail).
Backup en espera
La primera ampliación creo que la hicimos antes del año de haberlo montado, y vino propiciada por un susto con el RAID5 y una partición corrupta que nos costó Dios y ayuda recuperar. Se hizo evidente que el RAID y la fuente redundantes no eran suficientes para asegurar los datos y la disponibilidad del servicio, con lo que montamos otro servidor exactamente igual, y sincronizamos la configuración y los buzones mediante rsync y tareas programadas en el cron. El paso de un servidor a otro era manual por aquel entonces, a nivel de NAT en un router.
Con el tiempo se cambió de servidor varias veces pero mantuvimos la estructura con un backup en espera. La sincronización también se mejoró, con DRBD para los buzones y csync2 para la configuración, bases del anti-virus, etc. La monitorización y paso de backup a activo se automatizó con heartbeat.
Escalada de SPAM, especialización por recursos
En algún momento del 2003 los virus dejaron de ser el gran problema del correo electrónico que pasó a ser el SPAM, con lo que instalamos SpamAssassin en el servidor. Con el tiempo cada vez se recibía más y más SPAM, aumentando el consumo de CPU y memoria del servidor. Parecía que la única opción era migrar todos los años a un nuevo servidor más potente (¿y qué hacer con el anterior?), o montar varios servidores y distribuir los dominios entre ellos en un intento de distribuir la carga.
Finalmente nos dimos cuenta que teníamos necesidad de dos tipos de recursos distintos, con patrones de crecimiento también distintos:
- espacio en disco para los buzones: el nº de cuentas era más o menos estable y la gran mayoría de usuarios descargaban el correo por POP (frente al acceso remoto por IMAP), con lo que la necesidad de disco aumentaba pero muy lentamente y realmente no suponía un gran problema, podíamos ampliar discos cada X años pivotando el servicio al servidor de backup.
- CPU: las gráficas de correos recibidos (cada vez más SPAM) a lo largo de los años crecían de forma exponencial. Cada año prácticamente necesitábamos doblar la potencia del año anterior.
Así que, ¿por qué no especializar los servidores, unos para almacenamiento y otros para proceso de SPAM y virus? Quitamos el servicio SMTP del servidor principal y su backup, y los sacamos a una primera línea de servidores SMTP con las siguientes características:
- eran PCs normales y corrientes “de la tienda de la esquina” y apenas variaba la configuración de uno a otro (hostname, IP y poco más), con lo que teníamos un servidor “tipo” que podíamos replicar en cuestión de minutos en otra máquina en caso de que uno fallara o por el aumento de SPAM recibido necesitáramos más recursos.
- un router balanceaba la carga.
- eran independientes del servidor central salvo para el paso final de entregarle el correo ya analizado: cada uno tenía su copia del LDAP (sincronizada con slurpd), su copia de la configuración y datos del anti-virus y anti-SPAM (sincronizados con csync2), y un caché/resolver de DNS (dnscache).
- tenían logs en local pero también los enviaban a un servidor central de syslog.
- no almacenaban los correos, dicho de otra forma no tenían cola: si un correo se analizaba y cumplía ciertos requisitos (lista negra, varias RBL, dirección incorrecta, etc.) se rechazaba directamente con un error SMTP y se cortaba la conexión; si se dejaba pasar (correo legítimo, o marcado como posible SPAM), se enviaba al servidor central y no se daba el OK al servidor origen hasta que el central no aceptaba el correo. Todo esto con qmail es muy simple sustituyendo el qmail-queue por qmail-qmqpc. Con esta medida conseguimos que aunque uno de los servidores se caiga no se pierda ningún correo, ya que al no haber recibido el OK el servidor remoto si se cortara la conexión volvería a intentar el envío pasados unos minutos.
Los buzones, POP e IMAP, maestro LDAP, webmail y cola de envío remoto permanecieron en el servidor central, aunque con el tiempo si hubiera sido necesario alguno de éstos servicios se podría haber sacado también a un servidor independiente.
Especialización por tipo de cliente
El siguiente problema que nos encontramos fue cuando hará cosa de aproximadamente 3 años empezó a aparecer el SPAM basado en imágenes y PDF: tuvimos que añadir al SpamAssassin un script que recomponía las imágenes en el caso de los GIF animados, y hacía OCR del texto. Este análisis aumentó mucho el consumo de CPU (tuvimos que pasar de 2 ó 3 servidores SMTP a 5) y aún así había ocasiones en las que un servidor se sobrecargaba y durante unos 5-10 minutos podía tardar del orden de 2 minutos en procesar cada correo. En el caso de conexiones desde otro MTA esto no es un problema, ya que aunque se llegara a dar un timeout, se reintentaría el envío; sin embargo si el remitente era un usuario final desde su MUA, un tiempo de entrega excesivo o incluso un timeout implicaban una llamada porque “el correo no va”. :-)
La solución fue dividir la granja de servidores SMTP y de análisis en dos: una para el correo externo y otra para el interno. A la primera es donde apuntaba el registro MX del DNS, y tenía todos los filtros anti-SPAM activados; la segunda es la que configuramos a los usuarios, tenía los filtros más pesados desactivados y requería autenticación SMTP para cualquier IP externa. Así conseguimos que cualquier correo externo a nosotros pasara por todos los filtros, mientras que nuestros propios usuarios no sufrían las consecuencias del consumo de recursos del anti-SPAM.
