MEJOR FILTRADO BAYESIANO

Enero de 2003

(Este artículo se presentó como 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 la 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 "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 me enteré de este trabajo me sorprendí un poco. Si la gente ya conocía el filtrado bayesiano hace cuatro años, ¿por qué no lo usaba todo el mundo? Cuando leí los artículos descubrí por qué. El filtro de Pantel y Lin era el más eficaz de los dos, pero solo detectaba el 92% del correo basura, 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 pueden producir conclusiones opuestas. 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 un 99,5 % con menos del 0,03 % de falsos positivos significa que sí lo es.

Entonces, ¿por qué obtuvimos cifras 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 de ellas es que entrenaron su filtro con muy pocos datos: 160 mensajes spam y 466 mensajes no spam. El rendimiento del filtro debería seguir aumentando con conjuntos de datos tan pequeños. Por lo tanto, sus números pueden no ser ni siquiera una medida precisa del rendimiento de su algoritmo, y mucho menos del filtrado bayesiano de spam en general.

Pero creo que la diferencia más importante es probablemente que ignoraban los encabezados de los mensajes. A cualquiera que haya trabajado en filtros de spam le 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. En ese momento no sabía mucho sobre encabezados de correo y me parecían llenos de cosas aleatorias. Aquí hay una lección para los escritores de filtros: no ignoren 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 derivaron los tokens, es decir, redujeron, por ejemplo, tanto mailing'' and mailed'' a la raíz ``mail''. Es posible que se sintieran obligados a hacer esto debido al pequeño tamaño de su corpus, pero, de ser así, se trata de una especie de optimización prematura.

En cuarto lugar, calcularon las probabilidades de forma diferente. Utilizaron todos los tokens, mientras que yo solo utilizo los 15 más significativos. Si utilizas todos los tokens, tenderás a pasar por alto spams más largos, del tipo en el que alguien te cuenta la historia de su vida hasta el punto en el que se hizo rico gracias a algún esquema de marketing multinivel. Y un algoritmo de este tipo sería fácil de falsificar para los spammers: basta con añadir un gran fragmento de texto aleatorio para contrarrestar los términos del spam.

Por último, no se sesgaron los falsos positivos. Creo que cualquier algoritmo de filtrado de spam debería tener una perilla conveniente que se pueda girar para disminuir la tasa de falsos positivos a expensas de la tasa de filtrado. Lo hago contando el doble de veces las ocurrencias de tokens en el corpus que no es spam.

No creo que sea una buena idea tratar el filtrado de spam como un problema de clasificación de texto. Se pueden utilizar 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 se los debe tratar como un tipo diferente de error. Y la fuente del error no es solo una variación aleatoria, sino un spammer humano en vivo que trabaja activamente para vencer el filtro.

Fichas

Otro proyecto del que me enteré después del artículo de Slashdot fue el CRM114 de Bill Yerazunis [5]. Este es el contraejemplo del principio de diseño que acabo de mencionar. Es un clasificador de texto puro, pero tan increíblemente eficaz que consigue filtrar el correo basura casi a la perfección sin siquiera saber que lo está haciendo.

Una vez que comprendí cómo funcionaba CRM114, me pareció inevitable que, en algún momento, tendría que pasar del filtrado 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, hasta dónde puedo llegar.

Principalmente he estado trabajando en una tokenización más inteligente. En el caso del spam actual, he podido lograr índices de filtrado que se acercan a los 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" utiliza 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 y minúsculas.

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

El caso se conserva.

Los signos de exclamación son caracteres constituyentes.

Los puntos y las comas son constituyentes si aparecen 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 aparecen dentro de las líneas Para, Desde, Asunto y Ruta de retorno, o dentro de las URL, se marcan como corresponde. Por ejemplo, foo'' in the Subject line becomes Asunto*foo''. (El asterisco puede ser cualquier carácter que no permita como constituyente).

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

A continuación se presentan algunas de las probabilidades actuales [6]:

Asunto GRATIS 0,9999 ¡gratis! 0,9999 Hasta gratis 0,9998 Asunto gratis 0,9782 ¡gratis! 0,9199 Gratis 0,9198 Url gratis 0,9091 GRATIS 0,8747 Desde*gratis 0,7636 gratis 0,6546

En el plan de filtrado de 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 posibilidades de errores. Distribuir el corpus en más tokens tiene el mismo efecto que hacerlo más pequeño. Si consideramos los signos de exclamación como constituyentes, por ejemplo, entonces podríamos terminar sin tener una probabilidad de spam para un free con siete signos de exclamación, aunque sepamos que un free con solo dos signos de exclamación tiene una probabilidad del 99,99%.

Una solución a esto es lo que yo llamo degeneración. Si no puede encontrar una coincidencia exacta para un token, trátelo como si fuera una versión menos específica. Considero que los signos de exclamación terminales, las letras mayúsculas y la aparición 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!'', I look for probabilities for Subject*free'', free!'', and free'', y tomo la que esté más alejada de 0,5.

Estas son las alternativas [7] que se consideran si el filtro ve ``¡GRATIS!'' en la línea de Asunto y no tiene probabilidad de hacerlo.

Sujeto ¡Libre ! Sujeto ¡Libre! Sujeto ¡Libre! Sujeto ¡Libre ! Sujeto GRATIS Sujeto Gratis Sujeto gratis ¡GRATIS! ¡Gratis ...

Si haces esto, asegúrate de considerar las versiones con mayúscula inicial, así como todas en mayúsculas y todas en minúsculas. Los spam suelen tener más oraciones en modo imperativo y en ellas la primera palabra es un verbo. Por lo tanto, los verbos con mayúscula inicial tienen mayores probabilidades de ser spam que si estuvieran todos en minúsculas. En mi filtro, la probabilidad de spam de Act'' is 98% and for act'' solo del 62%.

Si aumentas el vocabulario de tu filtro, puedes terminar contando la misma palabra varias veces, según tu antigua definición de "mismo". Lógicamente, ya no son el mismo token. Pero si esto todavía te molesta, déjame agregar por experiencia que las palabras que pareces estar contando varias veces tienden a ser exactamente las que querrías contar.

Otro efecto de un vocabulario más amplio es que cuando se mira un correo entrante se encuentran más tokens interesantes, es decir, aquellos con probabilidades que se alejan del 0,5. Utilizo los 15 más interesantes para decidir si el correo es spam. Pero se puede encontrar un problema cuando se utiliza un número fijo como este. Si se encuentran muchos tokens de máximo interés, el resultado puede acabar siendo decidido por cualquier factor aleatorio que determine el orden de los tokens igualmente interesantes. Una forma de lidiar con esto es tratar a algunos como más interesantes que otros.

Por ejemplo, el token dalco'' occurs 3 times in my spam corpus and never in my legitimate corpus. The token Url*optmails'' (que significa ``optmails'' dentro de una URL) aparece 1223 veces. Y, sin embargo, como solía calcular las probabilidades de los tokens, ambos tendrían la misma probabilidad de spam, el umbral de 0,99.

Eso no parece correcto. Existen 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 aparecen en un corpus o en el otro, deberíamos dar prioridad a los que aparecen con mucha frecuencia. Así que ahora hay dos valores de umbral. Para los tokens que aparecen solo en el corpus de spam, la probabilidad es de 0,9999 si aparecen más de 10 veces y de 0,9998 en caso contrario. Lo mismo ocurre en el otro extremo de la escala para los tokens que se encuentran solo en el corpus legítimo.

Es posible que más adelante escale sustancialmente las probabilidades de los tokens, pero esta pequeña cantidad de escala al menos garantiza que los tokens se ordenen de la manera correcta.

Otra posibilidad sería considerar no sólo 15 tokens, sino todos los tokens que superen un cierto umbral de interés. Steven Hauser hace esto en su filtro de spam estadístico [8]. Si utiliza un umbral, hágalo muy alto, o los spammers podrían engañarlo llenando los mensajes con palabras más inocentes.

Por último, ¿qué se debe hacer con el código HTML? He probado todo el espectro de opciones, desde ignorarlo hasta analizarlo por completo. Ignorar el código HTML es una mala idea, porque está lleno de señales útiles de spam. Pero si lo analizas por completo, tu filtro puede degenerar en un mero reconocedor de HTML. El enfoque más eficaz parece ser el término medio, notar algunos tokens pero no otros. Miro las etiquetas a, img y font e ignoro el resto. Los enlaces y las imágenes sin duda deberías mirarlos, porque contienen URL.

Probablemente podría ser más inteligente en cuanto al manejo del HTML, pero no creo que valga la pena dedicarle mucho tiempo. El spam lleno de HTML es fácil de filtrar. Los spammers más inteligentes ya lo evitan. Por lo tanto, el rendimiento en el futuro no debería depender mucho de cómo se maneje el HTML.

Actuación

Entre el 10 de diciembre de 2002 y el 10 de enero de 2003 recibí unos 1750 mensajes de spam, de los cuales 4 lograron pasar, lo que supone una tasa de filtrado de aproximadamente el 99,75 %.

Dos de los cuatro mensajes de spam que no entré se enviaron porque usaban palabras que aparecen a menudo en mi correo electrónico legítimo.

El tercero era uno de esos que explotan un script cgi inseguro para enviar correo a terceros. Son difíciles de filtrar basándose únicamente en el contenido porque los encabezados son inocentes y tienen cuidado con las palabras que usan. Aun así, normalmente puedo atraparlos. Este pasó con una probabilidad de 0,88, justo por debajo del umbral de 0,9.

Por supuesto, si se observan múltiples secuencias de tokens, se detectará fácilmente. “A continuación se muestra el resultado de su formulario de comentarios” es una pista instantánea.

El cuarto spam era lo que yo llamo spam del futuro, porque es en lo que espero que se convierta el spam: un texto completamente neutro seguido de una URL. En este caso, se trataba de alguien que decía que finalmente había terminado su página de inicio y me preguntaba si podía ir a verla (la página era, por supuesto, un anuncio de un sitio pornográfico).

Si los spammers tienen cuidado con los encabezados y utilizan una URL nueva, no habrá nada en el spam del futuro que los filtros puedan detectar. Por supuesto, podemos contrarrestarlo enviando un rastreador para que revise la página, pero eso puede no ser necesario. La tasa de respuesta para el spam del futuro debe ser baja, o todo el mundo lo haría. Si es lo suficientemente baja, a los spammers no les resultará rentable enviarlo y no tendremos que esforzarnos demasiado para filtrarlo.

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

En cierto modo, es un alivio recibir algunos falsos positivos. Cuando escribí "Un plan para el spam" no había recibido ninguno y no sabía cómo serían. Ahora que he recibido unos cuantos, me alivia saber que no son tan malos como temía. Los falsos positivos que generan los filtros estadísticos resultan ser correos que suenan muy parecidos al spam y estos tienden a ser los que menos te importaría pasar por alto [9].

Dos de los falsos positivos eran boletines de empresas a las que les había comprado cosas. Nunca solicité recibirlos, por lo que podría decirse que eran spam, pero los cuento como falsos positivos porque no los había eliminado como spam antes. La razón por la que los filtros los detectaron 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 spam.

Sin embargo, el tercer falso positivo fue bastante malo. Procedía de alguien de Egipto y estaba escrito en mayúsculas. Esto fue el resultado directo de hacer que los tokens distingan entre mayúsculas y minúsculas; el filtro de Plan para correo no deseado no lo habría detectado.

Es difícil decir cuál es la tasa general de falsos positivos, porque estamos en medio de un gran ruido, estadísticamente. Cualquiera que haya trabajado con filtros (al menos, filtros efectivos) estará al tanto de este problema. Con algunos correos electrónicos es difícil decir si son spam o no, y estos son los que terminas viendo cuando aplicas filtros realmente estrictos. Por ejemplo, hasta ahora el filtro ha detectado dos correos electrónicos que se enviaron a mi dirección debido a un error tipográfico, y uno que me enviaron creyendo que era otra persona. Podría decirse que estos no son ni mi correo spam ni mi correo no spam.

Otro falso positivo fue el de un vicepresidente de Virtumundo. Les escribí haciéndome pasar por cliente y, como la respuesta llegó a través de los servidores de correo de Virtumundo, tenía los encabezados más incriminatorios imaginables. Podría decirse que tampoco se trata de un falso positivo real, sino de una especie de efecto de incertidumbre de Heisenberg: solo lo recibí porque estaba escribiendo sobre el filtrado de spam.

Sin contar estos, hasta ahora he recibido un total de cinco falsos positivos, de unos 7740 correos electrónicos legítimos, lo que supone una tasa del 0,06 %. Los otros dos fueron un aviso de que algo que había comprado estaba agotado y un recordatorio de una fiesta de Evite.

No creo que se pueda confiar en este número, en parte porque la muestra es muy 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 a los falsos negativos. La tasa de filtrado es una medida del rendimiento. Considero que los falsos positivos son más bien errores. Considero que la mejora de la tasa de filtrado es una optimización y la disminución de los falsos positivos es una depuración.

Así que estos cinco falsos positivos son mi lista de errores. Por ejemplo, el correo de Egipto fue bloqueado porque el texto en mayúsculas hizo que el filtro lo viera como spam nigeriano. Esto realmente es una especie de error. Al igual que con HTML, el correo electrónico que está todo en mayúsculas es realmente conceptualmente una característica, no una para cada palabra. Necesito manejar las mayúsculas y minúsculas de una manera más sofisticada.

¿Qué podemos hacer entonces con este 0,06 %? No creo que sea mucho. Se lo podría considerar 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 la creación de perfiles. No intente adivinar dónde es lento su código, porque se equivocará. Observe dónde es lento su código y arréglelo. En el filtrado, esto se traduce en: observe el spam que no detecta y determine qué podría haber hecho para detectarlo.

Por ejemplo, los spammers ahora están trabajando agresivamente para evadir los filtros, y una de las cosas que están haciendo es dividir 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 detectar este spam [10].

Hay dos tipos de spam con los que tengo problemas actualmente. Uno es el que simula ser un correo electrónico de una mujer que te invita a chatear con ella o a ver su perfil en un sitio de citas. Estos funcionan porque son el único tipo de discurso de ventas que puedes hacer sin usar el lenguaje comercial. Utilizan el mismo vocabulario que el correo electrónico común.

El otro tipo de correo basura que tengo problemas para filtrar son los que llegan de empresas de Bulgaria, por ejemplo, que ofrecen servicios de programación por contrato. Éstos pasan porque yo también soy programador y el correo basura está lleno de las mismas palabras que mi correo real.

Probablemente me centraré 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 redacción es ciertamente diferente, aunque puede que sea necesario un filtro de múltiples palabras para detectarlo. Además, he notado que tienden a repetir la URL, y alguien que incluye una URL en un correo legítimo no lo haría [11].

Los que subcontratan van a ser difíciles de detectar. Incluso si enviaras un rastreador al sitio, no encontrarías una prueba estadística irrefutable. Tal vez la única respuesta sea una lista central de dominios anunciados en spam [12]. Pero no puede haber tantos mensajes de este tipo. Si los únicos spams que quedaran fueran ofertas no solicitadas de servicios de programación por contrato de Bulgaria, probablemente todos podríamos dedicarnos a trabajar en otra cosa.

¿Será que el filtrado estadístico nos llevará 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 burlar los filtros estadísticos. ¿Qué ocurrirá cuando lo hagan?

No soy optimista en cuanto a los filtros que funcionan a nivel de red [13]. Cuando existe un obstáculo estático que vale la pena superar, los spammers son bastante eficientes a la hora de superarlo. Ya existe una empresa llamada Assurance Systems que procesa su correo a través de Spamassassin y le dice si se filtrará.

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 en realidad están ejecutando listas opt-in. Puedes filtrarlos basándote solo en los encabezados, sin importar lo que digan en el cuerpo. Pero cualquiera que esté dispuesto a falsificar encabezados o usar retransmisiones abiertas, presumiblemente incluidos la mayoría de los spammers de pornografía, debería poder hacer que algún mensaje pase los filtros a nivel de red si así lo desea. (Aunque de ninguna manera el mensaje que les gustaría enviar, lo cual es algo).

El tipo de filtros que me parecen más optimistas son los que calculan probabilidades en función del correo de cada usuario. Estos pueden ser mucho más eficaces, no sólo para evitar falsos positivos, sino también para 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 cada uno tienen probabilidades diferentes, el ciclo de optimización de los spammers, lo que los programadores llamarían su ciclo de edición-compilación-prueba, será terriblemente lento. En lugar de simplemente ajustar un spam hasta que pase 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 deseo a nadie.

Notas

[1] Paul Graham. «Un plan para el 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 previa de que un correo electrónico sea spam.

El primer supuesto es muy común en la clasificación de textos. Los algoritmos que lo utilizan se denominan «bayesianos ingenuos».

La segunda suposición que hice se debe a que la proporción de spam en mi correo entrante fluctuaba tanto de un día para otro (de hecho, de una hora para otra) que la proporción general anterior parecía inútil como predictor. Si supone que P(spam) y P(no spam) son ambas 0,5, se cancelan y puede eliminarlas de la fórmula.

Si estuvieras aplicando un filtro bayesiano en una situación en la que la proporción de correo no deseado con respecto a correo no deseado fuera constantemente muy alta o (especialmente) muy baja, probablemente podrías mejorar el rendimiento del filtro incorporando probabilidades previas. Para hacerlo bien, tendrías que hacer un seguimiento de las proporciones por hora del día, porque tanto el volumen de correo no deseado como el de correo legítimo tienen 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 categorización de textos.

[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 categorización de texto.

[4] En ese momento no tenía ningún falso positivo entre unos 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 no son fiables, como explico más adelante. Cito aquí una cifra sólo para enfatizar que, cualquiera que sea la tasa de falsos positivos, es inferior al 1,16 %.

[5] Bill Yerazunis. «Filtrado de mensajes mediante hash polinomial binario disperso y el discriminador CRM114». Actas de la Conferencia sobre spam de 2003.

[6] En "Un plan para el spam" utilicé umbrales de 0,99 y 0,01. Parece justificable utilizar umbrales proporcionales al tamaño de los corpus. Dado que ahora tengo alrededor de 10.000 de cada tipo de correo, utilizo 0,9999 y 0,0001.

[7] Hay un fallo aquí que probablemente debería corregir. Actualmente, cuando Subject*foo'' degenerates to just foo'', lo que eso significa es que estás obteniendo las estadísticas de ocurrencias de foo'' in the body or header lines other than those I mark. What I should do is keep track of statistics for foo'' en general, así como de versiones específicas, y degenerar de Subject*foo'' not to foo'' sino a ``Anywhere*foo''. Lo mismo para mayúsculas y minúsculas: debería degenerar de mayúsculas a cualquier mayúscula y minúscula, no a minúsculas.

Probablemente sería una victoria hacer lo mismo con los precios, por ejemplo, degenerar de $129.99'' to $--9,99'', $--.99'', and $--''.

También se podría degenerar desde las palabras hasta sus raíces, pero esto probablemente sólo mejoraría las tasas de filtrado al principio, cuando se tenían corpus pequeños.

[8] Steven Hauser. «El filtro de spam estadístico funciona para mí». http://www.sofbot.com.

[9] No todos los falsos positivos son iguales, y debemos recordarlo al comparar técnicas para detener el correo no deseado. Mientras que muchos de los falsos positivos causados por los filtros serán correos casi spam que no le importaría pasar por alto, los falsos positivos causados por las listas negras, por ejemplo, serán simplemente correos de personas que eligieron el ISP equivocado. En ambos casos, se detecta correo que es casi spam, pero en el caso de las listas negras la proximidad es física y en el caso de los filtros es textual.

[10] Si los spammers se vuelven lo suficientemente buenos en ocultar tokens como 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 una prueba de spam.

Seleccionar las palabras no será una tarea fácil. Requerirá algo más que reconstruir los límites de las palabras; los spammers añaden ( xHot nPorn cSite'') and omit ( P#rn'') letras. La investigación de la visión puede ser útil en este caso, ya que la visión humana es el límite al que se acercan estos trucos.

[11] En general, los mensajes de spam son más repetitivos que los correos electrónicos normales. Quieren que el mensaje llegue a la gente. Actualmente no permito duplicados en los 15 primeros tokens, porque podrías obtener un falso positivo si el remitente usa una mala palabra varias veces. (En mi filtro actual, "dick" tiene una probabilidad de spam de 0,9999, pero también es un nombre). Sin embargo, parece que deberíamos al menos 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 degenerarán enfoques como el de Brightmail una vez que los spammers se vean obligados a utilizar técnicas mad-lib para generar todo lo demás en el mensaje.

[13] A veces se sostiene 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 se puede dictar el problema para que se ajuste a la solución.

Históricamente, los argumentos basados en la escasez de recursos han sido el bando perdedor en los debates sobre el diseño de software. La gente tiende a utilizarlos solo para justificar decisiones (en particular, la inacción) tomadas por otros motivos.

Gracias a Sarah Harlin, Trevor Blackwell y Dan Giffin por leer los borradores de este artículo, y nuevamente a Dan por la mayor parte de la infraestructura en la que se ejecuta este filtro.

Relacionado:

Asunto GRATIS 0,9999 ¡gratis! 0,9999 Hasta gratis 0,9998 Asunto gratis 0,9782 ¡gratis! 0,9199 Gratis 0,9198 Url gratis 0,9091 GRATIS 0,8747 Desde*gratis 0,7636 gratis 0,6546

Sujeto ¡Libre ! Sujeto ¡Libre! Sujeto ¡Libre! Sujeto ¡Libre ! Sujeto GRATIS Sujeto Gratis Sujeto gratis ¡GRATIS! ¡Gratis ...