MEILLEUR FILTRAGE BAYÉSIEN

Janvier 2003

(Cet article a été présenté lors d'une conférence à la Spam Conference de 2003. Il décrit le travail que j'ai effectué pour améliorer les performances de l'algorithme décrit dans A Plan for Spam , et ce que je prévois de faire à l'avenir.)

La première découverte que je voudrais présenter ici est un algorithme d'évaluation paresseuse des articles de recherche. Écrivez simplement ce que vous voulez et ne citez aucun travail antérieur, et des lecteurs indignés vous enverront des références à tous les articles que vous auriez dû citer. J'ai découvert cet algorithme après la publication de « A Plan for Spam » [1] sur Slashdot.

Le filtrage du spam est un sous-ensemble de la classification de texte, qui est un domaine bien établi, mais les premiers articles sur le filtrage du spam bayésien en soi semblent avoir été deux articles donnés lors de la même conférence en 1998, l'un par Pantel et Lin [2], et l'autre par un groupe de Microsoft Research [3].

Quand j'ai entendu parler de ce travail, j'ai été un peu surpris. Si les gens s'étaient intéressés au filtrage bayésien il y a quatre ans, pourquoi tout le monde ne l'utilisait-il pas ? En lisant les articles, j'ai découvert pourquoi. Le filtre de Pantel et Lin était le plus efficace des deux, mais il ne captait que 92 % des spams, avec 1,16 % de faux positifs.

Lorsque j'ai essayé d'écrire un filtre anti-spam bayésien, il a détecté 99,5 % des spams avec moins de 0,03 % de faux positifs [4]. Il est toujours alarmant que deux personnes essayant la même expérience obtiennent des résultats très divergents. C'est particulièrement alarmant ici car ces deux séries de chiffres peuvent donner des conclusions opposées. Différents utilisateurs ont des exigences différentes, mais je pense que pour de nombreuses personnes, un taux de filtrage de 92 % avec 1,16 % de faux positifs signifie que le filtrage n'est pas une solution acceptable, alors que 99,5 % avec moins de 0,03 % de faux positifs signifie qu'il l'est.

Alors pourquoi avons-nous obtenu des chiffres aussi différents ? Je n'ai pas essayé de reproduire les résultats de Pantel et Lin, mais en lisant l'article, je vois cinq choses qui expliquent probablement cette différence.

L’une d’entre elles est qu’ils ont simplement entraîné leur filtre sur très peu de données : 160 spams et 466 non-spams. Les performances du filtre devraient encore augmenter avec des ensembles de données aussi petits. Leurs chiffres ne constituent donc peut-être même pas une mesure précise des performances de leur algorithme, sans parler du filtrage bayésien du spam en général.

Mais je pense que la différence la plus importante est probablement qu'ils ont ignoré les en-têtes des messages. Pour quiconque a travaillé sur des filtres anti-spam, cela semblera une décision perverse. Et pourtant, dans les tout premiers filtres que j'ai essayé d'écrire, j'ai également ignoré les en-têtes. Pourquoi ? Parce que je voulais garder le problème clair. Je ne savais pas grand-chose sur les en-têtes de courrier à l'époque, et ils me semblaient pleins de choses aléatoires. Il y a une leçon à tirer de tout cela pour les rédacteurs de filtres : n'ignorez pas les données. On pourrait penser que cette leçon serait trop évidente pour être mentionnée, mais j'ai dû l'apprendre plusieurs fois.

Troisièmement, Pantel et Lin ont réduit les tokens, c'est-à-dire qu'ils ont réduit par exemple à la fois mailing'' and « mailed » à la racine « mail ». Ils ont peut-être eu le sentiment d'avoir été contraints de le faire en raison de la petite taille de leur corpus, mais si tel est le cas, il s'agit d'une sorte d'optimisation prématurée.

Quatrièmement, ils ont calculé les probabilités différemment. Ils ont utilisé tous les tokens, alors que je n'utilise que les 15 plus significatifs. Si vous utilisez tous les tokens, vous aurez tendance à rater les spams plus longs, le type de spams où quelqu'un vous raconte l'histoire de sa vie jusqu'au moment où il s'est enrichi grâce à un système de marketing à paliers multiples. Et un tel algorithme serait facile à imiter pour les spammeurs : il suffirait d'ajouter un gros morceau de texte aléatoire pour contrebalancer les termes du spam.

Enfin, ils n'ont pas eu de préjugés contre les faux positifs. Je pense que tout algorithme de filtrage du spam devrait avoir un bouton pratique que vous pouvez tourner pour diminuer le taux de faux positifs au détriment du taux de filtrage. Je le fais en comptant les occurrences de jetons dans le double du corpus non spam.

Je ne pense pas que ce soit une bonne idée de traiter le filtrage du spam comme un simple problème de classification de texte. Vous pouvez utiliser des techniques de classification de texte, mais les solutions peuvent et doivent tenir compte du fait que le texte est un e-mail, et en particulier un spam. L'e-mail n'est pas seulement du texte ; il a une structure. Le filtrage du spam n'est pas seulement une classification, car les faux positifs sont bien pires que les faux négatifs et vous devez les traiter comme un autre type d'erreur. Et la source de l'erreur n'est pas simplement une variation aléatoire, mais un spammeur humain en direct qui travaille activement pour contourner votre filtre.

Jetons

Un autre projet dont j'ai entendu parler après l'article de Slashdot est CRM114 de Bill Yerazunis [5]. C'est le contre-exemple du principe de conception que je viens de mentionner. Il s'agit d'un classificateur de texte simple, mais tellement efficace qu'il parvient à filtrer le spam presque parfaitement sans même savoir ce qu'il fait.

Une fois que j'ai compris comment fonctionnait CRM114, il m'a semblé inévitable que je doive un jour passer du filtrage basé sur des mots simples à une approche comme celle-ci. Mais d'abord, je me suis dit : je vais voir jusqu'où je peux aller avec des mots simples. Et la réponse est : étonnamment loin.

J'ai principalement travaillé sur une tokenisation plus intelligente. Sur les spams actuels, j'ai pu atteindre des taux de filtrage proches de ceux de CRM114. Ces techniques sont pour la plupart orthogonales à celles de Bill ; une solution optimale pourrait incorporer les deux.

« A Plan for Spam » utilise une définition très simple d'un jeton. Les lettres, les chiffres, les tirets, les apostrophes et les symboles dollar sont des caractères constitutifs, et tout le reste est un séparateur de jeton. J'ai également ignoré la casse.

J'ai maintenant une définition plus compliquée d'un jeton :

L'affaire est conservée.

Les points d’exclamation sont des caractères constitutifs.

Les points et les virgules sont des constituants s'ils apparaissent entre deux chiffres. Cela me permet d'obtenir des adresses IP et des prix intacts.

Une fourchette de prix de 20 à 25 $ donne deux jetons, 20 $ et 25 $.

Les jetons qui apparaissent dans les lignes À, De, Objet et Chemin de retour, ou dans les URL, sont marqués en conséquence. Par exemple, foo'' in the Subject line becomes Sujet*foo''. (L'astérisque peut être n'importe quel caractère que vous n'autorisez pas comme constituant.)

De telles mesures augmentent le vocabulaire du filtre, ce qui le rend plus discriminant. Par exemple, dans le filtre actuel, « gratuit » dans la ligne d'objet a une probabilité de spam de 98 %, tandis que le même jeton dans le corps a une probabilité de spam de seulement 65 %.

Voici quelques-unes des probabilités actuelles [6] :

Sujet GRATUIT 0,9999 gratuit !! 0,9999 À gratuit 0,9998 Sujet gratuit 0,9782 gratuit ! 0,9199 Gratuit 0,9198 Url gratuit 0,9091 GRATUIT 0,8747 À partir de*gratuit 0,7636 gratuit 0,6546

Dans le filtre Plan for Spam, tous ces jetons auraient eu la même probabilité, 0,7602. Ce filtre a reconnu environ 23 000 jetons. Le filtre actuel en reconnaît environ 187 000.

L'inconvénient d'avoir un univers de tokens plus large est qu'il y a plus de risques d'échecs. Répartir votre corpus sur plus de tokens a le même effet que de le réduire. Si vous considérez les points d'exclamation comme des constituants, par exemple, vous pourriez vous retrouver à ne pas avoir de probabilité de spam pour les free avec sept points d'exclamation, même si vous savez que les free avec seulement deux points d'exclamation ont une probabilité de 99,99 %.

Une solution à ce problème est ce que j'appelle la dégénérescence. Si vous ne parvenez pas à trouver une correspondance exacte pour un jeton, traitez-le comme s'il s'agissait d'une version moins spécifique. Je considère que les points d'exclamation terminaux, les lettres majuscules et l'apparition dans l'un des cinq contextes marqués rendent un jeton plus spécifique. Par exemple, si je ne trouve pas de probabilité pour Subject*free!'', I look for probabilities for Subject*free'', free!'', and free'', et je prends celle qui est la plus éloignée de 0,5.

Voici les alternatives [7] envisagées si le filtre voit « GRATUIT !!! » dans la ligne d'objet et n'a pas de probabilité pour cela.

Sujet Gratuit !!! Sujet Gratuit !!! Sujet GRATUIT ! Sujet Gratuit ! Sujet Gratuit ! Sujet GRATUIT Sujet Gratuit Sujet gratuit GRATUIT !!! Gratuit !!! gratuit !!! GRATUIT ! Gratuit ! gratuit ! GRATUIT Gratuit gratuit

Si vous faites cela, assurez-vous de prendre en compte les versions avec des majuscules initiales ainsi que toutes les majuscules et toutes les minuscules. Les spams ont tendance à avoir plus de phrases à l'impératif, et dans celles-ci, le premier mot est un verbe. Ainsi, les verbes avec des majuscules initiales ont des probabilités de spam plus élevées que ceux avec des minuscules. Dans mon filtre, la probabilité de spam de Act'' is 98% and for act'' de seulement 62 %.

Si vous augmentez le vocabulaire de votre filtre, vous pouvez finir par compter le même mot plusieurs fois, selon votre ancienne définition de « même ». Logiquement, ce ne sont plus les mêmes mots. Mais si cela vous dérange toujours, laissez-moi ajouter, par expérience, que les mots que vous semblez compter plusieurs fois ont tendance à être exactement ceux que vous voudriez compter.

Un autre effet d'un vocabulaire plus large est que lorsque vous examinez un courrier entrant, vous trouvez des tokens plus intéressants, c'est-à-dire ceux dont la probabilité est loin de 0,5. J'utilise les 15 plus intéressants pour décider si un courrier est un spam. Mais vous pouvez rencontrer un problème lorsque vous utilisez un nombre fixe comme celui-ci. Si vous trouvez beaucoup de tokens extrêmement intéressants, le résultat peut finir par être déterminé par n'importe quel facteur aléatoire qui détermine l'ordre des tokens tout aussi intéressants. Une façon de gérer cela est de traiter certains comme plus intéressants que d'autres.

Par exemple, le token dalco'' occurs 3 times in my spam corpus and never in my legitimate corpus. The token Url*optmails'' (qui signifie ``optmails'' dans une URL) apparaît 1223 fois. Et pourtant, comme j'avais l'habitude de calculer les probabilités pour les tokens, les deux auraient la même probabilité de spam, le seuil de 0,99.

Cela ne me semble pas juste. Il existe des arguments théoriques pour attribuer à ces deux tokens des probabilités sensiblement différentes (Pantel et Lin le font), mais je n'ai pas encore essayé. Il semble au moins que si nous trouvons plus de 15 tokens qui n'apparaissent que dans l'un ou l'autre corpus, nous devrions donner la priorité à ceux qui apparaissent beaucoup. Il existe donc maintenant deux valeurs seuils. Pour les tokens qui n'apparaissent que dans le corpus de spam, la probabilité est de 0,9999 s'ils apparaissent plus de 10 fois et de 0,9998 sinon. Idem à l'autre extrémité de l'échelle pour les tokens trouvés uniquement dans le corpus légitime.

Je pourrai plus tard augmenter considérablement les probabilités des jetons, mais cette petite quantité d'augmentation garantit au moins que les jetons sont triés de la bonne manière.

Une autre possibilité serait de considérer non seulement 15 jetons, mais tous les jetons au-delà d'un certain seuil d'intérêt. Steven Hauser le fait dans son filtre anti-spam statistique [8]. Si vous utilisez un seuil, fixez-le très haut, sinon les spammeurs pourraient vous tromper en remplissant vos messages de mots plus innocents.

Finalement, que faire du HTML ? J'ai essayé toute la gamme des options, de l'ignorer à l'analyser dans son intégralité. Ignorer le HTML est une mauvaise idée, car il est plein de signes de spam utiles. Mais si vous l'analysez dans son intégralité, votre filtre pourrait dégénérer en un simple outil de reconnaissance HTML. L'approche la plus efficace semble être la voie médiane, qui consiste à remarquer certains jetons mais pas d'autres. Je regarde les balises a, img et font, et j'ignore le reste. Vous devriez certainement regarder les liens et les images, car ils contiennent des URL.

Je pourrais probablement être plus intelligent dans la gestion du HTML, mais je ne pense pas que cela vaille la peine d'y consacrer beaucoup de temps. Les spams remplis de HTML sont faciles à filtrer. Les spammeurs les plus intelligents les évitent déjà. Les performances futures ne devraient donc pas dépendre beaucoup de la façon dont vous gérez le HTML.

Performance

Entre le 10 décembre 2002 et le 10 janvier 2003, j'ai reçu environ 1750 spams. Parmi ceux-ci, 4 sont passés. Cela représente un taux de filtrage d'environ 99,75 %.

Deux des quatre spams que j'ai manqués sont passés car ils utilisaient des mots qui apparaissent souvent dans mon courrier électronique légitime.

Le troisième était l'un de ceux qui exploitent un script cgi non sécurisé pour envoyer du courrier à des tiers. Ils sont difficiles à filtrer en se basant uniquement sur le contenu, car les en-têtes sont innocents et ils font attention aux mots qu'ils utilisent. Malgré tout, je peux généralement les attraper. Celui-ci s'en sort avec une probabilité de 0,88, juste en dessous du seuil de 0,9.

Bien sûr, il suffit d'examiner plusieurs séquences de jetons pour le détecter facilement. « Vous trouverez ci-dessous le résultat de votre formulaire de commentaires » est un indice instantané.

Le quatrième spam était ce que j'appelle un spam du futur, car je m'attends à ce que le spam évolue vers ceci : un texte complètement neutre suivi d'une URL. Dans ce cas, il s'agissait d'une personne qui disait qu'elle avait enfin terminé sa page d'accueil et qu'elle irait la voir. (La page était bien sûr une publicité pour un site pornographique.)

Si les spammeurs font attention aux en-têtes et utilisent une URL récente, les filtres ne remarqueront rien dans le spam du futur. Nous pouvons bien sûr contrer en envoyant un robot d'exploration pour examiner la page. Mais cela n'est peut-être pas nécessaire. Le taux de réponse du spam du futur doit être faible, sinon tout le monde le ferait. S'il est suffisamment faible, les spammeurs ne seront pas payés pour l'envoyer, et nous n'aurons pas à travailler trop dur pour le filtrer.

Passons maintenant à la nouvelle vraiment choquante : au cours de cette même période d’un mois, j’ai eu trois faux positifs.

D'une certaine manière, c'est un soulagement d'obtenir quelques faux positifs. Lorsque j'ai écrit « A Plan for Spam », je n'en avais pas eu et je ne savais pas à quoi ils ressembleraient. Maintenant que j'en ai eu quelques-uns, je suis soulagé de constater qu'ils ne sont pas aussi graves que je le craignais. Les faux positifs générés par les filtres statistiques se révèlent être des messages qui ressemblent beaucoup à du spam, et ce sont généralement ceux que vous auriez le moins peur de manquer [9].

Deux des faux positifs étaient des newsletters de sociétés auprès desquelles j'ai acheté des choses. Je n'ai jamais demandé à les recevoir, donc il est possible qu'il s'agisse de spams, mais je les considère comme des faux positifs car je ne les supprimais pas comme spams auparavant. La raison pour laquelle les filtres les ont détectés est que les deux sociétés ont opté en janvier pour des expéditeurs de courrier électronique commerciaux au lieu d'envoyer les courriers depuis leurs propres serveurs, et les en-têtes et les corps sont devenus beaucoup plus spammés.

Le troisième faux positif était cependant un mauvais message. Il provenait d'une personne en Égypte et était écrit en majuscules. C'était le résultat direct de la prise en compte de la casse des jetons ; le filtre Plan for Spam ne l'aurait pas détecté.

Il est difficile de dire quel est le taux global de faux positifs, car nous sommes dans le coup, statistiquement parlant. Quiconque a travaillé sur des filtres (du moins, des filtres efficaces) sera conscient de ce problème. Avec certains e-mails, il est difficile de dire s'il s'agit de spam ou non, et ce sont ceux-là que vous finissez par regarder lorsque vous avez des filtres très stricts. Par exemple, jusqu'à présent, le filtre a détecté deux e-mails qui ont été envoyés à mon adresse à cause d'une faute de frappe, et un autre qui m'a été envoyé en pensant que j'étais quelqu'un d'autre. On peut dire qu'il ne s'agit ni de spam ni de courrier non spam.

Un autre faux positif est venu d'un vice-président de Virtumundo. Je leur ai écrit en me faisant passer pour un client, et comme la réponse est arrivée via les serveurs de messagerie de Virtumundo, elle contenait les en-têtes les plus compromettants imaginables. Il ne s'agit sans doute pas non plus d'un vrai faux positif, mais d'une sorte d'effet d'incertitude Heisenberg : je l'ai reçu uniquement parce que j'écrivais sur le filtrage du spam.

Sans compter ceux-ci, j'ai eu jusqu'à présent un total de cinq faux positifs, sur environ 7 740 e-mails légitimes, soit un taux de 0,06 %. Les deux autres étaient un avis indiquant que quelque chose que j'avais acheté était en rupture de stock et un rappel de fête d'Evite.

Je ne pense pas que ce nombre soit fiable, en partie parce que l'échantillon est si petit, et en partie parce que je pense pouvoir réparer le filtre pour ne pas en attraper certains.

Les faux positifs me semblent être un type d'erreur différent des faux négatifs. Le taux de filtrage est une mesure de performance. Les faux positifs me semblent plutôt être des bugs. J'aborde l'amélioration du taux de filtrage comme une optimisation et la diminution des faux positifs comme une opération de débogage.

Ces cinq faux positifs constituent donc ma liste de bugs. Par exemple, le courrier en provenance d'Égypte a été bloqué parce que le texte en majuscules le faisait passer pour un spam nigérian. C'est vraiment un bug. Comme pour le HTML, le fait que le courrier électronique soit entièrement en majuscules est en réalité une caractéristique conceptuelle, et non une caractéristique pour chaque mot. Je dois gérer la casse de manière plus sophistiquée.

Alors, que penser de ce 0,06 % ? Pas grand-chose, je pense. On pourrait le considérer comme une limite supérieure, compte tenu de la petite taille de l'échantillon. Mais à ce stade, il s'agit davantage d'une mesure des bugs de mon implémentation que d'un taux intrinsèque de faux positifs du filtrage bayésien.

Avenir

Et ensuite ? Le filtrage est un problème d'optimisation, et la clé de l'optimisation est le profilage. N'essayez pas de deviner où votre code est lent, car vous vous tromperez. Regardez où votre code est lent et corrigez cela. En matière de filtrage, cela se traduit par : regardez les spams que vous avez manqués et déterminez ce que vous auriez pu faire pour les attraper.

Par exemple, les spammeurs travaillent désormais de manière agressive pour échapper aux filtres, et l'une des choses qu'ils font est de décomposer et de mal orthographier les mots pour empêcher les filtres de les reconnaître. Mais travailler sur ce point n'est pas ma première priorité, car je n'ai toujours aucun mal à détecter ces spams [10].

Il y a deux types de spams qui me posent actuellement problème. Le premier est celui qui prétend être un e-mail d'une femme vous invitant à discuter avec elle ou à consulter son profil sur un site de rencontre. Ces spams passent au travers car ils constituent le seul type de discours commercial que vous pouvez faire sans utiliser de discours commercial. Ils utilisent le même vocabulaire que les e-mails ordinaires.

L'autre type de spam que j'ai du mal à filtrer est celui des entreprises bulgares qui proposent des services de programmation sous contrat. Ceux-ci passent parce que je suis moi-même programmeur et que les spams contiennent les mêmes mots que mon vrai courrier.

Je vais probablement me concentrer d'abord sur le type d'annonce personnelle. Je pense qu'en y regardant de plus près, je pourrai trouver des différences statistiques entre celles-ci et mon vrai courrier. Le style d'écriture est certainement différent, même s'il faudra peut-être filtrer plusieurs mots pour le détecter. De plus, je remarque qu'ils ont tendance à répéter l'URL, et quelqu'un qui inclut une URL dans un courrier légitime ne le ferait pas [11].

Les sites de ce type seront difficiles à repérer. Même si vous envoyez un robot d'exploration sur le site, vous ne trouverez pas de preuve statistique irréfutable. La seule réponse est peut-être une liste centrale de domaines annoncés dans les spams [12]. Mais il ne peut pas y avoir beaucoup de courriers de ce type. Si les seuls spams restants étaient des offres non sollicitées de services de programmation sous contrat en provenance de Bulgarie, nous pourrions probablement tous passer à autre chose.

Le filtrage statistique nous permettra-t-il d'en arriver là ? Je ne sais pas. Pour l'instant, le spam ne me pose pas de problème. Mais les spammeurs n'ont pas encore fait d'efforts sérieux pour tromper les filtres statistiques. Que se passera-t-il lorsqu'ils le feront ?

Je ne suis pas optimiste quant aux filtres qui fonctionnent au niveau du réseau [13]. Lorsqu'il existe un obstacle statique qui vaut la peine d'être dépassé, les spammeurs sont assez efficaces pour le contourner. Il existe déjà une société appelée Assurance Systems qui fera passer votre courrier par Spamassassin et vous dira s'il sera filtré.

Les filtres au niveau du réseau ne seront pas complètement inutiles. Ils peuvent suffire à éliminer tous les spams « opt-in », c'est-à-dire les spams provenant d'entreprises comme Virtumundo et Equalamail qui prétendent qu'elles gèrent en réalité des listes opt-in. Vous pouvez les filtrer en vous basant uniquement sur les en-têtes, peu importe ce qu'ils disent dans le corps. Mais quiconque est prêt à falsifier les en-têtes ou à utiliser des relais ouverts, y compris vraisemblablement la plupart des spammeurs pornographiques, devrait pouvoir faire passer certains messages au-delà des filtres au niveau du réseau s'il le souhaite. (Ce n'est en aucun cas le message qu'ils aimeraient envoyer, ce qui est déjà une bonne chose.)

Les filtres qui me semblent les plus optimistes sont ceux qui calculent les probabilités en fonction du courrier électronique de chaque utilisateur. Ils peuvent être beaucoup plus efficaces, non seulement pour éviter les faux positifs, mais aussi pour filtrer : par exemple, trouver l'adresse électronique du destinataire encodée en base 64 n'importe où dans un message est un très bon indicateur de spam.

Mais le véritable avantage des filtres individuels est qu'ils seront tous différents. Si les filtres de chacun ont des probabilités différentes, cela rendra la boucle d'optimisation des spammeurs, ce que les programmeurs appelleraient leur cycle d'édition-compilation-test, terriblement lente. Au lieu de simplement peaufiner un spam jusqu'à ce qu'il passe à travers une copie d'un filtre qu'ils ont sur leur bureau, ils devront faire un test d'envoi pour chaque modification. Ce serait comme programmer dans un langage sans niveau supérieur interactif, et je ne souhaite cela à personne.

Remarques

[1] Paul Graham. « Un plan pour le spam ». Août 2002. http://paulgraham.com/spam.html.

Les probabilités dans cet algorithme sont calculées à l'aide d'un cas dégénéré de la règle de Bayes. Il existe deux hypothèses simplificatrices : les probabilités des caractéristiques (c'est-à-dire des mots) sont indépendantes et nous ne savons rien de la probabilité a priori qu'un e-mail soit un spam.

La première hypothèse est largement répandue dans la classification de textes. Les algorithmes qui l'utilisent sont appelés « bayésiens naïfs ».

J'ai fait la deuxième hypothèse parce que la proportion de spam dans mon courrier entrant fluctuait tellement d'un jour à l'autre (et même d'une heure à l'autre) que le ratio global antérieur ne semblait pas avoir de valeur prédictive. Si vous supposez que P(spam) et P(non-spam) sont tous deux égaux à 0,5, ils s'annulent et vous pouvez les supprimer de la formule.

Si vous procédiez à un filtrage bayésien dans une situation où le ratio de spam par rapport aux non-spam était systématiquement très élevé ou (surtout) très faible, vous pourriez probablement améliorer les performances du filtre en intégrant des probabilités antérieures. Pour ce faire, vous devriez suivre les ratios en fonction de l'heure de la journée, car le volume de spam et de courrier légitime présente tous deux des tendances quotidiennes distinctes.

[2] Patrick Pantel et Dekang Lin. « SpamCop – Un programme de classification et d'organisation du spam. » Actes de l'atelier AAAI-98 sur l'apprentissage pour la catégorisation de texte.

[3] Mehran Sahami, Susan Dumais, David Heckerman et Eric Horvitz. « Une approche bayésienne pour filtrer le courrier indésirable ». Actes de l'atelier AAAI-98 sur l'apprentissage pour la catégorisation de texte.

[4] À l’époque, je n’avais aucun faux positif sur environ 4 000 courriels légitimes. Si le prochain courriel légitime était un faux positif, cela nous donnerait 0,03 %. Ces taux de faux positifs ne sont pas fiables, comme je l’expliquerai plus tard. Je cite un chiffre ici uniquement pour souligner que quel que soit le taux de faux positifs, il est inférieur à 1,16 %.

[5] Bill Yerazunis. « Filtrage des messages de hachage polynomial binaire clairsemé et le discriminateur CRM114. » Actes de la conférence Spam 2003.

[6] Dans « A Plan for Spam », j'ai utilisé des seuils de 0,99 et 0,01. Il semble justifié d'utiliser des seuils proportionnels à la taille des corpus. Comme j'ai maintenant environ 10 000 de chaque type de courrier, j'utilise 0,9999 et 0,0001.

[7] Il y a ici un défaut que je devrais probablement corriger. Actuellement, lorsque Subject*foo'' degenerates to just foo'', cela signifie que vous obtenez les statistiques pour les occurrences de foo'' in the body or header lines other than those I mark. What I should do is keep track of statistics for foo'' en général ainsi que pour des versions spécifiques, et dégénérer de Subject*foo'' not to foo'' mais en ``Anywhere*foo''. Idem pour la casse : je devrais dégénérer des majuscules en n'importe quelle casse, pas en minuscules.

Ce serait probablement une victoire de faire la même chose avec les prix, par exemple en passant de $129.99'' to --9,99 $, $--.99'', and -- $.

Vous pourriez également dégénérer des mots vers leurs racines, mais cela n'améliorerait probablement les taux de filtrage qu'au début, lorsque vous disposez de petits corpus.

[8] Steven Hauser. « Le filtre anti-spam statistique fonctionne pour moi. » http://www.sofbot.com.

[9] Les faux positifs ne sont pas tous égaux, et nous devons nous en souvenir lorsque nous comparons les techniques de lutte contre le spam. Alors que de nombreux faux positifs causés par les filtres seront des quasi-spams que vous ne craindrez pas de manquer, les faux positifs causés par les listes noires, par exemple, seront simplement des messages provenant de personnes qui ont choisi le mauvais FAI. Dans les deux cas, vous détectez les messages qui sont proches du spam, mais pour les listes noires, la proximité est physique, et pour les filtres, elle est textuelle.

[10] Si les spammeurs deviennent suffisamment doués pour masquer les jetons et que cela pose problème, nous pouvons réagir en supprimant simplement les espaces, les points, les virgules, etc. et en utilisant un dictionnaire pour extraire les mots de la séquence résultante. Et bien sûr, trouver de cette façon des mots qui n'étaient pas visibles dans le texte d'origine serait en soi une preuve de spam.

Choisir les mots ne sera pas une mince affaire. Il faudra plus que simplement reconstruire les limites des mots ; les spammeurs ajoutent ( xHot nPorn cSite'') and omit ( P#rn'') des lettres. La recherche sur la vision peut être utile ici, car la vision humaine est la limite que de telles astuces peuvent approcher.

[11] En général, les spams sont plus répétitifs que les e-mails classiques. Ils veulent faire passer le message. Je n'autorise actuellement pas les doublons dans les 15 premiers tokens, car vous pourriez obtenir un faux positif si l'expéditeur utilise un mot grossier plusieurs fois. (Dans mon filtre actuel, « dick » a une probabilité de spam de 0,9999, mais c'est aussi un nom.) Il semble que nous devrions au moins remarquer les doublons, donc je vais peut-être essayer d'autoriser jusqu'à deux de chaque token, comme le fait Brian Burton dans SpamProbe.

[12] C'est à cela que dégénéreront des approches comme Brightmail une fois que les spammeurs seront poussés à utiliser des techniques mad-lib pour générer tout le reste du message.

[13] On prétend parfois que nous devrions travailler sur le filtrage au niveau du réseau, car c'est plus efficace. Ce que les gens veulent généralement dire quand ils disent cela est : nous filtrons actuellement au niveau du réseau, et nous ne voulons pas tout recommencer à zéro. Mais vous ne pouvez pas dicter le problème pour qu'il s'adapte à votre solution.

Historiquement, les arguments relatifs à la rareté des ressources ont été perdants dans les débats sur la conception de logiciels. Les gens ont tendance à les utiliser uniquement pour justifier des choix (en particulier l'inaction) faits pour d'autres raisons.

Merci à Sarah Harlin, Trevor Blackwell et Dan Giffin pour avoir lu les brouillons de cet article, et encore à Dan pour la plupart de l'infrastructure sur laquelle ce filtre fonctionne.

En rapport:

Sujet GRATUIT 0,9999 gratuit !! 0,9999 À gratuit 0,9998 Sujet gratuit 0,9782 gratuit ! 0,9199 Gratuit 0,9198 Url gratuit 0,9091 GRATUIT 0,8747 À partir de*gratuit 0,7636 gratuit 0,6546