Luchando contra el spam con FreeBSD

Autor: Emilio Florido
Fecha: 1/2/2006
Revisado: 8/2/2006
Revisado: 8/10/2006
Plataforma: FreeBSD 4.11-STABLE

Quien debería leer este documento

Hace ahora ya más de dos años que escribí este otro artículo. Y aunque todo lo que ahí se cuenta no deja de ser cierto, también es verdad que durante ese tiempo varias cosas han cambiado.

Por una parte, suelo recibir mensajes de personas que, tras seguir las indicaciones que yo daba al pie de la letra, se encuentran con que tal o cual fichero ya no se llama así o no está exactamente en la ruta que yo comentaba... y la verdad es que no les falta razón.

Por otra parte, si bien es verdad que hace dos años con esas acciones se podía luchar contra el spam, también es verdad que a fecha actual esas acciones se quedan cortas.

Por tanto, este documento me gustaría que sirviera como actualización, pero sobre todo como ampliación del que ya escribí... es decir, que antes de seguir leyendo será casi imprescindible que leas el anterior para poder aprovechar mejor lo que viene a continuación. Eso si, si ya tienes tu sistema funcionando como propuse hace un par de años, puedes seguir leyendo directamente por aquí.

Antes de comenzar

Como ya avisé en el documento anterior, el proceso que voy a contar aquí está basado en como lo he realizado yo en una máquina con FreeBSD 4.11-STABLE. Este proceso ya sabes que requiere conectarse como administrador e instalar unos cuantos programas, retocar en algunos ficheros básicos de configuración y arrancar algunos "demonios" en la máquina FreeBSD.

Con esto quiero hacer ver que, como ya dije, siempre hay un riesgo de equivocarse y estropearlo todo (incluidas partes del sistema que no tengan en principio relación con la gestión de los mensajes de correo). Claro está que esto tampoco tiene porqué ocurrir y de hecho, a mi no me ha ocurrido siguiendo los pasos que a continuación expongo... pero no está de más que otra vez te avise de que eso podría ocurrir... dicho de otra forma, tu decides de nuevo si seguir o no adelante.

Actualizaciones

Tal vez te preguntes que porqué son necesarias determinadas actualizaciones, o dicho de otra forma, que porqué lo que antes era válido ahora ya no lo es.

En realidad, si das un vistazo al fichero /usr/ports/UPDATING verás que han sido los propios desarrolladores de los paquetes de software que necesitamos usar los que han realizados los cambios. Por ejemplo, revisa en ese fichero -que está ordenado de forma cronológica inversa- los cambios que se comentan para el día 22/12/2004. Fíjate que la base de datos del antivirus -ClamAV- que antes estaba en una determinada ubicación ahora está en otra... por tanto, todas las referencias que yo hacía a la misma en mi anterior documento deberían ser actualizadas a la nueva ubicación. Pues igual que ese caso, hay algunos otros detalles que han cambiado y que deberás revisar. Aquí te dejo indicados los principales (por cierto, los paquetes de software a instalar si que son los mismos que antes, y únicamente habrá que incluir alguno más pero que ya comentaré oportunamente). Por lo pronto, revisa todo esto:

Si ya has comprobado todos estos puntos, sería un buen momento para revisar que por ahora todo funciona correctamente, pues estas revisiones solo pretenden "ajustar" las variaciones que por el paso del tiempo -o más exactamente, por las modificaciones que han hecho los desarrolladores de los paquetes software- se habían producido entre lo que antes yo proponía y como a fecha de ahora (1-2-2006) deben estar. Yo te aconsejaría teclear algo como:

      # spamassassin --lint

que hará que spamassassin revise su lista de reglas en busca de cualquier posible error. Si todo va bien, no habrá salida alguna por pantalla... y si algo va mal, pues además de indicarte que es, puedes probar a ejecutar 

      # spamassassin --lint -D

que te dará muchísimos detalles de que es lo que ha fallado.

Tampoco estaría de más hicieras esto: 

      # cd /usr/local/etc/rc.d
      # ./clamav-freshclam.sh restart

y que luego mirases en el fichero /var/log/clamav/freshclam.log que todo ha sido correcto (recuerda que con esto lo que haces es forzar a que se actualice la base de datos del antivirus).

De todas formas, lógicamente la mejor comprobación de todas es que pruebes a enviarte un mensaje, revises si lo recibes y ojees en /var/log/maillog que todo está funcionando correctamente.

Antes de seguir

Como ya comenté, desde que escribí el anterior documento hasta ahora he recibido muchísimos mensajes haciéndome consultas sobre determinados aspectos del funcionamiento de este sistema, pero un tema que me han consultado muy a menudo es que en que orden deberían arrancarse los diferentes procesos que intervienen, ya que no sirve cualquier orden (más claro, si por ejemplo primero arrancas sendmail y luego  mimedefang te encontrarás con una "bonita" colección de mensajes de error). Aunque no hay un orden estricto de arranque, yo personalmente he fijado uno concreto renombrando los scripts que arrancan cada proceso y que están en /usr/local/etc/rc.d para que me queden de la siguiente forma:

      # ls -1 /usr/local/etc/rc.d/
      
      020.mimedefang.sh
      030.clamav-clamd.sh
      040.clamav-freshclam.sh
      050.sendmail.sh
      060.saslauthd.sh

lógicamente, en mi máquina "real" tengo más scripts de arranque, pero estos son los que afectan al tema que estamos tratando. Date cuenta que únicamente he antepuesto al nombre del script un número para que ese sea el orden concreto de arranque (o parada) de esos servicios (por cierto, ya lo comenté también, pero por si se te ha pasado, recuerda que el script clamd.sh NO hay que arrancarlo, si no que será mimedefang quien lo haga cuando lo necesite, de ahí que no lo veas como parte de los que yo tengo en /usr/local/etc/rc.d

Ampliaciones

Pues bien, si has conseguido que todo funcione (y solo en ese caso) es el momento de ampliar lo que ya tienes para que el filtrado del spam sea bastante más agresivo que el que ahora tienes. Date cuenta que tratar de seguir haciendo lo que te propondré sin que lo anterior esté funcionando correctamente es tener ganas de perder mucho tiempo, pues si un sistema básico no te funciona no parece buena idea "complicarlo" antes de arreglar los problemas previos. Muy bien, pues ya estás avisado.

Las ideas nuevas que me gustaría aportar a lo que ya había son fundamentalmente estas cinco:

Antes de seguir, y para satisfacer tu curiosidad, esto es lo que cada uno de esos puntos te proporcionará.

El primero (dsbl) consiste en hacer que sendmail cuando comience la comunicación para recibir un mensaje (antes siquiera de aceptarlo), revise si la dirección IP de quien dice ser el remitente figura en alguna de las muchas bases de datos que existen en Internet y que mantienen enormes listados de estas direcciones que por una causa u otra es sabido que desde ellas se han enviado mensajes tipo spam anteriormente. Lógicamente si así es, el mensaje no se aceptará.

El segundo de ellos (rules_du_jour) no es más que un script que conecta una vez al día con determinados servidores en Internet en los que los autores de reglas de filtrado para spamassassin almacenan sus nuevas modificaciones y, si tus reglas necesitan actualizarse, él sólo lo hará, las verificará, y si todo está correcto incluso rearrancará el proceso oportuno para que tomen efecto.

El tercero, Razor es la implementación de una idea que tiene una buena base real. Cuando recibes un mensaje tipo spam, desafortunadamente no es a ti a quien únicamente le llega ese mensaje. Quiero decir que los "señores" que se dedican a este tipo de actividad, habitualmente envían el mismo mensaje a miles (¿millones?) de usuarios... y esto afortunadamente, se puede aprovechar en su contra. Imagina que una cualquiera de las personas que reciben uno de esos mensajes lo envía a un sitio común -los servidores de Razor- y allí ese mensaje es "catalogado". El resto es simple. Lo que haremos será instruir a spamassassin para que cuando reciba un mensaje cualquiera, además de aplicarle sus reglas, consulte también con Razor para ver si ese mensaje está o no "catalogado"... y si lo está, que lo puntúe "muy seriamente" como un posible mensaje tipo spam.

El cuarto, el filtro bayesiano, consistirá en una base de datos -que residirá en tu propia máquina- y que poco a poco "aprenderá" a distinguir, de entre todos los mensajes que recibas cuales son spam y cuales no. Y cuando digo "aprenderá", quiero decir justo eso... es decir, tras un periodo de "entrenamiento a mano" en el que "enseñaremos" a nuestra base de datos como son los mensajes tipo spam y como los normales (ham los llaman los ingleses), ella sola será capaz de distinguir, de los que sigan llegando, cuales son spam y cuales no (y además, seguirá "aprendiendo" sin que tengamos que "entrenarla a mano" más que en contadas ocasiones). Luego, será spamassassin quien cuando reciba un mensaje cualquiera, además de aplicarle sus reglas, consultará también con la base de datos bayesiana para puntuar más positiva o negativamente un mensaje.

Y el quinto, spf, validará los dominios desde los que dicen provenir los mensajes y hará que spamassassin recele de cualquier mensaje cuyo dominio no pertenezca realmente a quien dice pertenecer.

Como ves, estoy dando por sentado que poco más o menos conoces como funciona spamassassin, pero si no es así, pásate por aquí y, aunque en perfecto inglés, te podrás hacer una idea.

Bueno, pues si te parecen interesantes estas ampliaciones, sigue leyendo y en un rato las tendrás funcionando en tu servidor de correo.

DSBL

Bajo estas siglas se "esconden" un buen montón de máquinas en Internet que disponen de inmensas listas de direcciones IP que, por una causa u otra han sido consideradas como fuentes de mensajes tipo spam.

Su funcionamiento técnico es sencillo,... son como servidores de nombres (DNS) en los que cuando una dirección IP se considera fuente de spam pasa a ser incluido en ellos. La forma de usarlas será esta: cuando una determinada máquina conecte con sendmail para tratar de "endosarle" un mensaje, antes siquiera de aceptarlo, sendmail usará -a modo de servidor de nombres- alguna de las máquinas DSBL y, si encuentra en ellas la IP que trata de comunicarse con él, directamente rechazará el mensaje.

Tal vez te pueda parecer complejo hacer que sendmail se comporte así, pero afortunadamente, la mayor parte de los gestores de correo -por supuesto sendmail incluido- están preparados para hacer esto.

Edita el fichero /etc/mail/freebsd.mc (o como lo llames en tu máquina) y añade estas líneas:

    FEATURE(`dnsbl', `cbl.abuseat.org', `"550 Mail discarded. Rechazado: Vea el porque aquí http://cbl.abuseat.org/lookup.cgi?ip="$&{client_addr}')
    FEATURE(`dnsbl', `dnsbl.njabl.org', `"550 Mail discarded. Rechazado: Vea el porque aquí http://njabl.org/lookup?"$&{client_addr}')
    FEATURE(`dnsbl', `psbl.surriel.com', `"550 Mail discarded. Rechazado: Vea el porque aquí http://psbl.surriel.com/listing?"$&{client_addr}')

luego, teclea:

      # cd /etc/mail
      # make all
      # make install

rearranca el sistema de correo y observa lo que ocurre en /var/log/maillog. Es muy probable que veas en muy poco tiempo líneas como estas:

      Feb  2 02:58:14 iesmajuelo sm-mta[20592]: ruleset=check_relay,
      arg1=[220.199.139.200], arg2=127.0.0.2, relay=[220.199.139.200],
      reject=550 5.7.1 Mail discarded. Rechazado: Vea el porque aquí
      http://cbl.abuseat.org/lookup.cgi?ip=220.199.139.200

Algún detalle más. Sólo con este cambio es muy posible que te deshagas de más del 60% de los mensajes tipo spam que estuvieras recibiendo. Es decir, este sistema es muy potente y muy fácil de instalar y configurar.

Quizás te puedas plantear que si hay tantas bases de datos DSBL porqué usar una u otra (es más, yo te aconsejaría probar alguna diferente a las  tres que te sugería más arriba). En esencia todas son muy parecidas, y una vez que una dirección IP pasa a estar en una de ellas es muy probable que al poco tiempo acabe también en las demás.

Sin embargo, hay algunas de estas listas que son tan "agresivas" que incluyen subredes que comprenden cientos de máquinas solo porque un único usuario de esa subred haya enviado un mensaje tipo spam (digamos que hacen pagar a justos por pecadores). ¿Y porqué digo esto?... pues porque si leíste e instalaste lo que se dice en este documento y por tanto permites que a tu máquina se conecten los usuarios desde cualquier lugar siempre que se autentiquen convenientemente, puedes encontrarte -y te lo digo por experiencia propia- que alguno de tus usuarios vea como tu servidor ahora no le deja conectar... lamentablemente el problema será que alguien que comparte la misma subred que la que tiene ese usuario tuyo (tal vez seguramente porque usa una dirección IP dinámica) ha hecho que en una base de datos DSBL se haya incluido toda esa subred. Ante este problema hay al menos tres de soluciones: una es usar delay_check para sendmail (pero eso tendrás que hacerlo tú porque yo NO lo uso y por tanto no te puedo orientar), otra es que el propio usuario se ponga en contacto con su proveedor de conexión a Internet y con los responsables de la base de datos donde figura para intentar ser eliminado de ella, y la última -quizás la más sencilla- que cambies la base de datos DSBL que te de estos problemas por otra de las muchas que hay.

Rules du jour

Conéctate como administrador y teclea:

      # portinstall spamass-rules_du_jour

de las opciones que te propone, puedes marcar todas sin más (luego afinaremos eso) y en cuanto termine de compilar e instalar, teclea esto: 

      # cd /usr/local/etc/mail
      # cp rulesdujour.sample rulesdujour

ahora, edita el fichero /usr/local/etc/mail/rulesdujour y haz los siguientes cambios:

Por otra parte, edita también el fichero /usr/local/etc/mail/spamassassin/local.cf y añádele esta línea  allow_user_rules 1

Para comprobar que todo está correcto, teclea rules_du_jour y verás que tras conectarse a varios servidores y descargar varios ficheros de reglas, los almacena en /usr/local/etc/mail/spamassassin en forma de ficheros con extensión .cf . También lanzará un comando como este: spamassassin --lint para asegurarse de que todo es correcto. Es más, incluso rearrancará mimedefang si fuese necesario. Si no ocurriera así y ves un buen montón de errores, revisa en TRUSTED_RULESETS= hasta que des con la regla que te está dando problemas.

Por cierto, verás que también se crea un nuevo directorio (concretamente en esta dirección: /usr/local/etc/mimedefang/spamassassin/RulesDuJour) que le sirve a rules_du_jour para saber la próxima vez que lo arranques si alguna regla ha sido o no modificada... y digo esto, porque lo siguiente que haremos será incluir la ejecución de este comando como una tarea más para cron ... así nos "olvidaremos" de él y siempre tendremos las reglas de spamassassin "a la última". Simplemente teclea crontab -e y añade estas líneas a las que ya tengas:

      ######### Actualiza reglas spamassassin #############
      30 5 * * * /usr/local/bin/rules_du_jour

que poco más o menos significa que todos los días a las 5:30 de la mañana se actualizarán -si lo necesitan- las reglas para spamassassin. Bueno, mejor elige otra hora para que no todos intentemos hacer las actualizaciones en el mismo instante, ¿no te parece? :-)

Algunos cambios

Antes de seguir configurando lo que queda (Razor y el filtro bayesiano) te voy a proponer unos pequeños ajustes en los ficheros de configuración para que todo quede más coherente.

Por una parte, si te sitúas en /usr/local/etc/mail verás que dentro hay un subdirectorio llamado spamassassin. Pero si te sitúas en /usr/local/etc/mimedefang comprobarás que también ahí hay un directorio llamado spamassassin. Así que, ¿cual usa realmente el sistema para configurar los detalles de funcionamiento de spamassassin? Pues verás, si llamas a spamassassin desde la línea de comandos usará el primero, y si lo hace desde el sistema de correos -desde mimedefang- usará el segundo. Aunque hay a quien esto le puede parecer necesario, yo he optado por "unificar" los detalles de funcionamiento de spamassassin tanto si lo llamo "a mano" como si es el sistema de correos quien hace la llamada (digamos que prefiero que se comporte de igual forma lo llame quien lo llame y desde donde lo llamen).

Para esto, en primer lugar he eliminado el directorio /usr/local/etc/mimedefang/spamassassin y luego lo he creado de nuevo pero enlazándolo con /usr/local/etc/mail/spamassassin, es decir, he tecleado -como administrador- esto:

      # cd /usr/local/etc/mimedefang
      # rm -rf spamassassin
      # ln -s /usr/local/etc/mail/spamassassin spamassassin

con lo que de esta forma tengo todos los detalles de spamassassin en un único sitio.

Algo parecido a esto ocurre con el fichero /usr/local/etc/mimedefang/spamassassin/local.cf y con este otro /usr/local/etc/mimedefang/sa-mimedefang.cf . Ambos deben contener una configuración similar o  spamassassin actuará de diferente forma según desde donde sea invocado. Sin embargo, en este caso no he querido "eliminar y enlazar" ambos ficheros pues no todo su contenido es idéntico... pero si que los he configurado de forma similar. No te preocupes ahora por esto y haz únicamente la operación que proponía más arriba, luego ya retocaremos estos ficheros.

Razor

Conectado como administrador, haz esto:

      # cd /usr/local/etc
      # razor-admin -create -conf=/usr/local/etc/razor-agent.conf

verás que esto hace que tengas un nuevo fichero, precisamente este: /usr/local/etc/razor-agent.conf. Edítalo y haz este cambio: logfile = /var/log/razor-agent.log  Luego, teclea estos cuantos comandos:

      # touch /var/log/razor-agent.log      
      # chown mailnull:mailnull /var/log/razor-agent.log      
      # chmod ugo+r /var/log/razor-agent.log
      # razor-admin -register

Edita el fichero /usr/local/etc/mail/spamassassin/local.cf y añade esto:

      # Razor
      # para que realmente funcione también hay que habilitarlo en v310.pre
      use_razor2 1
      razor_timeout 4
      razor_config  /usr/local/etc/razor-agent.conf

y tal y como dice en el comentario de la segunda línea, también hay que revisar en el fichero /usr/local/etc/mail/spamassassin/v310.pre para que la siguiente línea esté descomentada (ojo que por defecto por temas de licencia viene comentada... además, quizás quieras leer la licencia "artística" que protege a Razor antes de decidirte a usarlo):

      loadplugin Mail::SpamAssassin::Plugin::Razor2

Por último, en el fichero /usr/local/etc/mimedefang/sa-mimedefang.cf añade:

      # Razor
      skip_rbl_checks 0
      use_razor2 1
      razor_timeout 4
      razor_config /usr/local/etc/razor-agent.conf

Un detalle más para poder usar Razor. Verás, la comunicación con los servidores Razor se hace por el puerto 2703. Así que revisa tu router, firewall o cualquier otro sistema de protección que tengas funcionando y que pueda bloquear este puerto, porque si no permites su uso Razor no funcionará.

Quizás ahora sería un buen momento para comprobar que Razor funciona. Como administrador, teclea:

      # razor-check -d -mbox /var/mail/algunusuario

aunque lógicamente en lugar de /var/mail/algunusuario tendrás que usar el mbox de alguno de tus usuarios o cualquier mensaje de correo que tengas por ahí. Por otra parte, de todo lo que se muestra a la salida de ese comando lo más interesante son las líneas del estilo:

      # feb 04 11:18:21.771110 check[38800]: [ 3] mail 1 is not known spam.
      # feb 02 11:19:07.598988 check[38800]: [ 3] mail 2 is known spam.

en las que verás si cada uno de los mensajes que procesa lo ha considerado o no como spam.

Por último, si quieres que los logs que genera Razor (en /var/log/razor-agent.log) vayan "girando" automáticamente al alcanzar un determinado tamaño, añade esto al fichero /etc/newsyslog.conf :

      # cada 100K crea un nuevo fichero razor-agent.log
      /var/log/razor-agent.log mailnull:mailnull 644 3 100 * Z

y no olvides indicar a syslogd que considere estos cambios con kill -1

Filtro bayesiano

Este quizás sea el apartado más "delicado" de instalar y configurar. Y no por su dificultad técnica, si no porque para que este sistema funcione correctamente hay que "entrenarlo" previamente. Vamos en primer lugar a instalarlo y luego ya nos preocuparemos de "entrenarlo".

Edita /usr/local/etc/mimedefang/spamassassin/local.cf y /usr/local/etc/mimedefang/sa-mimedefang  para añadirles estas líneas a ambos (más arriba ya comenté que prefiero que spamassassin se comporte de igual forma se llame desde donde se llame, de ahí lo de "repetir" la misma configuración en dos ficheros diferentes):

    # White list
    auto_whitelist_path /var/spool/MIMEDefang/auto-whitelist
    auto_whitelist_file_mode 0770
    #
    # Bayes
    use_bayes 1
    bayes_auto_learn 1
    bayes_learn_during_report 1
    bayes_auto_learn_threshold_spam 7.0
    bayes_auto_learn_threshold_nonspam 0.0
    bayes_journal_max_size 102400
    bayes_auto_expire 0
    bayes_min_ham_num 160
    bayes_min_spam_num 160
    bayes_file_mode 0770
    bayes_path /var/spool/MIMEDefang/bayes

en estas tres direcciones (aquí, aquí y aquí) tienes más detalles -eso si, en inglés- de este tipo de filtros. Pero, poco más o menos lo que esta configuración indica es que se use el filtro bayesiano, que aprenda por si mismo de los mensajes que va procesando (siempre que se superen -o no se rebasen, según el caso- unos determinados niveles de puntuación) y algunos detalles más sobre el mínimo número de mensajes (tanto "buenos" -los ingleses los llaman ham- como tipo spam) que deberán existir en la base de datos bayesiana antes de que el filtro comience a decidir por si mismo.

Una vez configurado, lo siguiente es "entrenar" el filtro. La forma de hacerlo es sencilla si dispones de un buen montón de mensajes (160 o más según hemos indicado más arriba) que sabes con certeza que son spam y otro buen montón de mensajes que estas seguro de que no son spam. Imagina que tienes los primeros almacenados en /tmp/MensajesSpam y los otros en /tmp/MensajesNoSpam , necesitarías estos comandos para realizar el "entrenamiento":

es decir, con el primero "enseñarás" a tu base de datos bayesiana como son los mensajes de spam que TU sueles recibir y con el segundo, como los que no lo son. ¿Y porqué resalto tanto el TU?... pues verás, quizás pienses que sería mejor entrenar la base de datos con miles de mensajes. En realidad no te falta razón, y si así quieres hacerlo puedes encontrar muchos sitios (prueba aquí por ejemplo) en donde te proporcionarán miles de mensajes para que "entrenes" tu base de datos bayesiana.

El problema es que para que esta "enseñanza" sea efectiva, deberás "entrenar" a la base de datos con los propios mensajes que tú recibas, y no con los que hayan podido recibir otras personas. Quiero decir que, aunque puede parecer buena idea usar una base de datos bayesiana entrenada con miles de mensajes recuperados desde algún lugar de Internet, es mejor idea usar una más pequeña pero creada a medida con tus propios mensajes... claro que eso exigirá que previamente seas tú quien almacenes tanto mensajes spam como mensajes que no lo son durante un tiempo para poder realizar el "entrenamiento a medida".

Pues ya sea usando uno u otro método, después del "entrenamiento", si curioseas en /var/spool/MIMEDefang verás, entre otros, unos ficheros como estos:

      # ls -la /var/spool/MIMEDefang/bayes*
      
      -rw-rw---- 1 mailnull mailnull   72408 4 feb 19:00 bayes_journal
      -rw-rw---- 1 mailnull mailnull  131072 4 feb 18:34 bayes_seen
      -rw-rw---- 1 mailnull mailnull 1343488 4 feb 18:34 bayes_toks

que contendrán tu base de datos bayesiana. De ellos, observa el que se llama bayes_journal. Lo que contiene son las últimas actualizaciones que aún están pendientes de llevar a la base de datos (digamos que para no "bloquear" constantemente base de datos con cada nueva modificación, las actualizaciones quedan pendientes de realizar hasta que así se indique manualmente). Para automatizar este proceso, te propongo que lo añadas al fichero de tareas periódicas del administrador. Es decir, teclea crontab -e y añade estas líneas a las que ya tengas:

      ######### Sincroniza base datos bayesiana ############
      45 5 * * * /usr/local/bin/sa-learn --sync --siteconfigpath=/usr/local/etc/mimedefang/spamassassin

que hará que todos los días a las 5:45 de la mañana se "sincronice" la base de datos bayesiana (dicho de otra forma, desaparecerá el fichero bayes_journal y únicamente quedarán los dos que forman la base de datos... puedes probar a ejecutar esa línea tú mismo desde el prompt del sistema y verás que es así).

En cuanto a comprobar si todo funciona correctamente, teclea:

      #  bash -c "spamassassin --lint -D 2>& 1 | grep -i bayes"

que te mostrará algo como esto:

      [43640] dbg: config: read file /usr/local/share/spamassassin/23_bayes.cf
      [43640] dbg: config: read file /usr/local/etc/mail/spamassassin/70_sare_bayes_poison_nxm.cf
      [43640] dbg: bayes: tie-ing to DB file R/O /var/spool/MIMEDefang/bayes_toks
      [43640] dbg: bayes: tie-ing to DB file R/O /var/spool/MIMEDefang/bayes_seen
      [43640] dbg: bayes: found bayes db version 3
      [43640] dbg: bayes: DB journal sync: last sync: 1139119982
      [43640] dbg: bayes: DB journal sync: last sync: 1139119982
      [43640] dbg: bayes: corpus size: nspam = 761, nham = 309
      [43640] dbg: bayes: score = 0.532890102241501
      [43640] dbg: bayes: DB journal sync: last sync: 1139119982
      [43640] dbg: bayes: untie-ing
      [43640] dbg: bayes: untie-ing db_toks
      [43640] dbg: bayes: untie-ing db_seen
      [43640] dbg: rules: ran eval rule BAYES_50 ======> got hit
      [43640] dbg: check: tests=BAYES_50,MISSING_SUBJECT,NO_REAL_NAME,NO_RECEIVED,NO_RELAYS,TO_CC_NONE

en donde ves que efectivamente el filtrado bayesiano se ha llevado a cabo.

SPF

Como adminitrador, teclea esto: 

     # portinstall p5-Mail-SPF-Query

y en cuanto termine, edita el fichero /usr/local/etc/mail/spamassassin/init.pre y comprueba que la línea siguiente esté descomentada (que será lo normal):

       loadplugin Mail::SpamAssassin::Plugin::SPF

Pues ya puedes comprobar que tal va el sporte para spf, simplemente teclea esto:

      # bash -c "spamassassin -D --lint 2>&1 | grep -i spf"

y verás al menos unas líneas como estas

      [48495] dbg: diag: module installed: Mail::SPF::Query, version 1.997
      [48495] dbg: config: read file /usr/local/share/spamassassin/25_spf.cf
      [48495] dbg: config: read file /usr/local/share/spamassassin/60_whitelist_spf.cf
      [48495] dbg: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC
      [48495] dbg: plugin: registered Mail::SpamAssassin::Plugin::SPF=HASH(0x8e44eec)

que te confirmarán que todo está correcto.

Todo a funcionar

Una vez instalados y configurados estos cinco apartados, rearranca todo el sistema de correo. Si seguiste el consejo que te di aquí puedes hacer algo como esto:

      # cd /usr/local/etc/rc.d
      # ./060.saslauthd.sh stop
      # ./050.sendmail.sh stop
      # ./040.clamav-freshclam.sh stop
      # ./030.clamav-clamd.sh stop
      # ./020.mimedefang.sh stop

que detendrá todos los servicios, y luego:

      # ./020.mimedefang.sh start
      # ./030.clamav-clamd.sh start
      # ./040.clamav-freshclam.sh start
      # ./050.sendmail.sh start
      # ./060.saslauthd.sh start

que los volverá a arrancar. Ahora revisa en /var/log/maillog que todo esté correcto y al poco tiempo verás mensajes como estos:

      Feb  5 01:01:10 iesmajuelo sm-mta[41962]: k1500OPY041962:
        from=, size=2006, class=0, nrcpts=1,
        msgid=<6802413063.20060204184645@grandrios.com>, proto=SMTP,
        daemon=IPv4, relay=[200.87.19.179]
      Feb  5 01:01:14 iesmajuelo mimedefang.pl[35597]:
        Mensaje eliminado: 23.749 (***********************)
        BAYES_99,FUZZY_XPILL,HTML_30_40,HTML_MESSAGE,RAZOR2_CF_RANGE_51_100,
        RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK,UNPARSEABLE_RELAY,URIBL_AB_SURBL,
        URIBL_JP_SURBL,URIBL_SBL,URIBL_SC_SURBL
      Feb  5 01:01:14 iesmajuelo mimedefang.pl[35597]: MDLOG,k1500OPY041962,
        mail_in,,The Ultimate Online Pharmaceutical
      Feb  5 01:01:14 iesmajuelo sm-mta[41962]: k1500OPY041962: Milter: data, discard
      Feb  5 01:01:14 iesmajuelo sm-mta[41962]: k1500OPY041962: discarded

-----------------------------------------

      Feb  5 01:03:25 iesmajuelo sm-mta[41968]: ruleset=check_relay,
        arg1=c-67-176-130-60.hsd1.il.comcast.net, arg2=127.0.0.2,
        relay=c-67-176-130-60.hsd1.il.comcast.net [67.176.130.60],
        reject=550 5.7.1 Mail discarded.
        Rechazado: Vea el porque aquí http://cbl.abuseat.org/lookup.cgi?ip=67.176.130.60

es decir, que esos dos mensajes han sido eliminados sin más por el propio servidor (uno por cumplir con casi todas las reglas que aseguran que es un mensaje tipo spam -no tienes más que ver el título que he resaltado en rojo para confirmarlo :-) - y el otro por proceder de un lugar "non-grato" (que ya ves que ni siquiera se ha procesado por el sistema de correo). Después de esto no te quedará duda de que todo está funcionando correctamente y que tu trabajo ha merecido la pena.

Conclusiones

Pues hasta aquí este documento. Como he insistido varias veces, lo que he contado amplía -y actualiza- lo que contaba aquí. Si tienes todo ya funcionando deberás notar una disminución drástica del spam que estuvieses recibiendo (en mi caso concreto, con más de 500 mensajes diarios, el filtrado del spam es casi total y no más de un par de mensajes cada día "se cuelan" a este sistema).

Verás por tanto que, aunque justo después de instalar sendmail este no aporte muchos "extras", si que gracias a su diseño es posible incluirle opciones y hacerle trabajar en colaboración con otros programas para que todos consigamos librarnos en la medida de lo posible de los mensajes tipo spam.

Y si has leído este artículo, habrás visto que únicamente con software libre y con FreeBSD como sistema operativo se puede conseguir.

Agradecimientos

A Daniel, que tras leer este documento amablemente me ha indicado algún nombre de fichero que había confundido.

Y, como otras veces, tampoco estará de más desde aquí mostrar mi agradecimiento a toda la gente que hace posible FreeBSD. Por supuesto acepto cualquier sugerencia al respecto y si tengo que aclarar algo o corregir cualquier error estoy dispuesto a hacerlo.

Emilio Florido (eflorido@iesmajuelo.com)