Anda di halaman 1dari 5

DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) es un mecanismo de autenticación de correo electrónico que permite a una organización
responsabilizarse del envío de un mensaje, de manera que éste pueda ser validado por un destinatario. Dicha organización puede ser
una fuente directa del mensaje, como el autor, el servidor encargado de gestionar el correo de ese dominio, o un servidor intermedio
situado en el tránsito que recorre dicho correo, como por ejemplo un servicio independiente que provee recursos de correo al servidor
que gestiona el dominio principal.

La necesidad de este tipo de autenticación surge por la falsificación de contenidos de las que hace uso el spam. Por ejemplo, un
mensaje de spam puede falsear el campo "From:" de las cabeceras de un mensaje diciendo que el origen es usuario@ejemplo.com,
cuando realmente no proviene de esa dirección, y el único objetivo del spammer es convencer al destinatario de que acepte y lea el
mensaje. Como el mensaje no proviene realmente del dominio usuario@ejemplo.com, quejarse a ese dominio no serviría de nada.
Además, resulta complicado por parte de los destinatarios el distinguir cuándo deben confiar o no en un determinado dominio, y los
administradores de correo tienen que hacerse cargo de quejas de spam que supuestamente se originan desde su dominio, cuando
realmente no es así.

DKIM utiliza criptografía de clave pública para permitir al origen firmar electrónicamente correos electrónicos legítimos de manera
que puedan ser verificados por los destinatarios. Entre los proveedores de servicio de correo que implementan ese sistema se
encuentran Yahoo, Gmail, y FastMail. Cualquier correo originado desde estas organizaciones deben llevar una firma DKIM.1 2 3 4

DKIM también protege contra la manipulación de correo electrónico, proporcionando integridad de extremo a extremo, desde un
módulo firmante a un módulo validador. En la mayoría de los casos el módulo firmante actúa en nombre de la organización
originaria insertando una firma DKIM en las cabeceras del mensaje, y el módulo de comprobación en nombre de la organización
del receptor, validando la firma obteniendo la clave pública del firmante a través delDNS.

DKIM, según informa la página principal de la Organización DKIM, es el resultado de la fusión de DomainKeys y de Identified
Internet Mail. La especificación de esta fusión ha sido la base de un Grupo de Trabajo IETF que ha producido una serie de
especificaciones de estándares y documentos técnicos de soporte
.

Índice
Resumen
Cómo funciona
Desarrollo
Ventajas
Utilizado en conjunto con el filtrado de spam
Compatibilidad
Debilidades
Reenvío arbitrario
Modificación de contenido en tránsito
Coste computacional del protocolo
Véase también
Referencias
Enlaces externos

Resumen
DKIM es un método de autentificación de correo electrónico. A diferencia de otros métodos, ofrece integridad de datos de extremo a
extremo, desde un módulo firmante a un módulo validador como por ejemplo un Agente de Transporte de Correo (MTA). En la
mayoría de los casos el módulo firmante actúa en nombre de la organización remitente del mensaje, y el módulo validador en
nombre de la organización receptora del mensaje. DomainKeys se especifica en el RFC 4870, que ha sido actualizado en el RFC
4871, "DomainKeys Identified Mail (DKIM) Signatures" y posteriormente en el RFC 5672, "DomainKeys Identified Mail (DKIM)
Signatures -- Update".

DKIM es independiente del protocolo SMTP, actuando en el cuerpo y cabeceras del mensaje (RFC 5322) y no en la conversación
SMTP definida en el RFC 5321.

DKIM permite a la entidad firmante distinguir el flujo de su mail legítimo, pero no previene o identifica el comportamiento abusivo.
Esta capacidad de distinguir o firmar el correo legítimo tiene beneficios tanto para los destinatarios del correo como para los
remitentes. Además, ya hay clientes de correo electrónico que son capaces de hacer uso de ella.

Cómo funciona
DKIM añade una cabecera llamada "DKIM-Signature" que contiene una firma digital del contenido (cabeceras y cuerpo) del
mensaje. Los parámetros por defecto del mecanismo de autenticación son la utilización de SHA-256 como la firma criptográfica y
RSA como el esquema de criptografía asimétrica. Finalmente se codifica la firma resultante conBase64.

El servidor SMTP utiliza el nombre de dominio perteneciente al emisor, la cadena "_domainkey", y un selector del campo de la firma
DKIM para realizar una consulta al DNS. La respuesta debe incluir la clave pública del dominio. El receptor puede utilizar esta
información para descifrar el valor de la firma del campo de la cabecera, y al mismo tiempo, recalcular el valor de la firma para el
mensaje (cabeceras y cuerpo) que ha recibido. Si los dos resultados coinciden, esto prueba criptográficamente que el mensaje fue
firmado por el dominio indicado y que no ha sido alterado en tránsito.

Un fallo en la verificación de la firma no fuerza el rechazo del mensaje. Por contra, las razones precisas por las cuales la autenticidad
del mensaje no ha podido ser verificada deberían comunicarse tanto al proceso de envío como el de recepción. Los métodos para
llevar a cabo esta misión podrían ser enviar un mensaje FBL, o añadir una cabecera de Authentication-Results al mensaje tal y como
se describe en el RFC 5451.

Desarrollo
DomainKeys fue diseñado porMark Delany, de Yahoo!, y mejorado mediante los comentarios de mucha otra gente.

DKIM fue inicialmente desarrollado por un consorcio formado por un grupo de industria informal y posteriormente se presentó para
mejorar y estandarizar por el Grupo de Trabajo DKIM de la IETF, presidido por Barry Leiba y Stephen Farrell, con Eric Allman de
sendmail, Jon Callas de la Corporación PGP, Mark Delany y Miles Libbey de Yahoo!, y Jim Fenton y Michael Thomas de Cisco
Systems a los que se les atribuye la autoría principal.

DomainKeys está cubierto por la Patente USPTO nº 6986049 asignada a Yahoo!, que ha liberado DomainKeys bajo una licencia
dual: la licencia tradicional orientada a empresas libre de royalties, no exclusiva, y relicenciable diseñada para complementarse bien
con las implementaciones open source y free software, y también bajo GPL 2.0 para llevar a cabo el propósito del Grupo de Trabajo
DKIM de la IETF.

Ventajas
La principal ventaja de este sistema para los receptores de e-mail es que permite firmar el dominio de manera que se puede identificar
de manera fiable el flujo de correo legítimo, lo que permite que la utilización de listas blancas o negras basadas en dominio sean
mucho más efectivas.

Hay algunas ventajas para el que envía correo al firmarlo con DKIM:
Permite reducir drásticamente la falsificación de dominios de origen del mensaje, ya que podremos identificar
perfectamente aquellos e-mails que hayan sido firmados si su dominio tiene el DKIM habilitado.
El poseedor del dominio puede centrar sus esfuerzos para evitar el abuso reduciendo el ámbito de uso inapropiado
de ese dominio a sus mismos usuarios.

Utilizado en conjunto con el filtrado de spam


DKIM es una tecnología de autenticación, y no identifica o filtra el spam por sí mismo. Sin embargo, el uso generalizado de DKIM
puede evitar que los spammers falsear la dirección de origen de sus mensajes, una técnica que emplean habitualmente.

Si los spammers se ven obligados a utilizar un dominio de origen correcto, las técnicas de filtrado de spam podrán trabajar más
eficazmente.

En particular, el dominio de origen, puedan introducirse en unsistema de reputación para identificar mejor el spam.

Por el contrario, DKIM puede hacer que sea más fácil identificar el correo que sabemos que no es spam y por tanto no necesita ser
filtrado. Si un sistema de recepción de correo tiene una lista blanca de dominios que envían correo lícito, ya sea local o mantenida por
una tercera parte certificadora, puede saltarse el filtro de correo electrónico firmado desde esos dominios, y entonces filtrar el correoo
electrónico restante de manera más agresiva.5

DKIM puede ser útil como una tecnología anti-phishing. Los servidores de correo salientes de los dominios que sufren más ataques
de phishing pueden firmar su correo para demostrar que es lícito. Los destinatarios pueden asociar la ausencia de firma en el correo
de estos dominios como una indicación de que el correo es probablemente falso. La mejor manera de determinar el conjunto de
dominios que merecen este grado de control sigue siendo una cuestión abierta; DKIM, probablemente tendrá una función opcional
llamada ADSP que permite a los emisores que firman todos sus correos el auto-identificarse, pero la eficacia de este enfoque está
siendo sometida a prueba.6 7

Compatibilidad
Dado que DKIM se implementa utilizando registros DNS y una cabecera de correo compatible con el RFC 5322, es totalmente
compatible con la infraestructura de correo existente. En particular, es transparente con los sistemas de correo actuales que no
implementan el soporte DKIM.

Este enfoque es también compatible con otros servicios relacionados, tales como el S/MIME y OpenPGP, estándares en la protección
del contenido. DKIM es ortogonal y compatible con el estándarDNSSEC y con SPF.

Debilidades
Las firmas DKIM no abarcan todo el mensaje, deja fuera el return-path y los destinatarios del mensaje. Una preocupación para
cualquier solución criptográfica sería el abuso en el envío de mensajes repetidos, que se saltaría las técnicas que actualmente limitan
el nivel de abuso para grandes dominios. La repetición puede detectarse utilizando claves públicas por mensaje, haciendo consultas
DNS para esas claves y filtrando aquellas consultas masivas producidas por correos enviados a listas de correo enormes o consultas
maliciosas producidas por terceros.

Se puede ver una comparación de diferentes métodos que tratan este problema en
e-mail authentication.

Reenvío arbitrario
Como se mencionaba antes, autenticación no es lo mismo que prevención del abuso: DKIM no previene el que un spammer cree un
anuncio desde un dominio de buena reputación y se envíe a sí mismo el mensaje. Este mensaje firmado puede utilizarse entonces para
reenviarse a millones de destinatarios, por ejemplo a través de un botnet sin ningún tipo de control. El proveedor que firmó el
mensaje puede bloquear al usuario infractor,pero no puede parar la difusión de los mensajes ya firm
ados.
Modificación de contenido en tránsito
Uno de los problemas asociados a DKIM es que si el mensaje es modificado significativamente en su camino hacia el destinatario por
cualquier agente de transmisión, como por ejemplo un servidor de listas, la firma DKIM deja de ser válida, y si en el dominio se
especifica que todos los correos electrónicos deben ir firmados, el mensaje puede ser rechazado. Muchas soluciones de antivirus
añaden un pie en el cuerpo del mensaje indicando que el correo ha sido escaneado y la fecha de las firmas de virus utilizadas en la
exploración. Además, algunos servidores de correo electrónico gratuito añaden anuncios en la parte inferior del mensaje. La solución
es crear una lista blanca de correo electrónico para los dominios conocidos, o la máquina que hace el reenvío debería comprobar la
firma, modificar el correo, y volver a firmar el mensaje con una cabecera Sender. Sin embargo, cabe señalar que esta solución tiene
riesgos si el servidor SMTP de destino soporta el protocoloADSP.

Muchos dominios, por contra, establecen que sólo algunos de sus correos van firmados, y por tanto una firma inválida o inexistente
no debe ser razón para rechazar el correo. La solución aquí pasa por firmar todo tu correo. Si la única modificación en el camino que
recorre el mensaje son el añadido o modificación de cabeceras, la firma seguirá siendo válida; además el mecanismo incluye
características que permiten que sean hechas determinadas modificaciones a las cabeceras y el cuerpo del mensaje sin que esto
invalide la autenticidad de la firma.

Algunos sugieren que esta limitación podría ser solventada combinando DKIM con SPF, ya que SPF (que deja de ser válido cuando
los mensajes son reenviados) es inmune a las modificaciones de los datos del correo, y las listas de correo suelen utilizar sus propias
direcciones de error SMTP, también conocidas como Return-Path. Resumiendo, SPF funciona sin problemas donde DKIM tiene
dificultades, y viceversa.

Las listas de correo que añaden o cambian contenido también invalidan las firmas DKIM. Yahoo! sugirió que las listas de correo
deberían volver a firmar los mensajes en estas circunstancias, haciéndose así responsables del mensaje.

Coste computacional del protocolo


DKIM genera checksums criptográficos para cada mensaje original enviado a través de sus servidores, lo que resulta en una
sobrecoste computacional adicional al hacer el envío de correo.

Véase también
E-mail authentication
DomainKeys
Sender Policy Framework(SPF)
Author Domain Signing Practices(ADSP)
S/MIME
OpenPGP
Vouch by Reference

Referencias
1. Entrada en el Blog Corporativo de Yahoo! (http://ycorpblog.com/2007/05/22/one-small-step-for-email-one-giant-leap-f
or-internet-safety/) por Mark Delany, arquitecto jefe e inventor de DomainKeys
2. Entrada en el Blog de Gmail (http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html)
anunciando el soporte de DKIM en la recepción de correo por parte de Gmail
3. Gmail help entry (http://mail.google.com/support/bin/answer .py?hl=en&answer=12093#TimedOut) comentando el
soporte DKIM en el envío
4. Entrada del blog de FastMail: (http://blog.fastmail.fm/2009/08/13/all-outbound-email-now-being-dkim-signed/)
todo el
correo saliente se firma con DKIM
5. Falk, JD (17 de marzo de 2009). «Searching for Truth in DKIM» (http://www.circleid.com/posts/20090317_searching_
for_truth_in_dkim_part_3/). dotMobi.
6. Falk, JD (13 de marzo de 2009). «Searching for Truth in DKIM» (http://www.circleid.com/posts/20090313_searching_
for_truth_in_dkim_part_2/). dotMobi.
7. Hammer, Michael (23 de marzo de 2009). «Warning, Danger Lurks Here: Exploring DKIM/ADSP Edge Cases -
Missing message-id» (http://www.circleid.com/posts/20090323_exploring_dkim_adsp_edge_cases_missing_messag
e_id/). dotMobi.

Enlaces externos
Domain Keys Identified Mail (DKIM)
IETF DKIM working group(iniciado en 2006)
Especificaciones DKIM

RFC 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)


RFC 4871 DomainKeys Identified Mail (DKIM) Signatures
RFC 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
RFC 5585 DomainKeys Identified Mail (DKIM) Service Overview
Información y herramientas de DKIM

Internet Messaging Leaders Work Together to Fight Email Fraud


DKIM Software and Services Deployment Reports
DKIM-Connector (enlace roto disponible en Internet Archive; véase el historial y la última versión). Tool to simplify DKIM
deployment
DKIM installation for Exim (enlace roto disponible en Internet Archive; véase el historial y la última versión). Tutorial for installing
DKIM for outbound messages using Exim
DomainKeys on cPanelImplementing DomainKeys on a cPanel powered server
Domain Keys Identified Mail (DKIM)
DKIM signer/verifier drop-in replacement for qmail-queue
Domain Keys Identified Mail (DKIM) DNS Record Generator
Crocker, Dave (marzo de 2008), Trust in Email Begins With Authentication (PDF), Messaging Anti-Abuse Working
Group, archivado desdeel original el 6 de febrero de 2009, consultado el 9 de diciembre de 2009

Obtenido de «https://es.wikipedia.org/w/index.php?title=DomainKeys_Identified_Mail&oldid=109584609
»

Esta página se editó por última vez el 28 jul 2018 a las 14:37.

El texto está disponible bajo laLicencia Creative Commons Atribución Compartir Igual 3.0 ; pueden aplicarse cláusulas
adicionales. Al usar este sitio, usted acepta nuestrostérminos de uso y nuestra política de privacidad.
Wikipedia® es una marca registrada de laFundación Wikimedia, Inc., una organización sin ánimo de lucro.