samedi 06 septembre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[39] L'éditeur HTML Nvu 0.40 est sorti
[3] PloneiCalendar 1.0Beta2 est sorti !
[31] Yzis sort sa deuxième version
[38] Un aperçu de GNOME 2.8
[27] Blender 2.34 est sorti
[76] Nouvelles versions des pilotes ATI et NVIDIA pour GNU/Linux
[55] EFL atteint le stade de preview release
[44] IBM donne Cloudscape à la communauté open-source
[38] Helix Player 1.0 et Real Player 10
[37] Gnu TeXmacs 1.0.4 vient de sortir

Liens connexes

SpamAssassin (1608 hits)
Apache Software Fondation (333 hits)
FAQ sur l'Apache Licence version 2 (300 hits)
Le wiki de SpamAssassin (528 hits)
La version 2.64 (333 hits)
DLFP: la licence Apache 2.0 (769 hits)

Dépêche modérée par

Oumph

Dépêche éditée par

Oumph

Logiciel : SpamAssassin devient un projet Apache, et corrige une faille de sécurité

Posté par KaTeznik (page perso, ). Modéré le 12 août 2004.

Le filtre anti-spam SpamAssassin a été officiellement accepté comme projet par la fondation Apache. Cette modification implique que la nouvelle version (3.0.0, actuellement en préversion) sera publiée sous licence Apache version 2.

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.

SpamAssassin (1608 hits)
Apache Software Fondation (333 hits)
FAQ sur l'Apache Licence version 2 (300 hits)
Le wiki de SpamAssassin (528 hits)
La version 2.64 (333 hits)
DLFP: la licence Apache 2.0 (769 hits)

> Lire la suite (56 commentaires, moyenne: 2,5). [dépêche : 593 caractères]

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.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Projet apache

Posté par Sylvestre Ledru (Jabber id, page perso, ) le 12/08/2004 à 16:40. (lien). Évalué à 14.

Ca apporte quoi de devenir un project apache ?
(a part pour la reconnaissance/notoriete)

[^]Re: Projet apache

Posté par hachesse (page perso, ) le 12/08/2004 à 18:55. (lien). Évalué à 19.
L'ASF est une des plus grosses fondations du libre (avec la FSF, la fondation Mozilla, ...) et c'est aussi une des fondations qui à le plus de soutient. Ce soutient viens de societé qui aide l'ASF que ce soit par des donts d'argent ou de code, la mise a disposition de serveurs pour l'hebergement, mais aussi le pret de developpeur, des aides a la communication (presence lors de grand rendez vous de l'informatique)

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 () le 12/08/2004 à 16:54. (lien). Évalué à 1.

... il manque le 'h' de http dans l'adresse de la "position non officielle" : ttp://www.apache.org/foundation/licence-FAQ.html#GPL

2.64

Posté par FRLinux (page perso, ) le 12/08/2004 à 17:10. (lien). Évalué à 5.

Très bien cette version, je l'ai passée en prod la semaine dernière et elle apporte également un backport non négligeable de règles venant de 3.0. Pour ceux qui veulent encore un controle plus violent des règles, tentez rules_du_jour. A vos risques et perils ceci dit, car mal configuré, il mangera votre CPU sous la masse de processes Perl. C'est par la : http://www.exit0.us/index.php/RulesDuJour(...)

Steph

[^]Re: 2.64

Posté par Maxime Ritter (page perso, ) le 12/08/2004 à 17:58. (lien). Évalué à 3.
Ou la même chose avec gestion des signature GPG (entre autres), et dont la base de données des règles connus peut-être mis a jour tout seul (entre autres) :

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 (Jabber id, ) le 12/08/2004 à 17:39. (lien). Évalué à -10.

Attention, ça va forker !

----->[] (ça y est)

Dans le même genre

Posté par Fabien Penso (Jabber id, page perso, ) le 12/08/2004 à 18:06. (lien). Évalué à 3.

Dans la même catégorie, et pour ceux qui gèrent des serveurs de mails avec pas mal de domaines, vous avez choisis quel outil contre le spam pour que ça marche au niveau system (pour tous vos utilisateurs), les mails que vous relayez, etc.

--
blog them all :: la photo du jour
Je vote pour LinuxFr en Rails !

[^]Re: Dans le même genre

Posté par Cédric Foll (page perso, ) le 12/08/2004 à 18:46. (lien). Évalué à 12.
Je gère le domaine ac-rouen.fr qui contient environs 47 000 mails comptes mails (et qq autres domaines bcp plus modestes).
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 (page perso, ) le 12/08/2004 à 22:27. (lien). Évalué à 4.
  bon je m'occupe d'un serveur de mail beaucoup [...] beaucoup plus modeste... Environ 600 users :)
  
  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 ?
  
  --
  Album de photos numériques - Pages du manuel Linux
  - [^]Re: Dans le même genre
    
    Posté par champi (page perso, ) le 12/08/2004 à 23:28. (lien). Évalué à 6.
    Je viens de découvrir DSPAM (http://www.nuclearelephant.com/projects/dspam/(...) ) cf plus bas qui à l'air plus performant que spamass et moins gourmant au niveau ressources (codé en C, GPL, bayésien, compatible amavis-new...).
    
    A tester donc.
  - [^]Re: Dans le même genre
    
    Posté par Cédric Foll (page perso, ) le 13/08/2004 à 08:03. (lien). Évalué à 4.
    Faudrait que je teste bogofilter à la maison, je me demande si ça pourrait pas passer sur mon p200 avec 160Mo de RAM ?
    
    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 (Jabber id, page perso, ) le 13/08/2004 à 09:06. (lien). Évalué à 2.
      Pour quelle taille de base spam/ham ? La mienne fait plus de 70 MiB ( http://oumph.free.fr/textes/pourriel.html(...) ), sur un bi-PII 350 avec 786 MiB de RAM, et le temps d'analyse est clairement perceptible.
      - [^]Re: Dans le même genre
        
        Posté par Cédric Foll (page perso, ) le 13/08/2004 à 09:43. (lien). Évalué à 1.
        Ma base faisant environs 100 Mo.
        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 (page perso, ) le 13/08/2004 à 06:19. (lien). Évalué à 4.
  Bonjour,
  
  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 Desfontaines (page perso, ) le 13/08/2004 à 07:04. (lien). Évalué à 3.
    Perso, j'ai 3 processus amavis-new.
    
    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 :
```
5036 amavis  9  0 13320 1256 1004 S 0.0  0.2  0:00.54 amavisd-new

5041 amavis  9  0 13316  964  964   S 0.0  0.1  0:00.00 amavisd-new

5042 amavis  9  0 13316  972  972   S 0.0  0.1  0:00.00 amavisd-new
```
    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 () le 13/08/2004 à 07:24. (lien). Évalué à 5.
    Ca depend de la maniere dont est architecture le programme.
    
    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 () le 13/08/2004 à 08:00. (lien). Évalué à 2.
      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. Bref en gros ne pas traiter les threads comme des processus spéciaux mais comme des threads.
      
      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 () le 13/08/2004 à 09:33. (lien). Évalué à 2.
        Il me semble que pas mal de choses ont change de ce cote la dans le kernel 2.6
        
        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 () le 13/08/2004 à 09:51. (lien). Évalué à 3.
        Si le LinuxMag de juillet se trouve encore dans les kiosques (ce qui doit être le cas vu que c'était un # d'été), je te le conseille. Y'a un article sur le multithread qui explique justement assez bien ce qui a changé avec l'apparition des NPTL dans Linux 2.6.
      - [^]Re: Dans le même genre
        
        Posté par Sebastien Tanguy (page perso, ) le 13/08/2004 à 22:55. (lien). É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 () le 14/08/2004 à 14:10. (lien). Évalué à 2.
        j'avais entendu dire que le fait de devoir trouver un pid libre coûtait pas mal de temps. Mais je peux me tromper :p
        
        [^]Re: Dans le même genre
        
        Posté par MrTout (page perso, ) le 15/08/2004 à 15:28. (lien). Évalué à 1.
        Il me semble que "pid libre" = "dernier pid" + 1. Ce qui ne coûte pas tant que ça. Mais je peux me tromper :p

[^]Re: Dans le même genre

Posté par Blackknight (Jabber id, page perso, ) le 13/08/2004 à 08:15. (lien). Évalué à 2.
J'ai trouvé ça il y a quelques temps (http://www.onlamp.com/lpt/a/4710(...) ). Bon, je sais, c'est du Sendmail sur du BSD mais bon, ça marche. Par contre, j'ai pas vérifié si ça utilise le spamd qui est quand même moins consommateur et plus réactif que la version de base.

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 (page perso, ) le 13/08/2004 à 10:49. (lien). Évalué à 2.
Postfix en MTA
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 (page perso, ) le 13/08/2004 à 12:14. (lien). Évalué à 1.
Ben, MailScanner [http://www.sng.ecs.soton.ac.uk/mailscanner/(...)] marche plutôt bien. Il s'intercale entre deux instances du MTA, et traite les courriels par lot (batch pour les anglophones), ce qui accélère assez le traitement (très pratique sur un serveur un peu chargé). Il fait appel derrière à SpamAssassin et à un antivirus quelconque (ClamAV [http://clamav.net/(...)] est tout à fait valable, et je ne trouve pas que leur réactivité ait grand-chose à envier aux éditeurs d'antivirus propriétaires).

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.

--
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™

[+] compatibilité GPL

Posté par Antoine () le 12/08/2004 à 18:23. (lien). Évalué à -4.

On soulignera que, d'après la FSF, cette licence rendra SpamAssassin 3 non compatible GPL

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 (page perso, ) le 12/08/2004 à 19:14. (lien). Évalué à -1.
Ta tirade avec pour but de se moquer de qui ?

[^]Re: compatibilité GPL

Posté par Christophe (rOotix) GUILLOUX (Jabber id, page perso, ) le 12/08/2004 à 21:56. (lien). Évalué à 1.
C'est la licence CeCILL qui te donne des boutons ?
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é.

--
http://rootix.info
- [+] [^]Re: compatibilité GPL
  
  Posté par Antoine () le 12/08/2004 à 22:02. (lien). Évalué à -2.
  Visiblement l'humour est en option chez certains...
  - [^]Re: compatibilité GPL
    
    Posté par Christophe (rOotix) GUILLOUX (Jabber id, page perso, ) le 12/08/2004 à 22:06. (lien). Évalué à 0.
    Etant plus ou moins dans les postmasters quelque part à l'INRIA, je réagis.
    
    --
    http://rootix.info

[^]Re: compatibilité GPL

Posté par Bruce Le Nain (Jabber id, page perso, ) le 13/08/2004 à 09:03. (lien). Évalué à 3.
Elle est compatible GPL, la CeCiLL, non ? Qu'est ce qu'on lui reproche ? d'exister ?

Ç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.

--
Hôdo
Livingstone
- [^]Re: compatibilité GPL
  
  Posté par Maxx () le 13/08/2004 à 09:14. (lien). Évalué à 1.
  ça y est c'est reparti... ça sent le troll esperanto/ido à plein nez c't'histoire... ;)
  - [^]Re: compatibilité GPL
    
    Posté par Bruce Le Nain (Jabber id, page perso, ) le 13/08/2004 à 09:36. (lien). Évalué à 2.
    mais non, on s'en fiche c'est un exemple :)
    
    N'empeche que c'est un des plus vieux trolls, il date du début du siècle dernier.
    
    --
    Hôdo
    Livingstone

[+] allez je me lance...

Posté par Jerome Alet (page perso, ) le 12/08/2004 à 19:27. (lien). Évalué à -5.

SpamAssassin sucks !

DSpam rulez !

[^]Re: allez je me lance...

Posté par Jerome Alet (page perso, ) le 12/08/2004 à 20:25. (lien). Évalué à 0.
Visiblement personne d'autre n'a essayé les deux...
- [^]Re: allez je me lance...
  
  Posté par Fabien Penso (Jabber id, page perso, ) le 12/08/2004 à 20:30. (lien). Évalué à 0.
  On s'en fout, spamassasin on le lance de amavis au niveau système pour tous les mails qui passent, tu fais comment avec dspam ?
  
  --
  blog them all :: la photo du jour
  Je vote pour LinuxFr en Rails !
  - [^]Re: allez je me lance...
    
    Posté par Cédric Foll (page perso, ) le 12/08/2004 à 21:14. (lien). Évalué à 1.
    On peut faire pareil.
    
    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 (Jabber id, page perso, ) le 12/08/2004 à 22:50. (lien). Évalué à 2.
      Je lis :
      
      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 :)
      
      --
      blog them all :: la photo du jour
      Je vote pour LinuxFr en Rails !
      - [^]Re: allez je me lance...
        
        Posté par ArnY (Jabber id, page perso, ) le 13/08/2004 à 08:03. (lien). Évalué à 1.
        SpamAssassin 3.0 implemente les plugins, et il existe déja un plugin CRM114 qui permet d'utilise CRM114 avec/à la place du filtre bayesien de SA.
        
        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)
        
        --
        -- Université de Nantes --
  - [^]Re: allez je me lance...
    
    Posté par Jerome Alet (page perso, ) le 13/08/2004 à 16:06. (lien). Évalué à 3.
    dspam intercepte bien tous les mails qui passent, ensuite c'est à l'utilisateur de choisir s'il veut que dspam "apprenne" ce qu'est du spam ou pas et s'occupe des messages "emmerdants" automatiquement.
    
    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 champi (page perso, ) le 12/08/2004 à 20:42. (lien). Évalué à 7.
Bon la forme n'y était pas, mais c'est vrai que DSPAM a l'air d'être un projet très intéressant et il mériterait un peu plus de pub:
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 Christophe (rOotix) GUILLOUX (Jabber id, page perso, ) le 12/08/2004 à 22:01. (lien). Évalué à 4.

Alors moi j'ai essayé le plugin spamassassin pour sylpheed, résultat : le laptop qui rame à traiter tous les mails sur une boite IMAP distante donc j'ai vite fait abandonné l'idée, c'est inutilisable. Déjà que sylpheed n'est pas multi-tâche mais avec ça, adieu le mail....
Conclusion, il faut filtrer au niveau du serveur sinon, ça fait récupérer en plus de ça les mails pour rien.

--
http://rootix.info

[^]Re: tentative spamassassin + sylpheed [complètement HS]

Posté par Colin Leroy (page perso, ) le 13/08/2004 à 06:58. (lien). Évalué à 6.
Déjà que sylpheed n'est pas multi-tâche

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.

--
Claws Mail - it bites!
- [^]Re: tentative spamassassin + sylpheed [complètement HS]
  
  Posté par Christophe (rOotix) GUILLOUX (Jabber id, page perso, ) le 13/08/2004 à 11:37. (lien). Évalué à 2.
  j'utilise que SSL pratiquement, c'est donc pour ça. Bon ben j'attends sagement :)
  
  --
  http://rootix.info
  - [^]Re: tentative spamassassin + sylpheed [complètement HS]
    
    Posté par Nicolas Roard (page perso, ) le 13/08/2004 à 14:20. (lien). Évalué à 3.
    Juste pour confirmer que le multi-thread n'est pas forcèment la panacée : GNUMail (lecteur de mail comme son nom l'indique) était à l'origine en multi-thread, mais les dernières versions sont passées en IO non bloquantes et ont virés les threads. Et ben ça marche mieux, plus rapide et plus fluide. Comme quoi, les idées évidentes (utilisation des threads) ne sont pas forcèment toujours les bonnes :)

spamassassin vs thunderbird

Posté par Etienne Juliot (page perso, ) le 13/08/2004 à 07:12. (lien). Évalué à 3.

Quelqu'un a déjà fait un comparatif entre le filtre anti spam de spamassassin et celui de Mozilla ?

[^]Re: spamassassin vs thunderbird

Posté par Cédric Foll (page perso, ) le 13/08/2004 à 07:53. (lien). Évalué à 3.
"Comparatif" à vu de nez!

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 (page perso, ) le 13/08/2004 à 08:00. (lien). Évalué à 0.
  Ce qui est intéressant, c'est que spamassassin peut "apprendre" ce qui doit être un spam ou non. On lui précise le dossier ou sont poubellisés les spams en lui précisant que ces mails sont à jeter et les dossiers ou les mails ne sont pas du spam, en lui précisant que ceux là, il faut qu'il les garde.
  
  C'est bluffant :)
  - [^]Re: spamassassin vs thunderbird
    
    Posté par Blackknight (Jabber id, page perso, ) le 13/08/2004 à 08:39. (lien). Évalué à 1.
    Ben, c'est pas ça un filtre Bayésien ????
    - [^]Re: spamassassin vs thunderbird
      
      Posté par champi (page perso, ) le 13/08/2004 à 10:39. (lien). Évalué à 3.
      Non, ca c'est de l'apprentissage supervisé de manière plus générale (exemples posititifs et négatifs dans chaque répertoire). Le classement bayésien naif est une technique d'apprentissage supervisé parmis d'autres (support vector machines, réseaux de neuronne, programmation logique inductive, ...), Certains plugins de SA sont adaptatifs (il sont capable d'apprendre si on leur donne des exemple). Pour l'instant il semble que les filtres bayésiens soient les plus adaptés au classement du spam. En tout cas ce sont les plus répandus dans ce type de filtres.
  - [^]Re: spamassassin vs thunderbird
    
    Posté par Cédric Foll (page perso, ) le 13/08/2004 à 08:50. (lien). Évalué à 2.
    C'est le principe du filtre bayesien.
    
    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 (Jabber id, page perso, ) le 13/08/2004 à 09:07. (lien). Évalué à 3.
    le problème, c'est qu'au bout d'un moment, il n'apprend plus. Un peu comme les australopithèques. Faudra qu'on me réexplique le principe de saturation de l'intelligence...
    
    --
    Hôdo
    Livingstone
    - [^]Re: spamassassin vs thunderbird
      
      Posté par Maxx () le 13/08/2004 à 10:52. (lien). Évalué à 3.
      Disons que ce n'est encore qu'un programme à l'heure actuelle...
      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 () le 13/08/2004 à 11:39. (lien). Évalué à 4.
        Vous connaissez la célèbre nouvelle ultracourte de Frederic Brow, La Réponse.
        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 (page perso, ) le 13/08/2004 à 14:23. (lien). Évalué à 1.
        Fredric Brown
        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 champi (page perso, ) le 13/08/2004 à 12:11. (lien). Évalué à 3.
        > Disons que ce n'est encore qu'un programme à l'heure actuelle...
        
        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".

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : SpamAssassin devient un projet Apache, et corrige une faille de sécurité

Projet apache

[^]Re: Projet apache

En passant...

2.64

[^]Re: 2.64

[+] Fork?

Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[^]Re: Dans le même genre

[+] compatibilité GPL

[+] [^]Re: compatibilité GPL

[^]Re: compatibilité GPL

[+] [^]Re: compatibilité GPL

[^]Re: compatibilité GPL

[^]Re: compatibilité GPL

[^]Re: compatibilité GPL

[^]Re: compatibilité GPL

[+] allez je me lance...

[^]Re: allez je me lance...

[^]Re: allez je me lance...

[^]Re: allez je me lance...

[^]Re: allez je me lance...

[^]Re: allez je me lance...

[^]Re: allez je me lance...

[^]Re: allez je me lance...

tentative spamassassin + sylpheed

[^]Re: tentative spamassassin + sylpheed [complètement HS]

[^]Re: tentative spamassassin + sylpheed [complètement HS]

[^]Re: tentative spamassassin + sylpheed [complètement HS]

spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird

[^]Re: spamassassin vs thunderbird