ADVERTENCIA: Este tutorial data del año 2006 y no ha sido actualizado (salvo en su presentación.) Muchas cosas han cambiado en estos años, por lo que el lector debe considerar seriamente las alternativas a su disposición.
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.
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.
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.
Configuración del Software
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.
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.
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
Pruebas
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.)
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)
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.)