C'est à mon avis le but recherché par l'équipe de DSPAM. Les back-ends de données pour le stockage des tokens sont nombreux, mais l'accent est particulièrement mis sur les back-ends SGBD. A l'époque, l'auteur recommandait le back-end MySQL, qui était selon lui de loin le plus performant (il semblerait que sur la 3.6, PostgreSQL arrive à un niveau proche).
L'avantage de ces back-ends est de pouvoir avoir en frontal X serveurs DSPAM qui se partagent la même base de données de tokens. J'ai vu passer des références à des installations de ce type chez certains providers (cf la page de garde qui parle d'une installation de 350.000 boites). C'est à mon avis à prendre un peu avec des pincettes... Je me demande surtout comment sont gérés les accès concurrents en écriture sur un même token...
La grosse différence entre SA et Dspam va se situer au niveau performances. Même si les traitements effectués se prêtent bien à l'utilisation de Perl (parsing de messages texte), je pense qu'en termes de performances pures de traitement, Dspam est devant (100% C).
Au point de vue efficacité de filtrage, les dernieres stats que j'ai vu sur mon serveur étaient aux alentours de 99.3% de mails correctement triés (et surtout 99.8% d'innocents correctement classés). Il s'agit d'une installation purement Dspam, même si ce résultat est un peu biaisé, car je récupère une partie des mails à l'extérieur, qui ont déjà subis un traitement avec divers SA.
Je ne vois plus vraiment Dspam comme un complément à SA, mais plutôt comme un remplacement.
Quant à amavis, je crois qu'on partage le même point de vue...
[^] # Re: dspam + dspampd
Posté par sk . En réponse au journal Spamassassin et vous.. Évalué à 1.
L'avantage de ces back-ends est de pouvoir avoir en frontal X serveurs DSPAM qui se partagent la même base de données de tokens. J'ai vu passer des références à des installations de ce type chez certains providers (cf la page de garde qui parle d'une installation de 350.000 boites). C'est à mon avis à prendre un peu avec des pincettes... Je me demande surtout comment sont gérés les accès concurrents en écriture sur un même token...
La grosse différence entre SA et Dspam va se situer au niveau performances. Même si les traitements effectués se prêtent bien à l'utilisation de Perl (parsing de messages texte), je pense qu'en termes de performances pures de traitement, Dspam est devant (100% C).
Au point de vue efficacité de filtrage, les dernieres stats que j'ai vu sur mon serveur étaient aux alentours de 99.3% de mails correctement triés (et surtout 99.8% d'innocents correctement classés). Il s'agit d'une installation purement Dspam, même si ce résultat est un peu biaisé, car je récupère une partie des mails à l'extérieur, qui ont déjà subis un traitement avec divers SA.
Je ne vois plus vraiment Dspam comme un complément à SA, mais plutôt comme un remplacement.
Quant à amavis, je crois qu'on partage le même point de vue...