Tu idea de aplicar los filtros bayesianos en el servidor es bastante interesante. Los que yo veo son los siguientes:
1. Los filtros bayesianos tienen la particularidad de que tienen una primera etapa en la que hay que "educarlos". Y es aquí precisamente donde radica su utilidad, ya que al entrenarlos a distinguir SPAM del correo legítimo, se está jugando mucho con el tipo de correos que suele recibir un cliente particular. Si por ejemplo yo soy abogado y recibo mucho correo legal donde hay un registro del lenguaje determinado, los filtros se configuran de una forma diferente de lo que se le podría configurar a otra persona. Por eso combinar esta información entre todos los correos que llegan al servidor, podría originar una poca efectividad a la hora de la detección.
2. El segundo problema es consecuencia de la naturaleza de los filtros bayesianos (no sobre su aplicación en el servidor). A mí, en concreto usando el filtro bayesiano de Mozilla, me suele ocurrir que al educar al programa de correo, como la mayoría de los e-mails legítimos que recibo son en español y la mayoría del SPAM es en inglés, se empieza a formar, como si dijeramos, una separación entre las bases de datos de palabras: las que obtienen más probabilidad de ser SPAM son las inglesas y las otras las españolas. De esta manera, si alguna vez me llegaba un correo en inglés (o uno en español con un adjunto de texto en inglés) siempre me lo detectaba como SPAM. Esto es un problema bastante grave que da este filtro.
Yo tampoco confío en estos filtros como posibles soluciones. No hay recetas milagrosas. Yo soy más de la opinión de efectuar unos grandes servidores con bases de datos que almacenen correos electrónicos que YA han sido identificados como SPAM, pero no por filtros de cliente o de servidor, sino por los propios usuarios del correo. Es decir, que para eso los clientes de correo deberían implementar un servicio de envío de los correos que calificamos de SPAM, a otros servicios que se enargarían de este almacenamiento. Lo que ocurriría entonces es que los servidores de correo, al recibir un mensaje, lo enviarían a estos servicios de grandes bases de datos de SPAM para que comprueben si el correo ha sido notificado o no.
Esto tiene la desventaja de que un mensaje determinado de un spammer necesitaría ser recibido por cierto número de usuarios (sin poderlo evitar) antes de que fuera clasificado en la base de datos. Pero se ahorraría el recibirlo a muchos otros usuarios. A lo mejor estamos hablando de una reducción total del 95% de los correos (sin recibirlos en el cliente, es decir, sin generar tráfico, y sin usar filtros de IP's ni listas negras ni filtros bayesianos...).
Por eso combinar esta información entre todos los correos que llegan al servidor, podría originar una poca efectividad a la hora de la detección.
No es lo que tenía pensado. Evidentemente el programa servidor SMTP tiene que incorporar código para rechazar mensajes. Pero eso no quita para que tire de bases de datos alimentadas por cada usuario.
como la mayoría de los e-mails legítimos que recibo son en español y la mayoría del SPAM es en inglés, se empieza a formar, como si dijeramos, una separación entre las bases de datos de palabras...
Eso es un problema diferente y que también tiene solución sencilla.
En cualquier caso, ten en cuenta que con un sistema que genere errores de protocolo, los falsos positivos dejan de ser un grave problema para convertirse en una simple molestia. El remitente sabe que el envío ha fallado y puede buscar medios alternativos de comunicación.
un mensaje determinado de un spammer
necesitaría ser recibido por cierto número de
usuarios (sin poderlo evitar) antes de que
fuera clasificado en la base de datos
En realidad no es necesario que alguien lo reciba. Con que lo reciba una dirección spamtrap es suficiente. Lo que describes ya se ha hecho, por ejemplo con el Distributed Checksum Clearinghouse [rhyolite.com].
Lo que para mí está claro es que mientras
los filtros no sean fiables al 100% siempre
tendrás que andar rebuscando en la basura, no
sea que se te haya colado un "falso positivo".
Y puestos a escarbar en la basura, mejor hacerlo
en una carpeta de 100 mensajes que en una de 200.
Por eso soy partidario de las listas de bloqueo
por DNS para librarse por lo menos de una parte del spam (aquella que solamente por el IP
de procedencia sabemos que es spam con un 99,95%
de probabilidad), y si alguien por ejemplo se empeña en mandarte un mensaje desde un relay abierto, pues que se busque un poco
la vida y encuentre un servidor SMTP que no lo sea para enviarte su mensaje. No debería ser
tan difícil.
Si alguien le interesan listas de bloqueo
por DNS que sean buenas, bonitas y baratas,
recomiendo:
Re:Hay solución, pero no ésa
(Puntos:5, Interesante)( http://knocte.blogspot.com/ )
1. Los filtros bayesianos tienen la particularidad de que tienen una primera etapa en la que hay que "educarlos". Y es aquí precisamente donde radica su utilidad, ya que al entrenarlos a distinguir SPAM del correo legítimo, se está jugando mucho con el tipo de correos que suele recibir un cliente particular. Si por ejemplo yo soy abogado y recibo mucho correo legal donde hay un registro del lenguaje determinado, los filtros se configuran de una forma diferente de lo que se le podría configurar a otra persona. Por eso combinar esta información entre todos los correos que llegan al servidor, podría originar una poca efectividad a la hora de la detección.
2. El segundo problema es consecuencia de la naturaleza de los filtros bayesianos (no sobre su aplicación en el servidor). A mí, en concreto usando el filtro bayesiano de Mozilla, me suele ocurrir que al educar al programa de correo, como la mayoría de los e-mails legítimos que recibo son en español y la mayoría del SPAM es en inglés, se empieza a formar, como si dijeramos, una separación entre las bases de datos de palabras: las que obtienen más probabilidad de ser SPAM son las inglesas y las otras las españolas. De esta manera, si alguna vez me llegaba un correo en inglés (o uno en español con un adjunto de texto en inglés) siempre me lo detectaba como SPAM. Esto es un problema bastante grave que da este filtro.
Yo tampoco confío en estos filtros como posibles soluciones. No hay recetas milagrosas. Yo soy más de la opinión de efectuar unos grandes servidores con bases de datos que almacenen correos electrónicos que YA han sido identificados como SPAM, pero no por filtros de cliente o de servidor, sino por los propios usuarios del correo. Es decir, que para eso los clientes de correo deberían implementar un servicio de envío de los correos que calificamos de SPAM, a otros servicios que se enargarían de este almacenamiento. Lo que ocurriría entonces es que los servidores de correo, al recibir un mensaje, lo enviarían a estos servicios de grandes bases de datos de SPAM para que comprueben si el correo ha sido notificado o no.
Esto tiene la desventaja de que un mensaje determinado de un spammer necesitaría ser recibido por cierto número de usuarios (sin poderlo evitar) antes de que fuera clasificado en la base de datos. Pero se ahorraría el recibirlo a muchos otros usuarios. A lo mejor estamos hablando de una reducción total del 95% de los correos (sin recibirlos en el cliente, es decir, sin generar tráfico, y sin usar filtros de IP's ni listas negras ni filtros bayesianos...).
Saludos.
Re:Hay solución, pero no ésa
(Puntos:2)( http://barrapunto.com/ )
No es lo que tenía pensado. Evidentemente el programa servidor SMTP tiene que incorporar código para rechazar mensajes. Pero eso no quita para que tire de bases de datos alimentadas por cada usuario.
como la mayoría de los e-mails legítimos que recibo son en español y la mayoría del SPAM es en inglés, se empieza a formar, como si dijeramos, una separación entre las bases de datos de palabras...
Eso es un problema diferente y que también tiene solución sencilla.
En cualquier caso, ten en cuenta que con un sistema que genere errores de protocolo, los falsos positivos dejan de ser un grave problema para convertirse en una simple molestia. El remitente sabe que el envío ha fallado y puede buscar medios alternativos de comunicación.
Re:Hay solución, pero no ésa
(Puntos:1)En realidad no es necesario que alguien lo reciba. Con que lo reciba una dirección spamtrap es suficiente. Lo que describes ya se ha hecho, por ejemplo con el Distributed Checksum Clearinghouse [rhyolite.com].
Lo que para mí está claro es que mientras los filtros no sean fiables al 100% siempre tendrás que andar rebuscando en la basura, no sea que se te haya colado un "falso positivo". Y puestos a escarbar en la basura, mejor hacerlo en una carpeta de 100 mensajes que en una de 200. Por eso soy partidario de las listas de bloqueo por DNS para librarse por lo menos de una parte del spam (aquella que solamente por el IP de procedencia sabemos que es spam con un 99,95% de probabilidad), y si alguien por ejemplo se empeña en mandarte un mensaje desde un relay abierto, pues que se busque un poco la vida y encuentre un servidor SMTP que no lo sea para enviarte su mensaje. No debería ser tan difícil.
Si alguien le interesan listas de bloqueo por DNS que sean buenas, bonitas y baratas, recomiendo:
Distributed Server Boycott List [dsbl.org]
Spamhaus Block List [spamhaus.org]
Exploits Block List [spamhaus.org]