UN MEILLEUR FILTRAGE BAYÉSIEN

Janvier 2003

(Cet article a été présenté sous forme de 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 pour l'évaluation paresseuse des articles de recherche. Il suffit de écrire ce que vous voulez et de ne citer aucun travail antérieur, et les 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 que ``A Plan for Spam'' [1] a été 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 présentés à la même conférence en 1998, l'un par Pantel et Lin [2], et l'autre par un groupe de Microsoft Research [3].

Lorsque j'ai entendu parler de ce travail, j'ai été un peu surpris. Si les gens étaient au courant du filtrage bayésien il y a quatre ans, pourquoi tout le monde ne l'utilisait-il pas ? Lorsque j'ai lu les articles, j'ai compris pourquoi. Le filtre de Pantel et Lin était le plus efficace des deux, mais il ne capturait que 92 % du spam, avec 1,16 % de faux positifs.

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

Alors pourquoi avons-nous obtenu des chiffres si 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 la différence.

L'une est simplement qu'ils ont entraîné leur filtre sur très peu de données : 160 spams et 466 courriels non spams. Les performances du filtre devraient encore augmenter avec des ensembles de données aussi petits. Donc, leurs chiffres peuvent ne pas être une mesure précise des performances de leur algorithme, sans parler du filtrage du spam bayésien 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 tous ceux qui ont travaillé sur des filtres anti-spam, cela paraîtra une décision perverse. Et pourtant, dans les tout premiers filtres que j'ai essayé d'écrire, j'ai ignoré les en-têtes aussi. Pourquoi ? Parce que je voulais que le problème reste propre. Je ne connaissais pas grand-chose sur les en-têtes de courrier à l'époque, et elles me semblaient pleines de choses aléatoires. Il y a une leçon ici pour les auteurs 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 jetons, ce qui signifie qu'ils ont réduit par exemple à la fois mailing'' et mailed'' à la racine ``mail''. Ils ont peut-être pensé qu'ils étaient obligés de le faire en raison de la petite taille de leur corpus, mais si c'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 jetons, tandis que moi je n'utilise que les 15 plus significatifs. Si vous utilisez tous les jetons, vous aurez tendance à manquer les spams plus longs, du type où quelqu'un vous raconte sa vie jusqu'au moment où il s'est enrichi grâce à un système de marketing multi-niveaux. Et un tel algorithme serait facile à usurper pour les spammeurs : il suffit d'ajouter un gros bloc de texte aléatoire pour contrebalancer les termes de spam.

Enfin, ils n'ont pas biaisé 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 des jetons dans le corpus non spam deux fois.

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 refléter le fait que le texte est un courriel, et le spam en particulier. Le courriel n'est pas seulement du texte ; il a une structure. Le filtrage du spam n'est pas seulement de la classification, parce que les faux positifs sont bien pires que les faux négatifs que vous devriez les traiter comme un type d'erreur différent. Et la source de l'erreur n'est pas seulement une variation aléatoire, mais un spammeur humain vivant qui travaille activement pour vaincre votre filtre.

Jetons

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

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

J'ai surtout travaillé sur une tokenisation plus intelligente. Sur le spam actuel, j'ai pu atteindre des taux de filtrage qui se rapprochent 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 signes dollar sont des caractères constitutifs, et tout le reste est un séparateur de jetons. J'ai également ignoré la casse.

Maintenant, j'ai une définition plus complexe d'un jeton :

La casse est conservée.

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

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

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

Les jetons qui apparaissent dans les lignes To, From, Subject et Return-Path, ou dans les URL, sont marqués en conséquence. Par exemple, foo'' dans la ligne Subject devient Subject*foo''. (L'astérisque pourrait ê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, ``free'' dans la ligne Subject 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] :

SubjectFREE 0.9999 free!! 0.9999 Tofree 0.9998 Subjectfree 0.9782 free! 0.9199 Free 0.9198 Urlfree 0.9091 FREE 0.8747 From*free 0.7636 free 0.6546

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

L'inconvénient d'avoir un univers de jetons plus large est qu'il y a plus de chances de manquer. Répartir votre corpus sur plus de jetons a le même effet que de le rendre plus petit. 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 free avec sept points d'exclamation, même si vous savez que free avec seulement deux points d'exclamation a une probabilité de 99,99 %.

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

Voici les alternatives [7] prises en compte si le filtre voit ``FREE!!!'' dans la ligne Subject et n'a pas de probabilité pour elle.

SubjectFree!!! Subjectfree!!! SubjectFREE! SubjectFree! Subjectfree! SubjectFREE SubjectFree Subjectfree FREE!!! Free!!! free!!! FREE! Free! free! FREE Free free

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. Donc, les verbes avec des majuscules initiales ont des probabilités de spam plus élevées que s'ils étaient en minuscules. Dans mon filtre, la probabilité de spam de Act'' est de 98 % et pour act'' seulement 62 %.

Si vous augmentez le vocabulaire de votre filtre, vous pouvez vous retrouver à compter le même mot plusieurs fois, selon votre ancienne définition de ``même''. Logiquement, ce ne sont plus les mêmes jetons. Mais si cela vous dérange toujours, laissez-moi ajouter d'expérience que les mots que vous semblez être en train de compter plusieurs fois sont généralement exactement ceux que vous voudriez compter.

Un autre effet d'un vocabulaire plus large est que lorsque vous regardez un courriel entrant, vous trouvez des jetons plus intéressants, c'est-à-dire ceux dont les probabilités sont loin de 0,5. J'utilise les 15 plus intéressants pour décider si le courriel est un spam. Mais vous pouvez rencontrer un problème lorsque vous utilisez un nombre fixe comme celui-ci. Si vous trouvez beaucoup de jetons maximales intéressants, le résultat peut finir par être décidé par le facteur aléatoire qui détermine l'ordre des jetons également intéressants. Une façon de traiter cela est de traiter certains comme étant plus intéressants que d'autres.

Par exemple, le jeton dalco'' apparaît 3 fois dans mon corpus de spam et jamais dans mon corpus légitime. Le jeton Url*optmails'' (signifiant ``optmails'' dans une URL) apparaît 1223 fois. Et pourtant, comme je calculais les probabilités pour les jetons, 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 donner à ces deux jetons des probabilités sensiblement différentes (Pantel et Lin le font), mais je n'ai pas encore essayé cela. Il semble au moins que si nous trouvons plus de 15 jetons qui n'apparaissent que dans l'un ou l'autre corpus, nous devrions donner la priorité à ceux qui apparaissent beaucoup. Donc, maintenant il y a deux valeurs de seuil. Pour les jetons 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 jetons trouvés uniquement dans le corpus légitime.

Je pourrais plus tard mettre à l'échelle les probabilités des jetons de manière substantielle, mais cette petite quantité de mise à l'échelle garantit au moins que les jetons sont triés dans le bon ordre.

Une autre possibilité serait de ne pas considérer seulement 15 jetons, mais tous les jetons au-dessus d'un certain seuil d'intérêt. Steven Hauser le fait dans son filtre anti-spam statistique [8]. Si vous utilisez un seuil, faites-le très élevé, ou les spammeurs pourraient vous usurper en remplissant les messages de mots plus innocents.

Enfin, que faut-il faire avec le HTML ? J'ai essayé toute la gamme des options, de l'ignorer à l'analyser complètement. Ignorer le HTML est une mauvaise idée, car il est plein de signes de spam utiles. Mais si vous l'analysez complètement, votre filtre pourrait dégénérer en un simple reconnaisseur de HTML. L'approche la plus efficace semble être le juste milieu, de remarquer certains jetons mais pas d'autres. Je regarde les balises a, img et font, et j'ignore le reste. Les liens et les images, vous devriez certainement les regarder, car ils contiennent des URL.

Je pourrais probablement être plus intelligent dans ma façon de traiter le 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à. Donc les performances à l'avenir ne devraient pas dépendre beaucoup de la façon dont vous traitez 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 parce qu'ils utilisaient des mots qui apparaissent souvent dans mes courriels légitimes.

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

Bien sûr, regarder plusieurs séquences de jetons permettrait de l'attraper facilement. ``Voici 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 c'est ce que je m'attends à ce que le spam évolue : un texte complètement neutre suivi d'une URL. Dans ce cas, il provenait de quelqu'un qui disait avoir enfin terminé sa page d'accueil et me demandait d'aller la regarder. (La page était bien sûr une annonce pour un site porno.)

Si les spammeurs font attention aux en-têtes et utilisent une URL fraîche, il n'y a rien dans le spam-du-futur pour que les filtres puissent le remarquer. Nous pouvons bien sûr contrer en envoyant un robot d'exploration pour regarder la page. Mais cela pourrait ne pas être nécessaire. Le taux de réponse pour le spam-du-futur doit être faible, sinon tout le monde le ferait. S'il est suffisamment faible, il ne sera pas rentable pour les spammeurs de l'envoyer, et nous n'aurons pas à trop travailler pour le filtrer.

Maintenant, pour la nouvelle vraiment choquante : pendant cette même période d'un mois, j'ai reçu trois faux positifs.

D'une certaine manière, c'est un soulagement d'obtenir des 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 mauvais que je le craignais. Les faux positifs produits par des filtres statistiques s'avèrent être des courriels qui ressemblent beaucoup à du spam, et ce sont généralement ceux que vous auriez le moins envie de manquer [9].

Deux des faux positifs étaient des bulletins d'information de sociétés auprès desquelles j'ai acheté des choses. Je n'ai jamais demandé à les recevoir, donc on pourrait dire qu'ils étaient des spams, mais je les compte comme des faux positifs parce que je ne les supprimais pas comme des spams auparavant. La raison pour laquelle les filtres les ont attrapés est que les deux sociétés en janvier sont passées à des expéditeurs de courriels commerciaux au lieu d'envoyer les courriels depuis leurs propres serveurs, et les en-têtes et les corps sont devenus beaucoup plus spammeurs.

Le troisième faux positif était un mauvais. Il provenait de quelqu'un en Égypte et était écrit en majuscules. C'était un résultat direct du fait que les jetons sont sensibles à la casse ; le filtre Plan for Spam ne l'aurait pas attrapé.

Il est difficile de dire quel est le taux global de faux positifs, car nous sommes dans le bruit, statistiquement. Tous ceux qui ont travaillé sur des filtres (au moins, des filtres efficaces) seront au courant de ce problème. Avec certains courriels, c'est difficile de dire s'ils sont des spams ou non, et ce sont ceux que vous finissez par regarder lorsque vous obtenez des filtres vraiment serrés. Par exemple, jusqu'à présent, le filtre a attrapé deux courriels qui ont été envoyés à mon adresse parce que d'une faute de frappe, et un qui m'a été envoyé en pensant que j'étais quelqu'un d'autre. On pourrait dire que ce ne sont ni mes spams ni mes courriels non spams.

Un autre faux positif provenait d'un vice-président de Virtumundo. Je leur ai écrit en prétendant être un client, et comme la réponse est revenue via les serveurs de messagerie de Virtumundo, elle avait les en-têtes les plus incriminantes imaginables. On pourrait dire que ce n'est pas un vrai faux positif non plus, mais une sorte d'effet d'incertitude de Heisenberg : je ne l'ai eu que parce que j'écrivais sur le filtrage du spam.

Sans compter ceux-ci, j'ai eu un total de cinq faux positifs jusqu'à présent, sur environ 7740 courriels 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 chiffre puisse être considéré comme fiable, en partie parce que l'échantillon est si petit, et en partie parce que je pense que je peux corriger le filtre pour qu'il n'attrape pas certains de ceux-ci.

Les faux positifs me semblent être un type d'erreur différent de les faux négatifs. Le taux de filtrage est une mesure des performances. Les faux positifs, je les considère plus comme des bogues. J'aborde l'amélioration du taux de filtrage comme une optimisation, et la diminution des faux positifs comme un débogage.

Donc, ces cinq faux positifs sont ma liste de bogues. Par exemple, le courriel d'Égypte a été cloué parce que le texte en majuscules l'a fait ressembler au filtre à un spam nigérian. C'est vraiment une sorte de bogue. Comme avec le HTML, le fait que le courriel soit en majuscules est vraiment une caractéristique conceptuelle, pas une pour chaque mot. J'ai besoin de gérer la casse d'une manière plus sophistiquée.

Alors, que penser de ce 0,06 % ? Pas grand-chose, je pense. Vous pourriez le traiter comme une limite supérieure, en gardant à l'esprit la petite taille de l'échantillon. Mais à ce stade, il s'agit davantage d'une mesure des bogues dans ma mise en œuvre que d'un taux intrinsèque de faux positifs du filtrage bayésien.

Futur

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

Par exemple, les spammeurs travaillent maintenant activement pour contourner les filtres, et l'une des choses qu'ils font est de découper et de mal orthographier les mots pour empêcher les filtres de les reconnaître. Mais travailler sur cela n'est pas ma première priorité, car je n'ai toujours aucun problème à attraper ces spams [10].

Il y a deux types de spams que j'ai actuellement du mal à attraper. L'un est du type qui prétend être un courriel d'une femme vous invitant à discuter avec elle ou à voir son profil sur un site de rencontre. Ceux-ci passent parce qu'ils sont le seul type de vente que vous pouvez faire sans utiliser de discours de vente. Ils utilisent le même vocabulaire que les courriels ordinaires.

L'autre type de spams que j'ai du mal à filtrer sont ceux de sociétés en Bulgarie qui proposent des services de programmation sous contrat. Ceux-ci passent parce que je suis aussi un programmeur, et les spams sont pleins des mêmes mots que mes vrais courriels.

Je vais probablement me concentrer sur le type d'annonce personnelle en premier. Je pense que si je regarde de plus près, je serai en mesure de trouver des différences statistiques entre ceux-ci et mes vrais courriels. Le style d'écriture est certainement différent, bien qu'il puisse falloir un filtrage multi-mots pour l'attraper. De plus, je remarque qu'ils ont tendance à répéter l'URL, et quelqu'un qui inclut une URL dans un courriel légitime ne le ferait pas [11].

Le type d'externalisation va être difficile à attraper. Même si vous envoyiez un robot d'exploration sur le site, vous ne trouveriez pas d'arme à feu statistique. Peut-être que la seule réponse est une liste centrale de domaines annoncés dans les spams [12]. Mais il ne peut pas y avoir autant de ce type de courrier. 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 à travailler sur autre chose.

Le filtrage statistique nous permettra-t-il d'atteindre ce point ? Je ne sais pas. En ce moment, pour moi personnellement, le spam est un problème. Mais les spammeurs n'ont pas encore fait un effort sérieux pour usurper 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 y a un obstacle statique qui vaut la peine d'être franchi, les spammeurs sont assez efficaces pour le franchir. Il existe déjà une société appelée Assurance Systems qui fera passer votre courrier par Spamassassin et vous dira si il sera filtré.

Les filtres au niveau du réseau ne seront pas complètement inutiles. Ils peuvent suffire à tuer tous les spams "opt-in", c'est-à-dire les spams provenant de sociétés comme Virtumundo et Equalamail qui affirment qu'elles gèrent réellement des listes opt-in. Vous pouvez les filtrer en vous basant uniquement sur les en-têtes, sans tenir compte de ce qu'elles disent dans le corps. Mais toute personne disposée à falsifier les en-têtes ou à utiliser des relais ouverts, y compris la plupart des spammeurs de porno, devrait être en mesure de faire passer un message par les filtres au niveau du réseau si elle le souhaite. (Mais pas le message qu'elle aimerait envoyer, ce qui est quelque chose.)

Le type de filtres sur lesquels je suis optimiste sont ceux qui calculent les probabilités en fonction du courrier de chaque utilisateur. Ceux-ci peuvent être beaucoup plus efficaces, non seulement pour éviter les faux positifs, mais aussi pour filtrer : par exemple, trouver l'adresse électronique du destinataire codé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 appellent leur cycle d'édition-compilation-test, épouvantablement lente. Au lieu de simplement modifier un spam jusqu'à ce qu'il passe par une copie de quelque filtre qu'ils ont sur leur bureau, ils devront faire un test de mailing pour chaque modification. Ce serait comme programmer dans un langage sans niveau interactif, et je ne le souhaiterais pas à personne.

Notes

[1] Paul Graham. ``A Plan for Spam.'' August 2002. http://paulgraham.com/spam.html.

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

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

La deuxième hypothèse que j'ai faite parce que la proportion de spam dans mes courriels entrants fluctuait tellement d'un jour à l'autre (en fait, d'une heure à l'autre) que le ratio a priori global semblait sans valeur comme prédicteur. Si vous supposez que P(spam) et P(non spam) sont tous les deux égaux à 0,5, ils s'annulent et vous pouvez les supprimer de la formule.

Si vous faisiez du filtrage bayésien dans une situation où le ratio spam/non spam était constamment très élevé ou (surtout) très faible, vous pourriez probablement améliorer les performances du filtre en incorporant des probabilités a priori. Pour le faire correctement, vous devriez suivre les ratios en fonction de l'heure de la journée, car le volume de spam et de courrier légitime ont tous deux des schémas quotidiens distincts.

[2] Patrick Pantel et Dekang Lin. ``SpamCop-- A Spam Classification & Organization Program.'' Proceedings of AAAI-98 Workshop on Learning for Text Categorization.

[3] Mehran Sahami, Susan Dumais, David Heckerman et Eric Horvitz. ``A Bayesian Approach to Filtering Junk E-Mail.'' Proceedings of AAAI-98 Workshop on Learning for Text Categorization.

[4] À l'époque, j'avais zéro 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'explique 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. ``Sparse Binary Polynomial Hash Message Filtering and The CRM114 Discriminator.'' Proceedings of 2003 Spam Conference.

[6] Dans ``A Plan for Spam'', j'utilisais des seuils de 0,99 et 0,01. Il semble justifiable d'utiliser des seuils proportionnels à la taille des corpus. Comme j'ai maintenant de l'ordre de 10 000 de chaque type de courrier, j'utilise 0,9999 et 0,0001.

[7] Il y a un défaut ici que je devrais probablement corriger. Actuellement, lorsque Subject*foo'' dégénère en foo'', cela signifie que vous obtenez les statistiques pour les occurrences de foo'' dans le corps ou les lignes d'en-tête autres que celles que je marque. Ce que je devrais faire est de suivre les statistiques pour foo'' globalement ainsi que les versions spécifiques, et de dégénérer de Subject*foo'' non pas en 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 un gain de faire cela avec les prix aussi, par exemple, de dégénérer de 129,99 $'' en $--9,99'', $--.99'', et $--''.

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

[8] Steven Hauser. ``Statistical Spam Filter Works for Me.'' http://www.sofbot.com.

[9] Les faux positifs ne sont pas tous égaux, et nous devons nous en souvenir lorsque nous comparons les techniques pour arrêter le spam. Alors que la plupart des faux positifs causés par les filtres seront des quasi-spams que vous n'auriez pas envie de manquer, les faux positifs causés par les listes noires, par exemple, seront juste des courriels de personnes qui ont choisi le mauvais FAI. Dans les deux cas, vous attrapez des courriels 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 assez bons pour obscurcir les jetons pour que cela devienne un problème, nous pouvons y répondre 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 des mots de cette façon qui n'étaient pas visibles dans le texte original serait en soi une preuve de spam.

Extraire les mots ne sera pas trivial. Cela nécessitera plus que la simple reconstruction des limites des mots ; les spammeurs ajoutent (xHot nPorn cSite'') et omettent (P#rn'') des lettres. La recherche sur la vision pourrait être utile ici, car la vision humaine est la limite que ces astuces vont approcher.

[11] En général, les spams sont plus répétitifs que les courriels ordinaires. Ils veulent marteler ce message. Je n'autorise actuellement pas les doublons dans les 15 meilleurs jetons, car vous pourriez obtenir un faux positif si l'expéditeur utilise un mauvais mot 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 la duplication, donc je vais peut-être essayer d'autoriser jusqu'à deux de chaque jeton, comme Brian Burton le fait dans SpamProbe.

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

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

Historiquement, les arguments de rareté des ressources ont été le côté perdant dans les débats sur la conception des logiciels. Les gens ne les utilisent généralement que pour justifier des choix (l'inaction en particulier) faits pour d'autres raisons.

Merci à Sarah Harlin, Trevor Blackwell, et Dan Giffin pour avoir lu les brouillons de cet article, et à Dan encore pour la plupart des infrastructures sur lesquelles ce filtre fonctionne.

Connexe:

SubjectFREE 0.9999 free!! 0.9999 Tofree 0.9998 Subjectfree 0.9782 free! 0.9199 Free 0.9198 Urlfree 0.9091 FREE 0.8747 From*free 0.7636 free 0.6546

SubjectFree!!! Subjectfree!!! SubjectFREE! SubjectFree! Subjectfree! SubjectFREE SubjectFree Subjectfree FREE!!! Free!!! free!!! FREE! Free! free! FREE Free free