Emile “iMil” Heitor ’s home

Je suis toujours dans le fastidieux processus de migration des services d’iMil.net vers sa nouvelle demeure. Vous ne l’avez probablement pas remarqué, mais le site que vous avez sous les yeux est désormais servi par un apache chrooté, reverse-proxyisé par l’incroyable nginx. Je reviendrai probablement sur cette configuration dans un prochain post.

Ce week end, je m’attaque à la migration du MX. *soupir*

Dans la liste infinie de trucs à configurer, il y a mon “nouveau” meilleur ami: dspam.

On aurait pu s’attendre à une installation straightforward de la bête (j’utilise évidemment intensivement pkgin pour l’installation des packages), mais en réalité, quelques petits casse-tête sont dispersés de-ci de-la.

En premier lieu, le package lui même. On peut lire dans le fichier options.mk le commentaire suivant :

### This is the backend database used to store the DSPAM signatures as
### well as other state information.  The recommended storage driver is
### "mysql", even for small installations.

“Fabuleux”, me dis-je. Sauf que les deux lignes d’après précisent :

### Possible: mysql, pgsql, sqlite, sqlite3 or hash
### Default: hash

Va comprendre. Cela signifie que, une fois n’est pas coutume, je devrai me fendre de la compilation de ce package avec une option particulière :

$ grep -i dspam /etc/mk.conf
DSPAM_STORAGE_DRIVER=   mysql

Bon.

La configuration du logiciel en soi n’a pas changé, je vous renvoie aux differentes documentations expliquant les paramètres clé du fichier dspam.conf.
L’integration à sendmail n’a pas changé non plus, ces deux lignes appliquées à votre .mc suffiront :

define(`LOCAL_MAILER_PATH', `/usr/pkg/bin/dspam')
define(`LOCAL_MAILER_ARGS', `dspam -t -Y -a $h "--deliver=innocent" --user $u -d %u')

Je rappelle à toutes fins utiles que la construction du .cf, sous NetBSD, s’effectue de cette façon :

make install-cf CF=nom

Jusqu’ici, tout va bien.

Et nous en arrivons à la partie la moins bien integrée du package: l’interface web. Première chose, le package n’embarque pas toutes les dépendances nécessaires au bon fonctionnement de l’interface de dspam. Il vous faudra donc vous fendre d’un :

$ sudo pkgin in p5-GD p5-GD-Graph3d

Afin de ne pas voir admingraph.cgi se crouter misérablement.

Vient ensuite l’application web en elle même. Je ne souhaitais pas dédier un vhost à dspam, mais plutot l’utiliser dans un sous repertoire de la partie privée de mon site; en effet, cette dernière est accédée en HTTPS, sur un FQDN unique, et l’idée de gêrer plusieurs certificats CACert pour mes simples besoins me rebutait. En prime, cette methode me permet de configurer mon reverse proxy le plus simplement du monde.

Ainsi, j’ai copié l’ensemble des fichiers situés dans /usr/pkg/share/dspam/webui/cgi-bin/ et /usr/pkg/share/dspam/webui/htdocs/ dans un repertoire dédié. Afin de signifier à apache qu’il devra interpreter les cgi de ce repertoire, j’ai ajouté un fichier .htaccess contenant les directives suivantes :

Options +ExecCGI
AddHandler cgi-script .cgi .pl

Tous ces cgis incluent le fichier /usr/pkg/etc/dspam/configure.pl, qui définit entre autres la variable WEB_ROOT, chemin vers la CSS et la petite icône dspam. Plutot que de copier le fichier configure.pl puis modifier tous les scripts afin que l’inclusion se fasse sur ./configure.pl, j’ai renseigné la variable qui m’interesse directement dans /usr/pkg/etc/dspam/configure.pl :

$CONFIG{'WEB_ROOT'}     = "/dspam";

Reste à copier le fichier /usr/pkg/etc/dspam/cgi-default.prefs dans le repertoire choisi pour héberger l’interface dspam sous le nom default.prefs, et enfin d’ajouter l’utilisateur autorisé à manipuler l’interface dans /usr/pkg/etc/dspam/cgi-admins.

Tout ceci n’est pas bien propre, je vous l’accorde.

Notez que si vous souhaitez utiliser un vhost, la configuration serait bien moins fastidieuse puisqu’il suffirait de créer un VirtualHost dans lequel vous préciseriez un ScriptAlias et un DocumentRoot.

L’année dernière, je mettais en place dspam, sur mon serveur dédié. Naïf, je me disais que pour gerer mes propres mails, le backend sqlite serait amplement suffisant, et finalement tout ce petit monde a parfaitement fonctionné pendant quelques mois. Et puis la database a grossi, grossi, grossi au point d’etre lente à crever et provoquer ce type de réaction :

pid 71865 (dspam), uid 0: exited on signal 6 (core dumped)
pid 72017 (dspam), uid 0: exited on signal 6 (core dumped)
pid 72289 (dspam), uid 0: exited on signal 6 (core dumped)

Après que 2 attaques massives de spams aient écroulé la machine, je me suis enfin décidé à changer de backend… et la différence est simplement indescriptible.

L’opération s’est avérée plus simple que je ne l’imaginais. Tout d’abord, il est nécessaire de re-installer le port dspam en y ajoutant le support MySQL à l’aide de la commane make config

Un make deinstall reinstall plus loin, le binaire supporte les deux backends (sqlite et MySQL), et avant d’apporter les modifications à la configuration de dspam, nous nous assurons de créer une database dspam et de peupler cette dernière avec les commandes SQL fournies dans le package dspam :

$ mysql -u dspam -p dspam < /usr/local/share/examples/dspam/mysql/mysql_objects-4.1.sql

Nous pouvons alors modifier le fichier dspam.conf :

StorageDriver /usr/local/lib/libmysql_drv.so
# [...]
MySQLServer     /path/vers/mysql.sock
MySQLUser               dspam
MySQLPass               mangeducacaspammer
MySQLDb                 dspam
MySQLConnectionCache    10
MySQLUIDInSignature    on

Et redémarrer le serveur :

# /usr/local/etc/rc.d/dspam restart

Reste à nourrir notre nouvelle database à l’aide de deux corpus spam et ham d’environ 1000 mails chacun (voir le post de l’année dernière).

Pour finir, j’ajoute un cron-job qui nettoie la base de données tous les soirs, à l’aide d’un jeu de commandes SQL fourni par le package dspam :

30 01 * * * /usr/local/bin/mysql -u dspam --password=mangeducacaspammer dspam < /usr/local/share/examples/dspam/mysql/purge-4.1.sql

Et mon gentil dédié ne souffre plus.

Notez par ailleurs que devant une telle recrudescence, j'avais fini par réinstaller l'excellent milter-greylist du sieur Emmanuel Dreyfus, et que le résultat est sans appel: si certains MTAs tolèrent mal les codes 4xx et ne renvoient le mail que plusieurs heures plus tard, mon ratio de spams, lui, est passé de 800 / jour en moyenne à 30 / jour en moyenne. Le choix est vite fait...