DomainKeys Identified Mail ( DKIM ) es unmétodo de autenticación de correo electrónico diseñado para detectar direcciones de remitentes falsificadas en el correo electrónico ( suplantación de correo electrónico ), una técnica que se utiliza a menudo en el phishing y el correo no deseado .
DKIM permite al receptor verificar que un correo electrónico que se dice que proviene de un dominio específico fue autorizado por el propietario de ese dominio. [1] Esto se logra mediante la colocación de una firma digital , vinculada a un nombre de dominio, a cada mensaje de correo electrónico saliente. El sistema del destinatario puede verificar esto buscando la clave pública del remitente publicada en el DNS . Una firma válida también garantiza que algunas partes del correo electrónico (posiblemente incluidos los archivos adjuntos ) no se hayan modificado desde que se colocó la firma. [2] Por lo general, las firmas DKIM no son visibles para los usuarios finales y son fijadas o verificadas por la infraestructura en lugar de los autores y destinatarios del mensaje.
DKIM es un estándar de Internet . [3] Se define en RFC 6376, con fecha de septiembre de 2011; con actualizaciones en RFC 8301 y RFC 8463.
Descripción general
La necesidad de una identificación validada por correo electrónico surge porque las direcciones y el contenido falsificados se crean fácilmente y se utilizan ampliamente en el spam , el phishing y otros fraudes basados en el correo electrónico. Por ejemplo, un estafador puede enviar un mensaje que dice ser de [email protected] , con el objetivo de convencer al destinatario de que acepte y lea el correo electrónico, y es difícil para los destinatarios establecer si confiar en este mensaje. Los administradores de sistemas también tienen que lidiar con las quejas sobre correos electrónicos maliciosos que parecen haberse originado en sus sistemas, pero no lo hicieron. [4]
DKIM proporciona la capacidad de firmar un mensaje y permite al firmante ( organización autor ) comunicar qué correo electrónico considera legítimo. No previene ni revela directamente el comportamiento abusivo.
DKIM también proporciona un proceso para verificar un mensaje firmado. Los módulos de verificación normalmente actúan en nombre de la organización receptora , posiblemente en cada salto .
Todo esto es independiente de los aspectos de enrutamiento del Protocolo simple de transferencia de correo (SMTP), ya que opera en el mensaje RFC 5322, el encabezado y el cuerpo del correo transportado, no en el "sobre" SMTP definido en RFC 5321. Por lo tanto, las firmas DKIM sobreviven a las bases retransmisión a través de múltiples MTA .
Detalles técnicos
Firma
La organización firmante puede ser un gestor directo del mensaje, como el autor, el sitio de envío o un intermediario adicional a lo largo de la ruta de tránsito, o un gestor indirecto, como un servicio independiente que proporciona asistencia a un gestor directo.
Los módulos de firma insertan uno o más DKIM-Signature:
campos de encabezado, posiblemente en nombre de la organización del autor o del proveedor de servicios de origen. La especificación permite a los firmantes elegir qué campos de encabezado firmar, pero el From:
campo siempre debe estar firmado. [5] [6] El campo de encabezado resultante consta de una lista de tag=value
partes como en el siguiente ejemplo:
Firma DKIM: v = 1; a = rsa-sha256; d = ejemplo.net ; s = brisbane; c = relajado / simple; q = dns / txt; t = 1117574938; x = 1118006938; h = desde: hasta: asunto: fecha: palabras clave: palabras clave; bh = MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI =; b = dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav + yuU4zGeeruD00lszZ VoG4ZHRNiYzR
Donde las etiquetas utilizadas son:
- v , versión
- a , algoritmo de firma
- d , dominio
- s , selector
- c , algoritmo (s) de canonicalización para encabezado y cuerpo
- q , método de consulta predeterminado
- t , marca de tiempo de la firma
- x , tiempo de expiración
- h , campos de encabezado: lista de los que se han firmado
- bh , hash corporal
- b , firma de encabezados y cuerpo
Los más relevantes son b para la firma digital real de los contenidos (encabezados y cuerpo) del mensaje de correo, bh para el hash del cuerpo, d para el dominio de firma y s para el selector.
Tanto el encabezado como el cuerpo contribuyen a la firma. Primero, el cuerpo del mensaje tiene un hash, siempre desde el principio, posiblemente truncado en una longitud determinada (que puede ser cero). En segundo lugar, los campos de encabezado seleccionados se hash, en el orden dado por h . Los nombres de campo repetidos se hacen coincidir desde la parte inferior del encabezado hacia arriba, que es el orden en el que Received:
se insertan los campos en el encabezado. Un campo no existente coincide con la cadena vacía, por lo que agregar un campo con ese nombre romperá la firma. El DKIM-Signature:
campo de la firma que se está creando, con bh igual al hash del cuerpo calculado yb igual a la cadena vacía, se agrega implícitamente al segundo hash, aunque su nombre no debe aparecer en h ; si lo hace, se refiere a otro, firma preexistente. Para ambos hashes, el texto se canoniza de acuerdo con los algoritmos c relevantes . El resultado, después de la encriptación con la clave privada del firmante y la codificación usando Base64, es b .
Los algoritmos, los campos y la longitud del cuerpo deben elegirse de manera que se asegure una identificación inequívoca del mensaje y, al mismo tiempo, permitir que las firmas sobrevivan a los cambios inevitables que se producirán durante el tránsito. No se implica la integridad de los datos de un extremo a otro. [2]
Verificación
Un servidor SMTP receptor que desea verificar utiliza el nombre de dominio y el selector para realizar una búsqueda de DNS. [7] Por ejemplo, dado el ejemplo de firma anterior: la etiqueta d da el dominio del autor que se debe verificar con example.net ; la etiqueta s el selector, brisbane . La cadena _domainkey es una parte fija de la especificación. Esto hace que el registro de recursos TXT se busque como:
brisbane._domainkey.example.net
Tenga en cuenta que el selector y el nombre de dominio pueden ser UTF-8 en el correo electrónico internacionalizado. [8] En ese caso, la etiqueta debe estar codificada de acuerdo con IDNA antes de la búsqueda. Los datos devueltos por la consulta de este registro también son una lista de pares etiqueta-valor. Incluye la clave pública del dominio , junto con otros indicadores y tokens de uso de claves; [9] como en este ejemplo:
"k = rsa; t = s; p = MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd / mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg / EW72O1DiYVThkyCgpSYS8nmEQIDAQAB "
El receptor puede usar la clave pública (valor de la etiqueta p ) para luego validar la firma en el valor hash en el campo del encabezado y compararlo con el valor hash del mensaje de correo (encabezados y cuerpo) que se recibió. Si los dos valores coinciden, esto prueba criptográficamente que el correo fue firmado por el dominio indicado y no ha sido manipulado en tránsito.
La falla en la verificación de la firma no obliga al rechazo del mensaje. En su lugar, las razones precisas por las que no se pudo probar la autenticidad del mensaje deberían ponerse a disposición de los procesos descendentes y ascendentes. Los métodos para hacerlo pueden incluir enviar un mensaje FBL o agregar un campo de encabezado de resultados de autenticación al mensaje como se describe en RFC 7001.
Patentar
Aunque DomainKeys está cubierto por la patente estadounidense 6,986,049 , Yahoo! ha licenciado sus reclamos de patentes bajo un esquema de licencia dual: el Acuerdo de Licencia de Patente de DomainKeys v1.2 , [10] o la Licencia Pública General GNU v2.0 (y ninguna otra versión) . [11] [12]
Relación con SPF y DMARC
En esencia, tanto DKIM como SPF proporcionan diferentes medidas de autenticidad del correo electrónico. DMARC proporciona la capacidad para que una organización publique una política que especifique qué mecanismo (DKIM, SPF o ambos) se emplea al enviar correo electrónico desde ese dominio; cómo comprobar el campo De: presentado a los usuarios finales; cómo el receptor debe lidiar con las fallas, y un mecanismo de reporte de las acciones realizadas bajo esas políticas. [13]
Ventajas
La principal ventaja de este sistema para los destinatarios de correo electrónico es que permite que el dominio de firma identifique de manera confiable un flujo de correo electrónico legítimo, lo que permite que las listas blancas y negras basadas en dominios sean más efectivas. [14] También es probable que esto haga que ciertos tipos de ataques de phishing sean más fáciles de detectar.
Existen algunos incentivos para que los remitentes de correo firmen el correo electrónico saliente:
- Permite una gran reducción en el trabajo de escritorio de abuso para dominios habilitados para DKIM si los receptores de correo electrónico usan el sistema DKIM para identificar mensajes de correo electrónico falsificados que afirman ser de ese dominio.
- El propietario del dominio puede entonces enfocar las energías de su equipo de abuso en sus propios usuarios que en realidad están haciendo un uso inapropiado de ese dominio.
Usar con filtrado de spam
DKIM es un método para etiquetar un mensaje y no filtra ni identifica el spam por sí mismo. Sin embargo, el uso generalizado de DKIM puede evitar que los spammers falsifiquen la dirección de origen de sus mensajes, una técnica que emplean comúnmente en la actualidad. Si los spammers se ven obligados a mostrar un dominio de origen correcto, otras técnicas de filtrado pueden funcionar de manera más eficaz. En particular, el dominio de origen puede incorporarse a un sistema de reputación para identificar mejor el spam. Por el contrario, DKIM puede facilitar la identificación de correo que se sabe que no es spam y que no necesita ser filtrado. Si un sistema de recepción tiene una lista blanca de dominios de envío conocidos en buen estado, ya sea mantenidos localmente o de certificadores de terceros, puede omitir el filtrado del correo firmado de esos dominios y quizás filtrar el correo restante de manera más agresiva. [14]
Anti-phishing
DKIM puede resultar útil como tecnología antiphishing . Los remitentes en dominios fuertemente fraudulentos pueden firmar su correo para demostrar que es genuino. Los destinatarios pueden tomar la ausencia de una firma válida en el correo de esos dominios como una indicación de que el correo probablemente sea falso. La mejor manera de determinar el conjunto de dominios que merecen este grado de escrutinio sigue siendo una pregunta abierta. DKIM solía tener una función opcional llamada ADSP que permite a los autores que firman todo su correo autoidentificarse, pero fue degradado al estado histórico en noviembre de 2013. [15] En cambio, DMARC se puede utilizar para el mismo propósito [16] y permite dominios para auto-publicar qué técnicas (incluyendo SPF y DKIM) emplean, lo que facilita al receptor tomar una decisión informada sobre si un determinado correo es spam o no. [17] Por ejemplo, utilizando DMARC, eBay y PayPal publican políticas de que todo su correo está autenticado y solicitan que cualquier sistema de recepción, como Gmail , rechace cualquiera que no lo esté. [18]
Compatibilidad
Debido a que se implementa utilizando registros DNS y un campo de encabezado RFC 5322 agregado, DKIM es compatible con la infraestructura de correo electrónico existente. En particular, es transparente para los sistemas de correo electrónico existentes que carecen de soporte DKIM. [19]
Este enfoque de diseño también es compatible con otros servicios relacionados, como los estándares de protección de contenido S / MIME y OpenPGP . DKIM es compatible con el estándar DNSSEC y con SPF .
Gastos generales de computación
DKIM requiere que se generen sumas de verificación criptográficas para cada mensaje enviado a través de un servidor de correo, lo que da como resultado una sobrecarga computacional que de otro modo no se requiere para la entrega de correo electrónico. Esta sobrecarga computacional adicional es un sello distintivo de los matasellos digitales, lo que hace que el envío de spam masivo sea más costoso (computacionalmente). [20] Esta faceta de DKIM puede parecer similar al hashcash , excepto que la verificación del lado del receptor es una cantidad insignificante de trabajo, mientras que un algoritmo típico de hashcash requeriría mucho más trabajo.
No repudiabilidad
La función de no repudio de DKIM evita que los remitentes (como los spammers) nieguen de manera creíble haber enviado un correo electrónico. Ha demostrado ser útil para fuentes de medios de comunicación como WikiLeaks , que ha podido aprovechar las firmas corporativas de DKIM para demostrar que los correos electrónicos filtrados eran genuinos y no estaban alterados, por ejemplo, repudiar definitivamente tales afirmaciones del compañero de fórmula de Hillary Clinton en las elecciones presidenciales de EE. UU. 2016 Tim Kaine y la presidenta del DNC , Donna Brazile . [21]
Debilidades
El RFC en sí mismo identifica una serie de posibles vectores de ataque. [22]
Las firmas DKIM no abarcan el sobre del mensaje, que contiene la ruta de retorno y los destinatarios del mensaje. Dado que DKIM no intenta proteger contra el direccionamiento incorrecto, esto no afecta su utilidad.
En 2013 se plantearon y refutaron varias preocupaciones en el momento de la estandarización. [23]
Una preocupación para cualquier solución criptográfica sería el abuso de reproducción de mensajes , que pasa por alto las técnicas que actualmente limitan el nivel de abuso de dominios más grandes. [ aclaración necesaria ] La reproducción se puede inferir usando claves públicas por mensaje, rastreando las consultas DNS para esas claves y filtrando el alto número de consultas debido al correo electrónico enviado a grandes listas de correo o consultas maliciosas por parte de malos actores.
Para una comparación de los diferentes métodos que también abordan este problema, consulte Autenticación de correo electrónico .
Reenvío arbitrario
Como se mencionó anteriormente, la autenticación no es lo mismo que la prevención de abusos. Un usuario de correo electrónico malintencionado de un dominio de buena reputación puede redactar un mensaje incorrecto y hacer que lo firmen con DKIM y lo envíen desde ese dominio a cualquier buzón de correo desde donde puedan recuperarlo como un archivo, para obtener una copia firmada del mensaje. El uso de la etiqueta l en las firmas facilita aún más la manipulación de dichos mensajes. La copia firmada se puede reenviar a un millón de destinatarios, por ejemplo, a través de una botnet , sin control. El proveedor de correo electrónico que firmó el mensaje puede bloquear al usuario infractor, pero no puede detener la difusión de mensajes ya firmados. La validez de las firmas en dichos mensajes se puede limitar al incluir siempre una etiqueta de tiempo de vencimiento en las firmas, o al revocar una clave pública periódicamente o al recibir una notificación de un incidente. La eficacia del escenario difícilmente puede limitarse filtrando el correo saliente, ya que eso implica la capacidad de detectar si un mensaje podría ser potencialmente útil para los spammers. [24]
Modificación de contenido
DKIM cuenta actualmente con dos algoritmos de canonicalización , simple y relajado , ninguno de los cuales es consciente de MIME . [25] Los servidores de correo pueden convertir legítimamente a un conjunto de caracteres diferente y, a menudo, documentan esto con campos de encabezado X-MIME-Autoconverted . Además, los servidores en determinadas circunstancias tienen que reescribir la estructura MIME, alterando así el preámbulo , el epílogo y los límites de la entidad, cualquiera de los cuales rompe las firmas DKIM. Solo los mensajes de texto sin formato escritos en us-ascii , siempre que los campos de encabezado MIME no estén firmados, [26] disfrutan de la solidez que requiere la integridad de un extremo a otro.
El proyecto OpenDKIM organizó una recopilación de datos que involucró a 21 servidores de correo y millones de mensajes. El 92,3% de las firmas observadas se verificaron con éxito, una tasa de éxito que cae ligeramente (90,5%) cuando solo se considera el tráfico de la lista de correo. [27]
Anotaciones por listas de correo
Los problemas pueden agravarse cuando el software de filtrado o retransmisión realiza cambios en un mensaje. Sin una precaución específica implementada por el remitente, la adición de pie de página operada por la mayoría de las listas de correo y muchas soluciones antivirus centrales romperá la firma DKIM. Una posible mitigación es firmar solo el número designado de bytes del cuerpo del mensaje. Se indica mediante la etiqueta l en el encabezado DKIM-Signature . Todo lo que se agregue más allá de la longitud especificada del cuerpo del mensaje no se tiene en cuenta al calcular la firma DKIM. Esto no funcionará para los mensajes MIME. [28]
Otra solución es incluir en la lista blanca a los reenviadores conocidos; por ejemplo, por SPF . Para otra solución alternativa, se propuso que los reenviadores verifiquen la firma, modifiquen el correo electrónico y luego vuelvan a firmar el mensaje con un encabezado Sender :. [29] Sin embargo, esta solución tiene su riesgo de reenviar mensajes firmados por terceros recibidos en receptores SMTP que admiten el protocolo RFC 5617 ADSP . Por tanto, en la práctica, el servidor receptor todavía tiene que incluir en la lista blanca los flujos de mensajes conocidos .
La cadena recibida autenticada (ARC) es un sistema de autenticación de correo electrónico diseñado para permitir que un servidor de correo intermedio, como una lista de correo o un servicio de reenvío, firme los resultados de autenticación originales de un correo electrónico. Esto permite que un servicio de recepción valide un correo electrónico cuando el procesamiento de un servidor intermedio invalide los registros SPF y DKIM del correo electrónico . [30] ARC se define en RFC 8617, publicado en julio de 2019, como "Experimental". [31]
Vulnerabilidad de clave corta
En octubre de 2012, Wired informó que el matemático Zach Harris detectó y demostró una vulnerabilidad de suplantación de la fuente de correo electrónico con claves DKIM cortas para el google.com
dominio corporativo, así como varios otros dominios de alto perfil. Afirmó que la autenticación con claves de 384 bits se puede factorizar en tan solo 24 horas "en mi computadora portátil" y claves de 512 bits, en aproximadamente 72 horas con recursos de computación en la nube. Harris descubrió que muchas organizaciones firman correos electrónicos con claves tan cortas; los factorizó a todos y notificó a las organizaciones sobre la vulnerabilidad. Afirma que las claves de 768 bits podrían factorizarse con acceso a cantidades muy grandes de potencia informática, por lo que sugiere que la firma DKIM debería utilizar longitudes de clave superiores a 1.024.
Wired declaró que Harris informó, y Google confirmó, que comenzaron a usar nuevas claves más largas poco después de su divulgación. Según RFC 6376, la parte receptora debe poder validar firmas con claves que oscilan entre 512 bits y 2048 bits, por lo que el uso de claves de menos de 512 bits puede ser incompatible y debe evitarse. El RFC 6376 también establece que los firmantes deben usar claves de al menos 1024 bits para las claves de larga duración, aunque la duración no se especifica allí. [32]
Historia
DKIM resultó en 2004 de la fusión de dos esfuerzos similares, "DomainKeys mejorados" de Yahoo y "Identified Internet Mail" de Cisco . [33] [34] Esta especificación fusionada ha sido la base para una serie de especificaciones de seguimiento de estándares IETF y documentos de soporte que eventualmente resultaron en STD 76 , actualmente RFC 6376. [35] El "correo de Internet identificado" fue propuesto por Cisco como un Estándar de autenticación de correo basado en firmas, [36] [37] mientras que DomainKeys fue diseñado por Yahoo [38] [39] para verificar el dominio DNS de un remitente de correo electrónico y la integridad del mensaje .
Los aspectos de DomainKeys, junto con partes de Identified Internet Mail, se combinaron para crear DomainKeys Identified Mail (DKIM). [38] [40] [41] Los proveedores que marcan tendencia que implementan DKIM incluyen Yahoo , Gmail , AOL y FastMail . Cualquier correo de estas organizaciones debe llevar una firma DKIM. [38] [42] [43] [44]
Las discusiones sobre las firmas DKIM que pasan a través de flujos de correo indirectos, formalmente en el grupo de trabajo DMARC, tuvieron lugar justo después de que las primeras adopciones del nuevo protocolo causaron estragos en el uso regular de las listas de correo . Sin embargo, ninguno de los cambios DKIM propuestos se aprobó. En su lugar, se cambió el software de la lista de correo. [45]
En 2017, se lanzó otro grupo de trabajo, DKIM Crypto Update (dcrup), con la restricción específica de revisar las técnicas de firma. [46] RFC 8301 se emitió en enero de 2018. Prohíbe SHA-1 y actualiza los tamaños de clave (de 512 a 2048 a 1024 a 4096). [47] RFC 8463 se emitió en septiembre de 2018. Agrega un algoritmo de curva elíptica al RSA existente . El tipo de clave agregado es suficientemente fuerte al tiempo que presenta claves públicas cortas, más fácilmente publicables en DNS. [48]k=ed25519
Desarrollo
El DomainKeys original fue diseñado por Mark Delany de Yahoo! y mejorado a través de comentarios de muchos otros desde 2004. Se especifica en el histórico RFC 4870, reemplazado por Standards Track RFC 4871, DomainKeys Identified Mail (DKIM) Firmas; ambos publicados en mayo de 2007. Posteriormente se recopilaron varias aclaraciones y conceptualizaciones y se especificaron en RFC 5672, agosto de 2009, en forma de correcciones a la especificación existente. En septiembre de 2011, RFC 6376 fusionó y actualizó los dos últimos documentos, conservando la esencia del protocolo DKIM. También es posible la compatibilidad de claves públicas con las DomainKeys anteriores.
DKIM fue inicialmente producido por un consorcio informal de la industria y luego fue presentado para mejora y estandarización por el Grupo de Trabajo IETF DKIM, presidido por Barry Leiba y Stephen Farrell, con Eric Allman de sendmail , Jon Callas de PGP Corporation , Mark Delany y Miles Libbey de Yahoo! y Jim Fenton y Michael Thomas de Cisco Systems atribuidos como autores principales.
El desarrollo del código fuente de una biblioteca común está dirigido por The OpenDKIM Project , siguiendo las adiciones de protocolo más recientes y la licencia bajo la Nueva Licencia BSD . [49]
Ver también
- Cadena recibida autenticada (ARC)
- Prácticas de firma de dominio de autor
- Mensaje de rebote
- Filtrado de contexto
- Autenticación, informes y conformidad de mensajes basados en dominios (DMARC)
- DomainKeys
- Verificacion de Email
- OpenPGP
- S / MIME
- Marco de políticas del remitente
- Garantizar por referencia
Referencias
- ^ Tony Hansen; Dave Crocker; Phillip Hallam-Baker (julio de 2009). Descripción general del servicio DomainKeys Identified Mail (DKIM) . IETF . doi : 10.17487 / RFC5585 . RFC 5585 . Consultado el 6 de enero de 2016 .
Los receptores que verifican con éxito una firma pueden utilizar información sobre el firmante como parte de un programa para limitar el spam, la suplantación de identidad, el phishing u otros comportamientos no deseados. DKIM, por sí mismo, no prescribe ninguna acción específica por parte del destinatario; más bien, es una tecnología habilitadora para los servicios que lo hacen.
- ^ a b Dave Crocker; Tony Hansen; Murray S. Kucherawy, eds. (Septiembre de 2011). "Integridad de los datos" . Firmas de correo identificado de DomainKeys (DKIM) . IETF . segundo. 1.5. doi : 10.17487 / RFC6376 . RFC 6376 . Consultado el 6 de enero de 2016 .
La verificación de la firma afirma que el contenido hash no ha cambiado desde que se firmó y no afirma nada más sobre "proteger" la integridad de un extremo a otro del mensaje.
- ^ Crocker, D .; Hansen, T .; Kucherawy, M. "Firmas de correo identificado de DomainKeys (DKIM)" . Editor de RFC . ISSN 2070-1721 . Consultado el 30 de marzo de 2020 .
- ^ Jason P. Stadtlander (16 de enero de 2015). "Spoofing de correo electrónico: explicado (y cómo protegerse)" . HuffPost . Consultado el 11 de enero de 2016 .
- ^ Dave Crocker; Tony Hansen; Murray S. Kucherawy, eds. (Julio de 2009). "Determine los campos de encabezado para firmar" . Firmas de correo identificado de DomainKeys (DKIM) . IETF . segundo. 5.4. doi : 10.17487 / RFC6376 . RFC 6376 . Consultado el 6 de enero de 2016 .
El campo de encabezado De DEBE estar firmado (es decir, incluido en la etiqueta "h =" del campo de encabezado DKIM-Signature resultante).
- ^ Los módulos de firma utilizan la mitad privada de un par de claves para realizar la firma y publican la mitad pública en un registro TXT de DNS como se describe en la sección "Verificación" a continuación.
- ^ Tenga en cuenta que no hay CA ni listas de revocación involucradas en la administración de claves DKIM, y el selector es un método sencillo para permitir que los firmantes agreguen y eliminen claves cuando lo deseen; las firmas duraderas con fines de archivo están fuera del alcance de DKIM.
- ^ John Levine (junio de 2019). "DKIM y correo internacionalizado" . Autenticación de correo electrónico para correo internacionalizado . IETF . segundo. 5. doi : 10.17487 / RFC8616 . RFC 8616 .
- ^ por ejemplo, desde una línea de comandos: nslookup -q = TXT brisbane._domainkey.example.net
- ^ "Acuerdo de licencia de patente de Yahoo! DomainKeys v1.1" . SourceForge . 2006 . Consultado el 30 de mayo de 2010 .
Yahoo! Acuerdo de licencia de patente de DomainKeys v1.2
- ^ Levine, John R. (25 de enero de 2010). "Divulgaciones de derechos de propiedad intelectual, recopilaba preguntas sobre reestructuración" . lista de correo ietf-dkim . Asociación Mutua de Prácticas de Internet . Consultado el 30 de mayo de 2010 .
La referencia a la GPL me parece que solo cubre la antigua biblioteca Sourceforge DK, que no creo que nadie use más. La patente, que es lo importante, está cubierta por una licencia separada que escribió Yahoo.
- ^ Chen, Andy (26 de septiembre de 2011). "Declaración de Yahoo! Inc. sobre los derechos de propiedad intelectual relacionados con RFC 6376" . Divulgación de derechos de propiedad intelectual . IETF . Consultado el 3 de octubre de 2011 .
- ^ "Historia" . dmarc.org .
- ^ a b Falk, JD (17 de marzo de 2009). "Buscando la verdad en DKIM" . CircleID.
- ^ Barry Leiba (25 de noviembre de 2013). "Cambiar el estado de ADSP (RFC 5617) a Histórico" . IETF . Consultado el 13 de marzo de 2015 .
- ^ "Preguntas frecuentes - Wiki DMARC" .
El estándar DMARC establece en la Sección 6.7, “Consideraciones de aplicación de políticas”, que si se descubre una política DMARC, el receptor debe ignorar las políticas anunciadas a través de otros medios como SPF o ADSP.
- ^ "Agregar un registro DMARC - Ayuda del administrador de Google Apps" .
- ^ "Acerca de DMARC - Ayuda para administradores de Google Apps" .
Su política puede ser estricta o relajada. Por ejemplo, eBay y PayPal publican una política que requiere que todo su correo sea autenticado para aparecer en la bandeja de entrada de alguien. De acuerdo con su política, Google rechaza todos los mensajes de eBay o PayPal que no estén autenticados.
- ^ Tony Hansen; Dave Crocker; Phillip Hallam-Baker (julio de 2009). Descripción general del servicio DomainKeys Identified Mail (DKIM) . IETF . doi : 10.17487 / RFC5585 . RFC 5585 . Consultado el 1 de julio de 2013 .
- ^ Roic, Alessio (5 de julio de 2007). "Matasellos: ayudando en la lucha contra el spam" Archivado el 17 de julio de 2011 en Wayback Machine . Blog de Microsoft Office Outlook.
- ^ "Verificación DKIM" . www.wikileaks.org . 4 de noviembre de 2016 . Consultado el 7 de noviembre de 2016 .
- ^ "Consideraciones de seguridad" , ietf.org
- ^ "Informe IESG sobre" Apelación de decisión de adelantar RFC6376 " " . IETF.org . IETF . Consultado el 26 de diciembre de 2018 .
- ^ Jim Fenton (septiembre de 2006). "Reproducción de mensaje elegido" . Análisis de Amenazas que Motivan el Correo Identificado DomainKeys (DKIM) . IETF . segundo. 4.1.4. doi : 10.17487 / RFC4686 . RFC 4686 . Consultado el 10 de enero de 2016 .
- ^ Ned Freed (con el consentimiento de John Klensin ) (5 de marzo de 2010). "Revisión de secdir del borrador-ietf-yam-rfc1652bis-03" . Lista de correo de YAM . IETF . Consultado el 30 de mayo de 2010 .
DKIM WG optó por la simplicidad de la forma canónica en lugar de una forma canónica que es robusta frente a los cambios de codificación. Fue su elección de ingeniería y lo hicieron.
- ^ RFC 2045 permite que el valor de un parámetro sea un token o una cadena entre comillas, por ejemplo, en {{{1}}} las comillas se pueden eliminar legalmente, lo que rompe las firmas DKIM.
- ^ Kucherawy, Murray (28 de marzo de 2011). "Informe de implementación RFC4871" . IETF . Consultado el 18 de febrero de 2012 .
- ^ Murray S. Kucherawy (septiembre de 2011). DomainKeys Identified Mail (DKIM) y listas de distribución . IETF . doi : 10.17487 / RFC6377 . RFC 6377 . Consultado el 10 de enero de 2016 .
- ^ Eric Allman; Mark Delany; Jim Fenton (agosto de 2006). "Acciones del administrador de listas de correo" . Prácticas de firma de remitentes DKIM . IETF . segundo. 5.1. Proyecto de identificación-allman-dkim-ssp-02 . Consultado el 10 de enero de 2016 .
- ^ "Descripción general de la cadena recibida autenticada" (PDF) . Consultado el 15 de junio de 2017 .
- ^ "RFC 8617 - El protocolo de cadena recibida autenticada (ARC)" . datatracker.ietf.org . Consultado el 17 de julio de 2019 .
- ^ Zetter, Kim (24 de octubre de 2012). "Cómo un correo electrónico de Google Headhunter desenreda un enorme agujero de seguridad en la red" . Cableado . Consultado el 24 de octubre de 2012.
- ^ "Preguntas frecuentes sobre DKIM" . DKIM.org . 16 de octubre de 2007 . Consultado el 4 de enero de 2016 .
DKIM fue producido por un consorcio de la industria en 2004. Fusionó y mejoró DomainKeys, de Yahoo! y correo de Internet identificado, de Cisco.
- ^ Jim Fenton (15 de junio de 2009). "DomainKeys Identified Mail (DKIM) crece significativamente" . Cisco . Archivado desde el original el 24 de diciembre de 2014 . Consultado el 28 de octubre de 2014 .
- ^ "STD 76, RFC 6376 sobre firmas de correo identificado por DomainKeys (DKIM)" . IETF . 11 de julio de 2013 . Consultado el 12 de julio de 2013 .
RFC 6376 se ha elevado a estándar de Internet.
- ^ "Correo de Internet identificado: un enfoque de firma de mensajes basado en la red para combatir el fraude por correo electrónico" . 26 de abril de 2006. Archivado desde el original el 27 de abril de 2006 . Consultado el 4 de enero de 2016 .
- ^ Jim Fenton; Michael Thomas (1 de junio de 2004). Correo de Internet identificado . IETF . Proyecto de identificación-correo-identificado-fenton-00 . Consultado el 6 de enero de 2016 .
- ↑ a b c Delany, Mark (22 de mayo de 2007). "Un pequeño paso para el correo electrónico, un gran paso para la seguridad en Internet" . Yahoo! blog corporativo. A Delany se le acredita como arquitecto jefe, inventor de DomainKeys.
- ^ "Yahoo publica especificaciones para DomainKeys" . DMNews.com .
- ^ RFC 4870 ("Autenticación de correo electrónico basada en dominio mediante claves públicas anunciadas en el DNS (DomainKeys)"; obsoleto por RFC 4871).
- ^ RFC 6376 ("Firmas de correo identificado de DomainKeys (DKIM)"; obsoleto RFC 4871 y RFC 5672).
- ^ Taylor, Brad (8 de julio de 2008). "Lucha contra el phishing con eBay y Paypal" . Blog de Gmail.
- ^ "Tengo problemas para enviar mensajes en Gmail" . Entrada de ayuda de Gmail, mencionando la compatibilidad con DKIM al enviar.
- ^ Mueller, Rob (13 de agosto de 2009). "Todo el correo electrónico saliente ahora está firmado con DKIM" . Blog de Fastmail.
- ^ "Historial del grupo DMARC" . IETF .
- ^ "Actualización de cifrado DKIM (dcrup)" . IETF .
- ^ Scott Kitterman (enero de 2018). Actualización de algoritmo criptográfico y uso de claves para DomainKeys Identified Mail (DKIM) . IETF . doi : 10.17487 / RFC8301 . RFC 8301 .
- ^ John Levine (septiembre de 2018). Un nuevo método de firma criptográfica para el correo identificado con DomainKeys (DKIM) . IETF . doi : 10.17487 / RFC8463 . RFC 8463 .
- ^ "OpenDKIM" .
Otras lecturas
- RFC 4686 Análisis de amenazas que motivan el correo identificado por claves de dominio (DKIM)
- RFC 4871 DomainKeys Identified Mail (DKIM) Firmas Estándar propuesto
- RFC 5617 DomainKeys Identified Mail (DKIM) Prácticas de firma de dominio de autor (ADSP)
- RFC 5585 Descripción general del servicio DomainKeys Identified Mail (DKIM)
- RFC 5672 RFC 4871 Firmas de correo identificado por claves de dominio (DKIM): actualización
- RFC 5863 Desarrollo, implementación y operaciones de DKIM
- RFC 6376 DomainKeys Identified Mail (DKIM) Firmas Borrador de estándar
- RFC 6377 DomainKeys Identified Mail (DKIM) y listas de distribución
- RFC 8301 Actualización de uso de claves y algoritmo criptográfico para el correo identificado de DomainKeys (DKIM)
enlaces externos
- Correo identificado de DomainKeys (DKIM)