[Web1901] [Fwd: [forum isoc] Lesstratégies des logiciels anti-spam]

[Denis]

Bonjour,

concernant le spam, je vous relaie, à toutes fins utiles, un message 
diffusé sur une liste de l'ISOC qui me semble faire un point assez 
complet sur les outils.

Bien cordialement, et bonne digestion,
Denis

-------- Message d'origine --------
Sujet: [forum isoc] Les stratégies des logiciels anti-spam
Date: Sat, 1 Nov 2003 00:08:34 +0100
De: Michel Lo <michel at beltsa.com>
A: forum at isocfrance.org

Bonjour,

Avec les deux derniers mails de Dominique Volpe et Jean-Michel Yolin, on 
quitte les généralités et on entre dans le détail des outils anti-spams.

J'écris ce "très très long" mail essentiellement pour faire un point sur 
l'ensemble de ce qui existe et des grandes pistes techniques (par 
opposition aux pistes juridiques) pour lutter contre le spam. Vous aurez 
peut être l'impression que je rentre dans le détail, mais 
malheureusement, il n'en est rien : aujourd'hui presque tout existe, et 
il n'y a pas besoin d'une grande révolution pour que nous arrivions à 
nous protéger.

Il y a le minimum possible d'éléments pouvant être subjectifs, et les 
informations contenues dans ce mail sont (et c'est tant mieux) 
susceptibles de changer rapidement dans les mois qui viennent.

L'objectif de ce mail est bien entendu que vous le lisiez, mais surtout 
qu'il y ait toutes les chances pour que les membres du forum Isoc aient 
un socle de connaissances suffisant pour pouvoir discuter du sujet et 
avoir les idées à peu près claires sur le sujet.
Ensuite, chacun se fera son opinion et j'espère, pourra contribuer à 
cette lutte qui se révèle ardue ...

Ce mail est divisé en trois parties : Les stratégies par examen du mail, 
le processus de décision de l'endroit où doivent être installés les 
filtres , les stratégies par certification du mail, et bien entendu, une 
conclusion.

Bonne lecture,


LES STRATEGIES PAR EXAMEN DU MAIL

BLACKLIST

Ce système est le plus rustique et a été historiquement le premier à 
être mis en place.
Le principe est d'avoir une table interdisant soit un email, soit un 
domaine complet, soit une IP d'origine. C'est brutal et cela peut être 
fort injuste, car les spammeurs peuvent "forger" de faux headers SMTP 
qui font croire que l'email vient de chez quelqu'un d'autre et donc 
provoquer l'inscription en blacklist d'une adresse, d'un domaine ou d'un 
IP totalement innocent.

Actuellement, lorsque les blacklist existent, elles sont directement 
gérées à la main au niveau d'un domaine sur les serveurs (par exemple 
filtre tout ce qui arrive à @mondomaine.com sur le serveur de 
mondomaine.com). Il existe des versions un poil plus élaborées qui 
virent tout ce qui contient une certaine chaine de caractères genre 
\/ia.gra dont on peut (je pense) être raisonnablement sûr que ce n'est 
pas un mail professionnel ou venant de la famille.

Il existe des blacklist mises en commun sur le net, mais elles ne sont 
généralement (quoique) plus utilisées directement pour interdire, mais 
simplement faire du scoring. Certaines listes (celles des séquences de 
caractère par exemple) peuvent servir pour directement donner un score 
d'enfer qui fait que le mail est de toute manière considéré comme un 
spam (test GTUBE par exemple)

Dans les premiers temps, outil suprême, la méthode blacklist n'est 
désormais plus suffisante pour contrer les spammeurs devenus plus rusés 
(sauf quelques spammeurs rustiques). Il existe encore des trucs gratuits 
qu'on peut installer pour enlever le plus gros, genre 
http://www.jayallen.org/misc/projects/mt-blacklist/

SCORING

C'est le principe de base de Spamassassin.

Un mail passe par une analyse de différents critères qui lui donne un 
score. Par exemple, l'absence de reply-to ajoute un 0.1 au score.
Vous trouverez une liste des tests les plus habituels réalisés à 
http://www.spamassassin.org/tests.html
Notez que spamassassin peut aussi faire du Bayes, mais le scoring de 
spamassassin est indépendant des tests bayesiens (en fait Spamassassin 
utilise les deux stratégies ce qui le rend plus efficace). Cf chapitre 
suivant pour la définition des filtres bayesiens.

Bien entendu, ces tests évoluent au cours du temps, car par exemple, 
avec un mail en multipart html (partie texte et partie html) avec 
surtout du html, cela ajoute un score de 1.162
Il est évident que si la progression du mail en html continue (pour des 
raisons d'esthétique), ce test devra avoir moins d'impact sur la 
qualification de "spam".

Un mail est considéré comme étant du spam à partir d'un score de 5.

En standard, les mails sont simplement marqués par un header 
complémentaire dans le mail (non visible avec le plupart des affichages 
par défaut des logiciels d'email), mais côté server, on peut faire un 
reject du mail qui n'est alors même pas récupéré lorsque l'utilisateur 
se connecte. La recommandation de spamassassin est de ne pas détruire 
les emails, et si on le fait, de ne jamais le faire pour un score 
inférieur à 15.

Le scoring a vraiment constitué un bond fantastique par rapport aux 
blacklists et a permis de réaliser des filtres qui bloquent plus des 2/3 
des spams sans aucun faux positif ou faux négatif (si vous ne connaissez 
pas bien ces termes, voyez la définition dans le chapitre BAYES 
ci-dessous), et suivant les destinataires ou plutôt les communautés de 
destinataires, des résultats encore meilleurs.

Mais comme dans de nombreux domaines, ce sont les derniers pour cent qui 
sont les plus difficiles à obtenir.

BAYES

Le théorème de Bayes n'a rien à voir avec l'informatique ou le spam, 
mais c'est une méthode qui permet d'évaluer les risque d'erreur 
lorsqu'on a un phénomène et un test de mesure du phénomène.

[Explication théorème de Bayes ON]
Prenons un exemple, ce sera plus facile.
Soient
P(A) la probabilité d'avoir une maladie dans une population
P(B|A) est la probabilité d'avoir un test positif si on est malade. 
C'est en fait la validité du test
P(B|~A) est la probabilité d'erreur du test positif (le test dit qu'on a 
la maladie, mais on ne l'a pas)

On en déduit directement
P(~A) est la probabilité de ne pas avoir la maladie dans une population 
= 1 - P(A)
P(~B|A) est la probabilité d'avoir un test négatif si on est examiné et 
qu'on a la maladie = 1- P(B|A)
P(~B|~A) est la probabilité d'avoir un test négatif si on n'a pas la 
maladie = 1 - P(B|~A)

Le théorème de Bayes donne les 4 autres probabilités (celles qui nous 
intéressent)
P(A|B) = P(B|A)*P(A)/P(B) Probabilité que le test dise qu'on est malade 
si on l'est effectivement
P(~A|B)=P(B|~A)*P(~A)/P(B) Probabilité que le test dise qu'on est malade 
alors qu'on ne l'est pas (faux positifs)
P(~A|~B)=P(~B|~A)*P(~A)/P(~B) Probabilité que le test dise qu'on a rien 
et qu'on a effectivement rien
P(A|~B)=P(~B|A)*P(A)/P(~B) Probabilité que le test dise qu'on n'a rien 
alors qu'on l'est (faux negatifs)

[Explication théorème de Bayes OFF]

Si on considère que le spam est une maladie du mail et qu'on doit faire 
passer un test pour savoir si c'en est effectivement un ou non, 
l'objectif du test est de rendre minimiser P(A|~B) et P(~A|B), avec 
priorité au premier. En langage de tous les jours, cela veut dire qu'on 
ne veut pas que les bons mails soient vus comme des spams, et que, 
autant que faire se peut, on n'ait pas de spams qui passent comme bons 
mails.
En langage un peu plus "averti", il faut éliminer les faux positifs et 
diminuer les faux négatifs.

On parle donc de tests bayesiens pour des tests qui se basent sur ce 
genre de théorie.

Donc, un test de scoring peut être un test bayesien à condition 
d'ajuster le test par la valeur du score qui fait que l'on considère 
qu'un mail est spam ou non.
Et bien entendu, cela ne peut se faire qu'à partir du moment où on peut 
faire des statistiques pour obtenir des probabilités, et avec une 
validité d'autant plus grande qu'on a un échantillon important.
On considère que l'échantillon doit atteindre dans les 4000 emails 
traités à la main en spam/ham (*) pour pouvoir obtenir quelque 
consistance (**)
(*) Jean-Michel nous a rappelé plusieurs que le spam est une sorte de 
saucisse à base de jambon, ce qui explique que ceux qui travaillent sur 
le problème du spam aient naturellement appelé ham (jambon) le non spam. 
Les Monthy Python n'auraient jamais pensé une telle consécration à leur 
plaisanterie)
(**) Je pense que cela rappelera quelque choses à plusieurs si je leur 
dit que l'erreur commise sur un échantillon N est de 1/racine(n). Ce qui 
nous fait 1.5% d'erreur du à la taille de l'échantillon si on a 4000 
emails triés.

Quand on parle d'échantillon trié, il s'agit bien entendu de 4000 mails 
qu'on a sélectionné "à la main" pour décider s'il s'agissait de spam ou non.

Problème : la notion de spam n'est pas obligatoirement la même pour tout 
le monde, et donc les listes de référence doivent être adaptées à chaque 
personne ...

=========================

Il existe une autre approche plus bayesienne des tests basés non plus 
sur du scoring mais directement sur la probabilité en faisant du calcul 
arrière à partir de la base d'apprentissage.
En effet, spamassassin ajoute des scores (éventuellement négatifs, cf le 
paragraphe suivant des whitelists) pour donner un résultat, mais en 
fonction de l'état des recherches de chaque organisation ou groupe dans 
une organisation. Et le score est calculé sur un échantillon propre qui 
n'est n'est ni celui de la base commune (pas obligatoirement en tout 
cas), ni sur celle qu'un utilisateur particulier souhaiterait.

Les premiers résultats de Patrick Pantel et Dekang Lin ont été assez 
décevants (et Microsoft en 2002 encore moins bon),car ils ne détectaient 
que 92% du spam avec 1,16% de faux positifs. Mais Paul Graham (le gourou 
du LISP) a écrit un filtre bayesien orienté sur les mots avec (sur ses 
mails à lui) un taux de reconnaissance de 99,5% et un taux de 0,03% de 
faux positifs.
L'explication principale qu'il donne de cette différence est que bien 
que reposant sur des algorithmes très semblables, Pantel et Lin se sont 
basés uniquement sur les contenus et n'examinaient pas les headers.

Il est donc malheureusement évident que derrière les règles de calcul de 
probabilité, ce qui compte surtout, c 'est la règle de base et la 
conception du filtre.

Les filtres bayesiens actuels utilisent une base de ham (mails non 
spams) et spam pour faire une analyse de fréquence de tous les mots 
contenus pour leur affecter un score.
Les travaux de Paul Graham semblent faire référence dans le calcul des 
filtres basé sur des mots simples. Sa méthode consiste à prendre tous 
les mots qui existent dans les bons mails, et à faire un grand tableau 
de fréquence (une "hash table"). Idem pour les mots dans les mails de 
spam. Ensuite, une table finale de hash est composée en faisant la 
moyenne de fréquence entre la fréquence dans les spams (avec un proba de 
1) et la fréquence dans les bons (mais multipliée par deux pour éviter 
les faux positifs). Pour les mots uniquement dans une table et pas 
l'autre, il affecte respectivement 0.1 et 0.9
Pourquoi ces valeurs ? Parce que ça marche. Et de l'avis même de Paul 
Graham, il n'y a pas d'autre raison que les essais et erreurs.

A partir de là, on a une base de mots avec chacun une valeur de 
probabilité qui permet de recalculer la probabilité qu'un email soit du 
spam. Les mails avec 0.9 de proba ou plus sont considérés comme du spam.
C'est de la combinatoire de probabilité classique, je rappelle juste la 
méthode pour les curieux.

[combinatoire de proba ON]
Soit un événement dont on a deux indices de probabilité a et b indépendants
la probabilité jointe des deux proba est
a * b
c= -------------------------
a * b + (1 - a)(1 - b)

[combinatoire de proba OFF]

La très grosse majorité des filtres bayesiens proposés pour le lutter 
contre le spam est basé sur des algorithmes du type de ceux proposés dès 
2002 par Paul Graham, et fonctionnent sur des mots individuels.

Ce qu'il faut retenir de ces filtres, c'est qu'il est nécessaire 
d'analyser un grand nombre de mails positifs ET négatifs (spam/ham). On 
ne peut donc pas se contenter des listes de filtres mondiaux mis à 
disposition !
Il faut impérativement se constituer des bases personnelles pour que le 
programme construise des tables qui correspondent à ce que chaque 
utilisateur considère comme du spam.

Les travaux les plus en avance dans le domaine n'est plus basé sur des 
mots, mais sur un algorithme barbare nommé SBPH (Sparse Binary 
polynomial Hashing). En gros, il s'agit non plus de faire des tables de 
hashages basés sur des mots, mais basés sur des groupe de mot (donc à 
priori plus précis, puisqu'il réalise une sorte d'analyse mathématique 
de la sémantique des spams). J'écris bien "une sorte" d'analyse 
mathématique, car en fait dans le CRM114 Discriminator de Bill Yerazunis 
du MIT, il a une fenêtre d'ordre N (N = un nombre de mots) qu'il fait 
glisser et il réduit ce qu'il lit par un modulo d'un nombre premier pour 
que chaque bit ait une influence, mais que ce qui caractérise la phrase 
ne soit pas trop grand.
Ca marche plutôt bien, malgré deux impasses assez grossières : d'une 
part plusieurs phrases peuvent être représentées par une même valeur de 
hash (les deux phrases sont considérées comme la même expression, ce 
qu'elles ne sont évidemment pas) mais surtout parce que la loi de 
combinatoire utilisée n'est valable que pour des probabilités 
indépendantes, et il est évident que l'influence du mot ne l'est pas 
puis qu'il apparait dans plusieurs des valeurs de hashage.
Bon, ça marche...

L'ensemble des auteurs de filtres bayesiens basés sur des mots semblent 
dire que la voie SBPH est la plus prometteuse, mais le CRM114 n'est pas 
très pratique à utiliser car c'est un nouveau langage de description de 
filtres.
Il n'est toutefois pas exclus que spamassassin puisse intégrer un CRM114 
like.

Pour la petite histoire et détendre l'atmosphère après ces lourdes 
explications, le nom "CRM114 Discriminator" (CRM pour Controllable Regex 
Mutilator) est le nom d'un dispositif dans le film Dr Folamour de 
Stanley Kubrick, qui ajouté à la radio permettait de ne recevoir QUE les 
messages authentiques et rien d'autre (cela ne vous rappelle rien ?)


WHITELIST

La white list, par définition, est le contraire de la blacklist.

Mais, à la différence de la blacklist, la whitelist est généralement 
utilisée dans son acception de base : tout ce qui est dans la white list 
ne doit pas être considéré comme spam. Bien entendu, par "tout ce qui 
est dans la whitelist", il faut comprendre que tout email arrivant 
respectant les conditions de la whitelist sont de bons emails, même 
s'ils présentent par ailleurs toutes les caractéristiques du spam.

Ce n'est pas anodin, car, comme nous allons le voir, l'endroit où est 
positionnée la whitelist peut la rendre très efficace ou au contraire 
totalement inefficace : c'est la stratégie de placement des filtres.


LES STRATEGIES DE POSITIONNEMENT DES FILTRES

Pour suivre l'histoire, il vaut mieux connaître le chemin que suit un 
email avant de nous arriver.

L'histoire commence au moment où notre serveur (celui sur lequel l'email 
qui nous est envoyé DOIT passer) reçoit l'email.
C'est en général un programme de réception répondant à la norme SMTP 
dont le rôle va être de définir s'il est destiné à quelqu'un qu'il 
connaît et si c'est le cas, de le ranger dans un endroit bien précis 
pour pouvoir être récupéré par l'utilisateur.

Ensuite, l'utilisateur peut soit les examiner par un logiciel (tel que 
webmail), soit les récupérer avec un logiciel client qui va correspondre 
avec un serveur pop ou un serveur imap côté serveur.

Enfin, sur le PC de l'utilisateur, au niveau du logiciel d'email, on 
peut intégrer un autre filtrage des mails récupérés par pop ou imap à la 
réception côté client.


SUR LES SERVEURS, EN ENTREE

A ce niveau, il est possible d'intégrer un filtre de deux façons :
-> ajouter des capacités de traitement de filtrage complexes (scoring 
et/ou Bayes par exemple) au logiciel de traitement de réception des 
emails sur le serveur
-> détourner les emails entrants non marqués examinés vers un programme 
de filtrage qui tourne en parallèle, qui va marquer les emails (par 
exemple en changeant le destinataire des mails de spam pour les envoyer 
dans un endroit spécial spam plutôt que utilisateur) et les re-alimenter 
dans le logiciel de réception qui va traiter les mails marqués pour les 
distribuer.

Ces filtres ne peuvent pas être trop violents, car ils sont en général 
communs à de nombreux utilisateurs. Actuellement, il n'existe pas de 
méthode simple pour installer au niveau entrant du serveur un filtre qui 
puisse faire un traitement personnalisé par boite email, ni même par 
domaine. Théoriquement, c'est tout à fait faisable, mais ce n'est pas 
encore fait.

Comme les filtres sont communs à ce niveau, la politique généralement 
établie est de ne pas effacer les emails, mais de marquer leur scoring 
dans les headers.

SUR LES SERVEURS, PLUS TARD

Une fois l'email rangé dans sa boite, on peut désormais envisager de 
faire un traitement avec un filtre plus personnalisé.

De nouveau, il existe plein de possibilités, mais qui toutes se ramènent 
à faire tourner un programme sur un serveur (le même ou un autre) qui va 
traiter les emails de la boite.
Suivant les cas, ce peut être un programme lancé à la main, un programme 
déclenché par l'appel au serveur pop ou à intervalles réguliers (un 
"cron") ou un mix de plusieurs méthodes.
Les filtres seront situés au niveau du serveur, et l'apprentissage est 
délicat, car il faudra bien indiquer à un moment ou un autre au serveur 
quels sont les emails qui sont bons et ceux qui ne sont pas bons pour 
qu'il apprenne.
Si on ne lui dit rien, l'auto-apprentissage qui nous est vanté est 
illusoire, puisqu'il va apprendre qu'il ne se trompe jamais, ce qui 
n'est pas bien efficace pour l'améliorer.

PAR UN FILTRE PROXY

On peut également introduire un filtre au moment de la récupération en 
faisant passer le mail par un serveur proxy ayant des capacités de 
traitement.

En gros, il y a deux méthodes : soit un autre serveur spécialisé dans 
l'élimination des emails (il existe des services payants de ce type 
genre safersurf http://www.nutzwerk.com/english/safersurf/index.html ), 
soit un proxy que l'on installe sur son propre PC, ce qui permet 
d'utiliser des logiciels d'email qui ne savent pas encore intégrer des 
traitements anti-spam. Spamassassin a une version de ce genre, y compris 
pour windows.

SUR LE PC CLIENT

Il faut alors que le logiciel email permette l'intégration de filtres 
par scoring ou bayes.

Il faut noter qu'actuellement, la tendance générale est plus d'affirmer 
aux utilisateurs qu'ils n'ont à s'occuper de rien et qu'ils disposent 
avec x ou y de la meilleure solution et qu'on s'occupe de tout.
Inutile de préciser que ce n'est là que la manifestation d'un état 
immature de la population des utilisateurs d'email et que le discours va 
changer.

Mais pour tous les filtres qui fonctionnent par examen de l'email pour 
tenter de retrouver s'il s'agit d'un spam ou non, il est impératif de 
prendre conscience que cela ne peut se faire qu'avec un échantillon le 
plus large possible de mails qui sont notés spam ou pas spam par 
l'utilisateur.
Si on vous propose un filtrage où vous n'avez pas cette décision, c'est 
que quelqu'un d'autre a décidé pour vous et que votre filtre va filtrer 
selon ses décisions.

LES STRATEGIES PAR CERTIFICATION

Le principe des travaux de recherche dans ce domaine sont sous-tendus 
par le raisonnement de faire en sorte qu'un utilisateur recevant un 
email puisse décider (soit manuellement, soit automatiquement) qu'un 
email est valide.

Il s'agit en fait du raisonnement inverse des méthodes précédentes qui 
visaient à éliminer les spams. Les stratégies par certification sont 
basées sur une volonté d'être le plus sûr possible de ne pas perdre de 
"bons" emails, même s'ils ont toutes les caractéristiques de forme d'un 
spam.

Bien entendu, et heureusement, ces deux méthodes ne sont pas exclusives. 
Ainsi, la peur de rater un bon email (faux positif) serait très 
fortement diminué si on a une garantie raisonnable de pouvoir garder 
systématiquement les bons emails.

SANS TIERS DE CONFIANCE

C'est l'idée de base du weemail qui a été présenté sur ce forum comme 
panacée universelle et presqu'unique et qui ne l'est pas.

Dans ce cas, l'expéditeur n'envoie en fait pas l'email au destinataire, 
mais seulement un message de disponibilité dudit message sur un serveur 
intermédiaire avec un URL.
Un principe tout à fait similaire à l'envoi des cartes postales 
électroniques pour lesquelles on reçoit un avertissement et qu'on va 
récupérer en cliquant sur le lien fourni.

Malheureusement, le point essentiel n'est pas couvert : les spammeurs 
peuvent assez facilement imiter un weemail, y compris le fait d'avoir 
une url pointant vers un message sur un serveur.
En effet, la plupart des spammeurs ont des compétences du même niveau 
que les hackers et sont parfaitement capables d'ouvrir ne serait ce que 
quelques jours des adresses url ou stocker les emails de spam.

A la limite, c'est même leur faciliter les choses, car ils n'ont même 
plus à envoyer leur email de spam, il leur suffit d'envoyer simplement 
des "weeheader".

Enfin, gros inconvénient : tous ces emails qui attendent n'attendront 
plus sur la machine de celui qui reçoit l'email mais sur une machine 
choisie par celui qui envoie l'email.
Et autant le marché est habitué à avoir des boites pop liées à 
l'utilisation d'un nom, autant je sens mal le coup de faire payer de 
l'espace disque à celui qui envoie sous prétexte que celui qui lit n'a 
pas vidé sa boite (et peut être ne la videra qu'après semaines ou mois).

AVEC TIERS DE CONFIANCE

Le système existe déjà pour la signature électronique, avec tiers de 
confiance, clef asymétrique (privée/oublique) mais est un moyen trop 
lourd pour les emails de tous les jours, car actuellement, les services 
commercialisés sont chers.
Ils sont chers, car le concept de la signature électronique est qu'un 
tiers garantisse l'identité de l'expéditeur.

L'offre marché est donc que l'acquéreur d'une clef appose la clef, ce 
qui permet à celui qui reçoit d'avoir la garantie que l'email provient 
de cette personne et pas une autre.

Pour la garantie de non spam, il n'est pas besoin d'un service aussi 
complet, car la seule chose qui importe est d'avoir la garantie qu'en 
cas de violation de la loi (spam avéré avec dépôt de plainte recevable), 
on puisse retrouver l'émetteur.

Le tiers de confiance ne serait donc sollicité que pour délivrer une 
clef à un personne physique ou morale (une personne avec une 
responsabilité juridique), puis mettre à disposition un serveur 
automatique qui se contente de dire si la clef est valable (à la 
réception de la signature anonyme + clef publique).

Un système de ce type ne serait assorti d'aucune assurance (ce qui est 
le cas actuellement pour couvrir contre les conséquences d'une 
falsification de signature) et pourrait donc avoir un ordre de grandeur 
de prix similaire à celui d'un nom de domaine internet.
Par ailleurs, il continue de protéger l'anonymat (puisque le tiers de 
confiance ne révèle pas l'identité, sauf dans un cadre juridique).

Un système de ce type pourrait garantir l'arrivée d'un message 
important, car il suffirait que ces messages soient traités de façon 
adéquate (genre whitelist) par les filtres.


CONCLUSION (bien évidemment temporaire tellement les choses vont vite)

Il n'y actuellement aucune méthode unique absolue pour lutter de façon 
totalement sûre contre le spam.

Mais je pense que nous sommes dans une situation où un bon assemblage 
d'éléments ne nécessitant pas une mise en place complexe nécessitant des 
décisions politiques, administratives et universelle pourrait être 
proche de l'idéal tel que nous le concevons aujourd'hui :

-> un filtrage très conservateur au niveau des serveurs qui éliminerait 
tout ce qui est évidemment du spam, sauf les systèmes de whitelist dont 
bien entendu les signatures ou les garanties d'origine.
-> un filtrage personnalisé complémentaire au niveau des domaines du 
même type que le premier, avec plus de règles, mais moins de mails à 
traiter (et donc une surcharge acceptable du travail du serveur)
-> un filtrage individuel, soit sur le serveur, soit sur un proxy, soit 
dans le logiciel client basé sur un ensemble de règles locales mais qui 
ne s'appliquerait plus que sur les emails qui ont passé les deux 
premiers filtres

Cet ensemble permet d'espérer l'élimination de presque tous les emails 
non sollicités, et même, sans parler des messages qui veulent faire 
grossir certaines parties anatomiques, réussirait peut-être à nous 
protéger partiellement en email de ce que nous n'avons jamais réussi à 
faire dans notre boite aux lettre ou à la télé.

-> enfin, le système de garantie d'origine qui se contenterait de 
garantir par un tiers de confiance que ce mail a été envoyé par 
quelqu'un que les forces de la justice pourraient retrouver si jamais il 
y avait dépôt de plainte. Ce qui nous permettrait de garantir qu'aucun 
filtre mal réglé ne puisse nous priver des mails importants.
(Mais permettrait aux pubs légales de nous parvenir quand même...)


Michel Lo

PS : tous les systèmes de filtres anti-spam que j'ai repéré : Ifile, 
CRM114, Bogofilter, Bayespam, SpamOracle, SpamStat, SpamProbe, TOLD, Tcl 
Spam Filter, Funkplanet Filter, POPFile, Mail-SpamTest-Bayesian, 
Pitonyak's Filter, JoeEmail, AGMSBayesianSpam, Spambayes, Spambayes for 
Outlook, SpamSieve, VBayesSpam, Annoyance Filter, Plan.Scm, Mozilla (le 
filtre intégré), Delord's POPF, Statistical Spam Filter, SquirrelBayes, 
Spam Filter for VPOP, Spammunition, XWall for MS Exchange, PASP, 
SpamPal, BMF, Spamcan, Gauche (Japonais), ASSP, Mail::Classifier, BSpam, 
DSPAM, Death2Spam, Spamassassin, K9, KSpam, Spamihilator, Disruptor OL, 
BSFilter (Japonais), Outclass, C Bayesian Filter, BayesIt! (Russe), 
Apple Mail (en osX), MSN 8, Spam Bully, Oddpost, Cerebrus, LegMail, Spam 
Inspector, SpamWeed, Eudora 6.0 (intégré dans), PrismEmail, InboxShield, 
trimMail, Junk-Out, Exapia, SpamHammer, GFI MailEssentials, SpamTiger, 
Eureka Email, MT-blacklist
et je n'ai pas mis les bases genre Razor Vipul's etc...



-------------- section suivante --------------
A non-text attachment was scrubbed...
Name: file:///C|/DOCUME%7E1/DENIS/LOCALS%7E1/TEMP/nsmail.tmp
Type: text/enriched
Size: 26425 bytes
Desc: non disponible
Url : /marchives/web1901/attachments/20031104/8d195292/nsmail.bin