DMARC ( Autenticación, Informes y Conformidad de Mensajes basados en Dominios ) es un protocolo de autenticación de correo electrónico . Está diseñado para brindarles a los propietarios de dominios de correo electrónico la capacidad de proteger su dominio del uso no autorizado, comúnmente conocido como suplantación de correo electrónico . El propósito y el resultado principal de la implementación de DMARC es proteger un dominio para que no se utilice en ataques de compromiso de correo electrónico empresarial , correos electrónicos de phishing , estafas de correo electrónico y otras actividades de amenazas cibernéticas .
Una vez que se publica la entrada DMARC DNS , cualquier servidor de correo electrónico receptor puede autenticar el correo electrónico entrante según las instrucciones publicadas por el propietario del dominio dentro de la entrada DNS. Si el correo electrónico pasa la autenticación, se entregará y será de confianza. Si el correo electrónico no pasa la verificación, dependiendo de las instrucciones contenidas en el registro DMARC, el correo electrónico podría ser entregado, puesto en cuarentena o rechazado. Por ejemplo, un servicio de reenvío de correo electrónico entrega el correo, pero como "De: sin respuesta @
DMARC amplía dos mecanismos de autenticación de correo electrónico existentes, Sender Policy Framework (SPF) y DomainKeys Identified Mail (DKIM). Permite al propietario administrativo de un dominio publicar una política en sus registros DNS para especificar qué mecanismo (DKIM, SPF o ambos) se emplea al enviar correo electrónico desde ese dominio; cómo comprobar el From:
campo 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.
DMARC se define en el documento RFC 7489 publicado por el Grupo de Trabajo de Ingeniería de Internet , con fecha de marzo de 2015, como "Informativo". [2]
Descripción general
Una política de DMARC permite que el dominio de un remitente indique que sus correos electrónicos están protegidos por SPF y / o DKIM, y le dice al receptor qué hacer si ninguno de esos métodos de autenticación pasa, como rechazar el mensaje o ponerlo en cuarentena. La política también puede especificar cómo un receptor de correo electrónico puede informar al dominio del remitente sobre los mensajes que pasan y / o fallan. [3]
Estas políticas se publican en el Sistema de nombres de dominio (DNS) público como registros TXT de texto .
DMARC no aborda directamente si un correo electrónico es spam o fraudulento. En cambio, DMARC puede requerir que un mensaje no solo pase la validación DKIM o SPF, sino que también pase la alineación . Bajo DMARC, un mensaje puede fallar incluso si pasa SPF o DKIM, pero falla la alineación. [4]
La configuración de DMARC puede tener un impacto positivo en la capacidad de entrega para los remitentes legítimos. [5]
Alineación
DMARC funciona verificando que el dominio en el From:
campo del mensaje (también llamado "RFC5322.From" [2] ) esté "alineado" con otros nombres de dominio autenticados. Si las comprobaciones de alineación SPF o DKIM pasan, la prueba de alineación DMARC pasa.
La alineación puede especificarse como estricta o relajada. Para una alineación estricta, los nombres de dominio deben ser idénticos. Para una alineación relajada, el "Dominio organizacional" de nivel superior debe coincidir. El dominio organizativo se encuentra comprobando una lista de sufijos de DNS públicos y agregando la siguiente etiqueta de DNS. Entonces, por ejemplo, "abcdexample.com.au" y "example.com.au" tienen el mismo dominio organizacional, porque hay un registrador que ofrece nombres en ".com.au" a los clientes. Aunque en el momento de la especificación DMARC había un grupo de trabajo IETF sobre límites de dominio, hoy en día el dominio organizacional solo se puede derivar de la Lista de sufijos públicos . [6]
Al igual que SPF y DKIM, DMARC utiliza el concepto de propietario de dominio, la entidad o entidades que están autorizadas a realizar cambios en un dominio DNS determinado.
SPF comprueba que la dirección IP del servidor de envío esté autorizada por el propietario del dominio que aparece en el MAIL FROM
comando SMTP . (La dirección de correo electrónico en MAIL FROM también se denomina dirección de rebote , sobre-from o RFC5321.MailFrom.) Además de requerir que la verificación SPF pase, DMARC también verifica que RFC5321.MailFrom se alinee con 5322.From. [ cita requerida ]
DKIM permite que partes de un mensaje de correo electrónico se firmen criptográficamente y la firma debe cubrir el campo De. Dentro del encabezado del correo DKIM-Signature, las etiquetas d=
(dominio) y s=
(selector) especifican en qué lugar del DNS recuperar la clave pública para la firma. Una firma válida prueba que el firmante es propietario de un dominio y que el campo De no se ha modificado desde que se aplicó la firma. Puede haber varias firmas DKIM en un mensaje de correo electrónico; DMARC requiere una firma válida donde el dominio en la d=
etiqueta se alinea con el dominio del remitente indicado en el From:
campo del encabezado.
Registro DNS
Los registros DMARC se publican en DNS con una etiqueta de subdominio _dmarc
, por ejemplo _dmarc.example.com
. Compare esto con SPF en example.com
y DKIM en selector._domainkey.example.com
.
El contenido del registro de recursos TXT consta de name=value
etiquetas, separadas por punto y coma, similar a SPF y DKIM. Por ejemplo:
"v = DMARC1; p = ninguno; sp = cuarentena; pct = 100; rua = mailto: [email protected];"
Aquí v
está la versión, p
la política, la política sp
del subdominio, pct
el porcentaje de correos electrónicos "malos" en los que aplicar la política y rua
el URI al que enviar informes agregados. En este ejemplo, la entidad que controla el dominio DNS example.com tiene la intención de monitorear las tasas de falla de SPF y / o DKIM y no espera que se envíen correos electrónicos desde los subdominios de example.com. Tenga en cuenta que un subdominio puede publicar su propio registro DMARC; los receptores deben verificarlo antes de volver al registro de dominio organizacional.
Informes
DMARC es capaz de producir dos tipos de informes separados. Los informes agregados se envían a la dirección especificada después de rua
. Los informes forenses se envían por correo electrónico a la dirección que sigue a la ruf
etiqueta. Estas direcciones de correo deben especificarse en formato URI mailto (por ejemplo, mailto: [email protected]). Varias direcciones de informes son válidas y cada una debe estar en formato URI completo, separadas por una coma.
Las direcciones de correo electrónico de destino pueden pertenecer a dominios externos. En ese caso, el dominio objetivo tiene que configurar un registro DMARC para decir que acepta recibirlos; de lo contrario, sería posible aprovechar los informes para la amplificación del spam . Por ejemplo, say receiver.example
recibe un mensaje de correo From: [email protected]
y desea informarlo. Si lo encuentra ruf=mailto:[email protected]
, busca un registro DNS de confirmación en el espacio de nombres administrado por el objetivo, como este:
sender.example._report._dmarc.thirdparty.example IN TXT "v = DMARC1;"
Informes agregados
Los informes agregados se envían como archivos XML , normalmente una vez al día. El sujeto menciona el "Dominio del informe", que indica el nombre de dominio DNS sobre el cual se generó el informe, y el "Remitente", que es la entidad que emite el informe. La carga útil está en un archivo adjunto con un nombre de archivo largo que consta de elementos separados por bang, como el receptor de emisión del informe, las épocas de inicio y finalización del período informado como marcas de tiempo de estilo Unix, un identificador único opcional y una extensión que depende de la posible compresión (solía ser .zip
). [7]
Por ejemplo: example.com!example.org!1475712000!1475798400.xml.gz
.
El contenido XML consta de un encabezado, que contiene la política en la que se basa el informe y los metadatos del informe, seguido de varios registros. Los registros pueden colocarse en una base de datos como una relación y visualizarse en forma de tabla. El esquema XML se define en el Apéndice C de las especificaciones [8] y un registro sin formato se ejemplifica en dmarc.org. [9] Aquí nos quedamos con un ejemplo relacional, que transmite mejor la naturaleza de los datos. Los registros DMARC también se pueden transformar directamente en HTML aplicando una hoja de estilo XSL .
IP de origen | Contar | Disposición | SPF | DKIM | Encabezado de | Dominio SPF (resultado) | Dominio DKIM (resultado) | |
---|---|---|---|---|---|---|---|---|
192.0.2.1 | 12 | ninguno | ✓ Aprobar | ✓ Aprobar | example.org | example.org ( ✓ Aprobar ) | example.org ( ✓ Aprobar ) | |
192.0.2.1 | 1 | ninguno | ✓ Aprobar | ✗ Fallar | example.org | example.org ( ✓ Aprobar ) | example.org ( ✗ Fallar ) | |
192.0.2.28 | 42 | ninguno | ✗ Fallar | ✓ Aprobar | example.org | example.org ( ✗ Fallar ) | example.org ( ✓ Aprobar ) | reenviador.ejemplo ( ✓ Aprobado ) |
192.0.2.82 | 21 | ninguno | ✗ Fallar | ✗ Fallar | example.org | discusionlist.example ( ✓ Aprobado ) | example.org ( ✗ Fallar ) | discusionlist.example ( ✓ Aprobado ) |
... |
Las filas se agrupan por IP de origen y resultados de autenticación, pasando solo el recuento de cada grupo. Las columnas de resultados más a la izquierda, etiquetadas como SPF y DKIM, muestran resultados basados en DMARC, ya sea aprobados o reprobados, teniendo en cuenta la alineación. Los de la derecha, con etiquetas similares, muestran el nombre del dominio que dice participar en el envío del mensaje y (entre paréntesis) el estado de autenticación de ese reclamo según el protocolo original, SPF o DKIM, independientemente de la alineación de identificadores. En el lado derecho, SPF puede aparecer como máximo dos veces, una para la Return-Path:
prueba y otra para la HELO
prueba; DKIM puede aparecer una vez por cada firma presente en el mensaje. En el ejemplo, la primera fila representa el flujo de correo principal de example.org, y la segunda fila es un error DKIM, como la rotura de la firma debido a una alteración menor en tránsito. La tercera y cuarta filas muestran los modos de falla típicos de un reenviador y una lista de correo, respectivamente. La autenticación DMARC falló solo para la última fila; podría haber afectado la disposición del mensaje si example.org hubiera especificado una política estricta.
La disposición refleja la política publicada realmente aplicada a los mensajes, ninguno , cuarentena o rechazo . Junto con él, que no se muestra en la tabla, DMARC proporciona una anulación de la política. Algunas razones por las que un receptor puede aplicar una política diferente a la solicitada ya están previstas en la especificación:
- reenviado
- manteniendo la misma dirección de rebote, normalmente no rompe DKIM,
- muestreado
- porque un remitente puede optar por aplicar la política solo a un porcentaje de los mensajes,
- promotor de confianza
- el mensaje llegó de una fuente localmente conocida
- lista de correo
- el receptor determinó heurísticamente que el mensaje llegó de una lista de correo,
- política local
- obviamente, los destinatarios son libres de aplicar la política que deseen, es genial que los remitentes sepan,
- otro
- si no se aplica nada de lo anterior, un campo de comentario permite decir más.
Informes forenses
Los informes forenses, también conocidos como informes de fallas, se generan en tiempo real y consisten en copias redactadas de correos electrónicos individuales que fallaron en SPF, DKIM o ambos en función del valor especificado en la fo
etiqueta. Su formato, una extensión de Abuse Reporting Format , se parece al de los rebotes regulares en que contienen un "mensaje / rfc822" o un "texto / rfc822-encabezados".
Compatibilidad
Transportistas
Hay varios tipos diferentes de reenvío de correo electrónico , algunos de los cuales pueden romper el SPF. [10]
Listas de correo
Las listas de correo son una causa frecuente de ruptura legítima de la firma DKIM del dominio del autor original, por ejemplo, al agregar un prefijo al encabezado del asunto. Hay varias soluciones posibles, [11] y los paquetes de software de listas de correo están trabajando en soluciones. [12]
Desactivar todas las modificaciones de mensajes
Esta solución alternativa mantiene el flujo de trabajo estándar de la lista de correo y es adoptada por varios operadores de listas de correo grandes, pero impide que la lista agregue pies de página y prefijos de asunto. [13] Esto requiere una configuración cuidadosa del software de correo para asegurarse de que los encabezados firmados no se reordenen ni modifiquen. Un servidor de correo mal configurado puede List-id en su DKIM de mensajes enviados a una lista de correo, y luego el operador de la lista se ve obligado a rechazarlo o hacer De: reescritura.
From:
reescribiendo
Una de las soluciones más populares y menos intrusivas consiste en reescribir el From:
campo de encabezado. Luego, se puede agregar al Reply-To:
campo la dirección del autor original . [14] La reescritura puede variar desde simplemente agregar .INVALID
[nota 1] al nombre de dominio, hasta asignar una identificación de usuario temporal cuando se usa una identificación opaca, esto mantiene la dirección de correo electrónico "real" del usuario privada de la lista. Además, el nombre para mostrar se puede cambiar para mostrar tanto el autor como la lista (o el operador de la lista). [15] Estos ejemplos resultarían, respectivamente, en uno de los siguientes:
De: John Doe @example.com.invalid> De: John Doe <[email protected]> De: John Doe a través de MailingList
@mailinglist.example.org> y Responder a: John Doe @example.com>
La última línea Reply-To:
,, debe diseñarse para acomodar la funcionalidad de respuesta al autor, en caso de que la función de respuesta a la lista esté cubierta por el cambio anterior en el From:
campo de encabezado. De esa forma, se invierte el significado original de esos campos.
Alterar el autor no es justo en general y puede romper la relación esperada entre el significado y la apariencia de ese dato. También rompe el uso automatizado de la misma. Hay comunidades que usan listas de correo para coordinar su trabajo e implementan herramientas que usan el From:
campo para atribuir la autoría a los archivos adjuntos. [dieciséis]
Otras soluciones alternativas
Envolver el mensaje funciona bien para aquellos que usan un cliente de correo electrónico que entiende los mensajes envueltos. No hacer ningún cambio es quizás la solución más obvia, excepto que parece ser legalmente exigible en algunos países, y que la pérdida rutinaria de la autenticación SPF puede hacer que la autenticación general sea más frágil. [17]
Campo del remitente
Hacer cambios en el From:
campo de encabezado para pasar la alineación DKIM puede hacer que el mensaje no cumpla con la sección 3.6.2 de RFC 5322: "El campo 'De:' especifica el autor (es) del mensaje, es decir, el buzón (es) de la (s) persona (s) o sistema (s) responsables de la redacción del mensaje ". Buzón se refiere a la dirección de correo electrónico del autor. El Sender:
encabezado está disponible para indicar que se envió un correo electrónico en nombre de otra parte, pero DMARC solo verifica la política del dominio De e ignora el dominio del remitente. [nota 2]
Tanto ADSP como DMARC [4] rechazan el uso del campo Remitente sobre una base no técnica que muchos agentes de usuario no muestran esto al destinatario.
Historia
Se ha mantenido un proyecto de especificación DMARC desde el 30 de enero de 2012. [18]
En octubre de 2013, GNU Mailman 2.1.16 fue lanzado con opciones para manejar carteles desde un dominio con la política DMARC de p=reject
. [12] El cambio trató de anticipar los problemas de interoperabilidad esperados en caso de que se aplicaran políticas restrictivas a dominios con usuarios humanos (a diferencia de los dominios de correo puramente transaccionales).
En abril de 2014, Yahoo cambió su política DMARC a p=reject
, lo que provocó un mal comportamiento en varias listas de correo. [19] Unos días después, AOL también cambió su política DMARC a p=reject
. [20] Esos movimientos resultaron en una cantidad significativa de interrupciones, y esos proveedores de buzones de correo han sido acusados de imponer los costos de sus propias fallas de seguridad a terceros. [21] A partir de 2020, las preguntas frecuentes en la wiki oficial de DMARC contienen varias sugerencias para que las listas de correo manejen mensajes de un dominio con una política DMARC estricta, [22] de las cuales la más implementada es la lista de correo que cambia el "De" encabezado a una dirección en su propio dominio.
En agosto de 2014 se formó un grupo de trabajo de la IETF para abordar los problemas de DMARC, comenzando por cuestiones de interoperabilidad y posiblemente continuando con una especificación y documentación estándar revisada. [23] Mientras tanto, la especificación DMARC existente había alcanzado un estado editorial acordado e implementado por muchos. Se publicó en marzo de 2015 en el flujo de presentación independiente en la categoría "Informativo" (no estándar) como RFC 7489. [24]
En marzo de 2017, la Comisión Federal de Comercio publicó un estudio sobre el uso de DMARC por parte de las empresas. [25] De 569 empresas, el estudio encontró que aproximadamente un tercio implementó cualquier configuración DMARC, menos del 10% usó DMARC para indicar a los servidores que rechazaran mensajes no autenticados y la mayoría había implementado SPF.
Colaboradores
Los contribuyentes de la especificación DMARC incluyen: [26] [27]
- Receptores: AOL , Comcast , Google ( Gmail ), Mail.Ru , Microsoft ( Outlook.com , Hotmail ), [28] Netease (163.com, 126.com, 188.com, yeah.net), XS4ALL , Yahoo , Yandex
- Remitentes: American Greetings , Bank of America , Facebook , Fidelity Investments , JPMorganChase , LinkedIn , [29] PayPal , Twitter [30]
- Intermediarios y proveedores: [31] Agari (fundador / director ejecutivo Patrick R. Peterson), [31] Cloudmark, [31] Red Sift , [31] ReturnPath , [31] Trusted Domain Project [31]
Ver también
- Cadena recibida autenticada (ARC)
- Prácticas de firma de dominio de autor
- Correo identificado de DomainKeys (DKIM)
- Verificacion de Email
- Correo certificado
- Servidores de correo con DMARC
- Marco de políticas del remitente (SPF)
Notas
- ^ INVALID es un dominio de nivel superior reservado por RFC 2606 para este tipo de uso.
- ^ El uso del campo Remitente por remitentes se menciona (en el contexto de DKIM, no DMARC) en las secciones B.1.4 y B.2.3 de RFC 4871.
Referencias
- ^ "Preguntas frecuentes" . ForwardEmail . Consultado el 15 de junio de 2020 .
Si un remitente ha configurado DMARC en su dominio de manera que el reenvío habitual fallaría, entonces usamos este enfoque de reescritura "amigable desde" para asegurar que el correo electrónico llegue a su bandeja de entrada en lugar de ser rechazado.
- ^ a b > "RFC 7489 - Autenticación, informes y conformidad de mensajes basados en dominios (DMARC)" . datatracker.ietf.org .
- ^ Terry Zink (27 de septiembre de 2016). "Cómo movimos microsoft.com a ap = registro DMARC de cuarentena" . Blog de MSDN .
Si eso suena a mucho trabajo, es porque fue
- ^ a b Kucherawy, M .; Zwicky, E. (15 de julio de 2013). "Autenticación, notificación y conformidad de mensajes basados en el dominio (DMARC) [borrador 01]" . IETF. Apéndice A.3, Campo de encabezado del remitente . Consultado el 24 de mayo de 2016 .
- ^ "Directrices para remitentes masivos - Ayuda de Gmail" . support.google.com . Consultado el 24 de abril de 2015 .
- ^ John Levine (2 de noviembre de 2017). "Uso de la lista de sufijos públicos" . Desarrolladores Mailman (lista de correo).
- ^ "¿Cuál es la razón para elegir ZIP para los informes agregados?" . DMARC.org . 2012 . Consultado el 3 de abril de 2019 .
Una vez que GZIP esté registrado como un tipo de aplicación MIME con IANA, el grupo DMARC lo considerará incluido en el borrador.
- ^ Murray S. Kucherawy; Elizabeth Zwicky, eds. (Marzo de 2015). "Esquema XML DMARC" . Autenticación, informes y conformidad de mensajes basados en dominios (DMARC) . IETF . segundo. C. doi : 10.17487 / RFC7489 . RFC 7489 . Consultado el 3 de marzo de 2019 .
- ^ "Necesito implementar informes agregados, ¿cómo se ven?" . DMARC.org . Consultado el 26 de mayo de 2016 .
- ^ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (Septiembre de 2016). "Alias" . Problemas de interoperabilidad entre autenticación, informes y conformidad de mensajes basados en dominios (DMARC) y flujos de correo electrónico indirecto . IETF . segundo. 3.2.1. doi : 10.17487 / RFC7960 . RFC 7960 . Consultado el 14 de marzo de 2017 .
- ^ dmarc.org wiki
- ^ a b Mark Sapiro (16 de octubre de 2013). "Cartero y DMARC" . list.org . Consultado el 13 de agosto de 2015 .
- ^ "Próximos cambios para lists.debian.org" . listas.debian.org .
- ^ Al Iverson (9 de abril de 2014). "Recurso de spam: ¿ejecutar una lista de discusión por correo electrónico? Aquí se explica cómo tratar con DMARC" . spamresource.com . Consultado el 18 de abril de 2014 .
- ^ "Cómo Threadable resolvió el problema de DMARC" . Blog Threadable . Consultado el 21 de mayo de 2016 .
- ^ Theodore Ts'o (18 de diciembre de 2016). "Respuestas realistas a DMARC" . IETF-Discussion (lista de correo) . Consultado el 14 de marzo de 2017 .
El hecho de que el campo from no se reescriba es IMPORTANTE porque reescribir el campo from rompería el comando "git am", ya que usa el campo From: para completar el campo from de git commit
- ^ John Levine (31 de mayo de 2014). "Mitigar el daño de DMARC al correo de terceros" . wiki . ASRG . Consultado el 1 de junio de 2014 .
- ^ "Historia" , dmarc.org
- ^ Lucian Constantin (8 de abril de 2014). "La política anti-spoofing de correo electrónico de Yahoo rompe listas de correo" . PC World . Consultado el 15 de abril de 2014 .
- ^ Vishwanath Subramanian (22 de abril de 2014). "AOL Mail actualiza la política DMARC para 'rechazar ' " . AOL . Archivado desde el original el 13 de agosto de 2015 . Consultado el 13 de agosto de 2015 .
- ^ John Levine (13 de agosto de 2016). "DMARC y ietf.org" . IETF (lista de correo) . Consultado el 10 de octubre de 2016 .
- ^ "Preguntas frecuentes en la wiki de DMARC" . Consultado el 15 de julio de 2020 .
- ^ "Acción del grupo de trabajo: autenticación, informes y conformidad de mensajes basados en dominios formados (dmarc)" . IETF-Announce (lista de correo). 11 de agosto de 2014 . Consultado el 10 de octubre de 2016 .
- ^ "Preguntas frecuentes sobre DMARC" . dmarc.org .
- ^ "Las empresas pueden ayudar a detener el phishing y proteger sus marcas mediante la autenticación de correo electrónico" (PDF) . Comisión Federal de Comercio. 3 de marzo de 2017.
- ^ Murray, Kucherawy; Elizabeth, Zwicky. "Autenticación, informes y conformidad de mensajes basados en dominio (DMARC)" . tools.ietf.org .
- ^ Colaboradores de DMARC (PDF)
- ^ Vitaldevara, Krish (10 de diciembre de 2012). "Outlook.com aumenta la seguridad con soporte para certificados DMARC y EV" . Blog de Outlook . Microsoft . Consultado el 12 de diciembre de 2012 .
- ^ Martin, Franck (20 de septiembre de 2012). "DMARC: una nueva herramienta para detectar correos electrónicos genuinos" . Blog de ingeniería de LinkedIn . Linkedin . Consultado el 17 de agosto de 2013 .
- ^ Josh Aberant (21 de febrero de 2013). "Presentación de DMARC para correos electrónicos de Twitter.com" . twitter.com . Consultado el 10 de abril de 2014 .
- ^ a b c d e f "Historia - dmarc.org" . dmarc.org . Consultado el 23 de septiembre de 2020 .
enlaces externos
- Página web oficial
- Wiki del Grupo de Investigación Anti Spam: Mitigación del daño de DMARC al correo de terceros