Par ailleurs, l'équipe a publié une dernière version (la 2.64) sous licence GPL/Artistic pour corriger une faille de sécurité permettant un déni de service. On soulignera que, d'après la FSF, cette licence rendra SpamAssassin 3 non compatible GPL (même s'il restera un logiciel libre), bien que ce ne soit pas l'avis de la fondation Apache. Lisez la discussion DLFP si vous voulez des précisions.
NdM : la FAQ de la Fondation donne la position non officielle (!) sur la compatibilité GPL de l'ASL. La liste des licences libres incompatibles GPL de la FSF donne la position de celle-ci.
Aller plus loin
- SpamAssassin (9 clics)
- Apache Software Fondation (1 clic)
- FAQ sur l'Apache Licence version 2 (1 clic)
- Le wiki de SpamAssassin (6 clics)
- La version 2.64 (1 clic)
- DLFP: la licence Apache 2.0 (2 clics)
# Projet apache
Posté par Sylvestre Ledru (site web personnel) . Évalué à 10.
(a part pour la reconnaissance/notoriete)
[^] # Re: Projet apache
Posté par hachesse . Évalué à 10.
Pour un projet comme Spam Assasin, integrer l'ASF c'est bien plus qu'une reconnaissance, c'est l'acces a des moyens biens superieurs.
# En passant...
Posté par seeschloss . Évalué à 1.
# 2.64
Posté par FRLinux (site web personnel) . Évalué à 5.
Steph
[^] # Re: 2.64
Posté par Maxime Ritter (site web personnel) . Évalué à 3.
http://maxime.ritter.eu.org/rule-get(...)
Gros avantage pour les Français notamment : il reconnait mes règles perso pour les spams français !
# Fork?
Posté par Aldoo . Évalué à -10.
----->[] (ça y est)
# Dans le même genre
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Dans le même genre
Posté par Cédric Foll . Évalué à 10.
J'utilise postfix avec amavis-new.
On peut faire tout ce que tu veux (différentes cfg suivant les domaines et les users locaux).
Avec pour comme AV ClamAV (génial) et spamassassin (génial aussi).
Mes 2 MX sont des Bi-Xeon avec 2 Go de ram pour l'un 1Go de ram pour l'autre.
Ca marche top !
ClamAV est vif comme l'éclair et consomme très peu de ressources, en plus les signatures sont très souvent dispos avant la plupart des AV propriétaires. En fait il semble que seul Kaspersky soit plus réactif.
Spamassassin consome par contre bcp plus de ressources, 10 process de 50 Mo chacun chez moi. En fait avec amavis-new ce sont des process amavis mais ça revient au même. En ce qui concerne la qualité du filtrage elle est tout simplement excellente !
Avant cette conf j'utilisait un script shell home-made appelé par postfix et qui utilisait bogofilter et clamav. Ca consommait infinement moins de ressources mais le filtrage anti-spam était bcp moins bon et amavis-new fait pleins de choses supères (gestion de quarentaines, cfg par user, par domaine, notif par mail configurable, ...)
[^] # Re: Dans le même genre
Posté par Damien Pobel (site web personnel) . Évalué à 4.
Mais j'utilise les mêmes outils (sauf le serveur évidemment :) et j'ai les mêmes remarques. C'est vrai qu'amavis-new est très souple, mais bouffe énormément de ressources, d'ailleurs je pense qu'il faut pas hésiter à bien gaver la machine en RAM.
Faudrait que je teste bogofilter à la maison, je me demande si ça pourrait pas passer sur mon p200 avec 160Mo de RAM ?
https://damien.pobel.fr
[^] # Re: Dans le même genre
Posté par Olivier Grisel (site web personnel) . Évalué à 6.
A tester donc.
[^] # Re: Dans le même genre
Posté par Cédric Foll . Évalué à 4.
Sans aucun problèmes!
bogofilter ne fonctionne pas en mode démon, il se lance pour chaque mail mais est super rapide. Sur mon ex MX (un PIII avec 512 Mo de ram) l'analyse d'un message prenait qq centièmes de secondes.
[^] # Re: Dans le même genre
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
[^] # Re: Dans le même genre
Posté par Cédric Foll . Évalué à 1.
Le processseur était je crois un PIII 1 à GHz (à moins que ce soit un PIV, je me souviens plus trop).
Disque dur SCSI.
[^] # Re: Dans le même genre
Posté par Stéphane Thomas . Évalué à 4.
Je ne voudrais pas dire de bétise mais :
"Spamassassin consome par contre bcp plus de ressources, 10 process de 50 Mo chacun chez moi. "
Il me semble que si la commande top indiquent plusieurs process pour un même programme, en fasse de chaque process c'est la quantité totale de mémoire vive consommée par le programme. => Spamassasin consommerait donc en tout et pour tout 50 Mo chez toi...
Si je dis n'importe quoi j'éspère que quelqu'un corrigera.
[^] # Re: Dans le même genre
Posté par Ludovic . Évalué à 3.
Et, il y en a un qui a une taille différente. Donc, je ne m'etais jamais posé la question, mais, je dirai que tu te trompes et que c'est bien la taille de chacun de processus ;)
Mais bon, c'est à vérifier tout de même. Je peux me tromper aussi.
Pour info :
Oui !, je sais, ils sont ridicules en mémoire mes process, mais bon, faut dire que sur ma machine perso, je n'ai que ..... 1 utilisateur ;)
++
Ludo
[^] # Re: Dans le même genre
Posté par pasBill pasGates . Évalué à 5.
Si c'est des process independants et qu'ils ne partagent pas de memoire, alors c'est 50Mo chacun.
Si ce sont des thread d'un meme process, c'est 50Mo pour l'ensemble
Si ce sont des processus independants qui partagent de la memoire, alors c'est un chiffre entre 50 et z processus x 50
[^] # Re: Dans le même genre
Posté par flyer . Évalué à 2.
Sous AIX par exemple un ps ne fait apparaître qu'un seul processus même s'il est multithreadé.
[^] # Re: Dans le même genre
Posté par pasBill pasGates . Évalué à 2.
Quand au pourquoi du comment avant, ben si je dis ce que pense je vais encore me faire allumer, donc je te laisse te faire ton opinion...
[^] # Re: Dans le même genre
Posté par tgl . Évalué à 3.
[^] # Re: Dans le même genre
Posté par Sebastien (site web personnel) . Évalué à 1.
>Pourquoi l'implémentation des threads sous linux n'est-elle pas améliorée? Je
>pense au fait de ne pas attribuer des PID (Processus Id) à chaque thread.
Ce n'est pas forcément plus économe en resources de pratiquer sans PID. Typiquement, le point mis en avant sur le sujet pour comparaison, est que le coût de création d'un processus sous Linux est bien moindre que sous Windows. Et ce n'est pas parce qu'il porte un PID à part entière que ça en fait un réel processus. Les threads partagent le tas et n'ont que la pile pour les différencier, essentiellement.
Mais comme dit ailleurs dans la discussion, sous noyau 2.6 (ou backport) avec les NPTL, on ne se retrouve pas dans la même situation.
seb.
[^] # Re: Dans le même genre
Posté par LeMagicien Garcimore . Évalué à 2.
[^] # Re: Dans le même genre
Posté par MrTout (site web personnel) . Évalué à 1.
[^] # Re: Dans le même genre
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Un petit bémol pour finir, je n'ai pas énormément d'utilisateurs à gérer (3 ;-) donc après, faut voir la montée en charge de l'ensemble.
[^] # Re: Dans le même genre
Posté par FRLinux (site web personnel) . Évalué à 2.
SpamHaus en SBL/XBL
Spamassassin en filtrage de spams qui passent
Rules du jour en add on antispam pour SA
ClamAV en antivirus
Quelques regles perso en body,header dans postfix
Steph
[^] # Re: Dans le même genre
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Une solution complémentaire est la liste grise [http://projects.puremagic.com/greylisting/(...)]. Je n'y croyais pas trop, mais un ami a insisté et je dois dire que ça réduit considérablement le nombre de spams, ainsi que les retours (bounces) bloqués dans la file d'attente.
Envoyé depuis mon PDP 11/70
# compatibilité GPL
Posté par Antoine . Évalué à -4.
Ce n'est pas grave, l'INRIA planche sur un logiciel de remplacement sous licence CeCILL et fonctionnant sur ordinateurs Goupil. Tous les mails écrits dans une langue autre que le français, ou composés sur un clavier non-Azerty, seront automatiquement classés dans la rubrique "pourriels".
Le logiciel - parrainé par Alain Delon, Thierry Lhermitte et Renaud Dutreil - sera installé dans les mois qui viennent sur les serveurs de mail de l'INRIA.
Bien sûr, certains chercheurs se plaignent qu'ils ne pourront plus lire les mails de leurs correspondants étrangers, mais il était évident que la France avait besoin d'un système de filtrage adapté au contexte national. On ne pouvait plus décemment se contenter d'un système d'origine anglo-saxonne qui ne respectait en rien notre culture.
[^] # Re: compatibilité GPL
Posté par Stéphane Traumat (site web personnel) . Évalué à -1.
http://about.me/straumat
[^] # Re: compatibilité GPL
Posté par rootix . Évalué à 1.
Si tu as quelque chose à leur dire, y a postmaster@inria.fr pour te plaindre.
Un nouveau système de filtre a été mis ces derniers temps pour tenter de lutter contre le spam. Si ça filtre trop, ce sera enlevé.
[^] # Re: compatibilité GPL
Posté par Antoine . Évalué à -2.
[^] # Re: compatibilité GPL
Posté par rootix . Évalué à 0.
[^] # Re: compatibilité GPL
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
Ça me fait penser aux utilisateurs de l'espéranto qui refusaient de voir une modification ou amélioration de leur langue à travers l'Ido, ou même que l'esperanto soit considéré à valeur égale avec le neutral language.
Si un travail n'est pas populaire, hé bien il est moins utilisé... Mais ça ne veut pas dire qu'il est sans intérêt. Au contraire, bien souvent. Voir l'OCAML.
[^] # Re: compatibilité GPL
Posté par Maxx . Évalué à 1.
[^] # Re: compatibilité GPL
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
N'empeche que c'est un des plus vieux trolls, il date du début du siècle dernier.
# allez je me lance...
Posté par Jerome Alet (site web personnel) . Évalué à -5.
DSpam rulez !
[^] # Re: allez je me lance...
Posté par Jerome Alet (site web personnel) . Évalué à 0.
[^] # Re: allez je me lance...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 0.
[^] # Re: allez je me lance...
Posté par Cédric Foll . Évalué à 1.
En fait dspam est utilisable via amavis-new dans les dernières versions.
cf http://www.ijs.si/software/amavisd/release-notes.txt(...)
Cependant je ne l'ai jamais testé.
[^] # Re: allez je me lance...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
Eventually DSPAM support should be removed from amavisd-new, as soon as SA will be able to call it on its own.
Bon et bien on va attendre un peu :)
[^] # Re: allez je me lance...
Posté par ArnY (site web personnel) . Évalué à 1.
J'attend avec impatience la release finale de SA 3.0 pour pouvoir completer les fonctionnalité de base de SA avec dspam et crm114 (ou l'un ou l'autre)
[^] # Re: allez je me lance...
Posté par Jerome Alet (site web personnel) . Évalué à 3.
NB : du spam pour moi n'en est pas forcément pour toi, par exemple moi je ne m'intéresse guère aux pubs pour me faire grossir la bite, alors que toi tu les consultes avidement (ce n'est qu'un exemple, je ne sais pas si c'est vrai ;-) donc un filtrage système à priori j'y crois pas du tout.
en fait dans SA, c'est le système de règles qui est à chier : si elles ne sont pas régulièrement mises à jour la qualité du filtrage diminue énormément, sauf évidemment à utiliser des filtres statistiques, mais dans ce cas SA perd tout son intérêt puisque d'autres produits meilleurs et plus rapides existent.
[^] # Re: allez je me lance...
Posté par Olivier Grisel (site web personnel) . Évalué à 7.
http://www.nuclearelephant.com/projects/dspam/#top(...)
C'est un projet GPL de filtre anti-spam statistique (avec des extensions évoluées notamment au niveau preprocessing des emails). C'est codé en C dans un soucis de perfs et de bonnes gestion des ressources. Il se presente sous forme d'un service unix pour serveur de mails ou d'une lib à intégrer directement dans le client email.
# tentative spamassassin + sylpheed
Posté par rootix . Évalué à 4.
Conclusion, il faut filtrer au niveau du serveur sinon, ça fait récupérer en plus de ça les mails pour rien.
[^] # Re: tentative spamassassin + sylpheed [complètement HS]
Posté par Colin Leroy (site web personnel) . Évalué à 6.
Uh? Tu veux dire quoi par "multi-tâche"? multi-thread?
Sinon je suppose que tu veux parler de Sylpheed-claws, vu que Sylpheed n'a pas encore, à ma connaissance, de plugins.
Pour info, et on l'a répété beaucoup, le multi-threading n'est pas la panacée pour résoudre les problèmes d' I/O bloquante - principalement du fait de toute la synchronisation inter-thread qui doit être faite pour éviter toutes les race-conditions qui arrivent sinon. De plus, plusieurs threads dans une appli GTK signifie problèmes à très court terme si jamais plus d'un thread fait du GTK. Ce qui complique encore la tâche.
(Evidemment, ç'aurait été plus facile de traiter ces problèmes si sylpheed avait été multi-thread à la naissance).
Tout ça pour dire que d'autres solutions existent, les systèmes de rappel de callback quand des données sont prêtes (g_io_channels, ...) et tous les systèmes différents de poll de socket (poll, select) (qui ont chacun leurs avantages et inconvénients. Dans S-C c'est des systèmes de callbacks, principalement, qui sont utilisés.
Enfin, le débloquage des I/O dans sylpheed a beaucoup progressé ces derniers temps; le dernier appel bloquant que j'aie trouvé, SSL_connect(), qui faisait bloquer à l'initialisation, vient d'être 'débloqué' (grâce à un micro thread dont le cycle de vie est l'appel de cette fonction). Ce sera dans la prochaine release.
[^] # Re: tentative spamassassin + sylpheed [complètement HS]
Posté par rootix . Évalué à 2.
[^] # Re: tentative spamassassin + sylpheed [complètement HS]
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
# spamassassin vs thunderbird
Posté par Etienne Juliot (site web personnel) . Évalué à 3.
[^] # Re: spamassassin vs thunderbird
Posté par Cédric Foll . Évalué à 3.
Je reçoit énormément de spam personnelement sur mon adresse non-pro (environs 300 par jours) et spamassassin me les bloque bcp mieux (et fait bcp moins d'erreurs).
Sur les 300, thunderbird m'en bloque environs 290 et par contre c'est là ou le bas blaisse, il m'en met assez souvent en spam à tord.
En fait, à ma connaissance, thunderbird ne fait que du bayesien tout bête, système qui commence à montrer ses limites. Spamassassin de son coté fait bcp plus de tests, mais est bcp plus lent et consomme bcp plus de ressources.
[^] # Re: spamassassin vs thunderbird
Posté par nemerid . Évalué à 0.
C'est bluffant :)
[^] # Re: spamassassin vs thunderbird
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: spamassassin vs thunderbird
Posté par Olivier Grisel (site web personnel) . Évalué à 3.
[^] # Re: spamassassin vs thunderbird
Posté par Cédric Foll . Évalué à 2.
Thunderbird fait exactement la même chose. De même que bogofilter, dspam, crm114, ...
En fait la différence est que spamassassin fait d'autres trucs en plus alors que ces derniers ne font que ça. C'est à dire que même sans rien avoir apris, spamassassin sait deja classer a peu prêt bien ce qui est spam de ce qui ne l'est pas.
[^] # Re: spamassassin vs thunderbird
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
[^] # Re: spamassassin vs thunderbird
Posté par Maxx . Évalué à 3.
Il n'y a pas d'évolution prévue pour y intégrer de l'intelligence articielle ? ;)
D'ailleurs je ne sais pas si c'est au point ça l'I.A. ?
Qqn pour nous en parler dans ce contexte là ? Des chch de l'INRIA par ex.? ;)
[^] # Re: spamassassin vs thunderbird
Posté par Gauthier (Mastodon) . Évalué à 4.
Tous les ordinateurs de l'univers sont réunis en un réseau afin de constituer un superordinateur à qui l'on pose une première question: "Y a-t-il un Dieu?". La réponse est fulgurante: "Maintenant, il y en a un" Tandis qu'un éclair surgit du ciel et détruit le levier qui permettrait de débrancher le réseau.
Extrait de la préface de Gérard Klein, du livre Excession de Iain M.Banks.
A mes yeux, l'I.A. est non seulement un mythe mais le dernier avatar du mythe du Progrès au sens scientiste et rationnelle du terme ...
[^] # Re: spamassassin vs thunderbird
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
http://perso.club-internet.fr/branchum/brown.htm(...)
excellent auteur. Le recueil de nouvelles "fantômes et farfafouilles" est très bien et fortement conseillé :-)
[^] # Re: spamassassin vs thunderbird
Posté par Olivier Grisel (site web personnel) . Évalué à 3.
Certains considèrent que l'univers ne seraient "qu'un" ordinateur/caculateur (cf La Recherche - Janvier 2003 et cet article de G. Chaitin : http://www.cs.umaine.edu/~chaitin/bonn.html(...) ). Pour résumer, ce courant d'idées vient de l'études des automates cellulaires, petits objets mathématiques munis de règles d'évolution très simples qui sont capable d'engendrer des comportements globaux très complexes.
Si l'on adhère à ce point de vue et que l'on considère que l'Homme est intelligent et que l'Homme n'est qu'une sous-partie de l'univers, on peut considérer que l'Homme n'est "qu'une" sorte de programme intelligent. Donc "programme" et "intelligence" ne sont pas forcemment des notions antinommiques.
> D'ailleurs je ne sais pas si c'est au point ça l'I.A. ?
On considère généralement qu'un algorithme capable d'apprendre à classer des spams (comme le filtre bayésien de Thunderbird par exemple) comme relevant de l'intelligence artificielle (apprentissage inductif supervisé). Etant donné que certains filtres anti spam bien entrainés sont aussi efficaces qu'un être humain, alors on peut dire que pour certains domaines d'application, "l'I.A. est au point".
Par contre il n'existe pas à l'heure actuelle de machine capable de réussir le test de Turing (mais est ce vraiment un objectif utile ?). Tout dépend de l'objectif demandé et de la définition du mot "intelligence".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.