Exemple de mise en oeuvre

L'exemple de mise en oeuvre est un filtre en Perl pour Sendmail, bâti sur la version 0.18 de l'interface Sendmail::Milter (que l'on peut aussi se procurer sur CPAN. Il a été testé avec Sendmail 8.12.9, et devrait fonctionner avec toute version postérieure à 8.12.5. Sendmail::Milter impose l'utilisation d'une version de Perl avec threads. Nous avons fait les tests avec perl 5.8.0, que l'on peut aussi trouver sur CPAN.

Vous trouverez aussi des définitions de bases de données, ainsi qu'un fichier de configuration. La mise en oeuvre étant écrite en Perl, elle est facile à modifier (mais n'est pas encore sur CPAN...).

La base de données utilisée est Mysql 3.23.54, mais le système devrait fonctionner avec toute version postérieure, et probablement avec d'autres antérieures. Le système de tests utilisait aussi amavisd-new ainsi que la nouvelle interface milter associée, configurée à l'aide de Spamassassin 2.53 pour bloquer les pourriels reçus.

Dans l'idée de diffuser une version d'exemple simple et facile à comprendre, certaines fonctionnalités, qui auraient pu facilement être optimisées, ne l'ont pas été. Malgré cela, durant des tests sous forts volumes de pourriels, le léger allongement du temps de traitement est demeuré invisible dans la plupart des cas. Les rares fois pour lesquelles le délai devenait visible s'expliquaient par les temps d'accès à la base de données (placée sur un autre système).

Les aficionados de la programmation structurée pourront avoir un arrêt cardiaque en examinant certaines portions du code : nous y utilisons plusieurs fois des goto. Du fait du fonctionnement de l'interface milter, cela semblait la solution la plus simple.

Autres détails sur la version d'exemple

Les messages correctement transmis dont l'émetteur est nul () sont un cas particulier. L'enregistrement associé dans la base est détruit immédiatement après la transmission du message, afin d'éviter que cet émetteur ne soit placé en liste blanche. Cet émetteur (si l'on respecte la RFC 821) n'est utilisé que pour des messages administratifs, comme les rejets. Il n'est donc normalement jamais utilisé pour plus d'un message à la fois. De ce fait, il est inutile de mémoriser le triplet associé une fois le message transmis.

Malheureusement, de nombreux spammeurs utilisent volontairement cette adresse nulle car, usuellement, elle ne provoquera pas un message de rejet de la part du serveur de destination (il est inutile d'envoyer un message de rejet en réponse à ce qui est normalement déjà un message administratif). Supprimer immédiatement le triplet après la transmission du message permet de limiter son utilisation par les spammeurs, puisqu'ils ne peuvent en profiter pour envoyer plusieurs messages vers un même destinataire.

D'autres fonctionnalités mineures sont présentes dans la version d'exemple, qui ne font pas partie stricto sensu partie du Greylisting. Elles visent à améliorer ou affiner le fonctionnement du filtrage des pourriels.

La base de données n'est pas normalisée. Il s'agit d'un choix volontaire, pour permettre à des utilisateurs peu familiers des bases de données de comprendre son fonctionnement. Cependant, il devrait être relativement facile de normaliser le schéma si le besoin s'en fait sentir.

Les outils de la version d'exemple ne contiennent aucun outil de maintenance de la base de données. Il n'existe aucun moyen d'insérer des triplets en liste blanche, si ce n'est les commandes SQL du fichier dbdef.sql. Je suppose que, à terme, une interface Web apparaîtra, mais elle n'existe pas pour le moment.