vendredi 25 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

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

> Lire la dépêche (56 commentaires, moyenne: 2,5).  

Vous avez demandé le commentaire #459267.

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™
Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0878s (dont 0.0088 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.