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):
Parece que la ICANN se está empezando a tomar las cosas en serio. Acaba de retirar la acreditación de registrador a EstDomains, como se puede ver en esta nota:
http://www.icann.org/correspondence/burnette-to-tsastsin-28oct08-en.pdf
EstDomains es un agente registrador que tiene registrados más de 240.000 dominios según WebHosting.info, mediante el cuál se registra(ba)n numerosos dominios para el envío de spam y diversos fraudes a través de Internet. Un informe más completo se puede encontrar en:
http://www.f-secure.com/weblog/archives/00001522.html
En dicho artículo se comenta la relación de EstDomains con Atrivo (también conocido como Intercage), ISP que ha sido noticia recientemente debido al cese del peering con ellos de otros ISPs americanos como UnitedLayer, que cansados de intercambiar tráfico con un ISP dedicado a las «malas artes», decidieron poner fin a ello.
En resumen, bien por la ICANN!
Procedo a «liberar» un plugin que hice hace unos meses para qmail mediante el cuál, se puede realizar un rate limit de los emails que envía una cierta dirección.
El proceso consiste en guardar en una tabla en MySQL las direcciones que qmail va «viendo». Existe otra tabla en la que se guarda el valor por defecto que se le quiere dar al límite (por ejemplo, 100 mensajes) y si se llega a dicho límite en un rango de tiempo (por defecto, en 1 hora) el mensaje es rechazado a nivel de SMTP temporalmente.
Existe también la posibilidad de poner límites diferentes para determinadas direcciones; por ejemplo, alguna persona que por X razón legítima necesite enviar más correos.
Además, existe una lista blanca para IPs a las cuáles no aplicar dichos límites. Por ejemplo, si tenemos unos relays de entrada.
Qmail debe estar parcheado con SPP para poder usar este plugin. Por ejemplo, el qmail de Plesk viene de serie ya parcheado, por lo que no hay más que copiarlo en /var/qmail/plugins/ y añadirlo en el archivo /var/qmail/control/smtpplugins.
En la siguiente URL puede ser descargado:
Desde hace tiempo, 3 o 4 meses, vengo observando un comportamiento curioso por parte de algunos spammers. Se ve claramente en la siguiente imagen:
La línea rosa es nuestra RBL, rbl.dns-servicios.com, y el resto de líneas se corresponden con otra serie de RBLs o Rate Limits. Como se ve, existen una serie de picos (bastante notables) de emails rechazados, que siempre suelen darse a mitad tarde. El resto del día, la actividad es normal.
Tras un rediseño del sistema de notificaciones enviadas cuando una IP cae en nuestra lista negra RBL.DNS-SERVICIOS.COM, ahora el mensaje incluye una de las evidencias por la cuál ha sido listada. Con ella el ISP responsable de dicha IP podrá buscar el origen del mensaje de spam. Por ejemplo:
http://rbl.dns-servicios.com/ids/evidence.txt
Es curioso, no obstante, el «desastre» con el que uno se encuentra al enviar mensajes de este tipo a los contactos que aparecen en el WHOIS de las IPs:
mail.local: /var/mail/f/fkchung: Disc quota exceeded
Authentication required (in reply to MAIL FROM command)
Relay access denied (in reply to RCPT TO command)
Database disk quota exceeded
The user(s) account is temporarily over quota.
Reason: Over quota
Unable to deliver message to the following recipients, because
the message was forwarded more than the maximum allowed
times. This could indicate a mail loop.
Recipient address rejected: User unknown in local recipient
table (in reply to RCPT TO command)
Command rejected (in reply to end of DATA command)
Los hay incluso mejores, que pasan directamente de lo que pueda haber o salir de sus redes:
We would point out that, within its activity as a provider of
electronic communication services, XXXX merely provides its
clients with access to the Internet, which entails the activity
of simply transporting information over the network.
No obstante, también se reciben comentarios de agradecimiento por la información facilitada. Por ello y por ayudar a la erradicación de estas fuentes de spam, seguiremos con esta política.
Acaban de publicarse los nuevos RFCs 5321 y 5322 que sustituyen a los ya obsoletos 2821 (SMTP) y 2822 (Internet Message Format), respectivamente.
Leyendo el blog de MailChannels, que compara dichos RFCs, se aprecian los siguientes cambios:
Una nueva edición del Foro Abuses, esta vez en León, en la sede de INTECO, los días 2 y 3 de Octubre.
La agenda:
Día 2 de Octubre (jueves)
10.00-10.30 Bienvenida
10.30-11.30h Presentación INTECO
12.00-14.00h
Sobre la «Obligación por ley de almacenar los registros de actividad del servicio de correo electrónico.
…
16.00-18.00h Sesión2 (tarde): Intercambio de experiencias entre miembros del Foro
Sesión acerca de «Experiencias sobre la gestión (dinámica, herramientas, estadísticas etc) de incidentes abuse@ y seguridad en un ISP»
Día 3 de Octubre (viernes)
10.00-11.30h Sesión3 (mañana): Asuntos internos Foro ABUSES
Propuesta, evaluación y aprobación de documentos del Foro ABUSES:
Propuesta: «Recomendación de Listas Negras»
Propuesta: «Compartir rangos IP dinamicos»
Propuesta: «ListaBlanca de dominios»
Propuesta: «Intercambio de incidentes en Foro ABUSES»
13.00-13.30h Sesión 4: Conclusiones y próxima reunión
14.00h Comida despedida
Seguro que sacamos conclusiones interesantes :-)
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.
Varios clientes se nos quejaban de que recibían mensajes de rechazo de sus correos enviados a ciertos destinos. El mensaje devuelto era el siguiente:
Remote host said: 550 5.7.1 Sender ID (PRA) Not Permitted
Sender ID está claro lo que es, por eso, tras comprobar el registro SPF de los dominios emisores (por eso de «Not Permitted»), parecía todo correcto; dominios de clientes que usan los servidores de correo legítimos que les ofrecemos para hacer los envíos. Nada raro.
Hace ya unos meses, comentaba aquí mismo la sentencia a un conocido spammer llamado Adam Vitale, a 30 meses de cárcel y a pagar $180.000 a AOL debido al envío de 1?2 millones de mensajes basura a sus clientes.
Pues en otro proceso judicial de AOL contra otro spammer, esta vez un tal Jeremy Jaynes, el Tribunal Supremo de Virginia acaba de revocar la condena que pesaba sobre él de 9 años de cárcel. Los motivos han sido el «derecho» del acusado al envío de correos de forma anónima, según la primera enmienda de la constitución estadounidense (la de la libertad de expresión, vamos). La nueva sentencia aboga que la ley aplicada en la anterior es inconstitucional porque prohíbe el envío anónimo de correos masivos sin especificar si son de sentido religioso, político u otros tipos, protegidos estos últimos por dicha primera enmienda.
La reciente ley CAN-SPAM sí que hace incapié en el término «comercial» pero los mensajes fueron enviados antes de que se empezase a aplicar y no parece ser retroactiva.
Tiene «gracia» el asunto…