MEJOR FILTRADO BAYESIANO

Enero de 2003

(Este artículo fue presentado como una charla en la Conferencia de Spam de 2003. Describe el trabajo que he realizado para mejorar el rendimiento del algoritmo descrito en A Plan for Spam, y lo que planeo hacer en el futuro.)

El primer descubrimiento que me gustaría presentar aquí es un algoritmo para la evaluación perezosa de trabajos de investigación. Simplemente escribe lo que quieras y no cites ningún trabajo previo, y los lectores indignados te enviarán referencias a todos los artículos que deberías haber citado. Descubrí este algoritmo después de que ``A Plan for Spam'' [1] apareciera en Slashdot.

El filtrado de spam es un subconjunto de la clasificación de texto, que es un campo bien establecido, pero los primeros artículos sobre el filtrado de spam bayesiano per se parecen haber sido dos presentados en la misma conferencia en 1998, uno por Pantel y Lin [2], y otro por un grupo de Microsoft Research [3].

Cuando escuché sobre este trabajo me sorprendí un poco. Si la gente había estado trabajando en el filtrado bayesiano hace cuatro años, ¿por qué no lo estaba usando todo el mundo? Cuando leí los artículos descubrí por qué. El filtro de Pantel y Lin era el más efectivo de los dos, pero solo capturaba el 92% del spam, con un 1.16% de falsos positivos.

Cuando intenté escribir un filtro de spam bayesiano, capturó el 99.5% del spam con menos del 0.03% de falsos positivos [4]. Siempre es alarmante cuando dos personas que intentan el mismo experimento obtienen resultados muy divergentes. Es especialmente alarmante aquí porque esos dos conjuntos de números podrían dar conclusiones opuestas. Los diferentes usuarios tienen diferentes requisitos, pero creo que para muchas personas una tasa de filtrado del 92% con un 1.16% de falsos positivos significa que el filtrado no es una solución aceptable, mientras que el 99.5% con menos del 0.03% de falsos positivos significa que sí lo es.

Entonces, ¿por qué obtuvimos números tan diferentes? No he intentado reproducir los resultados de Pantel y Lin, pero al leer el artículo veo cinco cosas que probablemente expliquen la diferencia.

Una es simplemente que entrenaron su filtro con muy pocos datos: 160 correos spam y 466 correos no spam. El rendimiento del filtro aún debería estar aumentando con conjuntos de datos tan pequeños. Así que sus números pueden no ser ni siquiera una medida precisa del rendimiento de su algoritmo, y mucho menos del filtrado de spam bayesiano en general.

Pero creo que la diferencia más importante es probablemente que ignoraron los encabezados de los mensajes. Para cualquiera que haya trabajado en filtros de spam, esto parecerá una decisión perversa. Y sin embargo, en los primeros filtros que intenté escribir, también ignoré los encabezados. ¿Por qué? Porque quería mantener el problema ordenado. No sabía mucho sobre los encabezados de correo en ese momento, y me parecían llenos de cosas aleatorias. Hay una lección aquí para los escritores de filtros: no ignores los datos. Pensarías que esta lección sería demasiado obvia para mencionarla, pero he tenido que aprenderla varias veces.

En tercer lugar, Pantel y Lin redujeron los tokens, lo que significa que redujeron, por ejemplo, tanto mailing'' como mailed'' a la raíz ``mail''. Puede que sintieran que estaban obligados a hacerlo por el pequeño tamaño de su corpus, pero si es así, esto es una especie de optimización prematura.

En cuarto lugar, calcularon probabilidades de manera diferente. Usaron todos los tokens, mientras que yo solo uso los 15 más significativos. Si usas todos los tokens, tiendes a perder spams más largos, el tipo donde alguien te cuenta su historia de vida hasta el punto en que se hizo rico con algún esquema de marketing multinivel. Y tal algoritmo sería fácil de engañar para los spammers: simplemente agrega un gran trozo de texto aleatorio para contrarrestar los términos de spam.

Finalmente, no sesgaron contra los falsos positivos. Creo que cualquier algoritmo de filtrado de spam debería tener un control conveniente que puedas ajustar para disminuir la tasa de falsos positivos a expensas de la tasa de filtrado. Yo hago esto contando las ocurrencias de tokens en el corpus no spam el doble.

No creo que sea una buena idea tratar el filtrado de spam como un problema de clasificación de texto directo. Puedes usar técnicas de clasificación de texto, pero las soluciones pueden y deben reflejar el hecho de que el texto es correo electrónico, y spam en particular. El correo electrónico no es solo texto; tiene estructura. El filtrado de spam no es solo clasificación, porque los falsos positivos son mucho peores que los falsos negativos, por lo que deberías tratarlos como un tipo diferente de error. Y la fuente de error no es solo variación aleatoria, sino un spammer humano activo trabajando para derrotar tu filtro.

Tokens

Otro proyecto del que escuché después del artículo de Slashdot fue el de Bill Yerazunis, CRM114 [5]. Este es el contraejemplo al principio de diseño que acabo de mencionar. Es un clasificador de texto directo, pero tan sorprendentemente efectivo que logra filtrar spam casi perfectamente sin siquiera saber que eso es lo que está haciendo.

Una vez que entendí cómo funcionaba CRM114, parecía inevitable que eventualmente tendría que pasar de filtrar basado en palabras individuales a un enfoque como este. Pero primero, pensé, veré hasta dónde puedo llegar con palabras individuales. Y la respuesta es, sorprendentemente lejos.

Principalmente he estado trabajando en una tokenización más inteligente. En el spam actual, he podido lograr tasas de filtrado que se acercan a las de CRM114. Estas técnicas son en su mayoría ortogonales a las de Bill; una solución óptima podría incorporar ambas.

``A Plan for Spam'' utiliza una definición muy simple de un token. Letras, dígitos, guiones, apóstrofes y signos de dólar son caracteres constitutivos, y todo lo demás es un separador de tokens. También ignoré el caso.

Ahora tengo una definición más complicada de un token:

Se preserva el caso.

Los signos de exclamación son caracteres constitutivos.

Los puntos y comas son constitutivos si ocurren entre dos dígitos. Esto me permite obtener direcciones IP y precios intactos.

Un rango de precios como $20-25 produce dos tokens, $20 y $25.

Los tokens que ocurren dentro de las líneas To, From, Subject y Return-Path, o dentro de URLs, se marcan en consecuencia. Por ejemplo, foo'' en la línea de Asunto se convierte en Subject*foo''. (El asterisco podría ser cualquier carácter que no permitas como constitutivo.)

Tales medidas aumentan el vocabulario del filtro, lo que lo hace más discriminativo. Por ejemplo, en el filtro actual, ``free'' en la línea de Asunto tiene una probabilidad de spam del 98%, mientras que el mismo token en el cuerpo tiene una probabilidad de spam de solo el 65%.

Aquí hay algunas de las probabilidades actuales [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

En el filtro Plan for Spam, todos estos tokens habrían tenido la misma probabilidad, 0.7602. Ese filtro reconoció alrededor de 23,000 tokens. El actual reconoce alrededor de 187,000.

La desventaja de tener un universo más grande de tokens es que hay más posibilidad de fallos. Expandir tu corpus sobre más tokens tiene el mismo efecto que hacerlo más pequeño. Si consideras los signos de exclamación como constitutivos, por ejemplo, entonces podrías terminar sin tener una probabilidad de spam para free con siete signos de exclamación, a pesar de que sabes que free con solo dos signos de exclamación tiene una probabilidad del 99.99%.

Una solución a esto es lo que llamo degeneración. Si no puedes encontrar una coincidencia exacta para un token, trátalo como si fuera una versión menos específica. Considero que los signos de exclamación terminales, las letras mayúsculas y la ocurrencia en uno de los cinco contextos marcados hacen que un token sea más específico. Por ejemplo, si no encuentro una probabilidad para Subject*free!'', busco probabilidades para Subject*free'', free!'', y free'', y tomo la que esté más lejos de 0.5.

Aquí están las alternativas [7] consideradas si el filtro ve ``FREE!!!'' en la línea de Asunto y no tiene una probabilidad para ello.

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

Si haces esto, asegúrate de considerar versiones con mayúsculas iniciales así como todas en mayúsculas y todas en minúsculas. Los spams tienden a tener más oraciones en modo imperativo, y en esas el primer palabra es un verbo. Así que los verbos con mayúsculas iniciales tienen probabilidades de spam más altas de lo que tendrían en minúsculas. En mi filtro, la probabilidad de spam de Act'' es del 98% y para act'' solo del 62%.

Si aumentas el vocabulario de tu filtro, puedes terminar contando la misma palabra múltiples veces, de acuerdo a tu antigua definición de ``mismo''. Lógicamente, ya no son el mismo token. Pero si esto aún te molesta, permíteme agregar por experiencia que las palabras que parece que estás contando múltiples veces tienden a ser exactamente las que querrías contar.

Otro efecto de un vocabulario más grande es que cuando miras un correo entrante encuentras tokens más interesantes, es decir, aquellos con probabilidades lejos de 0.5. Yo uso los 15 más interesantes para decidir si un correo es spam. Pero puedes encontrarte con un problema cuando usas un número fijo como este. Si encuentras muchos tokens maximamente interesantes, el resultado puede terminar siendo decidido por cualquier factor aleatorio que determine el orden de los tokens igualmente interesantes. Una forma de lidiar con esto es tratar algunos como más interesantes que otros.

Por ejemplo, el token dalco'' ocurre 3 veces en mi corpus de spam y nunca en mi corpus legítimo. El token Url*optmails'' (que significa ``optmails'' dentro de una URL) ocurre 1223 veces. Y sin embargo, a medida que solía calcular probabilidades para tokens, ambos tendrían la misma probabilidad de spam, el umbral de 0.99.

Eso no se siente bien. Hay argumentos teóricos para dar a estos dos tokens probabilidades sustancialmente diferentes (Pantel y Lin lo hacen), pero aún no he intentado eso. Al menos parece que si encontramos más de 15 tokens que solo ocurren en uno de los corpus o en el otro, deberíamos dar prioridad a los que ocurren mucho. Así que ahora hay dos valores umbral. Para los tokens que ocurren solo en el corpus de spam, la probabilidad es 0.9999 si ocurren más de 10 veces y 0.9998 de lo contrario. Lo mismo al otro extremo de la escala para los tokens encontrados solo en el corpus legítimo.

Más adelante podría escalar las probabilidades de los tokens sustancialmente, pero esta pequeña cantidad de escalado al menos asegura que los tokens se ordenen de la manera correcta.

Otra posibilidad sería considerar no solo 15 tokens, sino todos los tokens por encima de un cierto umbral de interés. Steven Hauser hace esto en su filtro de spam estadístico [8]. Si usas un umbral, hazlo muy alto, o los spammers podrían engañarte llenando mensajes con palabras más inocentes.

Finalmente, ¿qué se debe hacer con el html? He probado todo el espectro de opciones, desde ignorarlo hasta analizarlo todo. Ignorar el html es una mala idea, porque está lleno de señales de spam útiles. Pero si lo analizas todo, tu filtro podría degenerar en un mero reconocedor de html. El enfoque más efectivo parece ser el camino intermedio, notar algunos tokens pero no otros. Miro las etiquetas a, img y font, y ignoro el resto. Los enlaces y las imágenes definitivamente deberías mirarlos, porque contienen URLs.

Probablemente podría ser más inteligente al tratar con html, pero no creo que valga la pena dedicar mucho tiempo a esto. Los spams llenos de html son fáciles de filtrar. Los spammers más inteligentes ya lo evitan. Así que el rendimiento en el futuro no debería depender mucho de cómo trates el html.

Rendimiento

Entre el 10 de diciembre de 2002 y el 10 de enero de 2003 recibí alrededor de 1750 spams. De estos, 4 pasaron. Esa es una tasa de filtrado de aproximadamente 99.75%.

Dos de los cuatro spams que perdí pasaron porque usaron palabras que ocurren a menudo en mi correo legítimo.

El tercero fue uno de esos que explotan un script CGI inseguro para enviar correo a terceros. Son difíciles de filtrar basándose solo en el contenido porque los encabezados son inocentes y son cuidadosos con las palabras que usan. Aun así, generalmente puedo atraparlos. Este pasó con una probabilidad de 0.88, justo por debajo del umbral de 0.9.

Por supuesto, mirar secuencias de múltiples tokens lo atraparía fácilmente. ``A continuación se muestra el resultado de su formulario de comentarios'' es una pista instantánea.

El cuarto spam fue lo que llamo un spam del futuro, porque esto es lo que espero que el spam evolucione: algún texto completamente neutral seguido de una URL. En este caso, era de alguien que decía que finalmente había terminado su página de inicio y que si podía ir a verla. (La página era, por supuesto, un anuncio de un sitio pornográfico.)

Si los spammers son cuidadosos con los encabezados y usan una URL nueva, no hay nada en el spam del futuro que los filtros puedan notar. Por supuesto, podemos contrarrestar enviando un rastreador para mirar la página. Pero eso podría no ser necesario. La tasa de respuesta para el spam del futuro debe ser baja, o todos estarían haciéndolo. Si es lo suficientemente baja, no valdrá la pena para los spammers enviarlo, y no tendremos que trabajar demasiado en filtrarlo.

Ahora la noticia realmente sorprendente: durante ese mismo período de un mes recibí tres falsos positivos.

En cierto modo, es un alivio tener algunos falsos positivos. Cuando escribí ``A Plan for Spam'' no había tenido ninguno, y no sabía cómo serían. Ahora que he tenido algunos, me alivia descubrir que no son tan malos como temía. Los falsos positivos generados por filtros estadísticos resultan ser correos que suenan mucho como spam, y estos tienden a ser los que menos te importaría perder [9].

Dos de los falsos positivos fueron boletines de empresas de las que he comprado cosas. Nunca pedí recibirlos, así que se podría argumentar que eran spams, pero los cuento como falsos positivos porque no los había estado eliminando como spams antes. La razón por la que los filtros los atraparon fue que ambas empresas en enero cambiaron a remitentes de correo electrónico comerciales en lugar de enviar los correos desde sus propios servidores, y tanto los encabezados como los cuerpos se volvieron mucho más spammy.

El tercer falso positivo fue uno malo, sin embargo. Era de alguien en Egipto y estaba escrito en mayúsculas. Esto fue un resultado directo de hacer que los tokens fueran sensibles al caso; el filtro Plan for Spam no lo habría atrapado.

Es difícil decir cuál es la tasa general de falsos positivos, porque estamos en el ruido, estadísticamente. Cualquiera que haya trabajado en filtros (al menos, filtros efectivos) será consciente de este problema. Con algunos correos es difícil decir si son spam o no, y estos son los que terminas mirando cuando ajustas los filtros realmente estrictos. Por ejemplo, hasta ahora el filtro ha atrapado dos correos que fueron enviados a mi dirección debido a un error tipográfico, y uno enviado a mí con la creencia de que era otra persona. Se podría argumentar que estos no son ni mi spam ni mi correo no spam.

Otro falso positivo fue de un vicepresidente de Virtumundo. Les escribí pretendiendo ser un cliente, y como la respuesta volvió a través de los servidores de correo de Virtumundo, tenía los encabezados más incriminatorios imaginables. Se podría argumentar que esto tampoco es un verdadero falso positivo, sino una especie de efecto de incertidumbre de Heisenberg: solo lo recibí porque estaba escribiendo sobre el filtrado de spam.

Sin contar estos, he tenido un total de cinco falsos positivos hasta ahora, de aproximadamente 7740 correos electrónicos legítimos, una tasa de 0.06%. Los otros dos fueron un aviso de que algo que compré estaba en espera, y un recordatorio de fiesta de Evite.

No creo que se pueda confiar en este número, en parte porque la muestra es tan pequeña, y en parte porque creo que puedo arreglar el filtro para que no atrape algunos de estos.

Los falsos positivos me parecen un tipo diferente de error que los falsos negativos. La tasa de filtrado es una medida de rendimiento. Los falsos positivos los considero más como errores. Enfoque la mejora de la tasa de filtrado como optimización, y la disminución de falsos positivos como depuración.

Así que estos cinco falsos positivos son mi lista de errores. Por ejemplo, el correo de Egipto fue atrapado porque el texto en mayúsculas hizo que al filtro le pareciera un spam nigeriano. Esto realmente es una especie de error. Al igual que con el html, el hecho de que el correo esté en mayúsculas es realmente conceptualmente una característica, no una para cada palabra. Necesito manejar el caso de una manera más sofisticada.

Entonces, ¿qué hacer con este 0.06%? No mucho, creo. Podrías tratarlo como un límite superior, teniendo en cuenta el pequeño tamaño de la muestra. Pero en esta etapa es más una medida de los errores en mi implementación que de alguna tasa intrínseca de falsos positivos del filtrado bayesiano.

Futuro

¿Qué sigue? El filtrado es un problema de optimización, y la clave para la optimización es el perfilado. No intentes adivinar dónde tu código es lento, porque adivinarás mal. Mira dónde tu código es lento y arregla eso. En el filtrado, esto se traduce en: mira los spams que pierdes y averigua qué podrías haber hecho para atraparlos.

Por ejemplo, los spammers ahora están trabajando agresivamente para evadir filtros, y una de las cosas que están haciendo es romper y mal escribir palabras para evitar que los filtros las reconozcan. Pero trabajar en esto no es mi primera prioridad, porque aún no tengo problemas para atrapar estos spams [10].

Hay dos tipos de spams con los que actualmente tengo problemas. Uno es el tipo que finge ser un correo electrónico de una mujer invitándote a chatear con ella o ver su perfil en un sitio de citas. Estos pasan porque son el único tipo de propuesta de venta que puedes hacer sin usar lenguaje de ventas. Usan el mismo vocabulario que el correo electrónico ordinario.

El otro tipo de spams que tengo problemas para filtrar son aquellos de empresas en, por ejemplo, Bulgaria, que ofrecen servicios de programación por contrato. Estos pasan porque yo también soy programador, y los spams están llenos de las mismas palabras que mi correo real.

Probablemente me centraré primero en el tipo de anuncios personales. Creo que si miro más de cerca podré encontrar diferencias estadísticas entre estos y mi correo real. El estilo de escritura es ciertamente diferente, aunque puede que se necesite filtrado de múltiples palabras para atraparlo. Además, noto que tienden a repetir la URL, y alguien que incluya una URL en un correo legítimo no haría eso [11].

El tipo de subcontratación va a ser difícil de atrapar. Incluso si envías un rastreador al sitio, no encontrarías una pistola estadística humeante. Quizás la única respuesta sea una lista central de dominios anunciados en spams [12]. Pero no puede haber tantos de este tipo de correo. Si los únicos spams que quedaran fueran ofertas no solicitadas de servicios de programación por contrato de Bulgaria, probablemente todos podríamos pasar a trabajar en algo más.

¿Llegará el filtrado estadístico realmente a ese punto? No lo sé. En este momento, para mí personalmente, el spam no es un problema. Pero los spammers aún no han hecho un esfuerzo serio por engañar a los filtros estadísticos. ¿Qué pasará cuando lo hagan?

No soy optimista sobre los filtros que funcionan a nivel de red [13]. Cuando hay un obstáculo estático que vale la pena superar, los spammers son bastante eficientes para superarlo. Ya hay una empresa llamada Assurance Systems que ejecutará tu correo a través de Spamassassin y te dirá si será filtrado.

Los filtros a nivel de red no serán completamente inútiles. Pueden ser suficientes para eliminar todo el spam "opt-in", es decir, spam de empresas como Virtumundo y Equalamail que afirman que realmente están ejecutando listas de opt-in. Puedes filtrar esos basándote solo en los encabezados, sin importar lo que digan en el cuerpo. Pero cualquiera que esté dispuesto a falsificar encabezados o usar relés abiertos, presumiblemente incluyendo a la mayoría de los spammers de pornografía, debería poder hacer que algún mensaje pase por los filtros a nivel de red si lo desea. (Por supuesto, no sería el mensaje que les gustaría enviar, lo cual es algo).

El tipo de filtros en los que soy optimista son aquellos que calculan probabilidades basadas en el correo de cada usuario individual. Estos pueden ser mucho más efectivos, no solo en evitar falsos positivos, sino también en el filtrado: por ejemplo, encontrar la dirección de correo del destinatario codificada en base-64 en cualquier parte de un mensaje es un muy buen indicador de spam.

Pero la verdadera ventaja de los filtros individuales es que todos serán diferentes. Si los filtros de todos tienen diferentes probabilidades, hará que el bucle de optimización de los spammers, lo que los programadores llamarían su ciclo de edición-compilación-prueba, sea espantosamente lento. En lugar de simplemente ajustar un spam hasta que pase por una copia de algún filtro que tienen en su escritorio, tendrán que hacer un envío de prueba para cada ajuste. Sería como programar en un lenguaje sin un nivel superior interactivo, y no desearía eso a nadie.

Notas

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

Las probabilidades en este algoritmo se calculan utilizando un caso degenerado de la Regla de Bayes. Hay dos suposiciones simplificadoras: que las probabilidades de las características (es decir, palabras) son independientes, y que no sabemos nada sobre la probabilidad previa de que un correo electrónico sea spam.

La primera suposición es generalizada en la clasificación de texto. Los algoritmos que la utilizan se llaman ``bayesianos ingenuos''.

La segunda suposición la hice porque la proporción de spam en mi correo entrante fluctuaba tanto de un día a otro (de hecho, de una hora a otra) que la relación previa general parecía inútil como predictor. Si asumes que P(spam) y P(nonspam) son ambos 0.5, se cancelan y puedes eliminarlos de la fórmula.

Si estuvieras haciendo filtrado bayesiano en una situación donde la relación de spam a no spam fuera consistentemente muy alta o (especialmente) muy baja, probablemente podrías mejorar el rendimiento del filtro incorporando probabilidades previas. Para hacer esto bien tendrías que rastrear las relaciones por hora del día, porque el volumen de spam y correo legítimo tiene patrones diarios distintos.

[2] Patrick Pantel y Dekang Lin. ``SpamCop-- Un Programa de Clasificación y Organización de Spam.'' Actas del Taller AAAI-98 sobre Aprendizaje para la Clasificación de Texto.

[3] Mehran Sahami, Susan Dumais, David Heckerman y Eric Horvitz. ``Un Enfoque Bayesiano para Filtrar Correo Basura.'' Actas del Taller AAAI-98 sobre Aprendizaje para la Clasificación de Texto.

[4] En ese momento no tenía falsos positivos de aproximadamente 4,000 correos electrónicos legítimos. Si el siguiente correo legítimo era un falso positivo, esto nos daría 0.03%. Estas tasas de falsos positivos no son confiables, como explico más adelante. Cito un número aquí solo para enfatizar que sea cual sea la tasa de falsos positivos, es menos del 1.16%.

[5] Bill Yerazunis. ``Filtrado de Mensajes Hash Polinómicos Binarios Escasos y El Discriminador CRM114.'' Actas de la Conferencia de Spam de 2003.

[6] En ``A Plan for Spam'' utilicé umbrales de 0.99 y 0.01. Parece justificable usar umbrales proporcionales al tamaño de los corpus. Dado que ahora tengo del orden de 10,000 de cada tipo de correo, uso 0.9999 y 0.0001.

[7] Hay un defecto aquí que probablemente debería arreglar. Actualmente, cuando Subject*foo'' degenera a solo foo'', lo que eso significa es que estás obteniendo las estadísticas para las ocurrencias de foo'' en el cuerpo o líneas de encabezado distintas de las que marco. Lo que debería hacer es llevar un registro de las estadísticas para foo'' en general, así como versiones específicas, y degenerar de Subject*foo'' no a foo'' sino a ``Anywhere*foo''. Lo mismo para el caso: debería degenerar de mayúsculas a cualquier caso, no a minúsculas.

Probablemente sería beneficioso hacer esto también con precios, por ejemplo, degenerar de $129.99'' a $--9.99'', $--.99'', y $--''.

También podrías degenerar de palabras a sus raíces, pero esto probablemente solo mejoraría las tasas de filtrado al principio, cuando tenías corpus pequeños.

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

[9] Los falsos positivos no son todos iguales, y deberíamos recordar esto al comparar técnicas para detener el spam. Mientras que muchos de los falsos positivos causados por filtros serán casi spams que no te importaría perder, los falsos positivos causados por listas negras, por ejemplo, serán solo correos de personas que eligieron el ISP equivocado. En ambos casos atrapas correos que están cerca del spam, pero para las listas negras la cercanía es física, y para los filtros es textual.

[10] Si los spammers se vuelven lo suficientemente buenos en ocultar tokens para que esto sea un problema, podemos responder simplemente eliminando espacios en blanco, puntos, comas, etc., y usando un diccionario para seleccionar las palabras de la secuencia resultante. Y, por supuesto, encontrar palabras de esta manera que no eran visibles en el texto original sería en sí mismo evidencia de spam.

Seleccionar las palabras no será trivial. Requerirá más que solo reconstruir los límites de las palabras; los spammers tanto añaden (xHot nPorn cSite'') como omiten (P#rn'') letras. La investigación en visión puede ser útil aquí, ya que la visión humana es el límite que tales trucos se acercarán.

[11] En general, los spams son más repetitivos que el correo electrónico regular. Quieren enfatizar ese mensaje. Actualmente no permito duplicados en los 15 principales tokens, porque podrías obtener un falso positivo si el remitente usa alguna palabra mala múltiples veces. (En mi filtro actual, ``dick'' tiene una probabilidad de spam de 0.9999, pero también es un nombre). Parece que al menos deberíamos notar la duplicación, así que podría intentar permitir hasta dos de cada token, como hace Brian Burton en SpamProbe.

[12] Esto es en lo que se degenerarán enfoques como el de Brightmail una vez que los spammers se vean obligados a usar técnicas de mad-lib para generar todo lo demás en el mensaje.

[13] A veces se argumenta que deberíamos trabajar en el filtrado a nivel de red, porque es más eficiente. Lo que la gente suele querer decir cuando dice esto es: actualmente filtramos a nivel de red, y no queremos empezar de cero. Pero no puedes dictar el problema para que se ajuste a tu solución.

Históricamente, los argumentos de recursos escasos han sido el lado perdedor en los debates sobre diseño de software. La gente solo tiende a usarlos para justificar elecciones (la inacción en particular) tomadas por otras razones.

Gracias a Sarah Harlin, Trevor Blackwell y Dan Giffin por leer borradores de este documento, y a Dan nuevamente por la mayor parte de la infraestructura sobre la que se ejecuta este filtro.

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