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 :

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 :

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 :

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 :

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…