Notas sobre dspam

Tras un par de días dedicado al nuevo filtro antispam (en los ratos libres quiero decir), llego a una serie de conclusiones fundamentales para guiarme en la implantación final.

La primera es que dspam sin entrenamiento nada de nada; la segunda es que la mayor parte de las configuraciones están pensadas para usarlo después de que el spam haya entrado, y no para pararlo en el diálogo SMTP, que era a lo que yo estaba antes acostumbrado.

He preparado algunos esquemas para ayudarme a entender las diferentes posibilidades en relación con exim, teniendo además en cuenta que existen dos maneras de usarlo desde este programa:

1. Completo: cada llamada a dspam invoca al programa entero que intentará tomar los datos del directorio asignado al usuario, si dispone de éste.
2. Cliente: usándo el programa exterior para conectar con un programa dspam en modo servidor, para lo cual es necesaria una configuración más concreta, que no viene por defecto en el paquete Debian. También es bueno saber que existe un programa llamado dspamc que incluye sólo el código para conectar con el servidor, por lo que se puede adivinar el ahorro de recursos en el ssistema.

dspam como transporte de correo

He preparado un esquema (en formato kivio) y la imagen resultante es:

Podemos apreciar lo siguiente:

• dspam se invoca después de los filtros greylist y clamav (y tal vez una comprobación MIME ó algún filtro más), cuando la sesión SMTP ha finalizado y ya tienes el mensaje en tu sistema. Sí, en ese momento se puede configurar el sistema para que, si detecta que es spam, no lo envíe y se intente retornar al emisor (efectivamente, me aguanto la risa cuando digo esto) y sólo entregue el correo en caso contrario. El problema con este enfoque es que el spammer nunca se entera de si su correo ha llegado realmente ó no; sólo sabe que nuestro servidor lo ha aceptado y puede que llegue. Ante la duda es más que posible que nos apunte en su lista de objetivos para otros ataques (una conversación al respecto en la que además se defiende el filtrado por listas grises).

• Dado que estamos en fase de despacho de correo tenemos todos los datos necesarios para personalizar el análisis en busca de spam, según las preferencias y la base de spam de cada usuario. Si se emplea como filtro existen cosas (tal y como funciona exim) que no estarán disponibles; y entre esas cosas está $local_part y $domain (ahí es nada).

• El mensaje de correo, una vez analizado, es reinyectado en exim añadiéndole un cerrojo para que no vuelva a entrar en la comprobación de spam, y pase directamente a los despachadores reales de correo del sistema.

dspam como un filtro de contenido

En este caso el esquema cambia ligeramente:

Y nos encontramos con que:

• El correo es analizado durante la fase DATA de la sesión SMTP por lo que es posible rechazarlo sin más contemplaciones, y el emisor (es decir, el spammer) sabrá que no lo hemos aceptado.
• Elimina la necesidad de crear rebotes a vete tú a saber dónde del correo que hemos aceptado.
• En caso de que alguno de los análisis fallen es posible decirle al MTA que prosiga y enrute el mensaje normalemente. Algo que en la fase anterior no estamos ya en condiciones de indicar.

Ahora bien, las desventajas son prácticamente de orden operativo, como muy bien explica Craig Sanders, y son en la práctica un mayor consumo de recursos, tanto en memoria como en tiempo de proceso. ¿ Esto es importante ? Pues depende de cuál sea la política del sitio, pero si no se cuenta con la capacidad de proceso suficiente se puede dar esta situación:

1. Recibimos una conexión exterior para entregarnos el correo y abrimos una sesión SMTP.
2. Pasamos la fase de cabeceras que aceptamos porque no vemos nada malo.
3. Entramos en la fase de datos y comenzamos el proceso de filtrado efectuando llamadas a programas externos como los antivirus ó el filtro de spam.
4. Nuestra CPU se ralentiza y el uso de memoria comienza a crecer, mientras mantenemos la conexión y la sesión abierta. Hay que recordar que el número de conexiones a un servidor de correo suele ser finito, y más en máquinas con poca capacidad.
5. Aunque el RFC 2821 determina que se pueden esperar hasta 10 minutos dentro de la sesión para tener una confirmación (positiva ó negativa) de entrega de correo, es habitual que los servidores no esperen tanto, piensen que estás ocupado y corten la conexión para volver a intentarlo más tarde ... y así lo harán prácticamente todos por lo que, dado que no puedes atenderlos debido a tu carga de trabajo, te aseguras otra avalancha sin nada productivo para un poco más tarde.

Y aunque este caso sea de los peores escenarios, sin haber hecho nada realmente malo, no estarás entregando correo y eso es precisamente lo que quizás quieras evitar. :-)

Correspondencia entre mensaje y receptor

Este es un aspecto en el que muchas de las fuentes consultadas hacen incapié; no existe la seguridad de que la correspondencia entre mensaje y receptor sea uno a uno. Es decir, una dirección de correo de destino, cuando llega a un servidor, puede convertirse en muchas, tanto locales como foráneas. Así pues, pensar que en la fase de filtrado podemos tener esa información disponible es, cuando menos, ingenuo.

Enlaces y referencias

• Tim Jackson ha escrito un artículo excelente sobre análisis de contenidos de correo usando exim4 y spamassasin. Sí, no está dedicado a dspam, pero su introducción y explicaciones sobre las dos fórmulas arriba expuestas es magnífica y lo he usado mucho para aclararme conceptos y tomar decisiones.
• El libro The Exim SMTP Mail Server (Official Guide for Release 4) de Philip Hazel, que adquirí hace un tiempo y que está resultando muy útil. Eso sí, habla mucho sobre la teoría subyacente del programa y no es, por tanto, un guía de consulta rápida ni nada similar.