Autenticación SMTP

La autenticación SMTP , a menudo abreviada como SMTP AUTH , es una extensión del Protocolo simple de transferencia de correo (SMTP) que permite a un cliente iniciar sesión utilizando cualquier mecanismo de autenticación compatible con el servidor. Se utiliza principalmente en servidores de envío , donde la autenticación es obligatoria. ^{[ 1 ]}

SMTP, tal como lo especificó Jon Postel en la década de 1970, no contemplaba el uso de contraseñas para enviar mensajes de correo electrónico; cada servidor era, por diseño, un relé de correo abierto . Como resultado, el spam y los gusanos , si bien no fueron un problema inicialmente, se convirtieron en una plaga a finales de la década de 1990. ^{[ 2 ]} Antes de SMTP AUTH, un cliente de relé debía ser identificado por su dirección IP , lo cual solo es práctico para los servicios de correo electrónico proporcionados por el mismo proveedor de servicios de Internet (ISP) que suministra la conexión, o bien utilizando métodos específicos, como POP antes de SMTP .

John Gardiner Myers publicó el primer borrador de SMTP AUTH en 1995, ^{[ 3 ]} y se ha desarrollado y discutido sucesivamente en el IETF junto con el protocolo de envío de correo, SMTP extendido (ESMTP) y la capa de autenticación y seguridad simple (SASL). Un mecanismo SASL anterior para la autenticación ESMTP (ESMTPA) es CRAM-MD5 , y el uso del algoritmo MD5 en HMAC (códigos de autenticación de mensajes basados ​​en hash) todavía se considera válido. ^{[ 4 ]}

El Consorcio de Correo de Internet (IMC) informó que el 55% de los servidores de correo eran relés abiertos en 1998, ^{[ 5 ]} pero menos del 1% en 2002. ^{[ 6 ]}

El uso de un agente de envío de correo (MSA), generalmente en el puerto 587, implica SMTP AUTH. El uso de MSA es compatible con la mayoría del software ^{[ 7 ]} y se recomienda, especialmente para dar soporte a usuarios nómadas, ya que varios nodos de red bloquean el puerto 25 o utilizan proxies SMTP . El MSA es responsable de garantizar que el sobre del mensaje contenga direcciones válidas y puede aplicar políticas locales para el Fromcampo de encabezado. Verificar que el remitente del sobre (también conocido como Return-Path) utilizado para SPF y la dirección From coincidan con el ID de usuario autenticado es particularmente importante para los dominios que firman mensajes mediante DKIM .

Las palabras clave que terminan en "A", como ESMTPAy ESMTPSA, se proporcionan para la withcláusula de Receivedcampos de encabezado, cuando se reciben mensajes con SMTP AUTH. ^{[ 8 ]} "Las palabras clave se proporcionan con fines estadísticos o de diagnóstico" (RFC 3848); son verificadas por algunos clientes, por ejemplo Spamassassin .

Al igual que con todas las extensiones SMTP, SMTP AUTH se anuncia en la respuesta EHLO, junto con una lista de los métodos de autenticación admitidos. Estos métodos pueden cambiar después de emitir STARTTLS , permitiendo normalmente contraseñas en texto plano solo en este último caso. El RFC 4954 proporciona el siguiente ejemplo ("C:" y "S:" no forman parte del protocolo, indican las líneas enviadas por el cliente y el servidor, respectivamente):

S: 220 smtp.example.com Servidor ESMTP C: EHLO client.example.com S: 250-smtp.example.com Hola cliente.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-CÓDIGOS DE ESTADO MEJORADOS S: 250 STARTTLS C: STARTTLS S: 220 Listo para comenzar TLS ... La negociación TLS continúa. Los comandos adicionales están protegidos por la capa TLS... C: EHLO client.example.com S: 250-smtp.example.com Hola cliente.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN aWxvdmV3aWtpcGVkaWE= S: 235 2.7.0 Autenticación exitosa

SMTP AUTH también se puede usar en el puerto 25. Por lo general, los servidores rechazan los comandos RCPT TO que implican reenvío a menos que se hayan aceptado las credenciales de autenticación. La especificación recomienda que los servidores emitan 530 5.7.0 Autenticación requerida en respuesta a la mayoría de los comandos en caso de que el servidor esté configurado para requerir autenticación y el cliente aún no lo haya hecho. Solo los servidores que escuchan en el puerto 587, o los servidores privados, deben configurarse de esa manera, no un Message eXchange (MX). Sin embargo, la característica histórica de que SMTP no se autentique por defecto resulta en un comportamiento diferente con respecto a los protocolos de acceso, en algunos casos; por ejemplo, cuando se usa AUTH EXTERNAL después de STARTTLS. ^{[ 9 ]}

Además del comando AUTH , la extensión también proporciona un parámetro AUTH para el comando MAIL FROM , lo que permite distinguir entre autenticación y autorización. De esta forma, un remitente puede identificarse y transmitir varios mensajes durante la misma sesión. Si bien la autenticación no tiene por qué variar, una vez establecida, se pueden enviar diferentes mensajes según distintos acuerdos, lo que requiere una autorización diferente. Por ejemplo, se pueden reenviar mensajes en nombre de distintos usuarios. El uso de este parámetro es mucho menos frecuente que el uso del comando para otorgar privilegios de reenvío.

La autenticación SMTP es una "extensión" en términos SMTP, por lo que requiere que el servidor y el cliente utilicen el verbo EHLO para el saludo para indicar la compatibilidad con extensiones, en lugar del saludo HELO obsoleto. ^{[ 10 ]} Para la compatibilidad con versiones anteriores, el saludo HELO puede aceptarse cuando no se utiliza ninguna extensión .

El texto en mayúsculas que aparece después del comando AUTH es una lista de los tipos de autorización que aceptará el servidor SMTP.

Algunos ejemplos de protocolos de autorización incluyen:

• LISOS (Utiliza codificación Base64)
• INICIO DE SESIÓN (Utiliza codificación Base64) ^{[ 11 ]} (obsoleto en favor de PLAIN)
• GSSAPI ( Interfaz de programación de aplicaciones de servicios de seguridad genéricos )
• DIGEST-MD5 ( autenticación de acceso mediante resumen )
• MD5
• CRAM-MD5
• OAUTH10A ( tokens HMAC-SHA1 de OAuth 1.0a según se definen en la RFC 5849)
• OAUTHBEARER ( tokens de portador de OAuth 2.0 según se definen en la RFC 6750)
• XOAUTH2 ^{[ 12 ]}

• RFC 3207 , Extensión del servicio SMTP para SMTP seguro sobre Transport Layer Security , Paul Hoffman, febrero de 2002. 
• RFC 3848 , Registro de tipos de transmisión ESMTP y LMTP , Chris Newman, julio de 2004. 
• RFC 6409 , Envío de mensajes para correo electrónico , Randall Gellens y John C. Klensin , noviembre de 2011 (sustituye a RFC 4409, de 2006, que a su vez reemplazó a RFC 2476, de diciembre de 1998). 
• RFC 4422 , Capa de autenticación y seguridad simple (SASL) , Alexey Melnikov y Kurt D. Zeilenga, junio de 2006. 
• RFC 4616 , El mecanismo PLAIN SASL , K. Zeilenga, Ed., agosto de 2006. 
• RFC 4954 , Extensión del servicio SMTP para autenticación , Robert Siemborski y Alexey Melnikov, julio de 2007. 
• RFC 7628 , Un conjunto de mecanismos sencillos de autenticación y capa de seguridad (SASL) para OAuth , W. Mills, T. Showalter y H. Tschofenig, agosto de 2015. 

• Erwin Hoffmann, Autenticación SMTP [ Tutorial ] , última edición 10/01/2017.

• Autenticación de correo electrónico
• Protocolo simple de transferencia de correo
• agente de envío de correo
• Números de puerto del cliente de correo electrónico
• Capa de autenticación y seguridad simple
• Relevo de correo abierto
• POP antes que SMTP