La autenticación o validación de correo electrónico es un conjunto de técnicas destinadas a proporcionar información verificable sobre el origen de los mensajes de correo electrónico mediante la validación de la propiedad del dominio de cualquier agente de transferencia de mensajes (MTA) que haya participado en la transferencia y posiblemente la modificación de un mensaje.
La base original del correo electrónico de Internet, el Protocolo simple de transferencia de correo (SMTP), no tiene esa característica, por lo que las direcciones de remitente falsificadas en los correos electrónicos (una práctica conocida como suplantación de correo electrónico ) se han utilizado ampliamente en el phishing , el correo no deseado y varios tipos de fraudes. Para combatir esto, se han desarrollado muchas propuestas de autenticación de correo electrónico que compiten entre sí. Para 2018, [actualizar]tres habían sido ampliamente adoptadas: SPF , DKIM y DMARC . [1] [2] Los resultados de dicha validación se pueden utilizar en el filtrado automático de correo electrónico o pueden ayudar a los destinatarios a seleccionar una acción adecuada.
Este artículo no cubre la autenticación de usuarios en el envío y recuperación de correo electrónico.
A principios de los años 1980, cuando se diseñó el Protocolo simple de transferencia de correo (SMTP), no preveía una verificación real del usuario o sistema remitente. Esto no era un problema mientras los sistemas de correo electrónico eran administrados por corporaciones y universidades de confianza, pero desde la comercialización de Internet a principios de los años 1990, se ha descubierto que el correo electrónico está cada vez más relacionado con el spam , el phishing y otros delitos.
La autenticación del correo electrónico es un primer paso necesario para identificar el origen de los mensajes y, de ese modo, hacer que las políticas y las leyes sean más aplicables.
La postura de depender de la propiedad del dominio surgió a principios de los años 2000. [3] [4] Implica una autenticación de grano grueso, ya que los dominios aparecen en la parte derecha de las direcciones de correo electrónico, después del signo arroba . La autenticación de grano fino, a nivel de usuario, se puede lograr por otros medios, como Pretty Good Privacy y S/MIME . En la actualidad, la identidad digital debe ser gestionada por cada individuo.
Una de las razones más destacadas para la autenticación de correo electrónico es la capacidad de automatizar el filtrado de correo electrónico en los servidores de recepción. De esa manera, los mensajes falsificados pueden rechazarse antes de que lleguen a la bandeja de entrada de un usuario. Si bien los protocolos se esfuerzan por idear formas de bloquear de manera confiable el correo no confiable, los indicadores de seguridad pueden etiquetar los mensajes no autenticados que aún llegan a la bandeja de entrada. Un estudio de 2018 muestra que los indicadores de seguridad pueden reducir la tasa de clics en más de diez puntos, del 48,9 % al 37,2 % de los usuarios que abren mensajes falsificados. [5]
SMTP define el transporte del mensaje , no el contenido del mismo . Por lo tanto, define el sobre del correo y sus parámetros, como el remitente del sobre , pero no el encabezado (excepto la información de seguimiento ) ni el cuerpo del mensaje en sí. STD 10 y RFC 5321 definen SMTP (el sobre), mientras que STD 11 y RFC 5322 definen el mensaje (encabezado y cuerpo), formalmente denominado Formato de Mensaje de Internet .
SMTP define la información de seguimiento de un mensaje, que se guarda en el encabezado utilizando los dos campos siguientes: [6]
Un agente de usuario de correo (MUA) conoce el servidor SMTP de correo saliente a partir de su configuración. Un MTA (o servidor de retransmisión) normalmente determina a qué servidor conectarse consultando el registro de recursos DNS MX (Mail eXchange) para el nombre de dominio de cada destinatario .
La ruta que se muestra a continuación se puede reconstruir a partir de los campos de encabezado de seguimiento que cada host agrega en la parte superior del encabezado cuando recibe el mensaje: [6]
Return-Path: <[email protected]> Recibido: desde D.example.org por E.example.org con SMTP ; mar., 05 feb. 2013 11:45:02 -0500 Recibido: desde C.example.net por D.example.org con SMTP ; mar., 05 feb. 2013 11:45:02 -0500 Recibido: desde B.example.com ( b.example.com [ 192.0.2.1 ]) por C.example.net (que soy yo) con ESMTP id 936ADB8838C para <[email protected]> ; mar., 05 feb. 2013 08:44:50 -0800 (PST) Recibido: de A.example.com por B.example.com con SMTP ; mar., 05 feb. 2013 17:44:47 +0100 Recibido: de [ 192.0.2.27 ] por A.example.com con SMTP ; mar., 05 feb. 2013 17:44:42 +0100 Las primeras líneas de la parte superior del encabezado suelen ser de confianza para el destinatario. Esas líneas las escriben las máquinas del dominio de gestión administrativa ( ADMD ) del destinatario, que actúan según su mandato explícito. Por el contrario, las líneas que prueban la participación de A y B , así como del MUA del supuesto autor, podrían ser una falsificación creada por C. El Received:campo que se muestra arriba es una parte del encabezado que marca una época. El Return-Path:está escrito por E , el agente de entrega de correo (MDA), según el sobre del mensaje . Los campos de seguimiento adicionales, diseñados para la autenticación de correo electrónico, pueden completar la parte superior del encabezado.
Normalmente, los mensajes enviados por el ADMD de un autor van directamente al MX del destino (que es B → D en las figuras). El ADMD del remitente puede agregar tokens de autenticación solo si el mensaje pasa por sus casillas. Los casos más comunes se pueden esquematizar de la siguiente manera:
Los proveedores de acceso NO DEBEN bloquear el acceso de los usuarios a Internet externo mediante el puerto de ENVÍO 587.
El SPF permite al receptor comprobar que un correo electrónico que supuestamente proviene de un dominio específico proviene de una dirección IP autorizada por los administradores de ese dominio. Por lo general, un administrador de dominio autorizará las direcciones IP utilizadas por sus propios MTA salientes, incluido cualquier proxy o host inteligente. [7] [8]
La dirección IP del MTA emisor está garantizada como válida por el Protocolo de Control de Transmisión , ya que establece la conexión comprobando que el host remoto es accesible. [9] El servidor de correo receptor recibe el comando HELO SMTP poco después de que se establezca la conexión, y un Mail from:al principio de cada mensaje. Ambos pueden contener un nombre de dominio. El verificador SPF consulta al Sistema de Nombres de Dominio (DNS) para encontrar un registro SPF coincidente, que si existe especificará las direcciones IP autorizadas por el administrador de ese dominio. El resultado puede ser "aprobado", "reprobado" o algún resultado intermedio, y los sistemas generalmente lo tendrán en cuenta en su filtrado antispam. [10]
.png/1280px-DomainKeys_Identified_Mail_(DKIM).png)
DKIM comprueba el contenido del mensaje y utiliza firmas digitales . En lugar de utilizar certificados digitales, las claves para la verificación de firmas se distribuyen a través del DNS. De esa manera, un mensaje se asocia a un nombre de dominio. [11]
Un administrador de dominio compatible con DKIM genera uno o más pares de claves asimétricas , luego entrega claves privadas al MTA firmante y publica claves públicas en el DNS. Las etiquetas DNS están estructuradas como selector._domainkey.example.com, donde selector identifica el par de claves y _domainkeyes una palabra clave fija, seguida del nombre del dominio firmante para que la publicación se produzca bajo la autoridad del ADMD de ese dominio. Justo antes de inyectar un mensaje en el sistema de transporte SMTP, el MTA firmante crea una firma digital que cubre campos seleccionados del encabezado y el cuerpo (o solo su comienzo). La firma debe cubrir campos de encabezado sustantivos como From:, To:, Date:, y Subject:, y luego se agrega al encabezado del mensaje en sí, como un campo de seguimiento. Cualquier número de relés puede recibir y reenviar el mensaje y en cada salto, la firma se puede verificar recuperando la clave pública del DNS. [12] Siempre que los relés intermedios no modifiquen las partes firmadas de un mensaje, sus firmas DKIM siguen siendo válidas.
DMARC permite especificar una política para los mensajes autenticados. Se basa en dos mecanismos 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 verificar el From:campo presentado a los usuarios finales; cómo debe lidiar el receptor con las fallas y un mecanismo de informe para las acciones realizadas bajo esas políticas.
Se han propuesto otros métodos, pero ya no se utilizan o aún no han obtenido un apoyo generalizado. Entre ellos se encuentran Sender ID , Certified Server Validation , DomainKeys y los siguientes:
ADSP permitió la especificación de una política para los mensajes firmados por el dominio del autor. Un mensaje tenía que pasar primero por la autenticación DKIM, luego ADSP podía exigir un tratamiento punitivo si el mensaje no estaba firmado por el dominio del autor (según el From:campo de encabezado). [13]
ADSP fue degradado a histórico en noviembre de 2013. [14]
VBR agrega una garantía a una identidad ya autenticada. Este método requiere de algunas autoridades reconocidas globalmente que certifiquen la reputación de los dominios.
Un remitente puede solicitar una referencia a una autoridad de validación. La referencia, si es aceptada, se publica en la rama DNS administrada por esa autoridad. Un remitente validado debe agregar un VBR-Info:campo de encabezado a los mensajes que envía. También debe agregar una firma DKIM o usar algún otro método de autenticación, como SPF. Un receptor, después de validar la identidad del remitente, puede verificar la validación solicitada VBR-Info:buscando la referencia. [15]
Las aplicaciones deben evitar utilizar este método como medio de autenticación. [16] Sin embargo, a menudo se lleva a cabo y sus resultados, si los hay, se escriben en el Received:campo de encabezado además de la información TCP requerida por la especificación SMTP.
La dirección IP inversa, confirmada al buscar la dirección IP del nombre que se acaba de encontrar, es sólo una indicación de que la IP se configuró correctamente en el DNS. La resolución inversa de un rango de direcciones IP se puede delegar al ADMD que las utiliza, [17] o puede seguir siendo administrada por el proveedor de red. En este último caso, no se puede obtener ninguna identidad útil relacionada con el mensaje.
Consultar una DNSWL (lista blanca basada en DNS) puede proporcionar una evaluación del remitente, posiblemente incluyendo su identificación.
RFC 8601 define un campo de encabezado de seguimiento Authentication-Results:donde un receptor puede registrar los resultados de las comprobaciones de autenticación de correo electrónico que realizó. [16] Se pueden informar múltiples resultados para múltiples métodos en el mismo campo, separados por punto y coma y envueltos como corresponda.
Por ejemplo, el siguiente campo supuestamente está escrito por SPF y DKIMreceiver.example.org y reporta resultados:
Resultados de autenticación: receiver.example.org ; spf=pass smtp.mailfrom = example.com ; dkim=pass [email protected] El primer token después del nombre del campo, receiver.example.org, es el ID del servidor de autenticación, un token conocido como authserv-id . Un receptor que admita RFC 8601 es responsable de eliminar (o cambiar el nombre) de cualquier encabezado falso que diga pertenecer a su dominio para que los filtros posteriores no se confundan. Sin embargo, esos filtros aún deben configurarse, ya que deben saber qué identidades puede usar el dominio.
Para un agente de usuario de correo (MUA), es un poco más difícil saber en qué identidades puede confiar. Dado que los usuarios pueden recibir correo electrónico de varios dominios (por ejemplo, si tienen varias direcciones de correo electrónico), cualquiera de esos dominios podría dejar Authentication-Results:pasar campos porque parecen neutrales. De esa manera, un remitente malintencionado puede falsificar un authserv-id en el que el usuario confiaría si el mensaje llegara desde un dominio diferente. Un legítimo Authentication-Results:suele aparecer justo encima de un Received:campo del mismo dominio desde el que se retransmitió el mensaje. Received:Pueden aparecer campos adicionales entre ese campo y la parte superior del encabezado, ya que el mensaje se transfirió internamente entre servidores que pertenecen a ese mismo ADMD de confianza.
La Autoridad de Números Asignados de Internet mantiene un registro de parámetros de autenticación de correo electrónico. Sin embargo, no es necesario registrar todos los parámetros. Por ejemplo, puede haber valores de "política" locales diseñados únicamente para el uso interno de un sitio, que corresponden a la configuración local y no necesitan registro.
Sin embargo, el informe identificó la autenticación a nivel de dominio como un desarrollo tecnológico prometedor
{{cite web}}: CS1 maint: URL no apta ( enlace ){{cite book}}: |work=ignorado ( ayuda )Cuando el servidor SMTP acepta un mensaje para su retransmisión o para su entrega final, inserta un registro de seguimiento (también denominado indistintamente "línea de marca de tiempo" o línea "Recibido") en la parte superior de los datos del correo. Este registro de seguimiento indica la identidad del host que envió el mensaje, la identidad del host que recibió el mensaje (y está insertando esta marca de tiempo) y la fecha y hora en que se recibió el mensaje. Los mensajes retransmitidos tendrán varias líneas de marca de tiempo.
Hay tres lugares en los que se pueden utilizar técnicas para mejorar las fallas no deseadas de SPF con mediadores.
Creo que, en general, está bien siempre que ofrezcas un mecanismo para incluir en la lista blanca a los reenvíos que no sean de SRS.
DomainKeys Identified Mail (DKIM) permite que una persona, función u organización reclame cierta responsabilidad por un mensaje al asociar un nombre de dominio con el mensaje, que está autorizado a utilizar.