Instalando DSPAM

Consideraciones previas

La instalación de dspam en el servidor de Taquiones ha sido muy fructífera por todo el conocimiento que me ha proporcionado sobre exim4, aunque en realidad ya tenía que haberlo estudiado por mi cuenta :-) No se puede estar en todo.

Tras recopilar alguna información y efectuar algunos estudios previos he llegado a las siguientes conclusiones:

• Mi interés principal es el despacho de correo en el servidor por lo que el uso del filtro será tras aceptar el mensaje, y no como filtro de contenido.
• No queremos perder correo en ningún caso, y dado que no es posible un filtro perfecto, y menos con dspam ya que tenemos que entrenarle, voy a optar por etiquetar el correo y despacharlo a los usuarios.

Y estoy rumiando estas otras ideas:

• Es muy posible que mantenga el filtro de listas grises si consigo un control más fino sobre su funcionamiento, y le incorporo algún tipo de capacidad de autowhitelist para las direcciones a las que uno de mis usuarios acaba de enviar correo (que viene a ser una consecuencia lógica, si envias un mensaje a alguien y esperas algún tipo de respuesta, lo lógico es que aparezca como fiable desde ese momento).
• Mantendré seguramente los dos sistemas de entrenamiento para el filtro: envío a direcciones especiales tipo spam-usuario@taquiones.net y una búsqueda regular en carpetas especiales.

Instalación y configuración

Los paquetes usados en la instalación han sido los siguientes:

La instalación no presenta problema alguno, y se conserva la buena costumbre de no arrancar el demonio hasta que el administrador no lo configure y así lo indique en su correspondiente archivo /etc/default/dspam.

La configuración, que reside en el archivo /etc/dspam/dspam.conf principalmente, podemos dividirla en varias áreas:

Almacenamiento y rutas de acceso

Estas son las opciones correspondientes:

Home /var/spool/dspam
StorageDriver /usr/lib/dspam/libhash_drv.so

Lo intenté con el controlador para SQLite3 pero no funcionaba correctamente en modo demonio, porque al parecer esta versión no soporta el uso de hilos (threads) y daba insistentemente un error de library routine called out of sequence.

Posteriormente lo pasaré a PostgreSQL, cuando me decida a instalarlo en la máquina, pero por el momento tiene que ser así.

Los siguientes son parámetros relacionados con los archivos hash que usa para almacenar datos sobre spam

HashRecMax              98317
HashAutoExtend          on
HashMaxExtents          0
HashExtentSize          49157
HashMaxSeek             100
HashConnectionCache     10

y de los que sé que al menos es necesario HashAutoExtend, porque los archivos se llenan con una rapidez pasmosa y puede darse el caso de empezar a ver registros de error como este

May 22 15:04:10 daga dspam[19728]: hash table /var/spool/dspam/data/local/victor/victor.css full

Modo cliente/servidor

He elegido las siguientes opciones:

ServerMode      dspam
ServerPort      24
ServerDomainSocketPath  "/var/run/dspam/dspam.sock"
ServerPass.Relay1       "XXXX"

ClientHost      "/var/run/dspam/dspam.sock"
ClientPort      24
ClientIdent     "XXXX@Relay1"

porque de momento no tengo intención de usar la capadidad LMTP de dspam y creo que esto es suficiente.

Parámetros y algoritmos de análisis

No he querido introducir más cambios que los recomendados en casi todos los ejemplos que he podido ver por las mismas razones que antes, por desconocimiento.

TrainingMode teft
Feature chained
Feature tb=4
Feature whitelist
Feature noise
Algorithm graham burton
PValue graham

He querido dejar estas preferencias activas

Preference "spamAction=tag"
Preference "spamSubject=SPAM"
Preference "signatureLocation=headers"
Preference "showFactors=on"

que consiguen que el correo sea marcado y no puesto en cuarentena, que sean las cabeceras del mensaje las modificadas y no el cuerpo, y que en ellas se expliquen los motivos por los que se ha considerado spam (ó no).

Y las opciones que los usuarios pueden cambiar según sus preferencias individuales:

AllowOverride trainingMode
AllowOverride spamAction spamSubject
AllowOverride statisticalSedation
AllowOverride enableBNR
AllowOverride enableWhitelist
AllowOverride signatureLocation
AllowOverride showFactors
AllowOverride optIn optOut
AllowOverride whitelistThreshold

Despacho de correo

En este caso la opción

TrustedDeliveryAgent "/usr/sbin/exim -oMr spam-scanned "

me permite cortocircuitar el enrutado de correo como mostraré más adelante.

Varios

Estas son otras opciones que dejo para explicar también más adelante:

Notifications   on

PurgeSignatures 14          
PurgeNeutral    30         
PurgeUnused     60        
PurgeHapaxes    15       
PurgeHits1S     10      
PurgeHits1I     10     

LocalMX 127.0.0.1

SystemLog on
UserLog   on

Opt out

Include /etc/dspam/dspam.d/

siendo la última línea la que me permite separar la configuración en fragmentos más manejables.

Además, la línea Opt determina que todos los usuarios pasarán por el filtrado a menos que tengan un archivo concreto llamado 'usuario.nodspam' en el directorio /var/spool/dspam/opt-out/.

Integración con exim4

Para la integración de dspam en exim4 he optado, como he dicho, por convertirlo en un despachador, para lo que necesito seguir algunos pasos un tanto extraños inicialmente, pero con sentido al final.

Lo primero es crear un enrutador llamado spamscan con el siguiente aspecto:

spamscan:
        driver = accept
        no_verify
        condition = "${if and \
                {{!eq {$received_protocol}{spam-scanned}} \
                {!eq {$received_protocol}{local}} } \
                {1}{0}}"
        transport = spamcheck
        require_files = /var/spool/dspam:+/usr/bin
        headers_add = "X-DSPAM-Check: by $primary_hostname on $tod_full"

del que cabe resaltar los siguiente:

1. Sólo actúa sobre el correo si éste no tiene un protocolo de recepción local (no exterior vía red) ni tiene un protocolo falso denominado spam-scanned.
2. En caso de cumplir la condición añade una cabecera al mensaje con la fecha y la máquina que lo analiza.
3. Envía el correo al transporte spamcheck

Este enrutador está situado en el nivel 550 (que puede variar de instalación a instalación), pero que en la mía es necesario porque debe aparecer después de los enrutados de alias virtuales, alias del sistema y hubuser que sólo se usa en configuraciones de tipo servidor satélite pero que me he preferido respetar allí.

Ojo con esto, porque el orden es muy importante dado que queremos que se analice cada correo con respecto a las preferencias de usuarios finales en el sistema.

Después he creado un transporte llamado spamcheck de esta forma:

spamcheck:
        driver = pipe
        command = "/usr/bin/dspamc --mode=teft --deliver=innocent,spam --user $local_part -- -bm %u"
        current_directory = "/var/spool/dspam"
        user = dspam
        group = dspam
        home_directory = "/var/spool/dspam"
        log_output
        message_prefix =
        message_suffix =
        return_fail_output = true
        return_path_add = no

el cual, a menos que tenga un error grave, llama al programa externo dspamc (un cliente ligero de dspam) y le indica que analice el correo, lo marque como spam sí ó no y lo despache al usuario correspondiente según la variable $local_part, que en esta fase está completamente identificada.

Además al final de todo le proporcionamos parámetros extra para que se los pase al despachador final. Este, como hemos visto más arriba en la configuración del demonio, es exim y la llamada final quedaría como sigue:

/usr/sbin/exim -oMr spam-scanned -bm %u

siendo %u reemplazada por el nombre del usuario final.

Dado que utilizamos el parámetro -oMr para definir el protocolo de entrada como spam-scanned exim4 cortocircuitará el enrutador spamscan y pasará a los siguientes; estos en mi sistema son userforward, procmail, maildrop y local_user.

Hay un par de enrutadores y de transportes más destinados a crear un mecanismo para entrenar a dspam mediante envío de mensajes y sobre los que hablaré más tarde.

Por ahora podemos ver este esquema (en formato Kivio) en la siguiente imagen:

y este otro desde la perspectiva de los enrutadores y los transportes:

Puesta en marcha

Ponerlo en marcha sólo ha requerido lanzar el demonio dspam mediante herramientas estándar Debian y lanzar el correo a continuación:

# /etc/init.d/dspam start
# /etc/init.d/exim4 start

Disposiciones globales

Utilizando maildrop para el despacho final de correo a los usuarios, se me ha ocurrido que es muy necesario que todos ellos compartan las mismas reglas de filtrado, y así he visto que el programa, en modo despacho de correo individual que es como lo llaman desde exim, lee primero el archivo /etc/maildroprc y luego el archivo de usuario en $HOME/.mailfilter.

Así pues he incluído estos párrafos en dicho archivo global

DEFAULT="$HOME/Maildir"

if (/X-DSPAM-Result:.*Spam/:h)
{
        to "$DEFAULT/.Spam"
}

de manera que todo aquél archivo que incluya un resultado positivo como spam (mirando una cabecera especial), vaya a parar a la carpeta correspondiente en cada uno.

La creación de la carpeta, eso sí, la he tenido que hacer a mano, aunque siempre se podría añadir lo siguiente para automatizarlo:

SPAM=$DEFAULT/.Spam

`test -d $SPAM`
if ($RETURNCODE != 0)
{
    `maildirmake $SPAM`
}

Otros temas

• Probando dspam
• Compartiendo información entre usuarios.
• Mantenimiento del filtro.

Enlaces y referencias

• Valiosísimas notas de Jason Boxma al respecto.
• Configuración con abundantes comentarios, en un lugar para preparar fragmentos de código y documentación para envío y uso en redes IRC.
• Notas para usuarios de la Universidad de Rice donde les explica cómo usar dspam en la red universitaria.
• Alan cuenta cómo le ha ido con dspam.
• Jeffrey también explica qué es dspam y cómo funciona.
• Simon McVittie tiene un tutorial para configurar un servidor de correo en Debian con Exim, Clamav y dspam.
• El sitio oficial de dspam y su sección de recursos.
• La propia documentación incluída en el paquete dspam-doc.
• Para maildrop:
  • Ejemplos de configuración en una lista sobre postfix.