SMTP extendido - Extended SMTP

SMTP extendido ( ESMTP ), a veces denominado SMTP mejorado , es una definición de extensiones de protocolo del estándar Protocolo simple de transferencia de correo (SMTP). ESMTP se definió en noviembre de 1995 en la publicación RFC 1869 del IETF, que estableció una estructura general para todas las extensiones existentes y futuras.

ESMTP define medios consistentes y manejables mediante los cuales los clientes y servidores ESMTP pueden identificarse y los servidores pueden indicar extensiones compatibles.

Extensiones

Como SMTP, ESMTP es un protocolo que se utiliza para transportar correo de Internet. Se utiliza como protocolo de transporte entre servidores y (con comportamiento restringido aplicado) como protocolo de envío de correo.

La característica de identificación principal para los clientes ESMTP es abrir una transmisión con el comando EHLO(Extended HELLO), en lugar de HELO(Hello, el estándar RFC 821 original ). Un servidor responderá con éxito (código 250), falla (código 550) o error (código 500, 501, 502, 504 o 421), según su configuración. Un servidor ESMTP devuelve el código 250 OK en una respuesta de varias líneas con su dominio y una lista de palabras clave para indicar las extensiones compatibles. Un servidor compatible con RFC 821 devuelve el código de error 500, lo que permite a los clientes ESMTP probar HELOo QUIT.

Cada extensión de servicio se define en un formato aprobado en RFC posteriores y se registra con la Autoridad de Números Asignados de Internet (IANA). Las primeras definiciones fueron los RFC 821 servicios opcionales: SEND, SOML(Enviar o Correo), SAML(Enviar y Correo), EXPN, HELP, y TURN. Se estableció el formato de los verbos SMTP adicionales y para los nuevos parámetros en MAILy RCPT.

Algunas palabras clave relativamente comunes (no todas corresponden a comandos) que se usan hoy en día son:

El formato ESMTP se reformuló en RFC 2821 (reemplazando a RFC 821 ) y se actualizó a la última definición en RFC 5321 en 2008. El soporte para el EHLOcomando en servidores se volvió obligatorio y se HELOdesignó como un respaldo obligatorio.

Las extensiones de servicio no estándar y no registradas se pueden utilizar mediante acuerdo bilateral. Estos servicios se indican mediante una EHLOpalabra clave de mensaje que comienza con "X" y con cualquier parámetro o verbo adicional marcado de manera similar.

Los comandos SMTP no distinguen entre mayúsculas y minúsculas. Se presentan aquí en mayúsculas sólo para enfatizar. Un servidor SMTP que requiere un método de uso de mayúsculas específico es una violación del estándar.

Lista de servidores de apoyo

  • IceWarp
  • Postfix  : no se necesitan parches para RFC 6531 .. RFC 6533 .
  • Sendmail  : parche de código fuente necesario para la compatibilidad con SMTPUTF8
  • HMailServer  : servidor de correo gratuito para Windows
  • Exim
  • MailEnable: soporte solo en Enterprise Edition
  • MagicMail: el revestimiento de tuberías no se admite intencionalmente

8BITMIME

Lista de servidores de apoyo

Al menos los siguientes servidores anuncian la extensión 8BITMIME:

Los siguientes servidores se pueden configurar para anunciar 8BITMIME, pero no realizan la conversión de datos de 8 bits a 7 bits cuando se conectan a relés que no son 8BITMIME:

  • Exim y qmail no traducen mensajes de ocho bits a siete bits cuando se intenta retransmitir datos de 8 bits a pares que no son 8BITMIME, como exige el RFC. Esto no causa problemas en la práctica, ya que prácticamente todos los retransmisores de correo modernos están limpios de 8 bits .
  • Microsoft Exchange Server 2003 anuncia 8BITMIME de forma predeterminada, pero la transmisión a un par que no es 8BITMIME da como resultado un rebote. Esto está permitido por RFC 6152 sección 3 .

SMTP-AUTH

La extensión SMTP-AUTH proporciona un mecanismo de control de acceso. Consiste en un paso de autenticación a través del cual el cliente efectivamente inicia sesión en el servidor de correo durante el proceso de envío de correo. Los servidores que admiten SMTP-AUTH generalmente se pueden configurar para requerir que los clientes usen esta extensión, asegurando que se conozca la verdadera identidad del remitente. La extensión SMTP-AUTH se define en RFC 4954.

SMTP-AUTH se puede utilizar para permitir a los usuarios legítimos retransmitir correo mientras se niega el servicio de retransmisión a usuarios no autorizados, como los spammers . No garantiza necesariamente la autenticidad del remitente del sobre SMTP ni del encabezado "De:" de RFC 2822. Por ejemplo, la suplantación de identidad , en la que un remitente se hace pasar por otra persona, todavía es posible con SMTP-AUTH a menos que el servidor esté configurado para limitar las direcciones de remitentes de mensajes a las direcciones para las que este usuario AUTHED está autorizado.

La extensión SMTP-AUTH también permite que un servidor de correo indique a otro que el remitente ha sido autenticado al retransmitir correo. En general, esto requiere que el servidor del destinatario confíe en el servidor de envío, lo que significa que este aspecto de SMTP-AUTH rara vez se usa en Internet.

SMTPUTF8

Lista de servidores de apoyo

Lista de servidores locales compatibles

Servidores de entrega local (LMTP)

  • Ninguna

Lista de clientes de apoyo

  • nmh (desde la versión 1.7)

Lista de filtros de contenido compatibles

  • Amavis (SMTP y LMTP) desde la versión 2.10.0

Ver también

Referencias

enlaces externos