La autenticación SMTP , a menudo abreviada SMTP AUTH , es una extensión del Protocolo simple de transferencia de correo (SMTP) mediante el cual un cliente puede iniciar sesión utilizando cualquier mecanismo de autenticación compatible con el servidor. Lo utilizan principalmente los servidores de envío , donde la autenticación es obligatoria. [1]
Historia
SMTP, tal como lo especificó Jon Postel en la década de 1970, no preveía el uso de contraseñas para enviar mensajes de correo electrónico; cada servidor era por diseño un retransmisor de correo abierto . Como resultado, el spam y los gusanos , aunque inicialmente no eran un problema, se habían convertido en una plaga a finales de los noventa. [2] Antes de SMTP AUTH, un cliente de retransmisión tenía que ser identificado por la dirección IP , lo que solo es práctico para los servicios de correo electrónico proporcionados por el mismo proveedor de servicios de Internet (ISP) que proporciona la conexión, o bien, utilizando hacks específicos, como POP antes de SMTP .
John Gardiner Myers publicó el primer borrador de SMTP AUTH en 1995, [3] y ha sido desarrollado y discutido sucesivamente en el IETF junto con el protocolo de envío de correo, SMTP extendido (ESMTP) y la capa de seguridad y autenticación simple (SASL). Un mecanismo SASL más antiguo para la autenticación ESMTP (ESMTPA) es CRAM-MD5 , y los usos del algoritmo MD5 en HMAC (códigos de autenticación de mensajes basados en hash) todavía se consideran sólidos. [4]
El Consorcio de Correo de Internet (IMC) informó que el 55% de los servidores de correo eran retransmisiones abiertas en 1998, [5] pero menos del 1% en 2002. [6]
Papel en el sistema de transporte de correo
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 admitir usuarios nómadas, ya que varios concentradores de red bloquean el puerto 25 o utilizan proxies SMTP . La MSA es responsable de garantizar que el sobre del mensaje contenga buenas direcciones y puede hacer cumplir las políticas locales para el From
campo de encabezado. Verificar que el remitente del sobre (también conocido como Return-Path
) utilizado para SPF y la dirección De coincida con el ID de usuario autenticado es particularmente importante para los dominios que firman mensajes usando DKIM .
Las palabras clave que terminan en "A", como ESMTPA
y ESMTPSA
, se proporcionan para la with
cláusula de Received
los campos de encabezado, cuando los mensajes se reciben con SMTP AUTH. [8] "Las palabras clave se proporcionan con fines estadísticos o de diagnóstico" (RFC 3848); algunos clientes los comprueban, por ejemplo, Spamassassin .
Detalles
Al igual que con todas las extensiones SMTP, SMTP AUTH se anuncia en la respuesta EHLO, junto con una lista de métodos de autenticación compatibles. Estos métodos pueden cambiar después de emitir STARTTLS , normalmente permitiendo contraseñas de texto sin formato solo en el último caso. RFC 4954 proporciona el siguiente ejemplo ("C:" y "S:" no son parte del protocolo, indican líneas enviadas por el cliente y el servidor, respectivamente):
S: 220 smtp.example.com Servidor ESMTPC: EHLO client.example.comS: 250-smtp.example.com Hola cliente.example.comS: 250-AUTH GSSAPI DIGEST-MD5S: 250-CÓDIGOS DE ESTADO MEJORADOSS: 250 STARTTLSC: STARTTLSS: 220 Listo para iniciar TLS ... Continúa la negociación de TLS. Más comandos protegidos por la capa TLS ...C: EHLO client.example.comS: 250-smtp.example.com Hola cliente.example.comS: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ =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 retransmisión 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, el rasgo histórico de que SMTP no está autenticado por defecto da como resultado 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 al comando MAIL FROM , para permitir distinguir la autenticación de la autorización. De esa forma, un remitente puede identificarse y transmitir varios mensajes durante la misma sesión. Si bien la autenticación no necesita variar, una vez establecida, se pueden enviar diferentes mensajes de acuerdo con diferentes acuerdos y, por lo tanto, requieren una autorización diferente. Por ejemplo, los mensajes pueden transmitirse en nombre de diferentes usuarios. El uso de este parámetro es mucho menos popular que el uso del comando para otorgar privilegios de retransmisión.
La autenticación SMTP es una "extensión" en términos SMTP, por lo que requiere que el servidor y el cliente usen el verbo EHLO para el saludo para indicar la compatibilidad con las extensiones, a diferencia del saludo HELO obsoleto. [10] Para compatibilidad con versiones anteriores, el saludo HELO puede aceptarse cuando no se utiliza ninguna extensión .
El texto en mayúsculas 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:
- PLAIN (usa codificación Base64)
- LOGIN (usa codificación Base64) [11]
- GSSAPI ( interfaz de programa de aplicación de servicios de seguridad genéricos )
- DIGEST-MD5 ( autenticación de acceso Digest )
- MD5
- CRAM-MD5
- OAUTH10A (tokens OAuth 1.0a HMAC-SHA1 como se define en RFC 5849)
- OAUTHBEARER ( tokens de portador de OAuth 2.0 como se define en RFC 6750)
Estándares
- RFC 3207, Extensión del servicio SMTP para SMTP seguro sobre seguridad de la capa de transporte , 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 , Randall Gellens y John C. Klensin , noviembre de 2011 (obsoleto RFC 4409, de 2006, que a su vez reemplazó a RFC 2476, de diciembre de 1998).
- RFC 4422, Capa de seguridad y autenticación simple (SASL) , Alexey Melnikov y Kurt D. Zeilenga, junio de 2006.
- RFC 4616, The PLAIN SASL Mechanism , 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 de capa de seguridad y autenticación simple (SASL) para OAuth , W. Mills, T. Showalter y H. Tschofenig, agosto de 2015.
Otro
- Erwin Hoffmann, Autenticación SMTP [Tutorial] , última edición 2017-01-10.
Ver también
Referencias
- ^ Las RFC relevantes para referencia se especifican en lasección # Normas
- ^ Los fideicomisarios de la Universidad de Indiana (1 de abril de 2008). "En Unix, ¿qué es una retransmisión de correo abierta?" . Servicios Universitarios de Tecnología de la Información . Universidad de Indiana . Archivado desde el original el 17 de junio de 2007 . Consultado el 7 de abril de 2008 .
- ^ John Gardiner Myers (abril de 1995). "Extensión del servicio SMTP para autenticación" . IETF . Consultado el 30 de mayo de 2010 .
- ^ Sean Turner, Lily Chen (marzo de 2011). "Consideraciones de seguridad actualizadas para MD5 Message-Digest y los algoritmos HMAC-MD5" . IETF .
- ^ Paul Hoffman (1 de febrero de 1998). "Permitir la retransmisión en SMTP: una encuesta" . Consorcio de correo de Internet . Consultado el 30 de mayo de 2010 .
- ^ Paul Hoffman (agosto de 2002). "Permitir la retransmisión en SMTP: una serie de encuestas" . Consorcio de correo de Internet . Archivado desde el original el 18 de enero de 2007 . Consultado el 30 de mayo de 2010 .
- ^ Randall Gellens (19 de enero de 2005). "Informe de interoperabilidad de envío de mensajes" . IETF . Consultado el 5 de julio de 2019 .
- ^ "Parámetros de correo" . Registro IANA . Consultado el 23 de julio de 2011 .
- ^ Chris Newman (30 de abril de 2010). "Problema de interoperabilidad: envío SMTP, STARTTLS, AUTH EXTERNAL" . IETF . Consultado el 30 de mayo de 2010 .
- ^ https://tools.ietf.org/html/rfc5321 ; Sin embargo, para la compatibilidad con implementaciones conformes más antiguas, los clientes y servidores SMTP DEBEN admitir los mecanismos HELO originales como alternativa.
- ^ K. Murchison y M. Crispin, The LOGIN SASL Mechanism , 28 de agosto de 2003, borrador caducado. LOGIN se describe como obsoleto en eldocumento Mecanismos SASL , pero el mecanismo todavía está en uso.