MEJOR FILTRADO BAYESIANO

January 2003

(Este artículo se dio como una charla en la Conferencia de Spam de 2003. Describe el trabajo que he realizado para mejorar el rendimiento de el 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 documentos de investigación. Simplemente escribe lo que quieras y no cites ningún trabajo anterior, y los lectores indignados te enviarán referencias a todos los trabajos que deberías haber citado. Descubrí este algoritmo después de que ``Un plan para el spam'' [1] estuviera en Slashdot.

El filtrado de spam es un subconjunto de la clasificación de texto, que es un campo bien establecido, pero los primeros trabajos sobre el filtrado de spam bayesiano per se parecen haber sido dos dados 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 sorprendió un poco. Si la gente había estado en el filtrado bayesiano hace cuatro años, ¿por qué no lo estaba usando todo el mundo? Cuando leí los trabajos descubrí por qué. El filtro de Pantel y Lin fue el más efectivo de los dos, pero solo atrapó 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 hacen el mismo experimento obtienen resultados muy diferentes. 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 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 documento veo cinco cosas que probablemente explican la diferencia.

Una es simplemente que entrenaron su filtro con muy poca información: 160 correos electrónicos de spam y 466 correos electrónicos no spam. El rendimiento del filtro todavía debería estar aumentando con información conjuntos tan pequeños. Entonces, sus números pueden no ser ni siquiera una medida precisa del rendimiento de su algoritmo, y mucho menos de 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, ignoré los encabezados también. ¿Por qué? Porque quería mantener el problema ordenado. No sabía mucho sobre los encabezados de correo electrónico entonces, y me parecían llenos de cosas aleatorias. Hay una lección aquí para el filtro escritores: no ignores los datos. Podrías pensar que esta lección sería demasiado obvio para mencionarlo, pero he tenido que aprenderlo varias veces.

Tercero, Pantel y Lin realizaron la extracción de la raíz de los tokens, lo que significa que redujeron p. ej. tanto correo electrónico'' como correo electrónico'' a la raíz ``correo''. Ellos pueden han sentido que se vieron obligados a hacer esto por el pequeño tamaño de su corpus, pero si es así, este es un tipo de optimización prematura.

Cuarto, 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 tiendes a perder los spams más largos, el tipo donde alguien te cuenta su vida historia hasta el punto en que se hizo rico con algún esquema de marketing multinivel plan. Y tal algoritmo sería fácil para los spammers de engañar: simplemente agrega un gran trozo de texto aleatorio para contrarrestar los términos de spam.

Finalmente, no se inclinaron contra los falsos positivos. Creo que cualquier algoritmo de filtrado de spam debería tener un práctico mando que puedes 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 no spam 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 el 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 que debes tratarlos como un tipo diferente de error. Y la fuente del 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 escuché 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 uno tan asombrosamente efectivo que logra filtrar spam casi perfectamente sin siquiera saber que es lo que está haciendo.

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

Mayormente he estado trabajando en una tokenización más inteligente. En el spam actual, he podido alcanzar 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'' utiliza un simple definición de un token. Las letras, dígitos, guiones, apóstrofes, y los 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 conserva el caso.

Los signos de exclamación son caracteres constitutivos.

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 produce dos tokens, $20 y $25.

Los tokens que ocurren dentro del líneas To, From, Subject y Return-Path, o dentro de las URL, están marcados en consecuencia. Por ejemplo, foo'' en la línea Subject se convierte en Subject*foo''. (El asterisco podría ser cualquier carácter que no permita como constituyente).

Tales medidas aumentan el vocabulario del filtro, que lo hace más discriminatorio. Por ejemplo, en el actual filtro, ``gratis'' en la línea Subject 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í están 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 el 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 fallas. Extender tu corpus sobre más tokens tiene el mismo efecto que hacerlo más pequeño. Si consideras los signos de exclamación como constituyentes, por ejemplo, podrías terminar sin tener una probabilidad de spam para gratis con siete signos de exclamación puntos, aunque sepas que gratis con solo dos signos de exclamación tiene una probabilidad de 99,99%.

Una solución a esto es lo que llamo degeneración. Si usted no puede encontrar una coincidencia exacta para un token, trata como si fuera una menos específica versión. Considero los signos de exclamación terminales puntos, letras mayúsculas y que ocurran en una de las cinco contextos marcados como para hacer un token más específico. Por ejemplo, si no encuentro una probabilidad para Subject*free!'', busco probabilidades para Subject*free'', free!'', y free'', y tomo cualquiera que esté más lejos de .5.

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

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 iniciales mayúsculas, así como todas las mayúsculas y todas las minúsculas. Los spams tienden a tener más oraciones en modo imperativo, y en esos, la primera palabra es un verbo. Entonces los verbos con iniciales mayúsculas tienen mayores probabilidades de spam que en todas 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 varias veces, de acuerdo con tu antigua definición de ``mismo''. Lógicamente, no son el mismo token ya. Pero si esto todavía te molesta, déjame añadir por experiencia que las palabras que parece que eres contando varias veces tienden a ser exactamente las que tú quisiera.

Otro efecto de un vocabulario más amplio es que cuando tú mira un correo entrante, encuentra más tokens interesantes, es decir, aquellos con probabilidades lejos de .5. Yo uso los 15 más interesantes para decidir si el correo electrónico es spam. Pero puedes encontrarte con un problema cuando utilizas un número fijo como este. Si encuentra muchos tokens de interés máximo, el resultado puede terminar siendo decidido por cualquier factor aleatorio que determina 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'' aparece 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) aparece 1223 veces. Y sin embargo, 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 teóricos argumentos para dar a estos dos tokens sustancialmente diferentes probabilidades (Pantel y Lin lo hacen), pero aún no lo he probado. Parece al menos que si encontramos más de 15 tokens que solo aparecen en un corpus u otro, debemos dar prioridad a los que aparecen mucho. Entonces ahora hay dos valores de umbral. Para los tokens que solo ocurren en el corpus de spam, la probabilidad es .9999 si ocurren más de 10 veces y .9998 de lo contrario. Idéntico en el otro extremo de la escala para tokens encontrados solo en el corpus legítimo.

Es posible que luego escale las probabilidades de los tokens sustancialmente, pero esta pequeña cantidad de escalado al menos garantiza que los tokens se ordenen correctamente.

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 utilizas un umbral, hazlo muy alto, o los spammers podrían engañarte empaquetando mensajes con más palabras inocentes.

Finalmente, ¿qué se debe hacer sobre el html? He probado todo el espectro de opciones, desde ignorarlo a analizarlo todo. Ignorar el html es una mala idea, porque está lleno de signos de spam útiles. Pero si 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, e ignoro el resto. Los enlaces y las imágenes que sin duda debes mirar, porque contienen URLs.

Probablemente podría ser más inteligente con respecto al manejo del html, pero no creo que valga la pena dedicar mucho tiempo a esto. Los spams llenos de html son fáciles de filtrar. Los más inteligentes spammers ya lo evitan. Entonces el rendimiento en el futuro no debería depender mucho de cómo trates con 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. Esa es una tasa de filtrado de aproximadamente 99,75%.

Dos de los cuatro spams que perdí se filtraron porque ocurrieron al usar palabras que aparecen con frecuencia en mi legítima correo electrónico.

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

Por supuesto, mirando varias secuencias de tokens lo atraparía fácilmente. ``A continuación se muestra el resultado de su formulario de comentarios'' es una entrega instantánea.

El cuarto spam fue lo que llamo un spam-del-futuro, porque esto es lo que espero que el spam evolucionar a: algo completamente neutral texto seguido de una url. En este caso, fue de alguien diciendo que finalmente había terminado su página de inicio y si yo iría a mirarlo. (La página era por supuesto un anuncio para un sitio porno.)

Si los spammers tienen cuidado con los encabezados y utilizan un URL nuevo, no hay nada en el spam-del-futuro para que los filtros notar. Por supuesto, podemos contrarrestarlo enviando un rastreador para mirar la página. Pero eso podría no ser necesario. La tasa de respuesta para spam-del-futuro debe ser bajo, o todos lo estarían haciendo. Si es lo suficientemente bajo, lo no valdrá la pena para los spammers enviarlo, y nosotros no tendremos que trabajar demasiado en filtrarlo.

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

En cierto modo, 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 como. Ahora que he tenido algunos, me alivia encontrar que no son tan malos como temía. Los falsos positivos producidos por estadísticas los filtros resultan ser correos electrónicos que suenan mucho a spam, y estos tienden a ser los que menos te importarían perder [9].

Dos de los falsos positivos fueron boletines informativos de empresas de las que he comprado cosas. Nunca pedí recibirlos, por lo que podría decirse que eran spams, 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 cambió 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.

El tercer falso positivo fue malo, sin embargo. Fue de alguien en Egipto y escrito todo en mayúsculas. Esto fue un resultado directo de hacer que los tokens sean sensibles al caso; el Plan el filtro de spam no lo habría detectado.

Es difícil decir cuál es la tasa general de falsos positivos, porque estamos en el ruido, estadísticamente. Cualquiera que haya trabajado con filtros (al menos, filtros efectivos) será consciente de este problema. Con algunos correos electrónicos es difícil saber si son spam o no, y estos son los que terminas viendo cuando tienes filtros realmente apretado. Por ejemplo, hasta ahora el filtro ha atrapó dos correos electrónicos que fueron enviados a mi dirección porque de una errata, y uno que me fue enviado en la creencia de que yo era alguien más. Podría decirse que estos no son mi spam ni mi correo no spam.

Otro falso positivo fue de un vicepresidente de Virtumundo. Les escribí fingiendo ser un cliente, y como la respuesta regresó a través de Virtumundo's servidores de correo electrónico, tenía lo más incriminatorio encabezados imaginables. Podría decirse que este no es un verdadero falso positivo tampoco, sino una especie de incertidumbre de Heisenberg efecto: solo lo obtuve porque estaba escribiendo sobre spam filtrado.

Sin contar estos, he tenido un total de cinco falsos positivos hasta ahora, de alrededor de 7740 correos electrónicos legítimos, una tasa del 0,06%. Los otros dos fueron un aviso de que algo que compré fue reservado, y un recordatorio de 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 diferente de error que los falsos negativos. La tasa de filtrado es una medida de rendimiento. Falso los positivos los considero más como errores. Me acerco a mejorar la tasa de filtrado como optimización, y disminuyendo los falsos positivos como depuración.

Entonces estos cinco falsos positivos son mi lista de errores. Por ejemplo, el correo electrónico de Egipto fue clavado porque el texto en mayúsculas lo hizo parecer al filtro un spam nigeriano. Esto realmente es un tipo de error. Como con html, el correo electrónico está todo en mayúsculas es realmente conceptualmente uno característica, no una para cada palabra. Necesito manejar el caso en un forma más sofisticada.

Entonces, ¿qué podemos decir de este 0,06%? No mucho, creo. Puedes tratarlo como un límite superior, teniendo en cuenta el tamaño pequeño de la muestra. Pero en esta etapa es más una medida de los errores en mi implementación que alguna 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 es lento tu código, porque adivinarás mal. Mira dónde es lento tu código, 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 los filtros, y una de las cosas que están haciendo es romper y deletrear mal las palabras para evitar que los filtros los reconozca. 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 pretende ser un correo electrónico de una mujer que te invita a chatear con ella o ver su perfil en un sitio de citas sitio. Estos se filtran porque son el único tipo de presentación de ventas que puedes hacer sin usar un discurso 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 p. ej. Bulgaria ofreciendo servicios de programación de contratos. Estos se filtran porque yo también soy programador, y los spams están llenos de las mismas palabras que mi correo real.

Probablemente me enfocaré 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 sin duda diferente, aunque puede que se requiera un filtrado de varias palabras para atrapar eso. Además, noto que tienden a repetir la url, y alguien que incluye una url en un correo electrónico legítimo no haría eso [11].

Los del tipo de subcontratación van a ser difíciles de atrapar. Incluso si enviaste un rastreador al sitio, no encontrarías un humo pistola estadística. Tal vez la única respuesta es una lista central de dominios anunciados en spams [12]. Pero no puede haber eso muchos de este tipo de correo. Si lo único los spams que quedaban eran ofertas no solicitadas de servicios de programación de contratos de Bulgaria, probablemente todos podríamos pasar a trabajar en algo más.

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

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

Los filtros de nivel de red no serán completamente inútiles. Pueden ser suficientes para matar a todos los "opt-in" spam, es decir, spam de empresas como Virtumundo y Equalamail que afirman que realmente están ejecutando listas de opt-in. Puedes filtrar esos solo en función de los encabezados, no importa lo que digan en el cuerpo. Pero cualquiera dispuesto a falsear encabezados o utilizar retransmisiones abiertas, presumiblemente incluyendo la mayoría de los spammers de pornografía, deberían poder pasar algún mensaje los filtros de nivel de red si lo desean. (De ninguna manera el mensaje que les gustaría enviar, que es algo.)

El tipo de filtros con los que soy optimista son aquellos que calcular 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 electrónico del destinatario codificada en base 64 en cualquier lugar en un mensaje es un muy buen indicador de spam.

Pero la verdadera ventaja de los filtros individuales es que todos serán diferente. Si todos los filtros 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, terriblemente lento. En lugar de simplemente ajustar un spam hasta que se filtre una copia de algún filtro que tienen en su escritorio, tendrán que hacer un correo de prueba para cada ajuste. Sería como programar en un idioma sin un tope interactivo, y no se lo desearía a nadie.

Notas

[1] Paul Graham. ``Un plan para el spam.'' Agosto de 2002. http://paulgraham.com/spam.html.

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

La primera suposición es muy extendida en la clasificación de texto. Los algoritmos que lo utilizan se denominan ``bayesiano ingenuo''.

La segunda suposición que hice porque la proporción de spam en mi correo electrónico entrante fluctuó tanto de un día a otro (de hecho, de hora en hora) que la proporción previa general pareció inútil como predictor. Si asumes que P(spam) y P(no spam) son ambos .5, se cancelan y puedes quítelos de la fórmula.

Si hicieras filtrado bayesiano en una situación donde la proporción de spam a no spam fue consistentemente muy alta o (especialmente) muy bajo, probablemente podrías mejorar el filtro rendimiento incorporando probabilidades previas. Para hacer esto correctamente, tendrías que hacer un seguimiento de las proporciones por hora del día, porque el volumen de spam y correo legítimo ambos tienen patrones diarios distintos.

[2] Patrick Pantel y Dekang Lin. ``SpamCop-- Un programa de clasificación y organización de spam.'' Actas de AAAI-98 Taller sobre Aprendizaje para la Categorización de Texto.

[3] Mehran Sahami, Susan Dumais, David Heckerman y Eric Horvitz. ``Un enfoque bayesiano para filtrar correo electrónico basura.'' Actas de AAAI-98 Taller sobre Aprendizaje para la Categorización de Texto.

[4] En ese momento no 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 no son confiables, como explico más adelante. Cito un número aquí solo para enfatizar que cualquiera que sea la tasa de falsos positivos es, es menor que 1.16%.

[5] Bill Yerazunis. ``Filtrado de mensajes hash polinomiales binarios dispersos y el discriminador CRM114.'' Actas de 2003 Conferencia de Spam.

[6] En ``Un plan para el spam'' utilicé umbrales de .99 y .01. Parece justificable utilizar umbrales proporcionales al tamaño de los corpora. Como ahora tengo del orden de 10.000 de cada tipo de correo electrónico, utilizo .9999 y .0001.

[7] Hay un error aquí que probablemente debería corregir. Actualmente, cuando Subject*foo'' se degenera a solo foo'', lo que eso significa es que estás obteniendo las estadísticas para las apariciones de foo'' en el cuerpo o encabezados distintos de los 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''. Idéntico para el caso: debo degenerar de mayúscula a cualquier caso, no minúsculas.

Probablemente sería una ganancia hacer esto con los precios también, p. ej. degenerar de $129.99'' a $--9.99'', $--.99'', y $--''.

También podrías degenerar de las palabras a sus raíces, pero esto probablemente solo mejoraría las tasas de filtrado al principio cuando tenías corpora 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 spams que no te importaría perder, los falsos positivos causados por las listas negras, por ejemplo, serán solo correo electrónico de personas que eligieron el ISP incorrecto. En ambos casos capturas correo electrónico 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 en oscurecer los tokens para que esto sea un problema, podemos responder simplemente eliminando espacios en blanco, puntos, comas, etc. y utilizando 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 evidencia de spam.

Extraer 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 de la visión puede ser útil aquí, ya que la visión humana es el límite al que se acercarán tales trucos.

[11] En general, los spams son más repetitivos que el correo electrónico normal. Quieren grabar ese mensaje. Actualmente, no permito duplicados en los 15 mejores tokens, porque podrías obtener un falso positivo si el remitente ocurre al usar alguna palabra mala 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, por lo que puedo intentar permitir hasta dos de cada token, como Brian Burton hace en SpamProbe.

[12] Esto es lo que los enfoques como el de Brightmail's degenerarán una vez que los spammers sean obligados a usar técnicas de libro de palabras para generar todo lo demás en el mensaje.

[13] A veces se argumenta que debemos trabajar en el filtrado en el nivel de red, porque es más eficiente. Lo que la gente generalmente significa cuando dicen esto es: actualmente filtramos en el nivel de red, y no queremos empezar de nuevo desde cero. Pero no puedes dictar el problema para que se ajuste a tu solución.

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

Gracias a Sarah Harlin, Trevor Blackwell, y Dan Giffin por leer borradores de este trabajo, y a Dan de nuevo por la mayoría 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