MELHOR FILTRAGEM BAYESIANA

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 pretendo 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 quiser e não citar nenhum trabalho anterior, e leitores indignados enviarão referências a todos os artigos que você deveria ter citado. Descobri este algoritmo depois que ``Um Plano para Spam'' [1] estava no Slashdot.

A filtragem de spam é um subconjunto da classificação de texto, que é um campo bem estabelecido, mas os primeiros artigos sobre filtragem de spam bayesiana em si 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 desse trabalho, fiquei um pouco surpreso. Se as pessoas estivessem usando a filtragem bayesiana há quatro anos, por que todos não estavam usando? Quando li os artigos, descobri porquê. O filtro de Pantel e Lin foi o mais eficaz dos dois, mas apenas pegou 92% do spam, com 1,16% de falsos positivos.

Quando tentei escrever um filtro de spam bayesiano, ele pegou 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 gerar conclusões opostas. Usuários diferentes têm requisitos diferentes, 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 e-mails não spams. O desempenho do filtro ainda deve estar subindo com dados conjuntos tão pequenos. Então seus números podem nem ser uma medida precisa do desempenho de seu algoritmo, muito menos de 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 pessoa que tenha trabalhado em filtros de spam, isso parecerá uma decisão perversa. E ainda nos primeiros filtros que tentei escrever, ignorei o cabeçalhos também. Por quê? Porque eu queria manter o problema limpo. Eu não sabia muito sobre cabeçalhos de e-mail na época, e eles me pareciam cheios de coisas aleatórias. Há uma lição aqui para o filtro escritores: não ignore dados. Você pensaria que essa lição seria óbvia demais para mencionar, mas tive que aprendê-la várias vezes.

Terceiro, Pantel e Lin eliminaram os tokens, ou seja, reduziram, por exemplo, ambos mailing'' e mailed'' para a raiz ``mail''. Eles podem ter sentido que foram forçados a fazer isso pelo pequeno tamanho de seu corpus, mas se for esse o caso, isso é uma espécie de otimização prematura.

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

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

Não acho que seja uma boa ideia tratar a filtragem de spam como um problema de classificação de texto direto. Você pode usar técnicas de classificação de texto, mas as soluções podem e devem refletir o fato de que o texto é e-mail, e spam em particular. O e-mail não é apenas texto; ele tem estrutura. A filtragem de spam não é apenas classificação, porque falsos positivos são muito piores do que falsos negativos 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 vivo trabalhando ativamente para derrotar seu filtro.

Tokens

Outro projeto do qual ouvi falar após o artigo do Slashdot foi o de Bill Yerazunis' CRM114 [5]. Este é o contra-exemplo ao princípio de design que eu acabo de mencionar. É um classificador de texto direto, mas um tão incrivelmente eficaz que consegue filtrar spam quase perfeitamente sem nem saber que é isso o que está fazendo.

Assim que entendi como o CRM114 funcionava, pareceu inevitável que eu eventualmente teria que passar da filtragem com base em palavras únicas para uma abordagem como esta. Mas primeiro, pensei, vou ver o quanto posso chegar com palavras únicas. E a resposta é, surpreendentemente longe.

Principalmente tenho trabalhado em uma tokenização mais inteligente. Em spam atual, consegui atingir taxas de filtragem que se aproximam do CRM114. Essas técnicas são principalmente ortogonais às de Bill; uma solução ideal pode incorporar ambas.

``Um Plano para Spam'' usa um muito simples definição de um token. Letras, dígitos, hífens, apóstrofos, e sinais de dólar são caracteres constituintes, e tudo o resto é 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.

Uma faixa de preço como $20-25 gera dois tokens, $20 e $25.

Tokens que ocorrem dentro do To, From, Subject e Return-Path linhas, ou dentro de urls, são marcados de acordo. Por exemplo, foo'' na linha Assunto torna-se Subject*foo''. (O asterisco pode ser qualquer caractere que você não permita como constituinte.)

Essas medidas aumentam o vocabulário do filtro, o que o torna mais discriminatório. Por exemplo, no atual filtro, ``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]:

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

No filtro Plano para Spam, todos esses tokens teriam 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 erros. Espalhar seu corpus por mais tokens tem o mesmo efeito que torná-lo menor. Se você considerar pontos de exclamação como constituintes, por exemplo, então você pode acabar não tendo uma probabilidade de spam para free com sete pontos de exclamação , embora você saiba que free 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 pontos de exclamação terminais , letras maiúsculas e ocorrendo em um dos cinco contextos marcados como tornando um token mais específico. Por exemplo, se eu não encontrar uma probabilidade para Subject*free!'', procuro probabilidades para Subject*free'', free!'', e free'', e pego aquele que está mais distante de .5.

Aqui estão as alternativas [7] consideradas se o filtro vir ``FREE!!!'' no linha Assunto e não tem uma probabilidade para ela.

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

Se você fizer isso, certifique-se de considerar versões com inicial maiúsculas, bem como todas as maiúsculas e todas as minúsculas. Spams tendem a ter mais frases no modo imperativo, e em aqueles a primeira palavra é um verbo. Então verbos com inicial maiúscula têm probabilidades de spam mais altas do que teriam em todas minúsculas. No meu filtro, a probabilidade de spam de Act'' é 98% e para act'' apenas 62%.

Se você aumentar o vocabulário do seu filtro, poderá acabar contando a mesma palavra várias vezes, de acordo com sua antiga definição de ``mesmo''. Logicamente, eles não são o mesmo token mais. Mas se isso ainda te incomoda, deixe eu acrescentar por experiência que as palavras que você parece estar contando várias vezes tendem a ser exatamente aquelas que você gostaria de.

Outro efeito de um vocabulário maior é que quando você olhe para um e-mail recebido, você encontra mais tokens interessantes , ou seja, aqueles com probabilidades distantes de .5. Eu uso o 15 mais interessantes para decidir se o e-mail é spam. Mas você pode ter 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 determina 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 ainda, como eu costumava calcular probabilidades para tokens , ambos teriam a mesma probabilidade de spam, o limite de .99.

Isso não parece certo. Existem teóricos argumentos para dar a esses dois tokens probabilidades substancialmente diferentes (Pantel e Lin fazem), mas ainda não tentei isso. Parece pelo menos que se encontrarmos mais de 15 tokens que só ocorrem em um corpus ou no outro, devemos dar prioridade aos que ocorrem muito. Então agora existem dois valores de limite. Para tokens que ocorrem apenas no corpus de spam, a probabilidade é .9999 se eles ocorrem mais de 10 vezes e .9998 caso contrário. Idem na outra ponta da escala para tokens encontrados apenas no corpus legítimo.

Posso escalar as probabilidades dos tokens substancialmente mais tarde , mas essa pequena quantidade de escala pelo menos garante que os tokens sejam classificados da maneira correta.

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, faça-o muito alto, ou os spammers podem enganá-lo embalando mensagens com mais palavras inocentes.

Finalmente, o que se deve fazer sobre html? Tentei todo o espectro de opções, desde ignorá-lo até analisá-lo completamente. Ignorar html é uma má ideia , porque está cheio de sinais úteis de spam. Mas se você analisar tudo, seu filtro pode degenerar em um mero html reconhecedor. 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 que você certamente deve olhar, porque eles contêm urls.

Provavelmente poderia ser mais inteligente em lidar com html, mas eu não acho que vale a pena gastar muito tempo nisso. Spams cheios de html são fáceis de filtrar. O mais inteligente spammers já evitam isso. Então o desempenho no futuro não deve depender muito de como você lida com html.

Desempenho

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

Dois dos quatro spams que perdi passaram porque eles aconteceram de usar palavras que ocorrem frequentemente no meu legítimo e-mail.

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

Claro, olhando para várias sequências de tokens capturaria facilmente. ``Abaixo está o resultado de seu formulário de feedback'' é uma traição instantânea.

O quarto spam foi o que eu chamo de spam-do-futuro, porque é nisso que espero que o spam evolua: algum completamente neutro texto seguido por uma url. Neste caso, foi de alguém dizendo que finalmente havia terminado sua página inicial e eu iria dar uma olhada. (A página era, é claro, um anúncio para um site pornô.)

Se os spammers forem cuidadosos com os cabeçalhos e usarem um url novo, não há nada no spam-do-futuro para os filtros notarem. Podemos, é claro, combater enviando um rastreador para olhar a página. Mas isso pode não ser necessário. A taxa de resposta para spam-do-futuro deve ser baixo, ou todos estariam fazendo isso. Se for baixo o suficiente, ele não vai pagar para os spammers enviarem, e nós não teremos que trabalhar muito duro para filtrá-lo.

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

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

Dois dos falsos positivos foram boletins informativos de empresas das quais comprei coisas. Eu nunca pedi para recebê-los, então, discutível, eles eram spams, mas eu os conto como falsos positivos porque eu não tinha estado a apagá-los como spams antes. A razão os filtros os pegaram 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 se tornaram muito mais spam.

O terceiro falso positivo foi um ruim, no entanto. Foi de alguém no Egito e escrito em maiúsculas. Isso foi um resultado direto de tornar os tokens sensíveis ao caso; o Plano para o filtro de spam não teria pegado.

É 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 estes são aqueles que você acaba olhando quando obtém filtros realmente apertados. Por exemplo, até agora o filtro tem pegou dois e-mails que foram enviados para meu endereço porque de um erro de digitação, e um enviado para mim na crença de que eu era alguém mais. Discutível, estes não são nem meu spam nem meu e-mail não spam.

Outro falso positivo foi de um vice-presidente da Virtumundo. Escrevi para eles fingindo ser um cliente, e como a resposta voltou através dos servidores de e-mail da Virtumundo , ela tinha os cabeçalhos mais incriminadores imagináveis. Discutível, isso não é um verdadeiro falso positivo também, mas uma espécie de efeito de incerteza de Heisenberg : só consegui 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 0,06%. Os outros dois foram um aviso de que algo que comprei estava em falta, e um lembrete de festa do Evite.

Não acho que esse número possa ser confiável, em parte porque a amostra é muito 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. Falso positivos que considero mais como bugs. Abordo a melhoria do taxa de filtragem como otimização e diminuição de falsos positivos como depuração.

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

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

Futuro

O que vem a seguir? 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 para onde seu código é lento , e corrija 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 é quebrando e errando palavras para evitar que os filtros os reconheçam. Mas trabalhar nisso não é minha primeira prioridade, porque ainda não tenho problemas para pegar esses spams [10].

Existem dois tipos de spams que atualmente tenho problemas. Um é o tipo que se passa por um e-mail de uma mulher convidando você a conversar com ela ou ver seu perfil em um site de namoro . Esses passam porque são o único tipo de apresentação 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 problemas para filtrar são aqueles de empresas na Bulgária, por exemplo, oferecendo serviços de programação de contratos . Esses passam porque também sou programador, e os spams estão cheios das mesmas palavras que meu e-mail real.

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

O tipo de terceirização vai ser difícil de pegar. Mesmo que você enviasse um rastreador para o site, você não encontraria um fumante arma estatística. 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 o único spams restantes fossem ofertas não solicitadas de serviços de programação de contratos da Bulgária, todos nós provavelmente poderíamos passar para trabalhar em outra coisa.

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

Não estou otimista com os filtros que funcionam no nível de rede [13]. Quando há um obstáculo estático que vale a pena superar, os spammers são bastante eficientes em superá-lo. Há já uma empresa chamada Assurance Systems que irá executar seu e-mail através do Spamassassin e dizer a você 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 "opt-in" spam, ou seja, spam de empresas como Virtumundo e Equalamail que afirmam que realmente estão executando listas de opt-in. Você pode filtrar esses com base apenas nos cabeçalhos, sem importar o que eles dizem no corpo. Mas qualquer pessoa disposta 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 quiserem. (De forma alguma o mensagem que eles gostariam de enviar, no entanto, o que é algo.)

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

Mas a verdadeira vantagem dos filtros individuais é que todos serão diferentes. Se os filtros de todos tiverem probabilidades diferentes , isso tornará o loop de otimização dos spammers, o que os programadores chamariam de 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 têm 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 toplevel interativo , e eu não desejaria isso a ninguém.

Notas

[1] Paul Graham. ``Um Plano para Spam.'' Agosto de 2002. http://paulgraham.com/spam.html.

As probabilidades neste algoritmo são calculadas usando um caso degenerado da Regra de Bayes. Existem duas suposições simplificadoras: que as probabilidades de recursos (ou seja, palavras) são independentes e que 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 o usam são chamados de ``ingênuos bayesianos.''

A segunda suposição que fiz porque a proporção de spam em meu e-mail recebido flutuava tanto de dia para dia (na verdade, de hora em hora) que a proporção a priori geral parecia sem valor como um 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 proporção de spam para não spam era consistentemente muito alta ou (especialmente) muito baixa, você provavelmente poderia melhorar o filtro desempenho incorporando probabilidades a priori. Para fazer isso direito, você teria que rastrear as proporções por hora do dia, porque o volume de spam e de e-mail legítimo tem padrões diários distintos.

[2] Patrick Pantel e Dekang Lin. ``SpamCop-- Um Programa de Classificação e Organização de Spam.'' Anais do AAAI-98 Workshop sobre Aprendizagem para Categorização de Texto.

[3] Mehran Sahami, Susan Dumais, David Heckerman e Eric Horvitz. ``Uma Abordagem Bayesiana para Filtrar E-mail Lixo.'' Anais do AAAI-98 Workshop sobre Aprendizagem para Categorização de Texto.

[4] Na época, eu tinha zero falsos positivos de 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 não são confiáveis, como explico mais tarde. Cito um número aqui apenas para enfatizar que, seja qual for a taxa de falsos positivos , é inferior a 1,16%.

[5] Bill Yerazunis. ``Filtragem de Mensagens Hash Polinomial Binário Esparso e o Discriminador CRM114.'' Anais da Conferência de Spam de 2003.

[6] Em ``Um Plano para Spam'' usei limites de .99 e .01. Parece justificável usar limites proporcionais ao tamanho dos corpora. Como agora tenho na ordem de 10.000 de cada tipo de e-mail, uso .9999 e .0001.

[7] Há uma falha aqui que provavelmente devo corrigir. Atualmente, quando Subject*foo'' degenera para apenas foo'', o que isso significa é que você está obtendo as estatísticas para ocorrências de foo'' em o corpo ou linhas de cabeçalho diferentes daquelas que marco. O que devo fazer é manter o controle das estatísticas para foo'' no geral, bem como versões específicas, e degenerar de Subject*foo'' não para foo'', mas para ``Anywhere*foo''. Idem para caso: devo 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 pode degenerar de palavras para seus radicais , mas isso provavelmente só melhoraria as taxas de filtragem no início quando você tinha corpora pequenos.

[8] Steven Hauser. ``Filtro de Spam Estatístico Funciona para Mim.'' http://www.sofbot.com.

[9] Falsos positivos não são todos iguais, e devemos lembrar isso ao comparar técnicas para parar 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-mail de pessoas que escolheram o ISP errado. Em ambos os casos, você pega e-mail que está perto do spam, mas para listas negras, a proximidade é física, e para filtros, é textual.

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

Extrair as palavras não será trivial. Vai exigir mais do que apenas reconstruir os limites das palavras; spammers tanto adicionam (xHot nPorn cSite'') quanto omitem (P#rn'') letras. A pesquisa de 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 bater naquela mensagem. Atualmente, não permito duplicatas nos 15 principais tokens, porque você pode obter um falso positivo se o remetente acontecer de 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 devemos pelo menos notar a duplicação, então posso tentar permitir até dois de cada token, como Brian Burton faz em SpamProbe.

[12] É nisso que abordagens como a do Brightmail vão degenerar assim que os spammers forem forçados a usar técnicas de mad-lib para gerar tudo mais na mensagem.

[13] Às vezes, argumenta-se que devemos 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 de rede, e não queremos começ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 os perdedores lado em debates sobre design de software. As pessoas só tendem a usá-los para justificar escolhas (inatividade em particular) feitas por outros motivos.

Obrigado a Sarah Harlin, Trevor Blackwell e Dan Giffin por ler 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