Servidor de Email con Múltiples Dominios y Antispam

Historial de revisiones
Revisión 1.010/09/2006Diego
Bravo
Primera versión

Tabla de contenidos

1. El Requerimiento
2. Solución Propuesta
2.1. Instalación de componentes
3. Configuración del Software
3.1. Configuración de Exim 4
3.2. Configuración de Spamassassin
3.3. Configuración de Vm-pop3d
4. Pruebas
4.1. Envíos hacia el exterior
4.2. Envíos hacia usuarios locales
4.3. Descarga desde cliente POP

Nota

Este documento es antiguo y seguramente obsoleto. Se publica sin ningún ánimo de ser tomado como recomendación puesto que muy probablemente las herramientas mencionadas han evolucionado o han sido favorablemente superadas con el transcurso del tiempo.

1. El Requerimiento

Configurar un servidor de correo electrónico bajo Linux con capacidad de soportar múltiples dominios independientes (dominios virtuales), con filtro Antispam, así como servidor POP3 para las descargas.

En particular, es necesario que los usuarios de email NO correspondan a usuarios del sistema operativo.

2. Solución Propuesta

La solución que se propone aquí no ha sido probada extensivamente ni bajo una gran carga; ni está respaldada por otras opiniones; sólo puedo indicar "que funciona".

Los componentes utilizados son:

  • Debian Sarge (stable)
  • Exim 4.50
  • Spamassasin 3.0.3
  • Vm-pop3d 1.1.6

A los lectores que tengan a bien implementar la solución aquí descrita, agradecería infinitamente se sirvan comentarme sus experiencias.

2.1. Instalación de componentes

Es comprensible que no se describirá aquí la instalación de Linux Debian.

Servidor Exim

Esta versión de Debian proporciona diversos paquetes relacionados a Exim 4. En particular, es menester instalar el paquete llamado "exim4-daemon-heavy", el cual (en contraposición al exim4-daemon-light) proporciona soporte para interactuar con el Spamassassin.

# apt-get install exim4-daemon-heavy

Como parte del proceso de instalación de este paquete, Debian inicia un "wizard" de configuración (ver más adelante.)

Filtro Antispam Spamassain

Nada especial aquí:

# apt-get install spamassassin

Servidor POP Vm-pop3d

Este servidor proporciona facilidades para descargar software de múltiples dominios. Este programa fue descargado libremente (como código fuente) de la siguiente dirección (no tengo relación con esta organización.)

http://www.reedmedia.net/software/virtualmail-pop3d/

El archivo se debe desempacar y compilar:

# tar xvzf vm-pop3d-1.1.6.tar.gz
# cd vm-pop3d-1.1.6
# ./configure
# make
# make install

Esto debe instalar el ejecutable vm-pop3d en /usr/local/sbin.

3. Configuración del Software

3.1. Configuración de Exim 4

Esta es de lejos, la sección más extensa de esta guía; sin embargo, es encomiable la "claridad lógica" de Exim en este aspecto.

Generación del archivo de configuración

Tal como se indicó, como parte del proceso de instalación Debian (al final del "apt-get"), aparecen una serie de menús que permiten configurar con facilidad a Exim 4, al menos para los casos más típicos.

Estos menús de configuración se pueden volver a invocar en el futuro (para posterores reconfiguraciones) mediante el comando:

# dpkg-reconfigure exim4-config

(exim4-config) es un paquete automáticamente instalado y contiene una serie de scripts y plantillas de configuración de Exim 4.

Para esta discusión asumiré las siguientes "respuestas" de configuración:

  • "NO" dividir la configuración en pequeños archivos
  • Tipo de configuración "internet site" (no smarthosts, etc)
  • System mail name "gatogringo.com" (no se utiliza mayormente pues los usuarios no tendrán cuenta de sistema operativo en el servidor)
  • Direcciones IP a escuchar: "En blanco". En ciertos casos esto puede ayudar a mejorar la seguridad del sistema, pero no se discutirá eso aquí
  • Lista de dominios de los que el servidor se considera el "destino final": sólo "gatogringo.com". Para el soporte de múltiples dominios, utilizaremos (ver más abajo) otro mecanismo más conveniente, por lo que no debemos preocuparnos de especificar nuestros dominios aquí. Sin embargo, el dominio que coloquemos aquí puede ser útil para realizar pruebas preliminares
  • Dominios a los que se acepta Relay: "En blanco"
  • Direcciones de red de las que se acepta Relay: "192.168.1.0/24". Aquí especificamos el rango de direcciones de nuestros computadores, los cuales son los únicos que tienen el privilegio de utilizar este servidor para enviar email a otros destinatarios. Tener cuidado de no permitir direcciones externas pues podrían emplear nuestro servidor como fuente de SPAM
  • DNS-Dial-on-demand? "NO" (no lo entiendo todavía:)

Tras todo esto, el "configurador" genera un archivo llamado /etc/exim4/exim4.conf.template [1]. En realidad, este no es el archivo "real" de configuración, sino una "plantilla" en la que se pueden hacer cambios complementarios. Los scripts de inicio del servidor se encargan de regenerar el "verdadero archivo de configuración" cada vez que aquel se reinicia. Esto es un tanto extraño… tal vez sea un "debianismo"; no mencionaremos más sobre el "verdadero" archivo de configuración por no ser relevante. En lo sucesivo se trabajará sólo con /etc/exim4/exim4.conf.template.

Tras estos pasos, el sistema reinicia automáticamente al servidor Exim. Es conveniente intentar hacer algunas pruebas básicas para verificar que todo está en operación. Como es usual, para reiniciar manualmente el servidor, emplear la sintaxis:

# /etc/init.d/exim4 restart

Soportar Multidominios - Ruteador

Es necesario agregar un "ruteador" en el archivo de configuración (en nuestro caso, en la plantilla):

# vi /etc/exim4/exim4.conf.template

Previamente, en el archivo de configuración debemos encontrar el "ruteador" encargado de procesar el correo "local" (es decir, el correo que se almacenará en el servidor de modo definitivo en las "casillas", hasta que los usuarios lo extraigan.)

Concretamente, en mi caso observo un "ruteador" denominado "procmail" (que se encarga de procesar el correo local invocando al programa procmail.) Tiene el siguiente aspecto:

procmail:
  debug_print = "R: procmail for $local_part@$domain"
  driver = accept
  domains = +local_domains
  check_local_user
  transport = procmail_pipe
  ...

(los detalles podrían variar mucho, pero los comentarios deben proporcionar alguna idea.)

Precísamente ANTES de este ruteador, colocaremos el nuevo ruteador con el siguiente contenido:

## Nuevo ruteador para Multiples Dominios locales
dominios_locales:
  debug_print ="R: dominios_locales para $local_part@$domain"
  driver = accept
  domains = dsearch;/etc/exim4/dbedomains
  local_parts = lsearch;/etc/exim4/dbedomains/$domain
  transport = transporte_local

## Ruteador estandar procmail
procmail:
  debug_print = "R: procmail for $local_part@$domain"
  ...

Nótese que hemos repetido parte del ruteador "procmail" por fines didácticos.

Nuestro nuevo "ruteador" señala sencillamente que los archivos listados en el nuevo directorio de configuración /etc/exim4/dbedomains (puede usarse cualquier nombre de directorio), se consideran los dominios locales de este servidor. Aquí es donde gradualmente agregaremos todos los dominios que se desea soportar:

# ls /etc/exim4/dbedomains/
gatogringo.com  oscuridad.com.pe

Cada uno de estos archivos deberá contener los "nombres de usuario" válidos para cada dominio. Por ejemplo, si deseamos mantener las cuentas: diego@gatogringo.com, oscar@gatogringo.com, ana@gatogringo.com, ana@oscuridad.com.pe, silvana@oscuridad.com.pe, entonces los contenidos serán:

# cat /etc/exim4/dbedomains/gatogringo.com
diego
oscar
ana
# cat /etc/exim4/dbedomains/oscuridad.com.pe
ana
silvana

Obsérvese que "ana" corresponde a dos usuarios totalmente independientes en ambos dominios. Asimismo, en el sistema operativo no será necesario crear absolutamente ninguno de estos usuarios.

Soportar Multidominios - Transporte y Casillas de correo

En la última parte del ruteador, el lector observará una directiva denominada "transport", la cual hace referencia al "transporte" por el que se envían los mensajes a los que se hace referencia. En nuestro caso, hemos definido un "transporte" denominado "transporte_local", el cual -para seguir el mismo orden- será definido justamente antes del transporte de procmail (procmail_pipe), con lo que se requerirá agregar estas líneas:

# Transporte multidominio
transporte_local:
  driver = appendfile
  file = /var/spool/virtual/$domain/$local_part
  user=mail

# Transporte procmail
procmail_pipe:
  debug_print = "T: procmail_pipe for $local_part@$domain"
  driver = pipe
  ....

Nuevamente, hemos colocado parte del transporte "procmail_pipe" por fines didácticos.

Nuestro "transporte" básicamente define la acción "appendfile" que corresponde a agregar el mensaje a un archivo. El archivo se define sencillamente como /var/spool/virtual/DOMINIO/USUARIO; por ejemplo, el correo que llega para "silvana@oscuridad.com.pe" se almacenará en /var/spool/virtual/oscuridad.com.pe/silvana.

A tal efecto, debemos crear el directorio /var/spool/virtual (si se desea usar otro directorio, es menester especificarlo en el momento de la compilación del Vm-pop3d) y cada vez que agreguemos un nuevo dominio en /etc/exim4/dbedomains, también crearemos un subdirectorio con el mismo nombre:

# mkdir /var/spool/virtual
# mkdir /var/spool/virtual/oscuridad.com.pe
# chown mail /var/spool/virtual/oscuridad.com.pe

Es necesario cambiar el propietario de cada subdirectorio de dominios al que utiliza el servidor Exim 4, pues éste tendrá que escribir allí.

Invocar a Spamassassin

Debemos identificar el grupo de "ACL’s" que realizan diversas validaciones a los mensajes. Estos ACL’s están normalmente antes de iniciarse los "ruteadores":

...
    message = No verifiable sender address in message headers
    !acl = acl_whitelist_local_deny
    !verify = header_sender
  .ifdef CHECK_DATA_LOCAL_ACL_FILE
  .include CHECK_DATA_LOCAL_ACL_FILE
  .endif

# TRAS PASAR LAS VALIDACIONES, ACEPTAR
  accept

# RUTEADORES
begin routers
...

Tal como se aprecia, la sección de ACL’s termina con una "aceptación" final del mensaje. Previamente a esta "aceptación" agregaremos una nueva validación con un ACL:

...
    message = No verifiable sender address in message headers
    !acl = acl_whitelist_local_deny
    !verify = header_sender
  .ifdef CHECK_DATA_LOCAL_ACL_FILE
  .include CHECK_DATA_LOCAL_ACL_FILE
  .endif

# RECHAZAR SPAM
  deny
    message = Mensaje fue clasificado como SPAM
    condition = ${if < {$message_size}{10K}}
    spam = nobody/defer_ok
    condition = ${if >{$spam_score_int}{60}{1}{0}}

# TRAS PASAR LAS VALIDACIONES, ACEPTAR
  accept

# RUTEADORES
begin routers
...

Brevemente, el "message" envia un mensaje al log; la primera condición evita que los mensajes sean enviados a Spamassassin si pasan de 10K (se consumiría mucho CPU y los mensajes de SPAM suelen ser pequeños.) El "spam" indica que todos los usuarios serán analizados vía Spamassassin y por último, rechazamos mensajes cuyo "nivel de spam" sea mayor a "6.0" (escrito como "60".) Este valor se deberá "calibrar" de acuerdo a la instalación.

3.2. Configuración de Spamassassin

Spamassassin proporciona un demonio denominado "spamd" el cual se reinicia manualmente por el procedimiento estándar:

/etc/init.d/spamassassin restart

Dados ciertos mensajes, hallé conveniente agregar una opción en el script /etc/init.d/spamassassin a fin de que el demonio se inicie bajo el usuario "spam" (creado durante la instalación del paquete.)

DOPTIONS="-d --pidfile=$PIDFILE -u spam"

La documentación de Spamassassin me parece en general bastante confusa (sospecho que es adrede.) El lector puede empezar con:

man spamassassin

y

man Mail::SpamAssassin::Conf

Básicamente, la idea es agregar archivos en /etc/spamassassin con directivas que señalen el "peso" de diversos "tests" que apuntan a señalar y calificar un mensaje como SPAM. Esta es una cuestión de "graduación" que potencialmente puede demandar bastante trabajo de personalización.

Tras la aplicación de una gran cantidad de tests, Spamassassin impone cierta calificación a cada mensaje con respecto a que tan "SPAM-oso" es éste. A partir de cierto nivel (por omisión 5.0) se generará una línea de cabecera adicional en el mensaje alertando su caracter de "SPAM" (con su graduación), la cual puede ser posteriormente analizada por el servidor Exim. A partir de la graduación Exim deicidirá en último término qué se hace con el mensaje.

Spamassassin nunca descarta los mensajes, sólo los califica. El descarte se deja a Exim, o en último término, al programa cliente del usuario.

3.3. Configuración de Vm-pop3d

Cuentas POP / Contraseñas

Empecemos creando el directorio padre de configuración:

# mkdir /etc/virtual

Dentro de este directorio, crearemos un subdirectorio para cada dominio:

# cd /etc/virtual
# mkdir gatogringo.com
# mkdir oscuridad.com.pe

Y ahora sólo queda asignar las contraseñas para los usuarios que descargan su correo pop. Para esto debemos utilizar un archivo llamado "passwd" ubicado en el subdirectorio /etc/virtual/DOMINIO. Este archivo utiliza la misma sintaxis (¿harto conocida?) de la autenticación básica de Apache, por lo cual podemos utilizar el clásico comando "htpasswd" (que se proporciona como parte de las utilidades de Apache.) De no estar disponible, el sitio web de Vm-pop3d proporciona un pequeño script en Perl con el mismo propósito.

Para las cuentas mencionadas como ejemplo, la secuencia de comandos sería:

# htpasswd -c /etc/virtual/gatogringo.com/oscar
password:
# htpasswd /etc/virtual/gatogringo.com/ana
password:
# htpasswd -c /etc/virtual/oscuridad.com.pe/ana
password:
# htpasswd /etc/virtual/oscuridad.com.pe/silvana
password:

La opción "-c" se utiliza para crear el archivo. Debe tenerse cuidado de no volver a emplearse o el contenido se "trunca".

Ejecución vía inetd

Como es usual, el servicio POP será disparado por inetd. Para esto, agregar una línea en /etc/inetd.conf conteniendo:

pop3    stream  tcp     nowait  root    /usr/local/sbin/vm-pop3d vm-pop3d

(como es usual, cuidar de comentar cualquier otra línea preexistente que se inicie con "pop3".)

Y recargar inetd:

# ps ax | grep inetd
....
# kill -1 PID_DE INETD

4. Pruebas

4.1. Envíos hacia el exterior

Como de costumbre, utilizar un cliente estándar de correo. Hacer un envío desde la red local vía SMTP hacia una cuenta exterior (un proveedor público tipo hotmail/gmail/yahoo.) Esto verifica que el servidor está permitiendo el "relay" desde la red local.

Verificar los mensajes en log de Exim (típicamente en /var/log/exim4/mainlog.)

4.2. Envíos hacia usuarios locales

Por comodidad, utilizar un proveedor operativo (una cuenta en un proveedor público) y enviar un mensaje a uno de los usuarios creados tal como se explicó anteriormente.

Por ejemplo, para "silvana@oscuridad.com.pe", debemos apreciar que el mensaje se almacena en /var/spool/virtual/oscuridad.com.pe/silvana; de no ser así, tenemos un problema con la configuración de Exim 4 (ver mensajes en el log)

4.3. Descarga desde cliente POP

Como de costumbre, el cliente debe apuntar hacia el host/ip donde está instalado el Vm-pop3d, y para el ejemplo anterior, en cuanto al "usuario" se deberá proporcionar "silvana@oscuridad.com.pe" (evidentemente, ahora no basta con "silvana")

En caso de error, verificar los logs de Syslog (por ejemplo, /var/log/mail.log.)



[1] Dependiendo de la respuesta al primer menu, la configuración se basa en un conjunto de pequeños archivos en vez de un único gran archivo. La diferencia no es esencial.