Miguel Oyarzo <[EMAIL PROTECTED]> wrote:
> Abro la discusion de los distintos metodos antispam existentes a la fecha
> y sus problemas asociados (para los que le interese los sistemas de
> correos
>
> Descip% y problemas asociados:
>
> 1) Spamassassin: Filtro que evalua el contenido de un mensaje de correo y
> segun la puntuacion obtenida lo marca como spam o no.
Hay varias herramientas basadas en el mismo principio.
> Principales defectos: (i) El mecanismo de evaluacion es muy conocido y
> los spammers se las arreglan para enviar correos cortos, poco
> formateados, con palabras codificadas o solo con URL que llaman objetos
> HTML, entre otros (ii) A veces se marcan correos fidedignos lo que lo
> vuelve un sistema poco confiable.
Es extremadamente confiable con entrenamiento personalizado... pero eso es
muy caro (un par de MiB para cada usuario, a procesar para cada (!)
mensaje), ademas que solia colgarse feamente (100% CPU en loop, maquina
solo recuperable via Big Red Switch).
> 2) Listas RBL: mediante la consulta a una base de datos publica permite
> identificar servdores SMTP acusados de SPAM o con algun tipo de problema
> de configuracion protencialmente peligrosa.
> Pricipal problema: (i) Al usar RBL podemos estar bloqueando, sin querer,
> miles de servidores SMTP de empresas e ISPs fidedignos, si las direciones
> MX de estos ultimos caen (por inexperiencia probable) en estas listas
> publicas. Se dice que es un problema del otro server, pero es uno el que
> activa ese filtro.
Si no son capaces de administrar sus MTAs como la gente, no quiero hablar
con ellos.
El problema es que la cobertura es parcial (si tanto), y hay una latencia
notoria en inscribir a los spammers.
> (i) Si eres proveedor SMTP para tus clientes (con smtp_auth y todo) y
> estos usan conexiones ADSL, o dial-up en general, es MUY probable que la
> mitad de ellos siempre esten llamando por no poder pasar mensajes de
> correo (los IPs dinamicos de los ISPs tradicionales estan siempre en
> listas negras por diversas razones). Situancion complicada de explicar
> algunas veces.
En VTR solian simplemente cortar SMTP hacia afuera...
> 3) Grey-List: Sistema que retrasa en X minutos la entrada de un mensaje
> de correo a nuestro servidor MX. Se supone que un servidor remoto SMTP
> no estandar o adulterado no intentará reenviarnos el mismo mensaje si
> este fue retrasado una vez (en teoria).
Algunos spammers han logrado saltarse esto (no se si usan MTAs propios, o
mas fuertemente se aprovechan de relays abiertos).
> Principal problema: Aun que nuestro GREY-LIST le diga al SMTP server
> remoto que envie el mensaje unos cuantos minutos mas, el servidor remoto
> lo encolara
No conozco ningun MTA que haga otra cosa... y hay que recordar que esto es
para el /primer/ mensaje de la serie que viene de alla.
> y lo despachara segun su configuracion local (y no la
> sugerencia de GREY-LIST).
Nadie nunca dijo que email es tiempo real duro...
> Servidores de grandes ISP u otras empresas
> pueden tener colas de varias horas.
Eso significa un MTA exageradamente sobrecargado alla. Not my problem si no
tienen idea como configurar un FallbackMX o similar...
> Produce un problema grave de
> oportunidad para los 1eros mensajes que provengan desde allá. (existe una
> lista blanca al interior de GREY-LIST, pero es manual)
Y?
> De las 3 anteriores le otorgo mayor eficiencia a Grey-List, a pesar de
> los retrasos dificiles de explicar a los usuarios. He comprobado que
> filtra mucho mas que los anteriores y es muy confiable.
> Me falta alguna otra tecnica que este al nivel de las anteriores o que
> las haya superado?
Estan las "brillantes" ideas de SPF y afines: Inscribes en DNS los MTAs
legitimos para tu dominio, un MTA remoto que sepa de esto no aceptara
correo "desde tu dominio" que viene de otras maquinas. Falla miserablemente
porque /yo/ tengo que mantener rigurosamente al dia la configuracion para
que (algunos pocos) /otros/ no reciban spam falsificado como de mi
direccion... y basta enviar spam "desde" alguno de los millones de dominios
que no usan esto para saltarse esto. Ademas, esta patentado por MSFT (o asi).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
From [EMAIL PROTECTED] Fri May 26 22:38:29 2006
From: [EMAIL PROTECTED] (Horst von Brand)
Date: Fri May 26 22:38:40 2006
Subject: Discusion para las distintas tecnicas antispam
In-Reply-To: Your message of "Thu, 25 May 2006 00:19:22 -0400."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Victor Hugo dos Santos <[EMAIL PROTECTED]> wrote:
> El 24/05/06, Miguel Oyarzo<[EMAIL PROTECTED]> escribió:
>
> [ varios comentarios...]
> > Me falta alguna otra tecnica que este al nivel de las anteriores o que las
> > haya superado?
> >
> > Cualquier comentario o aporte bienvenido
> mmm... la utilizacion de las listas-blancas, o sea, el servidor de
> correo solamente recibe los mensajes de los dominios a los cuales uno
> realmente desea recibir.
Eso es irracional. Seria completamente imposible de manejar para un sitio
medianamente activo (decenas de miles de mensajes diarios, algunos miles de
direcicones origen distintas impredecibles...).
Ah, se me olvidaba que hay tecnicas basadas en "challenge-response": Me
envias un correo, mi MTA te lo devuelve con indicacion de como reenviar el
mensaje con una clave &c; una vez que pasa por esta burocracia quedas
registrado como legitimo. No sirve, porque simplemente no respondo a tales
leseras; y por lo demas, basta con falsificar tu direccion de origen para
pasar de largo...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513