La autenticación, los informes y la conformidad de mensajes basados en dominios ( DMARC ) 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 contra el 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 contra el uso en ataques de vulneración de correo electrónico empresarial , correo electrónico de phishing , estafas por correo electrónico y otras actividades de amenazas cibernéticas .
Una vez que se publica la entrada DNS de DMARC , 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 se podrá confiar en él. Si el correo electrónico no pasa la verificación, según las instrucciones contenidas en el registro DMARC, el correo electrónico podría entregarse, ponerse en cuarentena o rechazarse.
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 cómo comprobar el From:campo presentado a los usuarios finales, cómo debe tratar el receptor las fallas y proporciona un mecanismo de informe para las acciones realizadas según esas políticas.
DMARC se define en el documento publicado RFC 7489 del Grupo de trabajo de ingeniería de Internet , [1] con fecha de marzo de 2015, como "Informativo". [2]
Una política DMARC permite que el dominio de un remitente indique que sus mensajes de correo electrónico están protegidos por SPF y/o DKIM, y le dice al receptor qué hacer si ninguno de esos métodos de autenticación es aprobado (por ejemplo, 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 aprobados y/o rechazados. [3]
Estas políticas se publican en el Sistema de nombres de dominio (DNS) público como registros de texto TXT .
DMARC no se ocupa directamente de si un correo electrónico es spam o fraudulento. En cambio, DMARC puede exigir que un mensaje no solo pase la validación DKIM o SPF, sino que también pase la § Alineación. Con DMARC, un mensaje puede fallar incluso si pasa la validación SPF o DKIM pero no pasa la alineación. [4]
La configuración de DMARC puede mejorar la capacidad de entrega de mensajes de remitentes legítimos. [5]
DMARC funciona comprobando 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 de SPF (especificadas mediante el aspfcampo ) o DKIM (especificadas mediante adkim) pasan, entonces la prueba de alineación de DMARC pasa.
La alineación puede especificarse como estricta o relajada. Para la alineación estricta, los nombres de dominio deben ser idénticos. Para la alineación relajada, el "Dominio organizacional" de nivel superior debe coincidir. El Dominio organizacional solía encontrarse consultando una lista de sufijos DNS públicos. La próxima especificación, en cambio, especifica un recorrido por el árbol a través de los dominios principales. Por lo tanto, por ejemplo, "abcdexample.com.au" y "example.com.au" tienen el mismo Dominio organizacional, porque _dmarc.example.com.au es el único registro DMARC definido entre todos los subdominios involucrados, incluido _dmarc.au. Como esto permite a los propietarios de dominios definir roles de dominio, se considera que es más preciso que la Lista de sufijos públicos . [6]
Al igual que SPF y DKIM, DMARC utiliza el concepto de propietario de un 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 FROMcomando SMTP. (La dirección de correo electrónico en MAIL FROM también se denomina dirección de rebote , envelope-from o RFC5321.MailFrom). Además de exigir que se apruebe la comprobación de SPF, DMARC comprueba que RFC5321.MailFrom coincida con 5322.From. [2]
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 de correo de DKIM-Signature, las etiquetas d=(dominio) y s=(selector) especifican dónde en DNS recuperar la clave pública para la firma. Una firma válida demuestra que el firmante es el 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 alinee con el dominio del remitente indicado en el From:campo de encabezado.
Los registros DMARC se publican en DNS con una etiqueta de subdominio _dmarc, por ejemplo _dmarc.example.com. Compárese con SPF en example.com, y DKIM en selector._domainkey.example.com.
El contenido del registro de recursos TXT consta de name=valueetiquetas, separadas por punto y coma, similares a SPF y DKIM.
Las etiquetas disponibles son: [7]
rpara relajado, alternativamente spara estricto)rpara relajado, alternativamente spara estricto)0, alternativamente 1, do s)100)p),Por ejemplo:
"v=DMARC1;p=ninguno;sp=cuarentena;pct=100;rua=mailto:[email protected];"
En este ejemplo, la entidad que controla el dominio DNS example.com pretende supervisar las tasas de errores de SPF o DKIM y no espera que se envíen correos electrónicos desde subdominios de example.com. Tenga en cuenta que un subdominio puede publicar su propio registro DMARC; los receptores deben comprobarlo antes de recurrir al registro del dominio de la organización.
El protocolo prevé varios mecanismos de transición para permitir que los administradores de correo realicen una transición gradual desde no implementar DMARC en absoluto hasta una configuración inflexible. [8] [9] [10] El concepto de adopción gradual supone que el objetivo de DMARC es la configuración más sólida, lo que no es el caso de todos los dominios. Independientemente de la intención, estos mecanismos permiten una mayor flexibilidad.
En primer lugar, hay tres políticas:
La política publicada se puede mitigar aplicándola solo a un porcentaje de los mensajes que no superan la comprobación DMARC. Se solicita a los receptores que seleccionen el porcentaje dado de mensajes mediante un algoritmo de muestreo de Bernoulli simple . El resto de los mensajes deben someterse a la política inferior; es decir, ninguno si p=quarantine, cuarentena si p=reject. Si no se especifica, pct toma el valor predeterminado del 100% de los mensajes. El caso p=quarantine; pct=0;se está utilizando para obligar a los administradores de listas de correo a reescribir el campo From:, ya que algunos no lo hacen cuando p=none. [11]
Finalmente, la política de subdominio sp=y la política de no dominio recientemente agregada np=[12] permiten ajustar la política para subdominios específicos.
DMARC es capaz de generar dos tipos de informes independientes. Los informes agregados se envían a la dirección especificada después de la etiqueta rua. Los informes forenses se envían por correo electrónico a la dirección que aparece después de la rufetiqueta . Estas direcciones de correo deben especificarse en formato URI mailto (por ejemplo, mailto:[email protected] ). Son válidas varias direcciones de informes y cada una debe estar en formato URI completo, separadas por una coma. [13]
Las direcciones de correo electrónico de destino pueden pertenecer a dominios externos. En ese caso, el dominio de destino debe configurar un registro DMARC para indicar que acepta recibirlas; de lo contrario, sería posible aprovechar la función de notificación para amplificar el correo no deseado . Por ejemplo, supongamos receiver.exampleque recibe un mensaje de correo From: [email protected]y desea informar sobre él. Si encuentra ruf=mailto:[email protected], busca un registro DNS de confirmación en el espacio de nombres administrado por el destino, de la siguiente manera:
remitente.ejemplo._informe._dmarc.tercero.ejemplo EN TXT "v=DMARC1;"
Los informes agregados se envían como archivos XML , normalmente una vez al día. El asunto menciona el "Dominio del informe", que indica el nombre del dominio DNS sobre el que se generó el informe, y el "Remitente", que es la entidad que emite el informe. La carga útil se encuentra en un archivo adjunto con un nombre de archivo largo que consta de elementos separados por signos de exclamación, como el receptor que emite el informe, las épocas de inicio y fin 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). [14]
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 una serie de registros. Los registros se pueden colocar 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 [15] y un registro sin procesar se ejemplifica en dmarc.org. [16] Aquí nos ceñimos a 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 .
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 según DMARC, ya sea aprobados o reprobados, teniendo en cuenta la alineación. Las más a la derecha, con etiquetas similares, muestran el nombre del dominio que afirma participar en el envío del mensaje y (entre paréntesis) el estado de autenticación de esa afirmación según el protocolo original, SPF o DKIM, independientemente de la alineación del identificador. En el lado derecho, SPF puede aparecer como máximo dos veces, una para la Return-Path:prueba y otra para la HELOprueba; DKIM puede aparecer una vez para 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 de DKIM, como la rotura de la firma debido a una alteración menor en el tránsito. La tercera y cuarta filas muestran modos de falla típicos de un reenvío 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 que realmente se aplica a los mensajes, none , cuarentena o reject . Junto con ella, no se muestra en la tabla, DMARC prevé 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:
Los informes forenses, también conocidos como informes de errores, se generan en tiempo real y consisten en copias redactadas de mensajes individuales que no pasaron la prueba SPF, DKIM o ambas, según el valor especificado en la foetiqueta. Su formato, una extensión del formato de informe de abuso , se parece al de los rebotes normales en el sentido de que contienen un "message/rfc822" o un "text/rfc822-headers".
Los informes forenses también contienen lo siguiente:
Existen varios tipos diferentes de reenvío de correo electrónico , algunos de los cuales pueden romper el SPF. [18] Esta es una de las razones por las que el reenvío de correo electrónico puede afectar los resultados de la autenticación DMARC. [19]
Las listas de correo son una causa frecuente de violación legítima de la firma DKIM del dominio del autor original, por ejemplo, al agregar un prefijo al encabezado del asunto. Existen varias soluciones alternativas [20] [21] y los paquetes de software de listas de correo están trabajando en soluciones. [22]
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 importantes, pero impide que la lista agregue pies de página y prefijos de asunto. [23] Esto requiere una configuración cuidadosa del software de correo para asegurarse de que los encabezados firmados no se reordenen ni se modifiquen. Un servidor de correo mal configurado puede colocar 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 a reescribir From:.
From:reescrituraUna de las soluciones alternativas más populares y menos intrusivas consiste en reescribir el From:campo de encabezado. Luego se puede agregar la dirección del autor original al Reply-To:campo. [24] La reescritura puede ir desde simplemente agregar .INVALID[nota 1] al nombre de dominio, hasta asignar un ID de usuario temporal donde se utiliza una versión modificada de la dirección del usuario, o se utiliza un ID opaco, que 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 (u operador de lista). [25] Esos ejemplos darían como resultado, respectivamente, uno de los siguientes:
De: John Doe <[email protected]> De: John Doe <[email protected]> De: John Doe <[email protected]> De: John Doe vía MailingList <[email protected]> Responder a: John Doe <[email protected]> La última línea, Reply-To:, debe diseñarse para incluir la función de responder al autor, en cuyo caso la función de responder a la lista queda cubierta por el cambio anterior en el From:campo de encabezado. De esa manera, se invierte el significado original de esos campos.
En general, alterar el nombre del autor no es justo y puede romper la relación esperada entre el significado y la apariencia de ese dato. También rompe el uso automatizado del mismo. Hay comunidades que utilizan listas de correo para coordinar su trabajo e implementan herramientas que utilizan el From:campo para atribuir la autoría a los archivos adjuntos. [26]
Envolver el mensaje funciona bien para quienes 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 parecen ser requeridos por ley en algunos países y que perder sistemáticamente la autenticación SPF puede hacer que la autenticación general sea más frágil. [27]
Realizar 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 o los autores del mensaje, es decir, el buzón o los buzones de la persona o los sistemas responsables de la redacción del mensaje". El 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 para el dominio De e ignora el dominio Remitente. [nota 2]
Tanto ADSP como DMARC [4] rechazan el uso del campo Remitente por el motivo no técnico de que muchos agentes de usuario no lo muestran al destinatario.
Se mantiene un borrador de especificación DMARC desde el 30 de enero de 2012. [28]
En octubre de 2013, se lanzó GNU Mailmanp=reject 2.1.16 con opciones para manejar publicaciones de un dominio con la política DMARC de . [22] El cambio intentó 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. [29] [30] Unos días después, AOL también cambió su política DMARC a p=reject. [31] Esos movimientos resultaron en una cantidad significativa de interrupciones, y esos proveedores de buzones de correo han sido acusados de forzar los costos de sus propios fallos de seguridad a terceros. [32] 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, [33] de las cuales la más ampliamente implementada es la lista de correo que cambia el encabezado "De" a una dirección en su propio dominio.
En agosto de 2014 se formó un grupo de trabajo de la IETF para abordar las cuestiones relacionadas con DMARC, comenzando por las preocupaciones sobre interoperabilidad y posiblemente continuando con una especificación y documentación estándar revisadas. [34] 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 envío independiente en la categoría "Informativa" (no estándar) como RFC 7489. [35]
En marzo de 2017, la Comisión Federal de Comercio publicó un estudio sobre el uso de DMARC por parte de las empresas. [36] De 569 empresas, el estudio encontró que aproximadamente un tercio implementó alguna configuración de DMARC, menos del 10% usó DMARC para indicar a los servidores que rechazaran mensajes no autenticados y la mayoría había implementado SPF.
Los contribuyentes a la especificación DMARC incluyen: [37] [38]
Si eso parece mucho trabajo, es porque fue
vez que GZIP esté registrado como un tipo de aplicación MIME con IANA, el grupo DMARC lo considerará como una inclusión en el borrador.
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 utiliza el campo From: para completar el
campo from de la confirmación de git
.