Sender Policy Framework ( SPF ) es un método de autenticación de correo electrónico que garantiza que el servidor de correo remitente esté autorizado a generar correo desde el dominio del remitente del correo electrónico. [1] [2] Esta autenticación solo se aplica al remitente del correo electrónico que aparece en el campo "envelope from" durante la conexión SMTP inicial. Si el correo electrónico rebota, se envía un mensaje a esta dirección [2] y, para la transmisión descendente, normalmente aparece en el encabezado "Return-Path". Para autenticar la dirección de correo electrónico que en realidad es visible para los destinatarios en la línea "From:", se deben utilizar otras tecnologías como DMARC . La falsificación de esta dirección se conoce como suplantación de correo electrónico [ 3] y se utiliza a menudo en phishing y correo no deseado .
La lista de hosts y direcciones IP de envío autorizados para un dominio se publica en los registros DNS de ese dominio. El Sender Policy Framework se define en la RFC 7208 de abril de 2014 como un "estándar propuesto". [4]
La primera mención pública del concepto fue en 2000, pero pasó prácticamente desapercibida. [5] No se volvió a hacer mención del concepto hasta que Dana Valerie Reese, [6] [3] [5], que desconocía la mención de la idea en 2000, publicó en 2002 un primer intento de especificación similar a SPF en la lista de correo de "namedroppers" de la IETF . Al día siguiente, Paul Vixie publicó su propia especificación similar a SPF en la misma lista. [7] [5] Estas publicaciones despertaron mucho interés y llevaron a la formación del Grupo de Investigación Antispam de la IETF (ASRG) y su lista de correo, donde se desarrolló más la idea de SPF. Entre las propuestas presentadas al ASRG se encontraban "Reverse MX " (RMX) de Hadmut Danisch y "Designated Mailer Protocol" (DMP) de Gordon Fecyk. [8]
En junio de 2003, Meng Weng Wong fusionó las especificaciones RMX y DMP [9] y solicitó sugerencias de otros. Durante los siguientes seis meses, se realizó una gran cantidad de cambios y una gran comunidad comenzó a trabajar en SPF. [10] Originalmente, SPF significaba Sender Permitted From (Remitente permitido desde) y a veces también se lo denominaba SMTP+SPF ; pero su nombre se cambió a Sender Policy Framework (Marco de política de remitente) en febrero de 2004.
A principios de 2004, el IETF creó el grupo de trabajo MARID e intentó utilizar SPF y la propuesta CallerID de Microsoft como base para lo que ahora se conoce como Sender ID ; pero esto fracasó debido a conflictos técnicos y de licencias. [11]
La comunidad SPF volvió a la versión "clásica" original de SPF. En julio de 2005, esta versión de la especificación fue aprobada por el IESG como un experimento de IETF , invitando a la comunidad a observar SPF durante los dos años posteriores a su publicación. El 28 de abril de 2006, la RFC de SPF se publicó como RFC experimental 4408.
En abril de 2014, IETF publicó SPF en RFC 7208 como un "estándar propuesto".
El Protocolo simple de transferencia de correo permite que cualquier computadora envíe mensajes de correo electrónico que dicen provenir de cualquier dirección de origen. Esto es aprovechado por los spammers y estafadores que a menudo utilizan direcciones de correo electrónico falsas , [12] lo que hace más difícil rastrear un mensaje hasta su origen y facilita que los spammers oculten su identidad para evitar responsabilidades. También se utiliza en técnicas de phishing , donde se puede engañar a los usuarios para que revelen información privada en respuesta a un correo electrónico supuestamente enviado por una organización como un banco.
El SPF permite al propietario de un dominio de Internet especificar qué equipos están autorizados a enviar correo con direcciones de remitente en ese dominio, utilizando registros del Sistema de nombres de dominio (DNS). Los receptores que verifican la información SPF en los registros TXT pueden rechazar mensajes de fuentes no autorizadas antes de recibir el cuerpo del mensaje. Por lo tanto, los principios de funcionamiento son similares a los de las listas negras basadas en DNS ( DNSBL ), excepto que el SPF utiliza el esquema de delegación de autoridad del Sistema de nombres de dominio. La práctica actual requiere el uso de registros TXT, [13] al igual que las primeras implementaciones. Durante un tiempo, se registró un nuevo tipo de registro (SPF, tipo 99) y se puso a disposición en el software DNS común. El uso de registros TXT para SPF fue pensado como un mecanismo de transición en ese momento. La RFC experimental, RFC 4408, sección 3.1.1, sugirió que "un nombre de dominio compatible con SPF DEBERÍA tener registros SPF de ambos tipos de RR ". [14] El estándar propuesto, RFC 7208, dice que "el uso de tipos de RR DNS alternativos fue apoyado en la fase experimental de SPF pero ha sido descontinuado". [13]
La dirección del remitente se transmite al comienzo del diálogo SMTP. Si el servidor rechaza el dominio, el cliente no autorizado debe recibir un mensaje de rechazo y, si ese cliente era un agente de transferencia de mensajes (MTA) de retransmisión, se puede generar un mensaje de rebote a la dirección del remitente original. Si el servidor acepta el dominio y, posteriormente, también acepta los destinatarios y el cuerpo del mensaje, debe insertar un campo Return-Path en el encabezado del mensaje para guardar la dirección del remitente. Si bien la dirección en Return-Path a menudo coincide con otras direcciones de origen en el encabezado del correo, como header-from , este no es necesariamente el caso y SPF no evita la falsificación de estas otras direcciones, como el encabezado del remitente .
Los spammers pueden enviar correos electrónicos con un resultado SPF PASS si tienen una cuenta en un dominio con una política de remitente o pueden abusar de un sistema comprometido en este dominio. Sin embargo, al hacerlo, es más fácil rastrear al spammer.
El principal beneficio de SPF es para los propietarios de direcciones de correo electrónico que se falsifican en Return-Path. Reciben una gran cantidad de mensajes de error no solicitados y otras respuestas automáticas. Si dichos receptores usan SPF para especificar sus direcciones IP de origen legítimas e indican el resultado FAIL para todas las demás direcciones, los receptores que verifican SPF pueden rechazar las falsificaciones, reduciendo o eliminando así la cantidad de retrodispersión .
El SPF tiene ventajas potenciales más allá de ayudar a identificar correo no deseado. En particular, si un remitente proporciona información del SPF, los destinatarios pueden usar los resultados del SPF PASS en combinación con una lista de permitidos para identificar remitentes confiables conocidos. Los escenarios como sistemas comprometidos y correos compartidos limitan este uso.
Si un dominio publica un registro SPF, los spammers y los phishers tienen menos probabilidades de falsificar mensajes de correo electrónico que pretendan ser de ese dominio, porque los mensajes falsificados tienen más probabilidades de ser detectados por los filtros de spam que comprueban el registro SPF. Por lo tanto, un dominio protegido con SPF es menos atractivo para los spammers y los phishers. Debido a que un dominio protegido con SPF es menos atractivo como dirección falsificada, es menos probable que los filtros de spam lo rechacen y, por lo tanto, en última instancia, es más probable que el correo electrónico legítimo del dominio pase. [15]
SPF interrumpe el reenvío de mensajes sin formato . Cuando un dominio publica una política SPF FAIL, los mensajes legítimos enviados a destinatarios que reenvían su correo a terceros pueden ser rechazados o rebotados si se dan todas las siguientes circunstancias:
Esta es una característica necesaria y obvia de SPF: los controles detrás del MTA ( MX ) "fronterizo" del receptor no pueden funcionar directamente.
Los editores de políticas SPF FAIL deben aceptar el riesgo de que sus correos electrónicos legítimos sean rechazados o rebotados. Deben realizar pruebas (por ejemplo, con una política SOFTFAIL) hasta que estén satisfechos con los resultados. Vea a continuación una lista de alternativas al reenvío de mensajes simple.
Para una ruta de retorno vacía como la que se usa en mensajes de error y otras respuestas automáticas, es obligatoria una verificación SPF de la identidad HELO .
Con una identidad HELO falsa, el resultado NONE no sería de ayuda, pero para nombres de host válidos, SPF también protege la identidad HELO. Esta característica de SPF siempre fue admitida como una opción para los receptores y los borradores de SPF posteriores, incluida la especificación final, recomiendan verificar siempre la identidad HELO.
Esto permite a los receptores incluir en la lista de permitidos los envíos de correos en función de un HELO PASS o rechazar todos los correos después de un HELO FAIL. También se puede utilizar en sistemas de reputación (cualquier lista de permitidos o denegados es un caso simple de un sistema de reputación).
El cumplimiento del FPS consta de tres tareas vagamente relacionadas:
551 User not local; please try <[email protected]>)Por lo tanto, la cuestión clave en SPF es la especificación de la nueva información DNS que los dominios establecen y utilizan los receptores. Los registros que se presentan a continuación tienen la sintaxis DNS típica, por ejemplo:
"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -todos"
"v=" define la versión de SPF utilizada. Las siguientes palabras proporcionan mecanismos que se pueden utilizar para determinar si un dominio es apto para enviar correo. "ip4" y "a" especifican los sistemas a los que se les permite enviar mensajes para el dominio en cuestión. El "-all" al final especifica que, si los mecanismos anteriores no coinciden, el mensaje debe rechazarse.
Se definen ocho mecanismos :
Cada mecanismo se puede combinar con uno de cuatro calificadores :
+para un resultado PASS. Esto se puede omitir; por ejemplo, +mxes lo mismo que mx.?para un resultado NEUTRAL interpretado como NINGUNO (sin política).~(tilde) para SOFTFAIL, una ayuda de depuración entre NEUTRAL y FAIL. Normalmente, los mensajes que devuelven SOFTFAIL se aceptan pero se etiquetan.-(menos) para FAIL, el correo debe ser rechazado (ver más abajo).Los modificadores permiten futuras ampliaciones del marco. Hasta la fecha, solo se han implementado ampliamente los dos modificadores definidos en el RFC 4408:
exp=some.example.comProporciona el nombre de un dominio con un registro TXT de DNS (interpretado mediante el lenguaje de macros de SPF) para obtener una explicación de los resultados FAIL (normalmente, una URL que se agrega al código de error SMTP). Esta función se utiliza con poca frecuencia.redirect=some.example.comse puede utilizar en lugar del mecanismo ALL- para vincular al registro de políticas de otro dominio. Este modificador es más fácil de entender que el mecanismo INCLUDE-, que es bastante similar .Tan pronto como las implementaciones de SPF detectan errores de sintaxis en una política de remitente, deben abortar la evaluación con el resultado PERMERROR. Los mecanismos de omisión de errores no pueden funcionar como se espera include:bad.exampley , por lo tanto, redirect=bad.exampletambién causan un PERMERROR.
Otra salvaguarda es el máximo de diez mecanismos que consultan DNS, es decir, cualquier mecanismo excepto IP4, IP6 y ALL. Las implementaciones pueden abortar la evaluación con el resultado TEMPERROR cuando toma demasiado tiempo o una consulta DNS se agota o pueden continuar fingiendo que la consulta no devolvió datos, lo que se llama una "búsqueda nula". Sin embargo, deben devolver PERMERROR si la política necesita directa o indirectamente más de diez consultas para mecanismos . Además, deben devolver PERMERROR tan pronto como se hayan encontrado más de dos "búsquedas nulas". Cualquiera redirect=también cuenta para estos límites de procesamiento . [16]
Una política SPF HELO típica v=spf1 a mx ip4:192.0.2.0 -allpuede ejecutar cuatro o más consultas DNS: (1) registro TXT (el tipo SPF quedó obsoleto por RFC 7208), (2) A o AAAA para mecanismo a, (3) registro MX y (4+) A o AAAA para cada nombre MX, para mecanismo mx. Excepto la primera, todas esas consultas cuentan para el límite de 10. Además, si, por ejemplo, el remitente tiene una dirección IPv6, mientras que su nombre y sus dos nombres MX solo tienen direcciones IPv4, entonces la evaluación de los primeros dos mecanismos ya da como resultado más de dos búsquedas nulas y, por lo tanto, PERMERROR. Mecanismos y ip4no necesitan ninguna búsqueda DNS.ip6all
Para permitir una rápida prueba e implementación, las versiones iniciales de SPF verificaron su configuración en el registro TXT de DNS del dominio de envío, aunque tradicionalmente se suponía que este registro era un texto de formato libre sin semántica adjunta. [17] Aunque en julio de 2005, IANA asignó un tipo de registro de recursos específico 99 a SPF, la adopción nunca fue alta, y tener dos mecanismos era confuso para los usuarios. En 2014, el uso de este registro se suspendió después de que el grupo de trabajo SPFbis concluyó que "... era muy poco probable una migración significativa al tipo RR de SPF en el futuro previsible y que la mejor solución para resolver este problema de interoperabilidad era dejar de brindar soporte para el tipo RR de SPF". [13]
Como SPF impide cada vez más que los spammers falsifiquen la dirección del remitente del sobre, muchos han optado por falsificar únicamente la dirección en el campo De del encabezado del correo, que en realidad se muestra al destinatario en lugar de que solo la procese el agente de transferencia de mensajes (MTA) del destinatario. Sin embargo, SPF (o DKIM ) se puede utilizar junto con DMARC para comprobar también el campo De del encabezado del correo. Esto se denomina "alineación de identificadores".
Se requieren implementaciones propietarias personalizadas para protegerse contra dicha suplantación de nombres para mostrar y no pueden utilizar SPF. [18] [19] [20]
El software antispam como SpamAssassin versión 3.0.0 y ASSP implementan SPF. Muchos agentes de transferencia de correo (MTA) admiten SPF directamente, como Courier , CommuniGate Pro, Wildcat , MDaemon y Microsoft Exchange , o tienen parches o complementos disponibles que admiten SPF, incluidos Postfix , Sendmail , Exim , qmail y Qpsmtpd . [21] En 2017, más de ocho millones de dominios publican -allpolíticas SPF FAIL. [22] En una encuesta publicada en 2007, el 5% de los dominios .comy .nettenían algún tipo de política SPF. En 2009, una encuesta continua realizada en Nokia Research informa que el 51% de los dominios evaluados especifican una política SPF. [23] Estos resultados pueden incluir políticas triviales como v=spf1 ?all. [24] [25] [ necesita actualización ]
En abril de 2007, BITS, una división de la Mesa Redonda de Servicios Financieros, publicó recomendaciones de seguridad de correo electrónico para sus miembros, incluida la implementación de SPF. [26] En 2008, el Grupo de Trabajo Anti-Abuso de Mensajería (MAAWG) publicó un documento sobre autenticación de correo electrónico que abarcaba SPF, Sender ID y DomainKeys Identified Mail (DKIM). [27] En sus "Mejores Prácticas de Comunicación con Remitentes", el MAAWG afirmó: "Como mínimo, los remitentes deberían incorporar registros SPF para sus dominios de correo". [28] En 2015, el Grupo de Trabajo Anti-Abuso de Mensajería (MAAWG) revisó un documento sobre autenticación de correo electrónico que abarcaba SPF, DomainKeys Identified Mail (DKIM) y DMARC (DMARC). En sus "Mejores Prácticas de Comunicación con Remitentes" revisadas, el MAAWG afirmó: "La autenticación respalda la transparencia al identificar aún más al remitente o remitentes de un mensaje, al mismo tiempo que contribuye a la reducción o eliminación de direcciones falsificadas y falsificadas". [29]
Un registro SPF cuidadosamente diseñado reducirá la probabilidad de que su nombre de dominio sea suplantado de manera fraudulenta y evitará que sus mensajes se marquen como spam antes de que lleguen a sus destinatarios. La suplantación de identidad de correo electrónico es la creación de mensajes de correo electrónico con una dirección de remitente falsificada; algo que es fácil de hacer porque muchos servidores de correo no realizan la autenticación. Los correos electrónicos de spam y phishing generalmente utilizan dicha suplantación de identidad para engañar al destinatario sobre el origen del mensaje.