ID del remitente

Sender ID es una propuesta histórica ^{[ 1 ]} contra la suplantación de identidad del antiguo grupo de trabajo MARID IETF que intentó combinar Sender Policy Framework (SPF) y Caller ID. Sender ID se define principalmente en el RFC experimental 4406 , ^{[ 2 ]} pero hay partes adicionales en el RFC 4405 , ^{[ 3 ]} RFC 4407 ^{[ 4 ]} y RFC 4408. ^{[ 5 ]}

Sender ID se basa en gran medida en SPF , con solo algunas adiciones.

Sender ID busca mejorar SPF: SPF no verifica las direcciones de encabezado (que pueden ser varias) que indican quién es el remitente declarado. Normalmente, una de estas direcciones se muestra al usuario y puede usarse para responder correos electrónicos. Estas direcciones de encabezado pueden ser diferentes de la dirección que SPF intenta verificar; es decir, SPF solo verifica la dirección "MAIL FROM", también conocida como 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 Presunta (PRA), así como un conjunto de reglas heurísticas para establecer esta dirección a partir de los muchos encabezados típicos en 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, al igual que con el SPF.
• spf2.0/mfrom,prao – lo que significa verificar tanto al remitente del sobre como a la PRA.spf2.0/pra,mfrom 
• spf2.0/pra – lo que significa verificar únicamente el PRA.

La única otra diferencia sintáctica es que Sender ID ofrece la función de modificadores posicionales que no son compatibles con SPF. En la práctica, hasta el momento 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, sin brindar protección real en caso de spam o phishing. Para la mayoría de los correos electrónicos legítimos, el pra será el campo de encabezado From:, ya sea el conocido From: o, en el caso de listas de correo, el campo Sender:. Sin embargo, en 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 cliente de correo (MUA) 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 MFO 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 ]}

La pra tiene la desventaja de que los reenviadores y las listas de correo solo pueden admitirla modificando el encabezado del correo, por ejemplo, insertando un Sendero Resent-Sender. Esto último viola la RFC 2822 ^{[ 7 ]} y puede ser incompatible con la RFC 822 . ^{[ 8 ]}

Con SPF, las listas de correo siguen funcionando como hasta ahora. Los reenviadores que deseen admitir SPF solo necesitan modificar los campos MAIL FROM y RCPT TO de SMTP, no el correo. Este concepto no es nuevo: con la RFC 821 original ^{[ 9 ],} los reenviadores SMTP siempre añadían su nombre de host a la ruta inversa en el campo MAIL FROM.

El punto más problemático de la especificación central de Sender ID es su recomendación de interpretar políticas como en lugar de . Esto nunca fue la intención de todos los borradores SPF publicados desde 2003, y para un número desconocido de políticas, una evaluación para pra podría causar resultados falsos en muchos casos donde pra y mfrom son diferentes. Este problema fue la base de una apelación ante la Junta de Arquitectura de Internet (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 IETF sin abordar la incompatibilidad con un MUST en RFC 2822. ^{[ 7 ]}v=spf1spf2.0/mfrom,praspf2.0/mfromv=spf1

Varias encuestas realizadas en 2012, cuando SPF pasó de ser experimental a estándar propuesto, mostraron que menos del 3% de los dominios de correo publicaron solicitudes específicas para usar la pra , en comparación con aproximadamente el 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 licencias : 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.

• Categoría: Autenticación de correo electrónico
• Descripción general de la autenticación de correo electrónico
• MARID (Grupo de Trabajo del IETF en 2004)
• DKIM
• Claves de dominio

• Posición de la ASF con respecto a la declaración Sender ID de la Apache Software Foundation
• Apelación de IAB archivada el 30 de mayo de 2011 en Wayback Machine sobre la reutilización de Sender ID v=spf1para PRA del proyecto SPF (2006).
• El proyecto Debian no puede implementar la declaración Sender ID delproyecto Debian.
• El IETF decide sobre la cobertura y el debate del tema SPF/Sender-ID en Slashdot.
• ¿Está Sender ID muerto? - Cobertura y debate del consenso del Grupo de Trabajo No MARID en groklaw
• Los copresidentes de MARID aclaran la declaración de consenso.
• MARID cerrará el hilo de la lista de correo.
• Identificador del remitente: ¿Una historia de estándares abiertos y avaricia corporativa?
• "SPF: SPF vs. Identificador del remitente" Archivado el 2 de noviembre de 2007 en Wayback Machine.
• "Tipos de identificadores de remitente en diferentes países"
• "Identificador del remitente"
• Identificadores de remitente, plantillas de SMS