Sender ID es una propuesta histórica [1] contra la suplantación de identidad del antiguo grupo de trabajo IETF MARID que intentó unirse al Sender Policy Framework (SPF) y al Caller ID. Sender ID se define principalmente en el RFC experimental 4406, [2] pero hay partes adicionales en el RFC 4405, [3] el RFC 4407 [4] y el RFC 4408. [5]
El ID del remitente se basa en gran medida en SPF , con solo unas pocas adiciones.
Sender ID intenta mejorar SPF: SPF no verifica las direcciones de encabezado (de las cuales puede haber más de una) que indican la parte que afirma ser la que envía el mensaje. Una de estas direcciones de encabezado se muestra normalmente al usuario y puede utilizarse para responder a los mensajes de correo electrónico. Estas direcciones de encabezado pueden ser diferentes de la dirección que SPF intenta verificar; es decir, SPF verifica únicamente la dirección "MAIL FROM", también llamada remitente del sobre.
Sin embargo, hay muchos campos de encabezado de correo electrónico similares que contienen información de la parte remitente; por lo tanto, Sender ID define en RFC 4407 [4] una Dirección Responsable Supuesta (PRA), así como un conjunto de reglas heurísticas para establecer esta dirección a partir de los muchos encabezados típicos de un correo electrónico.
Sintácticamente, Sender ID es casi idéntico a SPF excepto que v=spf1se reemplaza por uno de los siguientes:
spf2.0/mfrom – lo que significa verificar la dirección del remitente del sobre, tal como SPF.spf2.0/mfrom,prao spf2.0/pra,mfrom – es decir, verificar tanto el remitente del sobre como la PRA.spf2.0/pra – es decir, verificar únicamente la PRA.La única otra diferencia sintáctica es que Sender ID ofrece la característica de modificadores posicionales que no son compatibles con SPF. En la práctica, hasta ahora no se ha especificado ningún modificador posicional en ninguna implementación de Sender ID.
En la práctica, el esquema pra generalmente solo ofrece protección cuando el correo electrónico es legítimo, mientras que no ofrece protección real en el caso de spam o phishing. El pra para la mayoría de los correos electrónicos legítimos será el conocido campo de encabezado From: o, en el caso de las listas de correo, el campo de encabezado Sender:. Sin embargo, en el caso de phishing o spam, el pra puede basarse en campos de encabezado Resent-* que a menudo no se muestran al usuario. Para que sea una herramienta antiphishing eficaz, el MUA (Mail User Agent o Mail Client) deberá modificarse para mostrar el pra para Sender ID o el campo de encabezado Return-Path: para SPF.
El pra intenta contrarrestar el problema del phishing , mientras que el SPF o el mfrom intentan contrarrestar el problema de los rebotes de spam y otras respuestas automáticas a Return-Paths falsificados. Dos problemas diferentes con dos soluciones propuestas diferentes. Sin embargo, Sender-ID y SPF arrojan el mismo resultado en aproximadamente el 80% de los casos, según un análisis de mil millones de mensajes. [6]
El pra tiene la desventaja de que los reenvíos y las listas de correo sólo pueden admitirlo modificando el encabezado del correo, por ejemplo, insertando un Sendero Resent-Sender. Esto último viola el RFC 2822 [7] y puede ser incompatible con el RFC 822. [8]
Con SPF, las listas de correo siguen funcionando como hasta ahora. Los reenviadores que deseen admitir SPF solo necesitan modificar SMTP MAIL FROM y RCPT TO, no el correo. Este concepto no es nuevo: con el RFC 821 original [9], los reenviadores SMTP siempre añadían su nombre de host a la ruta inversa en MAIL FROM.
El punto más problemático [ ¿según quién? ] en la especificación básica de Sender ID es su recomendación de interpretar v=spf1políticas como spf2.0/mfrom,praen lugar de spf2.0/mfrom. Esto nunca fue la intención de ninguno de los borradores de SPF publicados desde 2003, y para una gran cantidad desconocida de v=spf1políticas, una evaluación de pra podría causar resultados falsos para muchos casos en los que pra y mfrom son diferentes. Este problema fue la base de una apelación al Internet Architecture Board (IAB) . En respuesta a otra apelación anterior, el IESG ya señaló que Sender ID no puede avanzar en la vía de los estándares de IETF sin abordar la incompatibilidad con un MUST en RFC 2822. [7]
Varias encuestas realizadas en 2012, cuando SPF pasó de ser experimental a ser un estándar propuesto, mostraron que menos del 3% de los dominios de correo publicaron solicitudes específicas para usar el pra , en comparación con alrededor del 40~50% de los dominios de correo que usaban SPF. [6]
La propuesta de Sender ID fue objeto de controversia en relación con cuestiones de licencia : Microsoft posee patentes [10] [11] sobre partes clave de Sender ID y solía licenciar esas patentes bajo términos que no eran compatibles con la Licencia Pública General de GNU y que se consideraban problemáticos para las implementaciones de software libre en general. El 23 de octubre de 2006, Microsoft colocó esas patentes bajo la Promesa de Especificación Abierta , que es compatible con algunas licencias libres y de código abierto, pero no con la versión más reciente de la licencia GPL, la versión 3.x. [ cita requerida ]
v=spf1para PRA del proyecto SPF (2006).