Discusion para las distintas tecnicas antispam

Horst von Brand vonbrand en inf.utfsm.cl
Vie Mayo 26 22:33:49 CLT 2006


Miguel Oyarzo <admin en aim.cl> 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


Más información sobre la lista de distribución Linux