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

Posté par (page perso) . Modéré par Benoît Sibaud.
Tags :
0
12
août
2004
Sécurité
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. 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.
  • # Projet apache

    Posté par (page perso) . Évalué à 10.

    Ca apporte quoi de devenir un project apache ?
    (a part pour la reconnaissance/notoriete)
    • [^] # Re: Projet apache

      Posté par . Évalué à 10.

      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 . É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 (page perso) . É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 (page perso) . É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 . Évalué à -10.

    Attention, ça va forker !

    ----->[] (ça y est)
  • # Dans le même genre

    Posté par (page perso) . É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.
    • [^] # Re: Dans le même genre

      Posté par . Évalué à 10.

      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 (page perso) . É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 ?

        http://damien.pobel.fr

      • [^] # Re: Dans le même genre

        Posté par . É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 . É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 . É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 . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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.

      Envoyé depuis mon PDP 11/70

  • # compatibilité GPL

    Posté par . É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 . Évalué à -1.

      Ta tirade avec pour but de se moquer de qui ?

      http://about.me/straumat

    • [^] # Re: compatibilité GPL

      Posté par (page perso) . É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é.

      Christophe

    • [^] # Re: compatibilité GPL

      Posté par (page perso) . É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.
      • [^] # Re: compatibilité GPL

        Posté par . Évalué à 1.

        ça y est c'est reparti... ça sent le troll esperanto/ido à plein nez c't'histoire... ;)
  • # allez je me lance...

    Posté par (page perso) . Évalué à -5.

    SpamAssassin sucks !

    DSpam rulez !
    • [^] # Re: allez je me lance...

      Posté par (page perso) . Évalué à 0.

      Visiblement personne d'autre n'a essayé les deux...
      • [^] # Re: allez je me lance...

        Posté par (page perso) . É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 ?
        • [^] # Re: allez je me lance...

          Posté par . É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 (page perso) . É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 :)
            • [^] # Re: allez je me lance...

              Posté par (page perso) . É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)
        • [^] # Re: allez je me lance...

          Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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.

    Christophe

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

      Posté par (page perso) . É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.
  • # spamassassin vs thunderbird

    Posté par (page perso) . É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 . É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 . É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 (page perso) . Évalué à 1.

          Ben, c'est pas ça un filtre Bayésien ????
          • [^] # Re: spamassassin vs thunderbird

            Posté par (page perso) . É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 . É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 (page perso) . É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...
          • [^] # Re: spamassassin vs thunderbird

            Posté par . É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 . É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 (page perso) . É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".

Suivre le flux des commentaires

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