Para todos es conocido que la gran mayoría de mensajes de correo electrónico NO solicitado utiliza la práctica de falsificación de identidad, tanto usando el dominio como en muchos casos el nombre del emisor. Por esto es que a menudo recibimos mensajes con contenido de dudosa reputación que proviene de nuestras propias cuenta y por supuesto no hemos enviado, o de fuentes cercanas y conocidas. Todo tipo de Spam, Phising, virus, estafas y fraudes, entre otros, utilizan dominios y cuentas conocidas para lograr sus oscuros propósitos.
El problema real consiste en que el correo electrónico con este tipo de prácticas ve amenazada su efectividad y confiabilidad como medio de comunicación, además y aún más grave, nosotros como usuarios y empresas perdemos credibilidad en nuestros nombres y marcas.
Un primer intento, vigente hasta hoy, consiste en mantener listas negras con las direcciones IP de los servidores que envían este tipo de comunicaciones, el problema de este enfoque consiste en que los Spammers son muy hábiles y rara vez utilizan la misma dirección IP estática, claro a menos que sea un virus que utilice el servidor de otro, y esto hace que sea muy costoso el mantenimiento de estas listas.
Una vez, nosotros como usuarios, caemos en las trampa de los Spammers y somos reportados en las listas negras, empieza el camino de la negación de responsabilidades y de recuperación de nuestra reputación. Lo primero con que nos estrellamos es que no hay una sola fuente de la verdad, sino cientos de listas negras que no cuentan con información actualizada ni sincronizada y al tratar de salir de ellas notamos que tampoco hay un procedimiento estándar, sino que éste varía dependiendo de cada proveedor. En conclusión este tipo de soluciones NO escala.
SPF y Cómo Funciona?
SPF (Secure Policy Framework) es una especificación (RFC 4408) que pretende ser el comienzo del fin de este tipo de prácticas. La estrategia para lograrlo consiste en definir que servidores están autorizados para enviar correo electrónico a nombre de un dominio específico. Es un
Para entender mejor cómo funciona, a continuación se presenta un diagrama muy simplificado de las partes de un correo electrónico:
Análogo a un mensaje de correo real el correo electrónico cuenta con una envoltura o sobre (envelope) que tiene el objetivo de enrutar el mensaje al lugar de destino sin importar que contenido lleva adentro. Ésta envoltura tiene la siguiente información: emisor, receptor y servidor que hace el envío. Es ahí donde está el poder de los registros SPF ya que el servidor de correo del destinatario, al recibir un correo, verifica que el servidor del emisor está autorizado a enviar correos electrónico a nombre del dominio haciendo una simple consulta directamente al DNS, sin necesidad de transmitir el contenidos en sí del mensaje, ni encabezados ni cuerpo.
Expandiendo un poco más en la configuración necesaria del lado del DNS consiste en la creación de un registro TXT común y corriente, donde se definen los servidores autorizados por medio de políticas, entendidas cómo registros A, MX, PTR, direcciones IP o también es posible incluir una lista de políticas definidas en otro dominio, con el parametro "include". En el sitio de SPF hay un asistente que ayuda a configurar los registros paso a paso.
Por el lado del servidor de correo que es responsable de hacer la verificación, muchos de los productos disponibles en el mercado de servidores de correo, MTAs y hasta clientes de escritorio, tanto de código abierto como comerciales, tienen módulos ya desarrollados o soporte nativo a la especificación.
En resumen se requieren dos partes para que la estrategia de SPF sea efectiva:
1. Que los emisores de correo saliente publiquen en su servidor DNS los servidores autorizados para el envío de correos en un registro TXT
2. Que los servidores de correo entrante hagan la verificación de las envolturas comparando contra el DNS
Ventajas
- Es un estándar abierto, es decir, no hay patentes ni nadie que sea el "dueño" como tal de la especificación.
- Se basa en tecnologías, protocolos y estándares existentes. No requiere ninguna modificación en la arquitectura ni del e-mail ni de la Web.
- Es muy fácil de implementar. También puede ser muy rápido, depende de la propagación de los servidores DNS.
- Ahorra ancho de banda al no tener que transmitir encabezados y contenido, al hacer la verificación con la envoltura.
- Altamente desplegado comparado con otros mecanismos similares. Ver sitio oficial de SPF para estadísticas. Sin embargo, todavía está en una fase muy temprana y sólo una fracción pequeña de los dominios declaran sus registros SPF, incluso en empresas "Fortune 500" según un estudio realizado.
- Poco riesgoso, en caso de haber algún error el mensaje de rebote por lo general incluye detalles específicos del error y existe una gran variedad de herramientas para verificar, las cuales se mencionan a continuación.
Verificar los registros SPF es igual de fácil que verificar cualquier otra entrada del DNS. Tal vez la herramienta más tradicional (pero ya en declive) es el comando nslookup, donde con simplemente digitar set type=txt y luego el dominio podemos obtener los registros SPF declarados, alternativamente se puede usar el comando dig en la misma manera. Igualmente hay varias herramientas Web disponibles como MxToolbox y Who.is, estas herramientas son excelentes porque hacen las consultas al NameServer directamente, por lo cual no se depende de la replicación del DNS. Por último y tal vez la herramienta más importante es por el mismo medio de un correo electrónico, enviando un mensaje de prueba a check-auth@verifier.port25.com o a spf-test@openspf.org se obtiene de vuelta un reporte detallado no sólo de SPF sino de otros mecanismos de autenticación.
Interrogantes
Existen todavía algunos puntos pendientes por resolver para SPF, en específico el mayor obstáculo que ha enfrentado consiste en el manejo al correo redirigido (forwards), ya que estos mensajes son entregados por un servidor diferente en nombre de un dominio diferente, esto genera falsos positivos. Por ejemplo en el diagrama a continuación supongamos que dominio.com tiene publicados sus registros SPF correctamente, cuando envía correos directamente a gmail.com la validación SPF pasa. Ahora, si dominio.com envía correos a un cuenta en hotmail.com donde se redirecciona a gmail.com la validación SPF va a fallar.
Alternativas y ComplementosLos promotores de SPF hacen enfasis en que la especificación no pretende ser la solución holítica al problema sino simplemente es una parte más. Inclusive admiten que a la fecha está en una versión temprana y que en el futuro las políticas disponibles van a ser mucho más precisas, robustas y posiblemente van a poder ser complementables con otros mecanismos.
El ecosistema de soluciones alternativas se clasifica en protocolos de autenticación de emisor y protocolos de autenticación de contenido. Por el lado de autenticación de emisor se destaca SenderId (de Microsoft) y por el lado de autenticación de contenido se destacan las soluciones que utilizan certificados y llaves públicas y privadas como PGP y DKIM.
Conclusión
Recomiendo publicar los registros SPF si somos responsables del dominio y verificarlos si somos responsables del servidor de correo. Es nuestro granito de arena para volver a hacer del correo electrónico un medio de comunicación confiable y de paso nos ayuda a estar más tranquilos respecto a la reputación de nuestros nombres, empresas y marcas.
A continuación les comparto los slides de mi presentación.
