Las listas individuales de SURBL cierran el 1 de Marzo

Según se puede leer en la propia sección de noticias de la web de SURBL, el 1 de Marzo del 2009, las zonas  DNS de las listas individuales de SURBL, serán deshabilitadas.

SURBL llevaba ofreciendo hasta ahora las siguientes listas para consultar:

* sc.surbl.org – SpamCop web sites
* ws.surbl.org – sa-blacklist web sites
* ob.surbl.org – Outblaze URI blacklist
* ab.surbl.org – AbuseButler web sites
* ph – Phishing and malware sites
* jp – jwSpamSpy + Prolocation sites
* multi.surbl.org – Combined SURBL list

con lo que a partir del 1 de Marzo, solamente quedará multi.surbl.org, que es la que se deberá consultar.

SpamAssassin, desde su versión 3.0 (actualmente la última versión es la 3.2.5), consulta «multi» por lo que no es necesario hacer cambio alguno si se usan versiones superiores.

MailChannels y Commtouch junto a Plesk

Como se puede ver en las noticias de la web de MailChannels, esta empresa y Commtouch, dos importantes empresas de servicios relacionados con el correo electrónico y las soluciones antispam, se han unido para dar a Plesk un sistema antispam decente (no como la instalación por defecto de SpamAssassin, como hace ahora). El acuerdo consiste en el uso de la herramienta Traffic Control de MailChannels junto con los filtros de Commtouch para dar una solución completa. Un vídeo de la instalación puede verse aquí:

http://tcblog.mailchannels.com/2008/11/direct-from-mailchannels-labs-plesk.html

Es sencillo por lo que parece, pero tampoco tiene pinta de ofrecer muchas opciones de configuración, más bien ninguna. Una versión de prueba (30 días)de dicho software se puede bajar de:

http://mailchannels.com/download/parallels/nov2008

Habrá que probarlo a ver…

SaneSecurity vuelve a la carga

Comentábamos hace algo más de un mes que SaneSecurity cerraba momentáneamente debido a ciertos ataques DDoS que estaba sufriendo.

La buena noticia es que desde hace dos días, las firmas vuelven a estar disponibles, esta vez para bajarse vía rsync. Los archivos que incluye son los siguientes:

phish.ndb: phishing, malware, ecards
scam.ndb: spam, 419s, lottery, job, stocks
junk.ndb: phishing, malware, ecards, spam, 419s, lottery, job, stocks
spear.ndb: email spears/phishing, converted from http://code.google.com/p/anti-phishing-email-reply/
rogue.hdb: fake anti-virus software, other malware
spamimg.hdb: spam images
lott.ndb: simple lottery scams
spam.ldb: spam (using logical signatures)

phish.ndb.sig: gpg signed file for phish.ndb
scam.ndb.sig: gpg signed file for scam.ndb
junk.ndb.sig: gpg signed file for junk.ndb
spear.ndb.sig: gpg signed file for spear.ndb
rogue.hdb.sig: gpg signed file for rogue.hdb
spamimg.hdb.sig: gpg signed file for spamimg.hdb
lott.ndb: gpg signed file for lott.ndb
spam.ldb: gpg signed file for spam.ldb

Todos los cambios se encuentran en el siguiente PDF, que es recomendable leerlo. Para bajarse los archivos, como comentaba vía rsync, existe también algún script ya hecho.

Mil gracias a los administradores de SaneSecurity por brindarnos de nuevo sus firmas!

Tensa calma tras la desaparición de McColo

Ya han pasado 13 días desde que comentábamos la desaparición de McColo en la red de redes. En diversos medios se han comentado la pronunciada bajada de mensajes de spam recibidos por distintos ISPs.

Por ejemplo, SpamCop muestra las estadísticas en su web del último mes:

SpamCop

Nosotros también seguimos notando dicho descenso.

Si por ejemplo miramos los mensajes recibidos (contando los rechazados por RBLs y otros motivos y los procesados), lo vemos claramente:

Total

Y si vemos la relación de correo legítimo (en verde) con el correo calificado como spam (en rojo), de los mensajes analizados por la pasarela antispam (una vez pasada la conversación SMTP), también es percibida:

SpamHam

Por tanto, seguimos con esa tranquilidad…pero como comentaba en el título de este post, da la sensación de ser una «tensa calma» ya que seguramente en unos días veamos el resurgir de mensajes no solicitados para volverse a establecer en los umbrales que teníamos meses anteriores o incluso más, debido a la campaña de navidad que realizarán (y más con la «crisis»).

McColo Corp. fuera de juego!

Esta mañana, al ver las gráficas de conexiones entrantes, mensajes rechazados…etc en nuestros relays de entrada, he notado un bajón importante en cuanto a spam recibido. La gráfica siguiente lo muestra claramente, cómo a partir de última hora de ayer empiezan a bajar los rechazos por listas negras (línea negra, rosa y verde):

Sigue leyendo

Barracuda Reputation Block List

Según se puede leer en la web de Barracuda, acaban de poner en funcionamiento una lista de reputación (aunque por ahora, a pesar del nombre, parece una DNSBL simple) de acceso gratuito, previo registro:

At the end of September Barracuda Networks will introduce the Barracuda Reputation Block List (BRBL – pronounced «bahr-bel») as a free DNSBL of IP addresses known to send spam.

The BRBL is open to public and can be used within reason. Barracuda is currently making this service available free of charge and we hope to keep it that way.

La «Listing Methodology» está aún en «Details coming soon…», así que no podemos saber qué política de inclusión en la lista usan. No obstante, sí que tienen un formulario para dar de baja IPs.

Ya la estoy probando bajo SpamAssassin (es muy pronto aún para ponerla a nivel SMTP y más, sin saber su metodología de listado) y parece que está dando buenos resultados…veremos qué nivel de falsos positivos tiene, que es al fin y al cabo, el indicador más importante de la calidad de una lista negra.

Resumen MAAWG

La semana pasada volví del MAAWG tras varios días en Heidelberg(Alemania).

El congreso como tal dio mucho de sí y se hablaron de cosas muy interesantes. Estaban presentes todos los «grandes» del mundo de Internet y del correo electrónico, tales como Microsoft, AOL, AT&T, ComCast, Yahoo, SpamHaus, IronPort, Cisco, Symantec…etc y la agenda del evento estuvo repleta de charlas y conferencias. A continuación un mini-resumen de alguna de ellas.

Sigue leyendo

ORDB devuelve falsos positivos a todas las consultas

El 31 de Diciembre del 2006, ORDB, una de las listas negras más conocidas hasta el momento y con buena reputación, cerraba para siempre. El cambio de técnicas usadas por los spammers para el envío de su email basura, hizo que los open relays ya casi no fueran utilizados, por lo que ORDB ya no tenía mucho que listar.

Desde hace unos días, ORDB, responde como positivo las consultas que se le hacen para cualquier IP, por ejemplo:

$ dig 4.64.194.82.relays.ordb.org +short
127.0.0.2

$ dig 152.175.55.65.relays.ordb.org +short
127.0.0.2

$ dig 240.246.14.72.relays.ordb.org +short
127.0.0.2

Los servidores de Hostalia, Hotmail y Google, serían calificados como «emisores de spam». Supongo que esta medida la habrán tomado para que los postmasters descuidados espabilen un poco :)

Un cliente nos comunicaba que estaba teniendo problemas para enviar correos a un servidor. El mensaje devuelto era relativo a ORDB, algo que nos extrañó bastante y que nos llevó al origen del problema.

Así, que ya sabéis, si no lo habíais hecho ya, quitad ORDB de todos vuestros chequeos antispam (incluido el SpamAssassin!) para evitaros problemas. Los que tengan appliances que sean una caja negra…lo tendrán más difícil :-/

Buenas prácticas de tratamiento de e-mail para ISPs

Hace tiempo que AOL, RIPE o RedIris, nos comentaban las buenas prácticas o recomendaciones de uso y tratamiento del correo electrónico desde su punto de vista (que no hay que negar que es más que correcto).

Creo que es algo que desde todos los ISPs habría que promover (y se está en ello…); saber cuáles son sus políticas de gestión de correo electrónico, qué tipo de chequeos deben de pasar los emails para que puedan ser entregados, formas de contacto ante cualquier incidencia…etc. Desde Hostalia, hemos hecho algo parecido para que quien tenga problemas entregándonos su correo, sepa a qué puede ser debido. El enlace en concreto es: abuse.hostalia.com.

Básicamente, las primeras comprobaciones se basan en los RFCs existentes sobre DNS y SMTP. En concreto el RFC 2181 y el RFC 2821, son RFCs que deben cumplirse «al dedillo» :-) Si todos los ISPs cumplieran al 100%, al menos, estos dos puntos tendríamos bastante ganado en la lucha contra el spam. De hecho, es bastante común encontrarse con entidades bastante importantes (no es cuestión de dar nombres :D ) con problemas bastante básicos de fallos en registros DNS, fallos en configuraciones de los servidores SMTP…etc; otra cosa es explicar al cliente que X compañía archiconocida por ser muy importante en Y sector (que normalmente no tiene nada que ver con las nuevas tecnologías), tiene mal configurados sus registros MX y por ello no les llega el correo…

Otro tipo de comprobaciones típicas que se hacen son las relativas a listas negras, filtros de contenidos, SPF, DKIM…etc, pero de eso hablaremos otro día ya que da para mucho…