Sender ID es una propuesta histórica [1] contra la suplantación de identidad del antiguo grupo de trabajo MARID IETF que intentó unirse al Sender Policy Framework (SPF) y al Caller ID. La identificación del remitente se define principalmente en el RFC 4406 experimental, [2] pero hay partes adicionales en el RFC 4405, [3] el RFC 4407 [4] y el RFC 4408. [5]
Principios de Operación
La identificación del remitente se basa en gran medida en SPF , con solo algunas adiciones.
El ID del remitente intenta mejorar SPF: SPF no verifica las direcciones de encabezado (de las cuales puede haber más de una) que indican la parte remitente reclamada. Una de estas direcciones de encabezado generalmente se muestra al usuario y se puede usar para responder correos electrónicos. Estas direcciones de encabezado pueden ser diferentes de la dirección que SPF intenta verificar; es decir, SPF verifica solo 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 emisora; por lo tanto, Sender ID define en RFC 4407 [4] una supuesta dirección responsable (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, el Id. Del remitente es casi idéntico al SPF, excepto que v=spf1
se reemplaza por uno de los siguientes:
spf2.0/mfrom
- lo que significa verificar la dirección del remitente del sobre como SPF.spf2.0/mfrom,pra
ospf2.0/pra,mfrom
- queriendo verificar tanto el remitente del sobre como el PRA.spf2.0/pra
- lo que significa verificar solo el PRA.
La única otra diferencia sintáctica es que Sender ID ofrece la función de modificadores de posición no admitidos en SPF. En la práctica, hasta ahora no se ha especificado ningún modificador posicional en ninguna implementación de Id. De remitente.
En la práctica, el esquema pra generalmente solo ofrece protección cuando el correo electrónico es legítimo, mientras que no ofrece una protección real en el caso de spam o phishing. El pra para el correo electrónico más legítimo será el conocido campo de encabezado From: o, en el caso de 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 anti-phishing efectiva, el MUA (Agente de usuario de correo o Cliente de correo) deberá modificarse para mostrar el pra de Id. Del remitente o el campo de encabezado Return-Path: para SPF.
El pra intenta contrarrestar el problema del phishing , mientras que SPF o mfrom intenta contrarrestar el problema de los rebotes de spam y otras respuestas automáticas a las rutas de retorno falsificadas. Dos problemas diferentes con dos soluciones propuestas diferentes. Sin embargo, Sender-ID y SPF producen el mismo resultado en aproximadamente el 80% de los casos, según un análisis de mil millones de mensajes. [6]
Problemas de estandarización
El pra tiene la desventaja de que los reenviadores y las listas de correo solo pueden admitirlo modificando el encabezado del correo, por ejemplo, insertando una Sender
o Resent-Sender
. Este último viola RFC 2822 [7] y puede ser incompatible con RFC 822. [8]
Con SPF, las listas de correo continúan funcionando como están. 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 [9] original, los reenviadores SMTP siempre agregaban 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 de ID de remitente principal es su recomendación para interpretar las v=spf1
políticas como en spf2.0/mfrom,pra
lugar de spf2.0/mfrom
. Esto nunca fue previsto por todos los borradores de SPF publicados desde 2003, y para un gran número desconocido de v=spf1
políticas, una evaluación de pra podría causar resultados falsos en muchos casos en los que pra y mfrom son diferentes. Este problema fue la base de un llamamiento a la Junta de Arquitectura de Internet (IAB) . En respuesta a otra apelación anterior, el IESG ya señaló que el Sender ID no puede avanzar en la pista de los estándares del IETF sin abordar la incompatibilidad con un MUST en RFC 2822. [10]
Varias encuestas realizadas en 2012, cuando SPF pasó del estándar experimental al propuesto, mostraron que menos del 3% de los dominios de correo publicaron solicitudes específicas para usar pra , en comparación con alrededor del 40 ~ 50% de los dominios de correo que usan SPF. [6]
Patentes
La propuesta de Sender ID fue objeto de controversia con respecto a cuestiones de licencia : Microsoft posee patentes [11] [12] sobre partes clave de Sender ID y se utiliza para licenciar esas patentes en términos que no eran compatibles con la Licencia Pública General GNU y que se consideraron problemático 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 gratuitas 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 ]
Ver también
- Categoría: Autenticación de correo electrónico
- Descripción general de la autenticación de correo electrónico
- MARID (IETF WG en 2004)
- DKIM
- DomainKeys
Referencias
- ^ Alexey Melnikov (7 de febrero de 2020). "Moviendo RFC 4405, RFC 4406, RFC 4407 (Sender-ID) a Histórico" . IETF .
- ^ Wong, Meng Weng; Lyon, Jim. "ID del remitente: autenticación de correo electrónico" . tools.ietf.org . Consultado el 11 de marzo de 2021 .
- ^ Katz, Harry; Allman, Eric. "Extensión del servicio SMTP para indicar el remitente responsable de un mensaje de correo electrónico" . tools.ietf.org . Consultado el 11 de marzo de 2021 .
- ^ a b Lyon
, Jim. @microsoft.com>"Dirección supuestamente responsable en mensajes de correo electrónico" . tools.ietf.org . Consultado el 11 de marzo de 2021 . - ^ Schlitt, Wayne; Wong, Meng Weng. "Marco de políticas del remitente (SPF) para autorizar el uso de dominios en el correo electrónico, versión 1" . tools.ietf.org . Consultado el 11 de marzo de 2021 .
- ^ a b Murray Kucherawy (2012). Resolución del marco de políticas del remitente (SPF) y experimentos de identificación del remitente . IETF . doi : 10.17487 / RFC6686 . RFC 6686 .
- ^ Resnick
, Peter W. @qualcomm.com>"Formato de mensaje de Internet" . tools.ietf.org . Consultado el 11 de marzo de 2021 . - ^ Crocker, D. "ESTÁNDAR PARA EL FORMATO DE LOS MENSAJES DE TEXTO DE INTERNET DE ARPA" . tools.ietf.org . Consultado el 11 de marzo de 2021 .
- ^ Postel, J. "Protocolo simple de transferencia de correo" . tools.ietf.org . Consultado el 11 de marzo de 2021 .
- ^ Resnick
, Peter W. @qualcomm.com>"Formato de mensaje de Internet" . tools.ietf.org . Consultado el 11 de marzo de 2021 . - ^ "Copia archivada" . Archivado desde el original el 14 de abril de 2012 . Consultado el 20 de diciembre de 2011 .CS1 maint: copia archivada como título ( enlace )
- ^ http://www.internetnews.com/dev-news/article.php/3409971/Exposed+Sender+ID+Patents+Up+Debate.htm
enlaces externos
- Posición de ASF con respecto a la declaración de identificación del remitente de Apache Software Foundation
- Apelación de la IAB sobre la reutilización de Sender ID
v=spf1
para PRA del proyecto SPF (2006). - El proyecto Debian no puede implementar la declaración de ID del remitente por elproyecto Debian
- IETF decide sobre la cobertura del problema de SPF / Sender-ID y discusión sobre slashdot
- ¿La identificación del remitente está muerta en el agua? - Sin cobertura de consenso del Grupo de Trabajo MARID y discusión sobre groklaw
- Los copresidentes de MARID aclaran la declaración de consenso
- MARID para cerrar el hilo de la lista de correo.
- Identificación del remitente: ¿Una historia de estándares abiertos y codicia corporativa?
- "SPF: SPF frente a ID de remitente"
- "Tipos de Id. De remitente en diferentes países"
- "Identificación del remitente"