Wikipedia

Sender Policy Framework

sistema simple de validación de correo electrónico diseñado para detectar la suplantación de correo electrónico
Para otros usos de este término, véase SPF (desambiguación).

SPF (Convenio de Remitentes, del inglés Sender Policy Framework) es una protección contra la falsificación de direcciones en el envío de correo electrónico.[1]​ Identifica, a través de los registros de nombres de dominio (DNS), a los servidores de correo SMTP autorizados para el transporte de los mensajes. Este convenio busca ayudar para disminuir abusos como el spam y otros males del correo electrónico.

El envío SMTP entre servidores editar

Cuando se envía un correo desde un programa cliente de correo electrónico, éste conecta con un servidor SMTP (a través del puerto TCP 25) al que le deja el mensaje para su envío a una o varias cuentas de correo destinatarias. Este servidor (servidor del remitente) es el encargado de conectar con el servidor donde está alojada la cuenta de correo del destinatario (servidor del destinatario) y de transmitir el mensaje para su almacenamiento y posterior descarga por el destinatario.

En el protocolo SMTP, obviamente, es imposible tener autenticación acordada entre todos los servidores de correo. Este inconveniente permite que cualquier servidor remitente pueda identificarse como el transportista en origen de un nombre de dominio. Esto lo aprovechan los suplantadores de identidad de direcciones de correo electrónico para llevar a cabo su fin.

En el envío de correos no solicitados (conocido como correo basura) y otras malas artes como la suplantación de identidad o envío de virus por correo, en casi la totalidad de los casos, interesa ocultar el remitente real o utilizar una dirección que al cliente le podría resultar familiar o confiable.

Un primer intento de controlar esta laguna técnica es el seguimiento de la ruta de direcciones IP por las que se envía el correo, de tal manera que se mantienen unas listas de IPs de servidores que envían correos falseados (listas negras). Esto, aparte de requerir un proceso manual por parte del destinatario, tiene efectos no deseados sobre otros usuarios del servidor que envían correos "reales".

SPF la solución para evitar falsas identidades editar

SPF extiende el protocolo SMTP para permitir comprobar las máquinas autorizadas a enviar correo para un dominio determinado. La idea es identificar las máquinas autorizadas por su dirección IP, y que esta identificación la haga el responsable del dominio que recibirá el correo.

Una aproximación a la solución podría suponer que el remitente del correo, hace los envíos desde la misma máquina que los recibe. Como se puede resolver la dirección IP a donde se enviarían correos al remitente a través del registro MX del servicio DNS (RMX, del inglés Reverse MX), si esta dirección coincide con la que genera el envío, se puede entender que es el remitente real. Pero esta suposición no siempre es cierta, especialmente en grandes proveedores de soluciones de correo como Yahoo!, Hotmail, o GMail.

Otra propuesta, la DMP (Protocolo de Servidores de Correo Identificados, del inglés Designated Mailer Protocol), consiste en que los proveedores de servicios de internet identifiquen las máquinas responsables del envío del correo. Esta solución es válida, pero para que sea efectiva requiere que todos los proveedores la adopten e implementen.

Como mezcla de estas dos propuestas, surge la idea de usar registros DNS para identificar las máquinas autorizadas para envío de correo (sean del proveedor de servicios de internet que sean). Esto es lo que se propone en la solución SPF.

Cómo se configura editar

Registros SPF en el DNS editar

El propietario del nombre de dominio, debe añadir en la configuración de la zona DNS del dominio las direcciones IP de las máquinas utilizadas para enviar correo. Esto se consigue utilizando registros DNS de texto. Un ejemplo de registro SPF para DNS sería: 

midominio.com. IN TXT "v=spf1 mx ptr ~all"

En el ejemplo se indica un registro de texto (IN TXT) para el dominio midominio.com con la siguiente descripción SPF:

  • v= define la versión usada de SPF (versión 1).
  • mx autoriza a las máquinas con la IP de los registros MX.
  • ptr autoriza a las máquinas bajo el dominio midominio.com.
  • ~all sugiere desautorización a las máquinas que no encajen en lo autorizado explícitamente.

El ejemplo debería servir de plantilla para la mayoría de los dominios hospedados.

Uso de SPF en los agentes destinatarios editar

El proceso de verificación SPF en el servidor de correo del destinatario consiste en comprobar los registros DNS del dominio del remitente. Si la dirección IP del servidor que ha conectado encaja en la especificación de direcciones permitidas en el registro SPF entonces se añade una cabecera de título Received-SPF indicando el resultado positivo de la comprobación.

Los programas lectores de correo harán uso de SPF para clasificar el correo justo al contrario del criterio de la carpeta de spam, llevando a la carpeta de entrada el correo verificado por el servidor del destinatario. Examinando las cabeceras de un mensaje verificado por SPF podría observarse la cabecera Received-SPF: 

Received-SPF: pass (domain of rafacouto@gmail.com designates 64.233.182.193 as permitted sender)


El software antispam como SpamAssassin versión 3.0.0 y ASSP tienen implementado SPF. Muchos agente de transferencia de correo (MTA) tales como Courier, CommuniGate Pro, Wildcat, MDaemon y Microsoft Exchange soportan SPF directamente, o tienen parches/plug-ins disponibles que permiten soportar SPF, incluyendo Postfix, sendmail, Exim, qmail y qpsmtpd.[2]​ A partir de 2013, más de siete millones de dominios publican políticas SPF FAIL -all.[3]​

En agosto de 2005 se supo que EarthLink se negaría a permitir que los dominios alojados incorporaran registros de SPF.[4]​

En una encuesta publicada en 2007, el 5% de los dominios .com y .net tenían algún tipo de política de SPF. En 2009, una encuesta continua de Nokia Research informa que el 51% de los dominios analizados especifican una directiva de SPF.[5]​ Estos resultados pueden incluir políticas triviales como v=spf1 ?all.[6]​ En abril de 2007, BITS, una división de la Mesa Redonda de Servicios Financieros, publicaron las recomendaciones de seguridad de correo electrónico de sus miembros, incluido el despliegue SPF.[7]​

En 2008, el Messaging Anti-Abuse Working Group (MAAWG) publicó un artículo acerca de la autenticación de correo electrónico que cubre SPF, Sender ID y DKIM.[8]​ En su "Mejores Prácticas de para enviar" del MAAWG declaró: "por lo menos, los remitentes deben incorporar registros SPF por sus dominios de correo."[9]​

Véase también editar

Referencias editar

  1. ↑ Cnet news (25 de mayo de 2004). «Antispam framework scores Microsoft endorsement» (en inglés). Consultado el 31 de mayo de 2012. 
  2. ↑ «Qpsmtpd SPF plugin». 2013. Archivado desde el original el 29 de junio de 2013. Consultado el 25 de abril de 2013. 
  3. ↑ «SPF -all Domain Survey». 2013. Consultado el 23 de abril de 2013. 
  4. ↑ «SPF Loses Mindshare». 2005. Consultado el 4 de abril de 2011. 
  5. ↑ «Nokia Research Report on SPF Adoption». Archivado desde el original el 20 de septiembre de 2011. 
  6. ↑ Liu, Cricket (enero de 2007). «Handicapping New DNS Extensions and Applications». ONLamp. Archivado desde el original el 26 de septiembre de 2007. Consultado el 4 de octubre de 2007. 
  7. ↑ «BITS Email Security Toolkit» (PDF). BITS. abril de 2007. Archivado desde el original el 15 de mayo de 2008. Consultado el 13 de junio de 2008. 
  8. ↑ Crocker, Dave (marzo de 2008). «Trust in Email Begins with Authentication» (PDF). MAAWG. Archivado desde el original el 29 de enero de 2013. Consultado el 28 de julio de 2011. 
  9. ↑ «MAAWG Sender Best Communications Practices Executive Summary» (PDF). MAAWG. 7 de octubre de 2011. Archivado desde el original el 7 de marzo de 2013. Consultado el 27 de abril de 2012. 

Enlaces externos editar

Obtenido de «https://es.wikipedia.org/w/index.php?title=Sender_Policy_Framework&oldid=158804025»