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: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]