MELHOR FILTRAGEM BAYESIANA

Janeiro de 2003

(Este artigo foi apresentado como palestra na Spam Conference 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 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 esse algoritmo depois que ``A Plan for 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 sobre esse trabalho, fiquei um pouco surpreso. Se as pessoas estavam usando a filtragem bayesiana há quatro anos, por que nem todo mundo a estava usando? Quando li os artigos, descobri o porquê. O filtro de Pantel e Lin era o mais eficaz dos dois, mas ele só pegava 92% do spam, com 1,16% de falsos positivos.

Quando tentei escrever um filtro de spam Bayesiano, ele capturou 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 produzir 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 em pouquíssimos dados: 160 e-mails de spam e 466 não spam. O desempenho do filtro ainda deve estar subindo com conjuntos de dados tão pequenos. Então seus números podem nem ser uma medida precisa do desempenho de 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 com filtros de spam, isso parecerá uma decisão perversa. E ainda assim, nos primeiros filtros que tentei escrever, ignorei os 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 escritores de filtros: não ignore os dados. Você pensaria que essa lição seria óbvia demais para mencionar, mas eu tive que aprendê-la várias vezes.

Terceiro, Pantel e Lin fizeram steming dos tokens, o que significa que eles reduziram, por exemplo, tanto mailing'' and 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 assim, isso é um tipo de otimização prematura.

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

Finalmente, eles não foram tendenciosos contra falsos positivos. Acho que qualquer algoritmo de filtragem de spam deve ter um botão conveniente que você pode girar para diminuir a taxa de falsos positivos às custas da taxa de filtragem. Eu faço isso contando as ocorrências de tokens no corpus não spam double.

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. 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, então 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.

Fichas

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 direto, mas tão incrivelmente eficaz que consegue filtrar spam quase perfeitamente sem nem saber o que está fazendo.

Depois que entendi como o CRM114 funcionava, parecia inevitável que eu eventualmente teria que mudar da filtragem baseada em palavras únicas para uma abordagem como essa. Mas primeiro, pensei, vou ver até onde posso chegar com palavras únicas. E a resposta é, surpreendentemente longe.

Na maior parte do tempo, tenho trabalhado em tokenização mais inteligente. No spam atual, consegui atingir taxas de filtragem que se aproximam das do CRM114. Essas técnicas são, na maioria, ortogonais às do Bill; uma solução ótima pode incorporar ambas.

``A Plan for Spam'' usa uma definição muito simples de um token. Letras, dígitos, traços, apóstrofos e cifrões são caracteres constituintes, e todo o resto é um separador de token. Eu também ignorei maiúsculas e minúsculas.

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 US$ 20-25 rende dois tokens, US$ 20 e US$ 25.

Tokens que ocorrem dentro das linhas To, From, Subject e Return-Path, ou dentro de urls, são marcados de acordo. Por exemplo, foo'' in the Subject line becomes Subject*foo''. (O asterisco pode ser qualquer caractere que você não permita como constituinte.)

Tais medidas aumentam o vocabulário do filtro, o que o torna mais discriminador. Por exemplo, no filtro atual, ``grátis'' 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]:

Assunto GRÁTIS 0,9999 grátis!! 0,9999 Para grátis 0,9998 Assunto grátis 0,9782 grátis! 0,9199 Grátis 0,9198 Url grátis 0,9091 GRÁTIS 0,8747 De*grátis 0,7636 grátis 0,6546

No filtro Plan for 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 chances 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 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 consegue encontrar uma correspondência exata para um token, trate-o como se fosse uma versão menos específica. Eu considero pontos de exclamação terminais, letras maiúsculas e ocorrência 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!'', I look for probabilities for Subject*free'', free!'', and free'', e pego 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 isso.

Assunto Livre !!! Assunto Livre !!! Assunto Livre! Assunto Livre! Assunto Livre! Assunto Livre Assunto Livre GRÁTIS!!! Grátis!!! grátis!!! GRÁTIS ! Grátis ! grátis! GRÁTIS Grátis grátis

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

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

Outro efeito de um vocabulário maior é que quando você olha para um e-mail recebido, você encontra tokens mais interessantes, ou seja, aqueles com probabilidades longe de 0,5. Eu uso os 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 determine a ordenação de tokens igualmente interessantes. Uma maneira de lidar com isso é tratar alguns como mais interessantes do que outros.

Por exemplo, o token dalco'' occurs 3 times in my spam corpus and never in my legitimate corpus. The token Url*optmails'' (que significa ``optmails'' dentro de uma url) ocorre 1223 vezes. E ainda assim, como eu costumava calcular probabilidades para 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 ainda não tentei isso. Parece pelo menos que se encontrarmos mais de 15 tokens que ocorrem apenas em um corpus ou outro, devemos dar prioridade aos que ocorrem muito. Então agora há dois valores de limite. Para tokens que ocorrem apenas no corpus de spam, a probabilidade é .9999 se 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.

Posso posteriormente dimensionar substancialmente as probabilidades dos tokens, mas essa pequena quantidade de dimensionamento 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 estatístico de spam [8]. Se você usar um limite, deixe-o bem alto, ou os spammers podem enganá-lo ao encher mensagens com palavras mais inocentes.

Finalmente, o que se deve fazer sobre o html? Eu tentei todo o espectro de opções, desde ignorá-lo até analisar tudo. Ignorar o html é uma má ideia, porque ele está cheio de sinais úteis de spam. Mas se você analisar tudo, seu filtro pode degenerar em um mero reconhecedor de html. A abordagem mais eficaz parece ser o caminho do meio, 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.

Eu provavelmente poderia ser mais inteligente ao lidar com html, mas não acho que valha a pena investir muito tempo nisso. Spams cheios de html são fáceis de filtrar. Os spammers mais inteligentes já os evitam. 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. Essa é uma taxa de filtragem de cerca de 99,75%.

Dois dos quatro spams que perdi foram enviados porque usavam palavras que aparecem com frequência nos meus e-mails legítimos.

O terceiro foi um daqueles que exploram um script cgi inseguro para enviar e-mails a 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, geralmente consigo pegá-los. Este passou por pouco com uma probabilidade de 0,88, logo abaixo do limite de 0,9.

Claro, olhar para várias sequências de tokens o detectaria facilmente. ``Abaixo está o resultado do seu formulário de feedback'' é uma oferta instantânea.

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

Se os spammers forem cuidadosos com os cabeçalhos e usarem uma URL nova, não há nada no spam-do-futuro para os filtros perceberem. Podemos, é claro, contra-atacar enviando um rastreador 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, ou todos estariam fazendo isso. Se for baixa o suficiente, não valerá a pena para os spammers enviá-lo, e não teremos que trabalhar muito para filtrá-lo.

Agora, as notícias realmente chocantes: durante o mesmo período de um mês, tive três falsos positivos.

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

Dois dos falsos positivos eram boletins informativos de empresas das quais comprei coisas. Nunca pedi para recebê-los, então, sem dúvida, eram spams, mas os considero falsos positivos porque não os estava excluindo como spams antes. O motivo pelo qual 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 ruim, no entanto. Era de alguém do Egito e escrito todo em letras maiúsculas. Isso foi um resultado direto de tornar os tokens sensíveis a maiúsculas e minúsculas; o filtro Plan for Spam não teria detectado.

É difícil dizer qual é a taxa geral de falsos positivos, porque estamos no meio do barulho, estatisticamente. Qualquer um que tenha trabalhado com filtros (pelo menos filtros eficazes) estará ciente desse problema. Com alguns e-mails é difícil dizer se são spam ou não, e esses são os que você acaba olhando quando os filtros são realmente rigorosos. 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. Pode-se argumentar que esses não são meus e-mails de spam nem meus e-mails não spam.

Outro falso positivo veio de um vice-presidente da Virtumundo. Escrevi para eles fingindo ser um cliente, e como a resposta voltou pelos servidores de e-mail da Virtumundo, ela tinha os cabeçalhos mais incriminadores imagináveis. Pode-se argumentar que isso também não é um falso positivo real, mas uma espécie de efeito de incerteza de Heisenberg: só recebi 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 da Evite.

Não acho que esse número seja confiável, em parte porque a amostra é muito pequena e em parte porque acho que posso consertar o filtro para não capturar alguns deles.

Falsos positivos me parecem um tipo diferente de erro de falsos negativos. A taxa de filtragem é uma medida de desempenho. Eu considero falsos positivos 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 minha lista de bugs. Por exemplo, o e-mail do Egito foi pego porque o texto em caixa alta fez com que parecesse um spam nigeriano para o filtro. Isso realmente é um bug. Assim como no HTML, o e-mail todo em caixa alta é conceitualmente um recurso, não um para cada palavra. Preciso lidar com maiúsculas e minúsculas de uma forma mais sofisticada.

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

Futuro

O que vem depois? Filtrar é um problema de otimização, e a chave para a otimização é o perfil. Não tente adivinhar onde seu código está lento, porque você vai adivinhar errado. Veja onde seu código está lento e corrija isso. Na filtragem, isso se traduz em: veja os spams que você deixa passar e descubra o que você poderia ter feito para pegá-los.

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

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

O outro tipo de spam que tenho dificuldade em filtrar são aqueles de empresas na Bulgária, por exemplo, que oferecem serviços de programação contratada. Eles passam porque eu também sou um programador, e os spams estão cheios das mesmas palavras do meu e-mail real.

Provavelmente vou focar primeiro no tipo de anúncio pessoal. Acho que se eu olhar mais de perto, vou conseguir encontrar diferenças estatísticas entre estes e meu e-mail real. O estilo de escrita é certamente diferente, embora possa ser necessária uma filtragem multipalavra para detectar isso. Além disso, notei 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 terceirizado vai ser difícil de pegar. Mesmo se você enviasse um rastreador para o site, 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 de contrato da Bulgária, provavelmente poderíamos todos passar a trabalhar em outra coisa.

A filtragem estatística realmente nos levará a esse ponto? Não sei. No momento, para mim, pessoalmente, 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 isso?

Não estou otimista sobre filtros que funcionam no nível de rede [13]. Quando há um obstáculo estático que vale a pena passar, os spammers são bem eficientes em passar por ele. Já existe uma empresa chamada Assurance Systems que executará seu e-mail pelo Spamassassin e informará se ele será filtrado.

Filtros de nível de rede não serão completamente inúteis. Eles podem ser o suficiente para matar todo o spam "opt-in", ou seja, spam de empresas como Virtumundo e Equalamail que alegam que estão 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 retransmissões abertas, presumivelmente incluindo a maioria dos spammers pornográficos, deve ser capaz de obter alguma mensagem passando pelos filtros de nível de rede se quiserem. (De forma alguma a mensagem que eles gostariam de enviar, o que é alguma coisa.)

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

Mas a vantagem real dos filtros individuais é que todos eles serão diferentes. Se os filtros de cada um 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, assustadoramente lento. Em vez de apenas ajustar um spam até que ele passe por uma cópia de algum filtro que eles tenham em seu desktop, eles terão que fazer um teste de envio de e-mail 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. ``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. Há duas suposições simplificadoras: que as probabilidades de características (ou seja, palavras) são independentes e que não sabemos nada sobre a probabilidade prévia de um e-mail ser spam.

A primeira suposição é amplamente difundida na classificação de texto. Algoritmos que a usam são chamados de ``bayesianos ingênuos.''

A segunda suposição que fiz foi porque a proporção de spam no meu e-mail recebido flutuava tanto de um dia para o outro (na verdade, de uma hora para outra) que a proporção geral anterior parecia inútil 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 fosse consistentemente muito alta ou (especialmente) muito baixa, você provavelmente poderia melhorar o desempenho do filtro incorporando probabilidades anteriores. Para fazer isso direito, você teria que rastrear as proporções por hora do dia, porque o volume de spam e e-mail legítimo têm padrões diários distintos.

[2] Patrick Pantel e Dekang Lin. ``SpamCop - Um programa de classificação e organização de spam.'' Anais do workshop AAAI-98 sobre aprendizagem para categorização de texto.

[3] Mehran Sahami, Susan Dumais, David Heckerman e Eric Horvitz. ``Uma abordagem bayesiana para filtrar lixo eletrônico.'' Anais do workshop AAAI-98 sobre aprendizagem para categorização de texto.

[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 não são confiáveis, como explico mais tarde. Cito um número aqui apenas para enfatizar que qualquer que seja a taxa de falsos positivos, ela é inferior a 1,16%.

[5] Bill Yerazunis. ``Filtragem de mensagens de hash polinomial binário esparso e o discriminador CRM114.'' Anais da Conferência de Spam de 2003.

[6] Em ``A Plan for Spam'' usei limiares de .99 e .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 .9999 e .0001.

[7] Há uma falha aqui que eu provavelmente deveria consertar. Atualmente, quando Subject*foo'' degenerates to just foo'', o que isso significa é que você está obtendo as estatísticas para ocorrências de foo'' in the body or header lines other than those I mark. What I should do is keep track of statistics for foo'' em geral, bem como versões específicas, e degenerar de Subject*foo'' not to foo'', mas para ``Anywhere*foo''. O mesmo para maiúsculas e minúsculas: eu deveria degenerar de maiúsculas para qualquer caixa, não minúsculas.

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

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

[8] Steven Hauser. ``O filtro estatístico de spam funciona para mim.'' http://www.sofbot.com.

[9] Falsos positivos não são todos iguais, e devemos lembrar disso ao comparar técnicas para interromper spam. Enquanto muitos dos falsos positivos causados por filtros serão quase spams que você não se importaria em deixar passar, falsos positivos causados por listas negras, por exemplo, serão apenas e-mails de pessoas que escolheram o ISP errado. Em ambos os casos, você pega e-mails que são quase 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 escolher as palavras da sequência resultante. E, claro, encontrar palavras dessa forma que não eram visíveis no texto original seria, por si só, evidência de spam.

Selecionar as palavras não será trivial. Exigirá mais do que apenas reconstruir os limites das palavras; os spammers adicionam ( xHot nPorn cSite'') and omit ( P#rn'') letras. A pesquisa de visão pode ser útil aqui, já que a visão humana é o limite que tais truques abordarão.

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

[12] É nisso que abordagens como a do Brightmail irão degenerar quando os spammers forem forçados a usar técnicas de mad-lib para gerar todo o resto na 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 começar do zero. Mas você não pode ditar o problema para se adequar à sua solução.

Historicamente, argumentos de recursos escassos têm sido o lado perdedor em debates sobre design de software. As pessoas tendem a usá-los apenas para justificar escolhas (inação em particular) feitas por outros motivos.

Obrigado a Sarah Harlin, Trevor Blackwell e Dan Giffin pela leitura dos rascunhos deste artigo, e a Dan novamente pela maior parte da infraestrutura na qual este filtro é executado.

Relacionado:

Assunto GRÁTIS 0,9999 grátis!! 0,9999 Para grátis 0,9998 Assunto grátis 0,9782 grátis! 0,9199 Grátis 0,9198 Url grátis 0,9091 GRÁTIS 0,8747 De*grátis 0,7636 grátis 0,6546

Assunto Livre !!! Assunto Livre !!! Assunto Livre! Assunto Livre! Assunto Livre! Assunto Livre Assunto Livre GRÁTIS!!! Grátis!!! grátis!!! GRÁTIS ! Grátis ! grátis! GRÁTIS Grátis grátis