20Jul Ayudando al “greylisting”

Comentaba el otro día con Sergio en Plurk sobre algunos de los problemas que presenta el greylisting del que hablaba el otro día.

Es cierto que, aunque las ventajas del greylisting superan, a mi parecer, las desventajas, puede no ser el caso para todos, pudiéndose convertir en algún momento en un problema inaceptable.

Esta técnica adolece principalmente de una molestia y de un problema.

La molestia del greylisting.

Los correos se demoran.

Puede darse la circunstancia de que esto no sea aceptable. Es cierto que es una molestia, cuando, por ejemplo, nos registramos en algún sitio y tenemos que esperar el tiempo de embargo para que nos llegue el correo de registro. Esos minutos se hacen eternos, haciendo dudar al receptor de si ha puesto correctamente su dirección de correo. No es raro el caso en que el usuario insiste en registrarse una y otra vez en ese servicio, probando incluso con direcciones distintas. Lógicamente, si las direcciones de correo radican en servidores que utilicen greylisting, no conseguirá nada más que recibir un aluvión de correos de registro una vez pasado el tiempo de embargo.

Esto es lo que yo denomino una molestia, y que para algunos, ciertamente, puede alcanzar el grado de problema. A veces es necesaria la inmediatez en el correo. La solución: paciencia. No hay más.

El problema del greylisting: distintos servidores de correo.

Aquí si que existe un problema se mire por donde se mire. Recordando el funcionamiento del greylisting, este se basaba en guardar una terna (<dirección IP del emisor>,<correo electrónico del emisor>,<correo electrónico del receptor>). Esta terna se almacenaba, y se devolvía un error al servidor emisor, quien reintentaría el envío más tarde.

El problema surge cuando el emisor no es un servidor único, sino es parte de una granja de servidores, donde el correo no tiene por que ser enviado siempre desde la misma dirección IP. Este es el caso de Gmail, por ejemplo, que dispone de una cantidad ingente de servidores de correo, y es muy común que el primer intento de correo y sus posteriores reintentos no provengan de la misma dirección, por lo que la terna nunca será la misma y el correo no se aceptará.

Perder un correo válido no es aceptable. Cualquier lucha contra el spam debe basarse en esta máxima.

Para paliar este problema, se utilizan las listas blancas, con rangos de direcciones IPs conocidas. De esta forma, le podemos indicar a nuestro sistema de greylisting que si el emisor proviene de una de las direcciones IP contenidas en nuestras listas blancas, se acepte el envío (siempre y cuando supere el resto de pruebas que realicemos a los mensajes entrantes, lógicamente).

Algunos sistemas de greylisting son capaces incluso de aprender e ir alimentando el fichero de listas blancas, detectando las granjas de servidores.

RedIRIS provee dos listas muy interesantes para añadir a nuestra solución de greylisting: La lista ESWL y la lista MTAWL. En la lista ESWL figuran las IPs de los servidores de correo salientes gestionados por ISPs españoles miembros del Foro ABUSES. La lista MTAWL es una lista de IPs de servidores de correo propuestos y validados por los miembros del Foro ABUSES de servidores de correo cuyo tráfico consideran no debe ser bloqueado (Hotmail, Gmail, Yahoo, bancos, agencias de viaje, etc).

La técnica del greylisting normalmente se acompaña de otras, como el RBL, SPF, DomainKeys, etc. Se pueden combinar estas técnicas con el greylisting, de forma que no sean comprobaciones independientes sino que se complementen. De esta forma, por ejemplo, podemos relajar las condiciones de la comprobación SPF, y en vez de denegar el acceso a quien no lo cumpla, y a quien lo cumpla dejarlo pasar para realizarle luego el greylisting, podríamos cambiar el test de SPF para que sea más permisivo y asi ayudar al greylisting. En este ejemplo, haríamos que quien pase el SPF sea aceptado automáticamente por nuestra solución de greylisting, haciendo que solo caiga en ella quien falle la prueba del SPF. Podemos meter en la ecuación también la comprobación de DomainKeys.

Lo que está claro es que hay un mundo de posibilidades (y de trabajo) para luchar contra el SPAM, que no es solo la molestia de un correo no deseado en nuestro buzón, sino que también es causa, como ya he comentado alguna que otra vez, de gastos importantes de recursos, y que lamentablemente no existe una solución de enchufar-y-listo válida para todas las situaciones.

Tags: correo, greylistin, spam