FILTRAGEM BAYESIANA MELHOR

Janeiro de 2003

(Este artigo foi apresentado como uma palestra na Conferência de Spam de 2003. Ele descreve o trabalho que fiz para melhorar o desempenho do algoritmo descrito em Um Plano para Spam, e o que planejo fazer no futuro.)

A primeira descoberta que gostaria de apresentar aqui é um algoritmo para avaliação preguiçosa de artigos de pesquisa. Basta escrever o que você quiser e não citar nenhum trabalho anterior, e leitores indignados lhe enviarão referências a todos os artigos que você deveria ter citado. Descobri este algoritmo depois que "Um Plano para Spam" [1] foi publicado no Slashdot.

Filtragem de spam é um subconjunto da classificação de texto, que é um campo bem estabelecido, mas os primeiros artigos sobre filtragem de spam bayesiana per se parecem ter sido dois apresentados na mesma conferência em 1998, um por Pantel e Lin [2], e outro por um grupo da Microsoft Research [3].

Quando ouvi falar deste trabalho, fiquei um pouco surpreso. Se as pessoas estavam usando a filtragem bayesiana há quatro anos, por que ninguém a estava usando? Quando li os artigos, descobri por quê. O filtro de Pantel e Lin era o mais eficaz dos dois, mas só pegava 92% do spam, com 1,16% de falsos positivos.

Quando tentei escrever um filtro de spam bayesiano, ele pegava 99,5% do spam com menos de 0,03% de falsos positivos [4]. Sempre é alarmante quando duas pessoas tentando o mesmo experimento obtêm resultados amplamente divergentes. É especialmente alarmante aqui porque esses dois conjuntos de números podem levar a conclusões opostas. Diferentes usuários têm diferentes requisitos, mas acho que para muitas pessoas, uma taxa de filtragem de 92% com 1,16% de falsos positivos significa que a filtragem não é uma solução aceitável, enquanto 99,5% com menos de 0,03% de falsos positivos significa que é.

Então, por que obtivemos números tão diferentes? Não tentei reproduzir os resultados de Pantel e Lin, mas lendo o artigo, vejo cinco coisas que provavelmente explicam a diferença.

Uma é simplesmente que eles treinaram seu filtro com muito pouco dados: 160 spams e 466 não-spams. O desempenho do filtro ainda deve estar subindo com conjuntos de dados tão pequenos. Então seus números podem nem mesmo ser uma medida precisa do desempenho do seu algoritmo, muito menos da filtragem de spam bayesiana em geral.

Mas acho que a diferença mais importante provavelmente é que eles ignoraram os cabeçalhos das mensagens. Para qualquer um que tenha trabalhado em filtros de spam, isso parecerá uma decisão perversa. E no entanto, nos primeiros filtros que tentei escrever, eu também ignorei os cabeçalhos. Por quê? Porque eu queria manter o problema limpo. Eu não sabia muito sobre cabeçalhos de e-mail na época, e eles pareciam para mim cheios de coisas aleatórias. Há uma lição aqui para os escritores de filtros: não ignore os dados. Você pensaria que essa lição seria óbvia demais para ser mencionada, mas tive que aprendê-la várias vezes.

Terceiro, Pantel e Lin reduziram os tokens, o que significa que eles reduziram, por exemplo, tanto "mailing" quanto "mailed" para a raiz "mail". Eles podem ter sentido que eram forçados a fazer isso pelo pequeno tamanho de seu corpus, mas se for o caso, é uma espécie de otimização prematura.

Quarto, eles calcularam as probabilidades de forma diferente. Eles usaram todos os tokens, enquanto eu uso apenas os 15 mais significativos. Se você usar todos os tokens você tenderá a perder os spams mais longos, o tipo em que alguém lhe conta sua história de vida até o ponto em que ficou rico com algum esquema de marketing multinível. E um algoritmo assim seria fácil para os spammers enganarem: basta adicionar um grande bloco de texto aleatório para contrabalançar os termos de spam.

Finalmente, eles não fizeram viés contra falsos positivos. Acho que qualquer algoritmo de filtragem de spam deve ter um botão conveniente que você possa girar para diminuir a taxa de falsos positivos à custa da taxa de filtragem. Eu faço isso contando as ocorrências de tokens no corpus de não-spam o dobro.

Eu não acho que seja uma boa ideia tratar o filtro de spam como um problema de classificação de texto simples. Você pode usar técnicas de classificação de texto, mas as soluções podem e devem refletir o fato de que o texto é um e-mail e, em particular, spam. O e-mail não é apenas texto; ele tem estrutura. O filtro de spam não é apenas classificação, porque os falsos positivos são muito piores do que os falsos negativos, de modo que você deve tratá-los como um tipo diferente de erro. E a fonte do erro não é apenas variação aleatória, mas um spammer humano ativo trabalhando para derrotar seu filtro.

Tokens

Outro projeto sobre o qual ouvi falar depois do artigo do Slashdot foi o CRM114 [5] de Bill Yerazunis. Este é o contraexemplo do princípio de design que acabei de mencionar. É um classificador de texto simples, mas tão eficaz que consegue filtrar o spam quase perfeitamente sem nem mesmo saber que é isso que está fazendo.

Assim que entendi como o CRM114 funcionava, parecia inevitável que eu eventualmente teria que passar da filtragem baseada em palavras únicas para uma abordagem como essa. Mas primeiro, pensei, verei o quão longe posso chegar com palavras únicas. E a resposta é, surpreendentemente longe.

Tenho trabalhado principalmente em uma tokenização mais inteligente. No spam atual, tenho conseguido taxas de filtragem que se aproximam das do CRM114. Essas técnicas são em grande parte ortogonais às de Bill; uma solução ideal pode incorporar ambas.

``Um Plano para o Spam'' usa uma definição muito simples de um token. Letras, dígitos, hifens, apóstrofos e cifrões são caracteres constituintes, e tudo o mais é um separador de tokens. Também ignorei o caso.

Agora tenho uma definição mais complicada de um token:

O caso é preservado.

Pontos de exclamação são caracteres constituintes.

Pontos e vírgulas são constituintes se ocorrerem entre dois dígitos. Isso me permite obter endereços IP e preços intactos.

Um intervalo de preços como $20-25 gera dois tokens, $20 e $25.

Os tokens que ocorrem nas linhas Para, De, Assunto e Caminho de Retorno, ou dentro de URLs, são marcados de acordo. Por exemplo, "foo" na linha Assunto se torna "Assunto*foo". (O asterisco poderia ser qualquer caractere que você não permita como constituinte.)

Tais medidas aumentam o vocabulário do filtro, o que o torna mais discriminatório. Por exemplo, no filtro atual, "free" na linha Assunto tem uma probabilidade de spam de 98%, enquanto o mesmo token no corpo tem uma probabilidade de spam de apenas 65%.

Aqui estão algumas das probabilidades atuais [6]:

AssuntoGRÁTIS 0,9999 free!! 0,9999 Paragrátis 0,9998 Assuntográtis 0,9782 free! 0,9199 Grátis 0,9198 Urlgrátis 0,9091 GRÁTIS 0,8747 De*grátis 0,7636 grátis 0,6546

No filtro Um Plano para o Spam, todos esses tokens teriam tido a mesma probabilidade, .7602. Esse filtro reconheceu cerca de 23.000 tokens. O atual reconhece cerca de 187.000.

A desvantagem de ter um universo maior de tokens é que há mais chance de perdas. Espalhar seu corpus por mais tokens tem o mesmo efeito que torná-lo menor. Se você considerar os pontos de exclamação como constituintes, por exemplo, pode acabar não tendo uma probabilidade de spam para "grátis" com sete pontos de exclamação, mesmo sabendo que "grátis" com apenas dois pontos de exclamação tem uma probabilidade de 99,99%.

Uma solução para isso é o que eu chamo de degeneração. Se você não conseguir encontrar uma correspondência exata para um token, trate-o como se fosse uma versão menos específica. Considero que os pontos de exclamação terminais, as letras maiúsculas e a ocorrência em um dos cinco contextos marcados tornam um token mais específico. Por exemplo, se eu não encontrar uma probabilidade para "Assuntográtis!", procuro probabilidades para "Assuntográtis", "grátis!" e "grátis", e escolho a que estiver mais distante de .5.

Aqui estão as alternativas [7] consideradas se o filtro vir "GRÁTIS!!!" na linha Assunto e não tiver uma probabilidade para ela.

AssuntoGrátis!!! Assuntográtis!!! AssuntoGRÁTIS! AssuntoGrátis! Assuntográtis! AssuntoGRÁTIS AssuntoGrátis Assuntográtis GRÁTIS!!! Grátis!!! grátis!!! GRÁTIS! Grátis! grátis! GRÁTIS Grátis grátis

Se você fizer isso, certifique-se de considerar versões com letras iniciais maiúsculas, bem como todas em maiúsculas e todas em minúsculas. Os spams tendem a ter mais frases no modo imperativo, e nessas o primeiro palavra é um verbo. Portanto, os verbos com letras iniciais maiúsculas têm probabilidades de spam mais altas do que teriam em minúsculas. No meu filtro, a probabilidade de spam de "Aja" é de 98% e de "aja" apenas 62%.

Se você aumentar o vocabulário do seu filtro, pode acabar contando a mesma palavra várias vezes, de acordo com sua antiga definição de "mesma". Logicamente, elas não são mais o mesmo token. Mas se isso ainda te incomodar, deixe-me adicionar da minha experiência que as palavras que você parece estar contando várias vezes tendem a ser exatamente aquelas que você gostaria.

Outro efeito de um vocabulário maior é que, quando você olha para um e-mail recebido, você encontra mais tokens interessantes, ou seja, aqueles com probabilidades distantes de .5. Eu uso os 15 mais interessantes para decidir se o e-mail é spam. Mas você pode se deparar com um problema quando usa um número fixo como este. Se você encontrar muitos tokens maximamente interessantes, o resultado pode acabar sendo decidido por qualquer fator aleatório que determine a ordem de tokens igualmente interessantes. Uma maneira de lidar com isso é tratar alguns como mais interessantes do que outros.

Por exemplo, o token "dalco" ocorre 3 vezes no meu corpus de spam e nunca no meu corpus legítimo. O token "Url*optmails" (significando "optmails" dentro de uma url) ocorre 1223 vezes. E, no entanto, como eu costumava calcular as probabilidades para os tokens, ambos teriam a mesma probabilidade de spam, o limite de .99.

Isso não parece certo. Há argumentos teóricos para dar a esses dois tokens probabilidades substancialmente diferentes (Pantel e Lin fazem isso), mas eu ainda não tentei isso. Pelo menos parece que, se encontrarmos mais de 15 tokens que ocorrem apenas em um corpus ou no outro, deveríamos dar prioridade aos que ocorrem mais. Então, agora há dois valores de limite. Para tokens que ocorrem apenas no corpus de spam, a probabilidade é .9999 se eles ocorrerem mais de 10 vezes e .9998 caso contrário. O mesmo vale para o outro extremo da escala, para tokens encontrados apenas no corpus legítimo.

Eu posso escalar substancialmente as probabilidades dos tokens mais tarde, mas essa pequena quantidade de escalonamento pelo menos garante que os tokens sejam classificados da maneira certa.

Outra possibilidade seria considerar não apenas 15 tokens, mas todos os tokens acima de um certo limite de interesse. Steven Hauser faz isso em seu filtro de spam estatístico [8]. Se você usar um limite, torne-o muito alto, caso contrário, os spammers poderiam enganá-lo empacotando mensagens com mais palavras inocentes.

Finalmente, o que se deve fazer sobre o HTML? Eu tentei todo o espectro de opções, desde ignorá-lo até analisá-lo completamente. Ignorar o HTML é uma má ideia, porque ele está cheio de sinais de spam úteis. Mas se você analisar tudo, seu filtro pode se degenerar em mero reconhecedor de HTML. A abordagem mais eficaz parece ser o meio-termo, notar alguns tokens, mas não outros. Eu olho para as tags a, img e font, e ignoro o resto. Links e imagens você certamente deve observar, pois contêm URLs.

Eu provavelmente poderia ser mais inteligente ao lidar com o HTML, mas não acho que valha a pena dedicar muito tempo a isso. Spams cheios de HTML são fáceis de filtrar. Os spammers mais espertos já os evitam. Então o desempenho no futuro não deve depender muito de como você lida com o HTML.

Desempenho

Entre 10 de dezembro de 2002 e 10 de janeiro de 2003, recebi cerca de 1750 spams. Desses, 4 passaram. Isso é uma taxa de filtragem de aproximadamente 99,75%.

Dois dos quatro spams que eu perdi passaram porque acabaram usando palavras que ocorrem com frequência no meu e-mail legítimo.

O terceiro foi um daqueles que exploram um script cgi inseguro para enviar e-mail a terceiros. Eles são difíceis de filtrar apenas com base no conteúdo porque os cabeçalhos são inocentes e eles têm cuidado com as palavras que usam. Mesmo assim, eu posso geralmente pegá-los. Este passou por uma probabilidade de .88, apenas abaixo do limite de .9.

Claro, olhar para múltiplas sequências de tokens o pegaria facilmente. "Abaixo está o resultado do seu formulário de feedback" é uma dica instantânea.

O quarto spam era o que eu chamo de spam do futuro, porque é isso que eu espero que o spam evolua para: algum texto completamente neutro seguido por uma URL. Neste caso, era de alguém dizendo que finalmente havia terminado sua página inicial e se eu fosse dar uma olhada. (A página, é claro, era um anúncio de um site pornográfico.)

Se os spammers tiverem cuidado com os cabeçalhos e usarem uma URL nova, não há nada no spam do futuro para os filtros notarem. Podemos, é claro, contra-atacar enviando um crawler para olhar a página. Mas isso pode não ser necessário. A taxa de resposta para o spam do futuro deve ser baixa, caso contrário, todo mundo estaria fazendo isso. Se for baixo o suficiente, não compensará para os spammers enviá-lo, e não teremos que trabalhar muito para filtrá-lo.

Agora, para a notícia realmente chocante: durante esse mesmo período de um mês eu tive três falsos positivos.

De certa forma, é um alívio ter alguns falsos positivos. Quando escrevi "Um Plano para o Spam", eu não tinha tido nenhum, e não sabia como eles seriam. Agora que tive alguns, estou aliviado em descobrir que não são tão ruins quanto eu temia. Os falsos positivos gerados por filtros estatísticos acabam sendo e-mails que soam muito como spam, e esses tendem a ser aqueles que você menos se importaria de perder [9].

Dois dos falsos positivos eram boletins informativos de empresas das quais eu comprei coisas. Eu nunca pedi para recebê-los, então, tecnicamente, eles eram spams, mas eu os conto como falsos positivos porque eu não os estava excluindo como spams antes. O motivo de os filtros os terem pego foi que ambas as empresas em janeiro mudaram para remetentes de e-mail comerciais em vez de enviar os e-mails de seus próprios servidores, e tanto os cabeçalhos quanto os corpos ficaram muito mais parecidos com spam.

O terceiro falso positivo foi um problema, no entanto. Era de alguém no Egito e escrito todo em maiúsculas. Isso foi um resultado direto de tornar os tokens sensíveis a maiúsculas e minúsculas; o filtro do Plano para o Spam não o teria pego.

É difícil dizer qual é a taxa geral de falsos positivos, porque estamos no ruído, estatisticamente. Qualquer pessoa que tenha trabalhado com filtros (pelo menos, filtros eficazes) estará ciente desse problema. Com alguns e-mails, é difícil dizer se eles são spam ou não, e esses são os que você acaba olhando quando deixa os filtros realmente apertados. Por exemplo, até agora o filtro pegou dois e-mails que foram enviados para o meu endereço por causa de um erro de digitação, e um enviado para mim na crença de que eu era outra pessoa. Tecnicamente, esses não são nem meu spam nem meu não-spam.

Outro falso positivo foi de um vice-presidente da Virtumundo. Eu escrevi para eles fingindo ser um cliente, e como a resposta voltou pelos servidores de e-mail da Virtumundo, tinha os cabeçalhos mais incriminadores possíveis. Tecnicamente, este também não é um falso positivo real, mas uma espécie de efeito de incerteza de Heisenberg: eu só o obtive porque estava escrevendo sobre filtragem de spam.

Sem contar esses, tive um total de cinco falsos positivos até agora, de cerca de 7740 e-mails legítimos, uma taxa de .06%. Os outros dois foram um aviso de que algo que eu comprei estava em atraso, e um lembrete de festa do Evite.

Não acho que esse número possa ser confiável, em parte porque a amostra é tão pequena, e em parte porque acho que posso consertar o filtro para não pegar alguns desses.

Falsos positivos me parecem um tipo diferente de erro de falsos negativos. A taxa de filtragem é uma medida de desempenho. Falsos positivos eu considero mais como bugs. Eu abordo a melhoria da taxa de filtragem como otimização, e a diminuição de falsos positivos como depuração.

Então esses cinco falsos positivos são a minha lista de bugs. Por exemplo, o e-mail do Egito foi atingido porque o texto em maiúsculas o fez parecer para o filtro como um spam nigeriano. Isso realmente é uma espécie de bug. Assim como no HTML, o e-mail estar todo em maiúsculas é realmente conceitualmente um recurso, não um para cada palavra. Eu preciso lidar com o caso de uma maneira mais sofisticada.

Então, o que fazer com esse 0,06%? Não muito, eu acho. Você poderia tratá-lo como um limite superior, levando em conta o pequeno tamanho da amostra. Mas neste estágio, é mais uma medida dos bugs na minha implementação do que uma taxa intrínseca de falsos positivos da filtragem bayesiana.

Futuro

E agora? A filtragem é um problema de otimização, e a chave para a otimização é o perfil. Não tente adivinhar onde seu código é lento, porque você vai adivinhar errado. Olhe onde seu código é lento e conserte isso. Na filtragem, isso se traduz em: olhe para os spams que você perde e descubra o que você poderia ter feito para pegá-los.

Por exemplo, os spammers agora estão trabalhando agressivamente para evitar filtros, e uma das coisas que eles estão fazendo é quebrar e soletrar mal as palavras para evitar que os filtros as reconheçam. Mas trabalhar nisso não é a minha primeira prioridade, porque ainda não tenho dificuldade em pegar esses spams [10].

Existem dois tipos de spams com os quais atualmente tenho dificuldade. Um é o tipo que finge ser um e-mail de uma mulher convidando você para conversar com ela ou ver seu perfil em um site de namoro. Esses passam porque são o único tipo de oferta de vendas que você pode fazer sem usar linguagem de vendas. Eles usam o mesmo vocabulário que o e-mail comum.

O outro tipo de spams que tenho dificuldade em filtrar são aqueles de empresas, por exemplo, na Bulgária, oferecendo serviços de programação por contrato. Esses passam porque eu também sou programador, e os spams estão cheios das mesmas palavras que meu correio real.

Provavelmente vou me concentrar primeiro no tipo de anúncio pessoal. Acho que se eu olhar mais de perto, serei capaz de encontrar diferenças estatísticas entre esses e meu correio real. O estilo de escrita certamente é diferente, embora possa levar a filtragem de várias palavras para pegar isso. Além disso, eu percebo que eles tendem a repetir a URL, e alguém que inclui uma URL em um e-mail legítimo não faria isso [11].

Os tipos de terceirização serão difíceis de pegar. Mesmo que você enviasse um rastreador para o site, você não encontraria uma arma estatística fumegante. Talvez a única resposta seja uma lista central de domínios anunciados em spams [12]. Mas não pode haver tantos desse tipo de e-mail. Se os únicos spams restantes fossem ofertas não solicitadas de serviços de programação por contrato da Bulgária, provavelmente todos poderíamos passar a trabalhar em outra coisa.

A filtragem estatística realmente nos levará a esse ponto? Eu não sei. No momento, para mim pessoalmente, o spam não é um problema. Mas os spammers ainda não fizeram um esforço sério para falsificar filtros estatísticos. O que acontecerá quando eles fizerem?

Não sou otimista sobre filtros que funcionam no nível da rede [13]. Quando há um obstáculo estático que vale a pena ultrapassar, os spammers são bastante eficientes em ultrapassá-lo. Já existe uma empresa chamada Assurance Systems que executará seu e-mail através do Spamassassin e lhe dirá se ele será filtrado.

Os filtros de nível de rede não serão completamente inúteis. Eles podem ser suficientes para matar todo o spam "opt-in", ou seja, spam de empresas como a Virtumundo e a Equalamail que alegam estar realmente executando listas opt-in. Você pode filtrá-los com base apenas nos cabeçalhos, não importa o que eles digam no corpo. Mas qualquer um disposto a falsificar cabeçalhos ou usar relays abertos, presumivelmente incluindo a maioria dos spammers de pornografia, deve ser capaz de passar alguma mensagem pelos filtros de nível de rede, se quiser. (De forma alguma a mensagem que eles gostariam de enviar, o que é algo.)

O tipo de filtros em que tenho otimismo são aqueles que calculam probabilidades com base no correio de cada usuário individual. Esses podem ser muito mais eficazes, não apenas em evitar falsos positivos, mas também em filtrar: por exemplo, encontrar o endereço de e-mail do destinatário codificado em base-64 em qualquer lugar em uma mensagem é um ótimo indicador de spam.

[1]

Mas a verdadeira vantagem de filtros individuais é que eles serão todos diferentes. Se os filtros de todos tiverem probabilidades diferentes, isso tornará o loop de otimização dos spammers, o que os programadores chamariam de seu ciclo de edição-compilação-teste, terrivelmente lento. Em vez de apenas ajustar um spam até que ele passe por uma cópia de algum filtro que eles tenham em sua área de trabalho, eles terão que fazer um teste de envio para cada ajuste. Seria como programar em uma linguagem sem um nível superior interativo, e eu não desejaria isso a ninguém.

Notas

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

As probabilidades neste algoritmo são calculadas usando um caso degenerado da Regra de Bayes. Há duas suposições simplificadoras: que as probabilidades de recursos (ou seja, palavras) são independentes e que não sabemos nada sobre a probabilidade a priori de um e-mail ser spam.

A primeira suposição é generalizada na classificação de texto. Algoritmos que a usam são chamados de ``Bayesiano ingênuo.''

A segunda suposição que fiz porque a proporção de spam em meu e-mail de entrada flutuava tanto de um dia para outro (de fato, de hora em hora) que a proporção a priori geral parecia inútil como preditor. Se você assumir que P(spam) e P(não spam) são ambos .5, eles se cancelam e você pode removê-los da fórmula.

Se você estivesse fazendo filtragem Bayesiana em uma situação em que a razão de spam para não spam fosse consistentemente muito alta ou (especialmente) muito baixa, você provavelmente poderia melhorar o desempenho do filtro incorporando probabilidades a priori. Para fazer isso corretamente, você teria que rastrear as proporções por hora do dia, porque o volume de spam e de e-mails legítimos têm padrões diários distintos.

[2] Patrick Pantel e 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 e Eric Horvitz. ``A Bayesian Approach to Filtering Junk E-Mail.'' Proceedings of AAAI-98 Workshop on Learning for Text Categorization.

[4] Na época, eu tinha zero falsos positivos em cerca de 4.000 e-mails legítimos. Se o próximo e-mail legítimo fosse um falso positivo, isso nos daria 0,03%. Essas taxas de falsos positivos são pouco confiáveis, como eu explico mais tarde. Eu cito um número aqui apenas para enfatizar que, seja qual for a taxa de falsos positivos, ela é inferior a 1,16%.

[5] Bill Yerazunis. ``Sparse Binary Polynomial Hash Message Filtering and The CRM114 Discriminator.'' Proceedings of 2003 Spam Conference.

[6] Em ``A Plan for Spam'', usei limiares de 0,99 e 0,01. Parece justificável usar limiares proporcionais ao tamanho dos corpora. Como agora tenho cerca de 10.000 de cada tipo de e-mail, uso 0,9999 e 0,0001.

[7] Há uma falha aqui que provavelmente deveria consertar. Atualmente, quando Subject*foo'' degenera apenas para foo'', o que isso significa é você está obtendo as estatísticas de ocorrências de foo'' em o corpo ou linhas de cabeçalho, exceto aquelas que eu marco. O que eu deveria fazer é manter estatísticas para foo'' geral, bem como versões específicas, e degenerar de Subject*foo'' não para foo'', mas para ``Anywhere*foo''. O mesmo vale para case: eu deveria degenerar de maiúsculas para qualquer caso, não minúsculas.

Provavelmente seria uma vitória fazer isso com preços também, por exemplo, degenerar de $129,99'' para $--9,99'', $--.99'', e $--''.

Você também poderia degenerar de palavras para seus radicais, mas isso provavelmente só melhoraria as taxas de filtragem no início quando você tinha pequenos corpora.

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

[9] Falsos positivos não são todos iguais, e devemos lembrar isso ao comparar técnicas para interromper o spam. Enquanto muitos dos falsos positivos causados por filtros serão quase-spams que você não se importaria de perder, falsos positivos causados por listas negras, por exemplo, serão apenas e-mails de pessoas que escolheram o provedor de internet errado. Em ambos os casos você pega e-mails que estão próximos do spam, mas para as listas negras a proximidade é física, e para os filtros é textual.

[10] Se os spammers ficarem bons o suficiente em obscurecer tokens para isso se tornar um problema, podemos responder simplesmente removendo espaços em branco, pontos, vírgulas, etc. e usando um dicionário para escolher as palavras da sequência resultante. E, claro, encontrar palavras dessa maneira que não eram visíveis no texto original seria, em si, uma evidência de spam.

Escolher as palavras não será trivial. Exigirá mais do que apenas reconstruir os limites das palavras; os spammers tanto adicionam (xHot nPorn cSite'') quanto omitem (P#rn'') letras. A pesquisa sobre visão pode ser útil aqui, já que a visão humana é o limite que tais truques se aproximarão.

[11] Em geral, os spams são mais repetitivos do que o e-mail regular. Eles querem martelar essa mensagem. Atualmente, não permito duplicatas entre os 15 principais tokens, porque você poderia obter um falso positivo se o remetente por acaso usar alguma palavra ruim várias vezes. (No meu filtro atual, ``dick'' tem uma probabilidade de spam de .9999, mas também é um nome.) Parece que pelo menos deveríamos notar a duplicação, então posso tentar permitir até dois de cada token, como Brian Burton faz no SpamProbe.

[12] É isso que abordagens como a da Brightmail se degenerarão assim que os spammers forem empurrados para usar técnicas de "mad-lib" para gerar todo o resto da mensagem.

[13] Às vezes, argumenta-se que deveríamos estar trabalhando na filtragem no nível da rede, porque é mais eficiente. O que as pessoas geralmente querem dizer quando dizem isso é: atualmente filtramos no nível da rede e não queremos recomeçar do zero. Mas você não pode ditar o problema para se ajustar à sua solução.

Historicamente, os argumentos de recursos escassos têm sido o lado perdedor em debates sobre design de software. As pessoas só tendem a usá-los para justificar escolhas (inação em particular) feitas por outras razões.

Agradecimentos a Sarah Harlin, Trevor Blackwell e Dan Giffin por lerem rascunhos deste artigo e a Dan novamente pela maior parte da infraestrutura em que este filtro é executado.

Relacionado:

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