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 HELO
o 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 MAIL
y RCPT
.
Algunas palabras clave relativamente comunes (no todas corresponden a comandos) que se usan hoy en día son:
-
8BITMIME
- Transmisión de datos de 8 bits, RFC 6152 -
ATRN
- AutenticadoTURN
para retransmisión de correo a pedido , RFC 2645 -
AUTH
- SMTP autenticado, RFC 4954 -
CHUNKING
- Fragmentación, RFC 3030 -
DSN
- Notificación de estado de entrega, RFC 3461 (consulte Ruta de devolución de sobre variable ) -
ETRN
- Versión extendida del comando de inicio de cola de mensajes remotosTURN
, RFC 1985 -
HELP
- Suministrar información útil, RFC 821 -
PIPELINING
- Canalización de comandos, RFC 2920 -
SIZE
- Declaración de tamaño de mensaje, RFC 1870 -
STARTTLS
- Seguridad de la capa de transporte , RFC 3207 (2002) -
SMTPUTF8
- Permitir codificación UTF-8 en nombres de buzones y campos de encabezado, RFC 6531 -
UTF8SMTP
- Permitir la codificación UTF-8 en los nombres de los buzones de correo y los campos de encabezado, RFC 5336 (obsoleto)
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 EHLO
comando en servidores se volvió obligatorio y se HELO
designó 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 EHLO
palabra 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:
- Apache James (desde 2.3.0a1)
- Ciudadela (desde las 7.30)
- Servidor de correo de mensajería
- Exim
- Gmail
- IceWarp
- Servicio IIS SMTP
- Kerio Connect
- Lotus Domino
- Microsoft Exchange Server (a partir de Exchange Server 2000)
- Novell GroupWise
- OpenSMTPD
- Servidor de mensajería de comunicaciones de Oracle
- Sufijo
- Sendmail (desde 6.57)
- SubEtha
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
- Postfix (versión 3.0 y posteriores)
- Momentum (versiones 4.1 y 3.6.5, y posteriores)
- Sendmail (en desarrollo)
- Exim (experimental a partir de la versión 4.86)
- CommuniGate Pro a partir de la versión 6.2.2
- Courier-MTA a partir de la versión 1.0
- Halón a partir de la versión 4.0
- Microsoft Exchange Server a partir de la revisión de protocolo 14.0
- Haraka y otros servidores.
- Oracle Communications Messaging Server a partir de la versión 8.0.2.
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
- Autenticación SMTP
- Correo electrónico
- CRAM-MD5 (un mecanismo SASL para ESMTPA) RFC 2195
- Capa de seguridad y autenticación simple (SASL) RFC 4422
- Lista de software de servidor de correo
- RFC 3516, Extensión de contenido binario del Protocolo de acceso a mensajes de Internet
Referencias
enlaces externos
- El registro IANA de parámetros de correo incluye palabras clave de extensión de servicio
- Extensiones de servicio SMTP RFC 1869
- RFC 5321 Protocolo simple de transferencia de correo
- RFC 4954 - Extensión de servicio SMTP para autenticación (obsoleta RFC 2554 )
- RFC 3848 - SMTP y LMTP Transmisión Tipos de registro (con ESMTPA)
- RFC 6409 - Envío de mensajes para correo (obsoleta RFC 4409 , que deja obsoleta RFC 2476 )