Bonjour !
Après des mois d'utilisation, je suis toujours aussi épaté de voir l'efficacité redoutable du filtre anti-spam de Mozilla Thunderbird.
Plus efficace que le Spamassasin que j'utilise pour identifier les spams côté serveur, malgré l'apprentissage de plusieurs milliers de ham et spams personnels, et un réglage que j'ai essayé d'affiner au fur et à mesure.
Est ce qu'à votre connaissance il existe un projet ré-utilisant le filtre anti-spam Mozillien, qui saurai s'interfacer avec amavisd ?
Si ce n'est pas le cas, par quel filtre bayésien (+ simple peut-être..) me conseillerez vous pour remplacer ce bon vieux SpamAssasin ?
# bogofilter ?
Posté par Vincent P (site web personnel) . Évalué à 1.
J'utilise bogofilter qui fonctionne très bien chez moi. plus d'infos ici :
http://bogofilter.sourceforge.net/(...)
Hope this helps,
vincent
[^] # Re: bogofilter ?
Posté par Francois SIMOND . Évalué à 1.
J'avais lu une critique concernant bogofilter, concernant le format de fichier d'apprentissage.
Est ce que tu n'as pas eu à re-construire trop souvent ta base spam/ham en fonction des versions ?
Sinon, est ce que tu l'utilises conjointement à Thunderbird ? (ce qui permet de comparer les résultats facilement, quand le client mail re-identifie des spams non marqués :)
C'est bête mais j'avais lu (je lis beaucoup :D) http://www.linuxfr.org/comments/507593.html#507593(...) , qui semblait supposer que bogofilter était surpassé par le filtre de thunderbird. Qu'en penses-tu ?
[^] # Re: bogofilter ?
Posté par Vincent P (site web personnel) . Évalué à 1.
J'utilise Bogofilter avec sylpheed(-claws). Je n'ai jamais reconstruit ma base d'apprentissage, qui doit dater maintenant de presque 2 ans je pense. J'ajoute de temps en temps les quelques spams qui passent a travers.
Je n'ai jamais utilisé thunderbird donc je ne peux pas faire de comparaison entre les deux. Je sais juste que Bogofilter fonctionne bien pour moi,il doit laisser passer un ou deux spams par semaines, sur pas loin d'un millier reçu.
A noter que la derniere version de bogofilter pose un probleme, une histoire de fichiers de log trop gros. Marqué comme bug grave sous debian, je pense que cela sera corrigé rapidement.
# récupérer les .dat de mozilla
Posté par jerome (site web personnel) . Évalué à 2.
. rules.dat pour les filtres (inutile dans ton cas)
. msgFilterRules.dat (la même chose)
. training.dat : ça se sont les rêgles pour filtrer le spam (celles que tu lui as appris)
Après faut trouver un moyen de rendre lisible tout ça (ça doit pouvoir se faire assez facilement) et voir si c'est réutilisable à moindre effort ...
[^] # Re: récupérer les .dat de mozilla
Posté par Francois SIMOND . Évalué à 1.
-rw-r--r-- 1 curio curio 1,4M nov 29 19:07 training.dat
Il n'est pas très gros. Pas très lisible non plus :)
Je songe à contacter le développeur mozilla concerné, peut être as t'il déjà pensé à exporter son filtre hors dépendance du codebase ?
Je suis intéressé par une piste à propos de qui contacter :D
# DSPAM
Posté par tuan kuranes (site web personnel) . Évalué à 1.
http://dspam.nuclearelephant.com/(...)
99.95%, plus rapide, moins de charge serveur et utilisation de base de donnees (mysql, pgsql et meme oracle)
Tu peux meme te generer des graphes pour montrer a quel point tu filtres.
[^] # Re: DSPAM
Posté par Francois SIMOND . Évalué à 1.
Le site web est très vendeur d'ailleurs :)
Et ses capacités impressionantes!
Et puis qu'il gère SQLite ou d'autres moteurs de base de données sans démon est une très bonne idée. Ça ferai désordre que la chaîne du MTA soit cassé à cause d'un démon SQL down !
Merci bien du conseil Paul, c'est du consulting efficace :D
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.