Muere Ray Tomlinson, el creador del correo electrónico

Ray Tomlinson, ingeniero estadounidense creador del correo electrónico, murió el pasado sábado a los 74 años de edad.

Mientras trabajaba en ARPANET, en 1971, modificó el programa sndmsg, que se usaba para enviar mensajes entre usuarios de una misma máquina, para enviar mensajes entre distintos ordenadores. Lo que ahora entendemos por correo electrónico.

Para identificar en qué máquina estaba cada usuario, ideó el uso de la arroba “@” para indicarlo, con el formato: usuario@host. De esta forma, el programa sabía si un envío era a un usuario local o remoto y en caso de ser remoto, a qué máquina enviarlo. Este sistema sigue funcionando ahora, 45 años después.

Sirva esta escueta entrada como humilde homenaje.

Cuando los resolvers DNS de Google no resuelven

Cuando un dominio no resuelve en los resolvers DNS públicos de Google (8.8.8.8 y 8.8.4.4), lo primero que piensas es que tiene algún fallo en sus registros DNS (los NS de la zona, por ejemplo), que el dominio ha caducado…etc. Pero cuando compruebas que todo es correcto y que el resto de resolvers responden bien a a las consultas DNS, entonces se acaban las ideas.

Buscando errores similares, llegué a un artículo que comentaba:

Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!

We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures. Apologies again for the original, unclear announcement.

Sigue leyendo

Bug de Scan Messages en MailScanner

Unas de las cosas que más gustan de MailScanner es la feature de que cada una de las directivas de configuración, en su gran mayoría, pueden ser un archivo de reglas o una llamada a una función. Esto permite que para cada configuración típica de un sistema antispam pueda diferenciarse en base a cuenta origen/destino, IP origen, dominio origen/destino…etc, lo cuál, permite la personalización absoluta del sistema.

Por ejemplo, a la hora de decidir si un mensaje va a ser escaneado o no, en vez de tener un valor de “yes” o “no” para la directiva de configuración que lo controla, que se aplicaría a todos los mensajes, puede hacerse mediante un archivo de reglas externo:

Scan Messages = %rules-dir%/scanmessages.rules

donde se establecerán las reglas que se deseen, por ejemplo:

From: origen@confiable.com no
From: 192.168.1.10 no
From: /^192\.168\.13[4567]\./ no
FromOrTo: default yes

evitando que se escaneen los mensajes de un determinado FROM, de una determinada IP o de un conjunto de IPs que cumplan la expresión regular. Con el resto de mensajes, se hará lo que el “default” diga, en este caso, “yes” (escanearse).

Sigue leyendo

Postfix con DKIM y múltiples dominios

Tras pruebas varias e integraciones con otros sistemas de la plataforma, ya estamos firmando, desde hace unos meses, correos salientes con DKIM (RFC 5585).

¿Y qué es DKIM? Es una idea desarrollada a partir de DomainKeys e IdentifiedMail que
garantiza que un mensaje procede de un determinado sitio. Es usado por grandes proveedores como Yahoo, Gmail, Hotmail…etc.

DKIM usa claves públicas/privadas para certificar el origen de un email a través de DNS. Se crean dos claves, la pública se publica en un registro TXT del DNS del dominio cuyos mensajes se quieren firmar y la privada se usa para crear la firma digital de los mensajes añadiendo el resultado en una cabecera del propio mensaje a enviar.

El servidor destino, consultará la clave pública y chequeará que se corresponde con la clave que ha firmado el mensaje.

Sigue leyendo

Desaparición de mensajes en Postfix

He tenido dudas a la hora de poner un título a este post. El concepto “desaparición” puede que sea algo amarillista, quizás “pérdida de rastro de mensajes” pudiese hacer más justicia a lo que voy a comentar, pero bueno, queda más “Expediente X” el actual ;-)

Todo esto viene debido a que buscando en los logs un determinado mensaje enviado, no se sabía (a priori) qué había pasado con él. Esto es lo que creo (y supongo que todo el mundo cree) que no debe hacer un log, no dejar evidencias de lo que pasa.

Juntar MailScanner con Postfix siempre ha sido muy criticado, sobre todo en la lista de usuarios de Postfix. No hay una interfaz que pase los mensajes recibidos en el demonio smtpd de Postfix a MailScanner, como sucede con otras pasarelas de correo como amavids-new, sino que cuando llegan los mensajes vía SMTP, pasan a la cola hold donde quedan retenidos y MailScanner, con un proceso batch, procede a recogerlos de ahí regularmente para analizarlos.

Sigue leyendo

Greylisting II

Ya hablábamos hace algunos años (¡cómo pasa el tiempo!) sobre Greylisting y la efectividad que tenía al rechazar temporalmente conexiones de ciertas IPs (rangos dinámicos y residenciales). Gracias a esto, todos esos mensajes de spam que envían los bots (que no tienen un sistema de gestión de rechazos (sistema de colas, básicamente) como exige el RFC), son rechazados en primera instancia y no se vuelven a intentar entregar.

Un paso más es combinar esto con la geolocalización de IPs. Gracias a GeoIP, disponemos de una base de datos que guarda el país al que pertenece cada IP de Internet. En Debian por ejemplo, basta hacer:

apt-get install geoip-bin geoip-database

y disponemos ya de un comando que hace la consulta correspondiente:

# geoiplookup 81.12.209.54
GeoIP Country Edition: RO, Romania

¿Y qué podemos hacer con esto? Pues juntarlo con la idea de Greylisting y poder rechazar temporalmente, aparte de las IP dinámicas/residenciales, las conexiones realizadas desde ciertos países que son conocidos por el envío masivo de spam. Podemos sacar un listado de la web de SpamHaus:

Por ejemplo, podemos rechazar temporalmente, las conexiones que tengan como origen IPs de Rumanía, Polonia, China y Brasil. Si decidimos hacer esto, sería conveniente saber si los clientes suelen intercambiar correos con otros usuarios de dichos países, para evaluar el impacto que tendría. No obstante, los servidores legítimos de dichos países, reintentarán el envío del mensaje una vez recibido el rechazo temporal (como exige el RFC), por lo que no habrá problemas de pérdida de correos.

Si lo comentado anteriormente es aplicable para el correo entrante, algo parecido se puede hacer para el correo saliente (el que los clientes nos entregan para hacer relay y entregarlo al destino). Aplicar RBLs sobre los clientes directamente, suele provocar bastantes falsos positivos (con IPs dinámicas sobretodo) así que puede combinarse estas consultas con la geolocalización. La idea podría ser “rechazar los envíos de clientes cuya IP origen esté en una o más RBLs y además el país origen sea poco habitual o sospechoso”.

En nuestros servidores de salida, en el día de ayer por ejemplo, estos son algunos de los países al que pertenecen las IPs cuyas conexiones fueron rechazadas por la política anteriormente mencionada:

Vietnam
Rusia
Polonia
Taiwan
Turquía
Rumanía
Kazajistán
Omán

mensajes que no tenían pinta de ser legítimos.

Por tanto, vemos como la combinación de varias herramientas, puede proporcionarnos funcionalidades que podemos aplicar en diferentes ámbitos y de diferentes formas en nuestras plataformas de correo.

La lista NJABL echa el cierre

Se puede leer en la web de la lista negra NJABL, que se vacían las zonas DNSBL, en el proceso de cierre de dicha lista negra:

March 1, 2013: NJABL is in the process of being shut down. The DNSBL zones have been emptied. After “the Internet” has had some time to remove NJABL from server configs, the NS’s will be pointed off into unallocated space (192.0.2.0/24 TEST-NET-1) to hopefully make the shutdown obvious to those who were slower to notice.

Esta lista se consulta desde SpamAssassin en su instalación por defecto, por lo que es conveniente deshabilitarla para evitar consultas DNS en balde. Para ello, bastará con añadir:

score RCVD_IN_NJABL_CGI 0
score RCVD_IN_NJABL_MULTI 0
score RCVD_IN_NJABL_PROXY 0
score RCVD_IN_NJABL_RELAY 0
score RCVD_IN_NJABL_SPAM 0

en la configuración de SpamAssassin. No obstante, habrá que estar atentos a futuras actualizaciones de reglas (vía sa-update), ya que dichas reglas serán deshabilitadas por los propios desarrolladores.

Actualización: a día de hoy, 6 de Marzo, ya se han actualizado las reglas por parte del equipo de SpamAssassin de tal forma que no incluyen los chequeos a dicha DNSBL.

DNS-Servicios en MXToolBox

Hemos comprobado que la lista negra RBL.DNS-SERVICIOS.COM, que es gestionada por nosotros, está incluida entre las RBLs a comprobar en MXToolBox cuando se solicita un informe de una determinada IP (bajo el apartado Blacklists).
Este servicio gratuito es ampliamente utilizado por usuarios y administradores de servidores para comprobar en qué listas negras están incluidas sus IPs.

En su propia web, hacen referencia a nuestro servicio y la URL disponible para dar de baja la dirección IP de nuestra lista.

Ya comentábamos hace tiempo además, que nuestra lista negra notifica en formato ARF a los contactos abuse de la IP que es listada, para avisar de dicha incorporación.

DMARC: Domain-based Message Authentication, Reporting & Conformance

Un grupo de empresas de la “élite” actual de Internet, entre las que están Google, Microsoft, Facebook y Paypal, han anunciado una nueva especificación técnica colaborativa llamada DMARC “Domain-based Message Authentication, Reporting & Conformance”.

Se trata de un nuevo protocolo mediante el cuál, un emisor que usa SPF y/o DKIM, puede indicar qué hacer si alguno de estos dos tests falla (nótese aquí la diferencia con el “hardfail”, “softfail”…etc de SPF) al llegar a un destinatario que consulte DMARC y es más, se establece un canal de comunicación para que el destinatario pueda reportar esos emails al propietario del dominio emisor, con el fin de que éste por ejemplo, pueda investigar los posibles casos de envíos fraudulentos, phishing…etc y atajarlos de forma rápida.

Existe ya un extenso draft al respecto que habrá que ir mirando, ya que la idea parece interesante. El modo de publicación de las políticas DMARC para un determinado dominio, es similar a las de SPF, mediante un registro TXT en el DNS, por ejemplo:

“v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@alvaromarin.com”

en el que se indica la política a aplicar por los destinatarios de mensajes de este dominio cuyos tests SPF/DKIM fallen (“reject” en este caso), el porcentaje de mensajes a los que aplicar esta política (100%) y la dirección donde enviar los reportes para ser analizados.

Habrá que seguir de cerca esta iniciativa.