RFC 1869 – Extensiones de Servicio SMTP (ESMTP)

Internet Standard Core SMTP & Message Format Published March 2026

ELI5: El SMTP original era como dos personas que solo podían hablar inglés básico. ESMTP es como empezar una conversación diciendo "¿También hablo francés, alemán y japonés — ¿y tú?" El comando EHLO reemplazó a HELO y permite que ambos lados descubran qué características extras comparten antes de empezar a intercambiar correo. Cada característica SMTP moderna — autenticación, cifrado, límites de tamaño — depende de este mecanismo de negociación.

Por Qué Existe Este RFC

El protocolo SMTP original (RFC 821, 1982) no tenía mecanismo para agregar nuevas características. No había forma de que un cliente descubriera qué soporta un servidor, ni forma de que un servidor anunciara capacidades. Cada extensión requería una nueva versión de protocolo incompatible.

RFC 1869, publicado en 1995, resolvió esto definiendo un marco genérico para extensiones SMTP. Introdujo el comando EHLO (Extended HELLO) como reemplazo para HELO. Cuando un cliente envía EHLO, el servidor responde con una lista de extensiones que soporta. El cliente puede entonces usar cualquier extensión que ambos lados entiendan.

Este marco es tan fundamental que fue posteriormente incorporado directamente a la especificación base de SMTP en RFC 5321. Prácticamente cada sesión SMTP hoy usa ESMTP — HELO simple es efectivamente obsoleto.

Cómo Funciona

El cliente se conecta y recibe el banner de bienvenida del servidor.
El cliente envía EHLO client.example.com (en lugar del antiguo HELO).
El servidor responde con 250 seguido de su nombre de host, luego una palabra clave de extensión por línea. Cada línea usa 250- (continuación) excepto la última, que usa 250 (final).
El cliente inspecciona la lista de extensiones y usa solo las características que el servidor anunció.
Si el servidor no entiende EHLO (extremadamente raro hoy), devuelve un error 500, y el cliente retrocede a HELO.

Ejemplo SMTP

Una negociación típica de capacidades ESMTP:

S: 220 mx.example.com ESMTP ready C: EHLO sender.example.net S: 250-mx.example.com Hello sender.example.net S: 250-SIZE 52428800 S: 250-8BITMIME S: 250-STARTTLS S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-CHUNKING S: 250-SMTPUTF8 S: 250 AUTH PLAIN LOGIN # El cliente ahora sabe exactamente qué soporta este servidor: # SIZE — tamaño máximo de mensaje es 50 MB # 8BITMIME — codificación de transferencia de contenido de 8 bits permitida # STARTTLS — cifrado TLS disponible # ENHANCEDSTATUSCODES — códigos de estado RFC 3463 # PIPELINING — puede lotes de comandos (RFC 2920) # CHUNKING — comando BDAT disponible (RFC 3030) # SMTPUTF8 — direcciones internacionalizadas (RFC 6531) # AUTH — autenticación con PLAIN o LOGIN

Detalles Técnicos Clave

El Registro de Extensiones

Las extensiones ESMTP están registradas con IANA. Cada extensión define una palabra clave (por ejemplo, STARTTLS, AUTH, PIPELINING) y opcionalmente parámetros. Las extensiones más importantes para correo electrónico:

Palabra Clave	RFC	Propósito
`SIZE`	RFC 1870	Declarar tamaño máximo de mensaje
`8BITMIME`	RFC 6152	Permitir contenido de 8 bits en cuerpo de mensaje
`STARTTLS`	RFC 3207	Mejorar conexión a cifrado TLS
`AUTH`	RFC 4954	Autenticación SMTP
`PIPELINING`	RFC 2920	Lotes de múltiples comandos sin esperar
`CHUNKING`	RFC 3030	Transferencia de datos binarios con BDAT
`SMTPUTF8`	RFC 6531	Direcciones de correo electrónico internacionalizadas
`DSN`	RFC 3461	Solicitudes de notificación de estado de entrega
`ENHANCEDSTATUSCODES`	RFC 3463	Códigos de estado detallados en respuestas
`REQUIRETLS`	RFC 8689	Requerir TLS para este mensaje

EHLO vs. HELO

HELO es el saludo SMTP original de 1982. No proporciona descubrimiento de capacidades. EHLO es un superconjunto estricto: realiza la misma función de saludo pero también desencadena la lista de capacidades. Los servidores deben soportar ambos, pero los clientes siempre deben usar EHLO primero y solo retroceder a HELO si EHLO es rechazado.

Re-EHLO Después de Cambios de Estado

La lista de capacidades puede cambiar durante una sesión. Después de un apretón de manos STARTTLS, el cliente debe enviar un nuevo EHLO porque el servidor puede anunciar diferentes extensiones sobre la conexión cifrada (por ejemplo, AUTH a menudo solo está disponible después de TLS). Después de RSET, la lista de capacidades sigue siendo válida.

Parámetros de Extensión

Algunas extensiones incluyen parámetros en la línea de respuesta EHLO. Por ejemplo, SIZE 52428800 declara un límite de 50 MB, y AUTH PLAIN LOGIN enumera los mecanismos de autenticación disponibles. Las extensiones también pueden agregar parámetros a los comandos MAIL FROM y RCPT TO, como MAIL FROM:<user@example.com> SIZE=1048576.

Errores Comunes

Usar HELO en lugar de EHLO. Algunas aplicaciones heredadas aún envían HELO. Esto deshabilita todas las extensiones SMTP, incluida autenticación y cifrado. Siempre usa EHLO.
No verificar la respuesta EHLO. Los clientes que ciegamente usan extensiones sin verificar que el servidor las anunció obtendrán errores. Siempre analiza la lista de capacidades antes de usar cualquier extensión.
Almacenar en caché capacidades entre sesiones. Las extensiones que un servidor soporta pueden cambiar entre conexiones. Siempre realiza un EHLO nuevo para cada conexión nueva.
Olvidar re-EHLO después de STARTTLS. Después de mejorar a TLS, la lista de capacidades pre-TLS es inválida. Un nuevo EHLO es obligatorio para obtener las capacidades actualizadas.
Enviar un nombre de host EHLO inválido. El argumento para EHLO debe ser el FQDN de tu servidor o, si no hay nombre de host disponible, un literal de dirección como [192.0.2.1]. Enviar un nombre de host vacío o falso puede causar rechazo.
Ignorar el dominio EHLO para seguridad. Los servidores receptores no deben confiar en el nombre de host EHLO para autenticación — es auto-reportado y trivialmente falsificado. Usa SPF, DKIM y DMARC en su lugar.

Impacto en la Entregabilidad

ESMTP es requerido para correo moderno. Sin EHLO, no puedes usar STARTTLS, AUTH, PIPELINING u otra extensión. Un cliente que solo habla HELO es tratado como sospechoso por la mayoría de servidores de correo.
El soporte de extensiones señala legitimidad. Los servidores que anuncian e implementan correctamente extensiones estándar (ENHANCEDSTATUSCODES, PIPELINING, SIZE) son vistos como bien configurados. El soporte de extensiones faltante o roto puede desencadenar puntuación negativa en filtros de spam.
El nombre de host EHLO importa para reputación. Aunque el nombre de host EHLO no está autenticado, muchos filtros de spam verifican que se resuelva en DNS y coincida con el DNS inverso de la IP conectada. Las discrepancias contribuyen a la puntuación de spam.
La declaración SIZE previene ancho de banda desperdiciado. Cuando el servidor anuncia su límite de tamaño, los clientes pueden evitar enviar mensajes demasiado grandes que serían rechazados después de la transferencia de datos completa. Esto mejora la eficiencia de entrega.