FILTRADO BAYESIANO MEJOR

Enero 2003

(Este artículo se presentó como una charla en la Conferencia sobre Spam de 2003. Describe el trabajo que he realizado para mejorar el rendimiento del algoritmo descrito en Un plan para el spam, y lo que planeo hacer en el futuro.)

El primer descubrimiento que me gustaría presentar aquí es un algoritmo para evaluación perezosa de artículos 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 "Un plan para el 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 en sí parecen haber sido dos presentados en la misma conferencia en 1998, uno de Pantel y Lin [2], y otro de un grupo de Microsoft Research [3].

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

Cuando intenté escribir un filtro de spam bayesiano, atrapaba 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 lugar a 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 de spam y 466 de no spam. El rendimiento del filtro aún debería estar aumentando con conjuntos de datos tan pequeños. Por lo tanto, sus números pueden no ser siquiera una medida precisa del rendimiento de su algoritmo, 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 limpio. No sabía mucho sobre los encabezados de correo entonces, y me parecían llenos de cosas aleatorias. Aquí hay una lección para los escritores de filtros: no ignores los datos. Uno pensaría 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". Pueden haber sentido que se veían obligados a hacer esto por el pequeño tamaño de su corpus, pero si es así, se trata de una especie de optimización prematura.

En cuarto lugar, calcularon las probabilidades de manera diferente. Utilizaron todos los tokens, mientras que yo solo uso los 15 más significativos. Si usas todos los tokens tenderás a perder los spams más largos, el tipo donde alguien te cuenta su historia de vida hasta el punto en que se hizo rico de algún esquema de marketing multinivel. Y un algoritmo así 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 una perilla conveniente que puedas girar para disminuir la tasa de falsos positivos a expensas de la tasa de filtrado. Hago esto contando las ocurrencias de tokens en el corpus de no spam el doble.

No creo que sea una buena idea tratar el filtrado de spam como un problema de clasificación de texto simple. Puedes usar técnicas de clasificación de texto, pero las soluciones pueden y deben reflejar el hecho de que el texto es un correo electrónico y, en particular, spam. 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 de error diferente. Y la fuente de error no es solo la variación aleatoria, sino un spammer humano vivo que trabaja activamente para derrotar tu filtro.

Tokens

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

Una vez que entendí cómo funcionaba CRM114, me pareció inevitable que eventualmente tendría que pasar del filtrado basado en palabras individuales a un enfoque como este. Pero primero, pensé, veré qué tan lejos puedo llegar con las 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.

"Un plan para el spam" usa una definición muy simple de un token. Las letras, los dígitos, los guiones, los apóstrofos y los signos de dólar son caracteres constituyentes, y todo lo demás es un separador de tokens. También ignoré las mayúsculas.

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

Se conserva el caso.

Los signos de exclamación son caracteres constituyentes.

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

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

Los tokens que ocurren dentro de las líneas Para, De, Asunto y Devolver-Ruta, o dentro de las URL, se marcan en consecuencia. Por ejemplo, "foo" en la línea Asunto se convierte en "Asunto*foo". (El asterisco podría ser cualquier carácter que no permitas como constituyente).

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

Aquí hay algunas de las probabilidades actuales [6]:

AsuntoGRATIS 0.9999 ¡gratis!! 0.9999 Agratis 0.9998 Asuntogratis 0.9782 ¡gratis! 0.9199 Gratis 0.9198 Urlgratis 0.9091 GRATIS 0.8747 De*gratis 0.7636 gratis 0.6546

En el Plan para el filtro de spam, todos estos tokens habrían tenido la misma probabilidad, .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 errores. Extender tu corpus a más tokens tiene el mismo efecto que hacerlo más pequeño. Si consideras los signos de exclamación como constituyentes, por ejemplo, entonces podrías terminar sin tener una probabilidad de spam para gratis con siete signos de exclamación, a pesar de que sabes que gratis 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 que ocurran en uno de los cinco contextos marcados hacen que un token sea más específico. Por ejemplo, si no encuentro una probabilidad para Asunto*¡gratis!'', busco probabilidades para Asunto*gratis'', ¡gratis!'', y gratis'', y tomo la que esté más lejos de .5.

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

Asunto*¡¡¡Gratis! Asunto*¡gratis!!! Asunto*¡¡GRATIS! Asunto*¡Gratis! Asunto*¡gratis! AsuntoGRATIS AsuntoGratis Asunto*gratis ¡¡¡GRATIS! ¡¡¡Gratis! ¡¡¡gratis! ¡¡GRATIS! ¡¡Gratis! ¡¡gratis! ¡GRATIS! ¡Gratis! ¡gratis!

Si haces esto, asegúrate de considerar versiones con mayúscula inicial así como todas en mayúscula y todas en minúscula. Los spams tienden a tener más oraciones en modo imperativo, y en esos la primera palabra es un verbo. Así que los verbos con mayúscula inicial tienen probabilidades de spam más altas de lo que tendrían en minúscula. En mi filtro, la probabilidad de spam de Actúa'' es 98% y para actúa'' solo 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, déjame agregar por experiencia que las palabras que pareces estar contando múltiples veces tienden a ser exactamente las que querrías.

Otro efecto de un vocabulario más grande es que cuando miras un correo entrante encuentras más tokens interesantes, lo que significa aquellos con probabilidades lejos de .5. Uso los 15 más interesantes para decidir si un correo es spam. Pero puedes encontrar un problema cuando usas un número fijo como este. Si encuentras muchos tokens máximamente interesantes, el resultado puede terminar siendo decidido por cualquier factor aleatorio que determine el orden de 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, tal como solía calcular probabilidades para tokens, ambos tendrían la misma probabilidad de spam, el umbral de .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 lo he intentado. Al menos parece que si encontramos más de 15 tokens que solo ocurren en uno u otro corpus, deberíamos dar prioridad a los que ocurren muchas veces. Así que ahora hay dos valores de umbral. Para tokens que ocurren solo en el corpus de spam, la probabilidad es .9999 si ocurren más de 10 veces y .9998 de lo contrario. Igual en el otro extremo de la escala para tokens encontrados solo en el corpus legítimo.

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

Otra posibilidad sería considerar no solo 15 tokens, sino todos los tokens sobre 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 empacando mensajes con más palabras inocentes.

Finalmente, ¿qué debería hacer uno 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 útiles de spam. Pero si analizas todo, tu filtro podría degenerar en un mero reconocedor de html. El enfoque más efectivo parece ser el curso medio, notar algunos tokens pero no otros. Miro las etiquetas a, img y font, e ignoro el resto. Los enlaces y las imágenes ciertamente debes mirarlos, porque contienen urls.

Probablemente podría ser más inteligente al lidiar con el html, pero no creo que valga la pena dedicarle 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 manejes 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 se filtraron. Eso es una tasa de filtrado de aproximadamente 99.75%.

Dos de los cuatro spams que me perdí se filtraron porque por casualidad usaban 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 solo por el contenido porque los encabezados son inocentes y tienen cuidado con las palabras que usan. Aun así, generalmente puedo atraparlos. Este se escabulló con una probabilidad de .88, justo debajo del umbral de .9.

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

El cuarto spam fue lo que yo 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ían terminado su página de inicio y si yo podría echarle un vistazo. (La página era por supuesto un anuncio de un sitio de pornografía).

Si los spammers tienen cuidado con los encabezados y usan una url fresca, no hay nada en el spam del futuro para que los filtros se den cuenta. 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 todo el mundo lo estaría haciendo. Si es lo suficientemente bajo, no valdrá la pena que los spammers lo envíen, y no tendremos que trabajar demasiado en filtrarlo.

Ahora para la noticia realmente impactante: durante ese mismo mes período obtuve tres falsos positivos.

De alguna manera es un alivio obtener algunos falsos positivos. Cuando escribí "Un plan para el spam" no había tenido ninguno, y no sabía cómo serían. Ahora que he tenido algunos, me alegro de encontrar 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 eran boletines de empresas de las que he comprado cosas. Nunca pedí recibirlos, por lo que técnicamente eran spam, pero los cuento como falsos positivos porque no los había estado eliminando como spam antes. La razón de que los filtros los atraparan fue que ambas empresas en enero cambiaron a proveedores 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 parecidos a spam.

El tercer falso positivo fue uno malo, sin embargo. Era de alguien en Egipto y escrito todo en mayúsculas. Esto fue un resultado directo de hacer que los tokens distingan entre mayúsculas y minúsculas; el Plan para el filtro de 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 electrónicos es difícil decir si son spam o no, y estos son los que terminas mirando cuando consigues filtros realmente ajustados. Por ejemplo, hasta ahora el filtro ha atrapado dos correos electrónicos que se enviaron a mi dirección debido a un error de escritura, y uno que se me envió con la creencia de que yo era otra persona. Técnicamente, estos no son ni mi spam ni mi correo no deseado.

Otro falso positivo fue de un vicepresidente de Virtumundo. Les escribí haciéndome pasar por 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. Técnicamente, este tampoco es un falso positivo real, sino una especie de efecto de incertidumbre de Heisenberg: solo lo obtuve porque estaba escribiendo sobre 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 .06%. Los otros dos fueron un aviso de que algo que compré estaba agotado, y un recordatorio de una fiesta de Evite.

No creo que este número se pueda confiar, 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 de error diferente de los falsos negativos. La tasa de filtrado es una medida de rendimiento. Los falsos positivos los considero más como errores. Me acerco a mejorar la tasa de filtrado como optimización, y disminuir los 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 lo hizo parecer al filtro como un spam nigeriano. Esto realmente es una especie de error. Al igual que con el html, que el correo electrónico esté todo en mayúsculas es realmente conceptualmente una característica, no una por cada palabra. Necesito manejar las mayúsculas de una manera más sofisticada.

Entonces, ¿qué hacer con este .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 una tasa intrínseca de falsos positivos del filtrado bayesiano.

Futuro

¿Qué sigue? El filtrado es un problema de optimización, y la clave de 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 arréglalo. En el filtrado, esto se traduce en: mira los spams que te pierdes y averigua qué podrías haber hecho para atraparlos.

Por ejemplo, los spammers ahora están trabajando agresivamente para evadir los filtros, y una de las cosas que están haciendo es romper y escribir mal las palabras para evitar que los filtros las reconozcan. Pero trabajar en esto no es mi primera prioridad, porque todavía 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 se filtran porque son el único tipo de oferta de ventas que se puede hacer sin usar un lenguaje de ventas. Usan el mismo vocabulario que el correo electrónico normal.

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

Probablemente me centre primero en el tipo de anuncio personal. 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 un filtrado de varias palabras para atrapar eso. Además, me doy cuenta de que tienden a repetir la url, y alguien que incluye una url en un correo legítimo no lo haría [11].

Los de externalización van a ser difíciles de atrapar. Incluso si enviaras un rastreador al sitio, no encontrarías una pistola humeante estadística. Tal vez 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 restantes fueran ofertas no solicitadas de servicios de programación por contrato desde Bulgaria, probablemente todos podríamos pasar a trabajar en otra cosa.

¿Realmente nos llevará el filtrado estadístico 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 para 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 existe una empresa llamada Assurance Systems que ejecutará su correo a través de Spamassassin y le 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, el spam de empresas como Virtumundo y Equalamail que afirman que realmente están ejecutando listas opt-in. Puede filtrarlos solo en función de 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 la mayoría de los spammers de pornografía, debería poder pasar algunos mensajes a través de los filtros a nivel de red si lo desean. (De ninguna manera el mensaje que les gustaría enviar, que es algo).

El tipo de filtros en los que soy optimista son los que calculan probabilidades basadas en el correo de cada usuario individual. Estos pueden ser mucho más efectivos, no solo en evitar los falsos positivos, sino también en filtrar: por ejemplo, encontrar la dirección de correo electrónico 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 son diferentes, hará que el bucle de optimización de los spammers, lo que los programadores llamarían su ciclo de editar-compilar-probar, sea terriblemente lento. En lugar de simplemente ajustar un spam hasta que pase a través de una copia de algún filtro que tengan 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 se lo desearía a nadie.

Notas

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

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

El primer supuesto es generalizado en la clasificación de texto. Los algoritmos que lo utilizan se llaman "bayesianos ingenuos".

El segundo supuesto lo hice porque la proporción de spam en mi correo entrante fluctuaba tanto de un día a otro (de hecho, de hora en hora) que la relación a priori general parecía inútil como predictor. Si se asume que P(spam) y P(no spam) son ambos .5, se cancelan y se pueden eliminar de la fórmula.

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

[2] Patrick Pantel y Dekang Lin. ``SpamCop-- A Spam Classification & Organization Program.'' Actas del taller AAAI-98 sobre aprendizaje para categorización de texto.

[3] Mehran Sahami, Susan Dumais, David Heckerman y Eric Horvitz. ``A Bayesian Approach to Filtering Junk E-Mail.'' Actas del taller AAAI-98 sobre aprendizaje para categorización de texto.

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

[5] Bill Yerazunis. ``Sparse Binary Polynomial Hash Message Filtering and The CRM114 Discriminator.'' Actas de la Conferencia sobre Spam de 2003.

[6] En "A Plan for Spam" usé umbrales de .99 y .01. Parece justificable usar umbrales proporcionales al tamaño de los corpus. Como ahora tengo del orden de 10,000 de cada tipo de correo, uso .9999 y .0001.

[7] Hay un defecto aquí que probablemente debería arreglar. Actualmente, cuando "Subjectfoo" se degrada a simplemente "foo", lo que eso significa es que está obteniendo las estadísticas de las ocurrencias de "foo" en el cuerpo o las líneas de encabezado que no marco. Lo que debería hacer es hacer un seguimiento de las estadísticas de "foo" en general, así como de versiones específicas, y degradar de "Subjectfoo" no a "foo" sino a "Anywhere*foo". Lo mismo para mayúsculas: debería degradar de mayúsculas a cualquier mayúscula, no a minúsculas.

Probablemente sería una mejora hacer esto con los precios también, por ejemplo, degradar de "$129.99" a "$--9.99", "$--.99", y "$--".

También podrías degradar 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 debemos recordar esto al comparar técnicas para detener el spam. Mientras que muchos de los falsos positivos causados por los filtros serán casi spam que no le importaría perder, los falsos positivos causados por las listas negras, por ejemplo, serán solo correo de personas que eligieron el proveedor de servicios de Internet equivocado. En ambos casos se captura el correo que está 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 ocultando tokens como para que esto sea un problema, podemos responder simplemente eliminando espacios en blanco, puntos, comas, etc. y usando un diccionario para extraer las palabras de la secuencia resultante. Y por supuesto, encontrar palabras de esta manera que no fueran visibles en el texto original sería en sí mismo una evidencia de spam.

Extraer las palabras no será trivial. Requerirá más que simplemente reconstruir los límites de las palabras; los spammers tanto agregan ("xHot nPorn cSite") como omiten ("P#rn") letras. La investigación sobre 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 correos no deseados son más repetitivos que los correos electrónicos regulares. Quieren martillar ese mensaje. Actualmente no permito duplicados en los 15 tokens principales, porque podrías obtener un falso positivo si el remitente usa algunas palabras malas varias veces. (En mi filtro actual, ``dick'' tiene una probabilidad de spam de .9999, pero también es un nombre). Parece que al menos deberíamos notar la duplicación, así que puedo intentar permitir hasta dos de cada token, como hace Brian Burton en SpamProbe.

[12] Esto es en lo que se degenerarán los 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 estar trabajando en el filtrado a nivel de red, porque es más eficiente. Lo que la gente generalmente quiere decir cuando dicen esto es: actualmente filtramos a nivel de red, y no queremos volver a 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 el diseño de software. La gente solo tiende a usarlos para justificar elecciones (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 de nuevo por la mayor parte de la infraestructura en 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