Ícono del sitio Mailtrap

Lista de Todos los Comandos SMTP y Códigos de Respuesta

En el artículo del blog SMTP vs. IMAP vs. POP3, explicamos que una sesión SMTP es una especie de conversación entre el cliente SMTP y el servidor SMTP. El cliente se comunica usando comandos que consisten en caracteres alfabéticos. El servidor responde con códigos numéricos. Hoy, profundizaremos en esto en detalle. Descubrirá los comandos SMTP válidos y los obsoletos. Además, aclararemos qué códigos de respuesta corresponden a cada comando.

Comandos SMTP esenciales en el orden en que pueden ser usados

Cada comando SMTP define una función particular dentro de la sesión SMTP, que consta de tres pasos:

Por lo tanto, decidimos hacer una lista de los comandos SMTP de acuerdo con este flujo.

HELO/EHLO

El comando HELO inicia la conversación de la sesión SMTP. El cliente saluda al servidor y se presenta. Como regla general, HELO se atribuye con un argumento que especifica el nombre de dominio o la dirección IP del cliente SMTP.

Ejemplo: HELO cliente.net

EHLO es una alternativa a HELO para servidores que soportan las extensiones del servicio SMTP (ESMTP). Si el servidor no soporta ESMTP, responderá con un error.

Ejemplo: EHLO cliente.net

En cualquier caso, HELO o EHLO es un comando OBLIGATORIO para que el cliente SMTP comience una transferencia de email.

MAIL FROM

El comando MAIL FROM inicia una transferencia de email. Como argumento, MAIL FROM incluye un sender mailbox (buzón de remitente) (reverse-path). Para algunos tipos de mensajes de reporte como notificaciones de no-entrega, el reverse-path puede estar vacío. También se pueden especificar parámetros opcionales.

Ejemplo: MAIL FROM "prueba@cliente.net"

RCPT TO

El comando RCPT TO especifica el destinatario. Como argumento, RCPT TO incluye un destination mailbox (buzón de destino) (forward-path). En caso de múltiples destinatarios, RCPT TO se utilizará para especificar cada destinatario por separado.

Ejemplo: RCPT TO "usuario@destinatario.net"

DATA

Con el comando DATA, el cliente pide permiso al servidor para transferir los datos del email. El código de respuesta 354 otorga el permiso, y el cliente lanza la entrega del contenido del email línea por línea. Esto incluye la fecha, encabezado “De” y “Para” (from y to), línea de asunto, archivos adjuntos y texto del cuerpo.

Una línea final que contiene un punto (“.”) termina la transferencia de datos del email. El servidor responde a la línea final.

Ejemplo:
DATA
354 (código de respuesta del servidor)
Fecha: Mie, 30 Jul 2019 06:04:34
De: prueba@cliente.net
Título: Cómo funciona SMTP
Para: usuario@destinatario.net
Texto del cuerpo
.

NOOP

El comando NOOP se usa solo para comprobar si el servidor puede responder. La respuesta “250 OK” es la respuesta estándar.

Ejemplo: NOOP

HELP

Con el comando HELP, el cliente solicita una lista de comandos que el servidor soporta. HELP puede usarse con un argumento (un comando específico). Si el servidor soporta esto, proporcionará la información correspondiente a esta solicitud.

Ejemplo: HELP 

VRFY y EXPN

VRFY se utiliza para verificar si un buzón (mailbox) en el argumento existe en el local host. La respuesta del servidor incluye el buzón del usuario y puede incluir el nombre completo del usuario.

Example:
VRFY usuario2
250 Samantha Smith usuario2@cliente.net (respuesta del servidor)

EXPN se utiliza para verificar si una lista de email en el argumento existe en el local host. La respuesta positiva especificará los miembros de los destinatarios.

Ejemplo:
EXPN lista-email
250-usuario1@cliente.net (respuesta del servidor)
250-usuario2@cliente.net (respuesta del servidor)
250-usuario3@cliente.net (respuesta del servidor)

El guión (-) entre el código numérico y el buzón del usuario indica que la respuesta continúa en la siguiente línea.

VRFY y EXPN implementan la autenticación SMTP. Además, son útiles para realizar una auditoría interna del servidor. Por otro lado, estos comandos se consideran un riesgo de seguridad. Los spammers pueden usarlos para recolectar direcciones de email válidas del servidor. Por lo tanto, los sistemas de mensajería instalan las protecciones correspondientes o deshabilitan los comandos.

RSET

El comando RSET restablece la conexión SMTP al estado inicial. Borra todos los buffers y tablas de estado (tanto del remitente como del destinatario). RSET recibe solo la respuesta positiva del servidor – 250. Al mismo tiempo, la conexión SMTP permanece abierta y está lista para una nueva transacción de email.

Ejemplo: RSET

QUIT

El comando QUIT envía la solicitud para terminar la sesión SMTP. Una vez que el servidor responde con 221, el cliente cierra la conexión SMTP. Este comando especifica que el receptor DEBE enviar una respuesta “221 OK” y luego cerrar el canal de transmisión.

Ejemplo: QUIT

Comandos SMTP extendidos que algunos servidores SMTP pueden soportar

STARTTLS 

El comando STARTTLS se utiliza para iniciar un handshake TLS para una sesión SMTP segura. STARTTLS restablece el protocolo SMTP al estado inicial. Una vez que se recibe la respuesta 220 del servidor, el cliente SMTP debe enviar HELO o EHLO para iniciar la sesión. En caso de una respuesta negativa (454), el cliente debe decidir si continuar la sesión SMTP o no.

Ejemplo: STARTTLS

AUTH

El comando AUTH se utiliza para autenticar al cliente ante el servidor. Para esto, usa un argumento que especifica diferentes niveles de seguridad y métodos de inicio de sesión: PLAIN, LOGIN y CRAM-MD5. La sesión se considera autenticada una vez que el servidor proporciona una respuesta positiva. Para más información sobre esto, lea el artículo del blog sobre autenticación SMTP.

Ejemplo: AUTH CRAM-MD5

ATRN 

El comando ATRN reemplazó al comando obsoleto TURN. Se usaba para revertir la conexión entre los servidores SMTP locales y externos (remitente y receptor). TURN carecía de autenticación, por lo tanto, fue desaprobado. ATRN carece de este inconveniente. Además, está disponible para direcciones IP asignadas dinámicamente.

Ejemplo:
ATRN client.net,client.com
250 OK ahora revirtiendo la conexión (respuesta del servidor)

BDAT

El comando BDAT se usa para enviar contenidos de email. Puede ser una alternativa al comando DATA. BDAT tiene dos argumentos. El primero define la longitud del fragmento de datos en octetos. El segundo indica que el fragmento de datos es terminal. No es necesario un punto para terminar la transferencia de email como en el comando DATA. BDAT se usa ampliamente en Microsoft Exchange Server. Al mismo tiempo, DATA es un comando obligatorio para todos los servidores.

Ejemplo:
BDAT 67 LAST
Para: usuario@destinatario.net
De: prueba@cliente.net
Título: Cómo funciona SMTP
250 Message OK, 67 octetos recibidos (respuesta del servidor)

ETRN

El comando ETRN es la solicitud para iniciar el procesamiento de la cola SMTP de un host de servidor especificado.

Ejemplo:
ETRN client.com
250 OK, inicio de cola para cliente.com (respuesta del servidor)

Comandos SMTP de uso privado

El cliente y el servidor pueden usar comandos SMTP de uso privado a través de un acuerdo bilateral. Estas son extensiones de servicio propietarias y deben comenzar con “X”. No deben ser registrados ni estandarizados. Aquí hay algunos de ellos:

Comandos SMTP obsoletos

En la web, hay muchas fuentes desactualizadas donde puedes encontrar comandos SMTP obsoletos. Para no perder tiempo en opciones inválidas, aquí hay una lista de los comandos que ya no puede usar:

Códigos de respuesta SMTP

El servidor SMTP responde al cliente usando un código de tres dígitos. Cada dígito tiene un significado especial:

El código numérico es seguido por un texto destinado a un usuario humano para entender el punto. Diferentes servidores pueden usar una descripción textual modificada de la respuesta, mientras que el código numérico es permanente. Entonces, esto es lo que su servidor SMTP puede responder:

CódigoQué significa
101Error de conexión con el servidor (nombre de servidor incorrecto o puerto de conexión)
211Estado del sistema (respuesta a HELP)
214Mensaje de ayuda (respuesta a HELP)
220El servidor está listo (respuesta al intento del cliente de establecer una conexión TCP)
221El servidor cierra el canal de transmisión
235Autenticación exitosa (respuesta a AUTH)
250El comando solicitado está completado. Por regla general, el código es seguido por OK
251El usuario no es local, pero el servidor reenviará el mensaje a <forward-path>
252El servidor no puede verificar al usuario (respuesta a VRFY). El mensaje será aceptado e intentado para la entrega
334Respuesta al comando AUTH cuando el mecanismo de seguridad solicitado es aceptado
354El servidor confirma la transferencia del contenido del email (respuesta a DATA). Después de eso, el cliente comienza a enviar el email. Terminado con un punto ( “.”)
421El servidor no está disponible porque cierra el canal de transmisión
422El buzón del destinatario ha excedido su límite de almacenamiento
431Sobrecarga de archivos (demasiados mensajes enviados a un dominio particular)
441No hay respuesta del servidor del destinatario
442Conexión interrumpida
446Se ha producido un bucle interno
450Buzón no disponible (ocupado o temporalmente bloqueado). Acción solicitada abortada
451El servidor abortó el comando debido a un error local
452El servidor abortó el comando debido a insuficiente almacenamiento del sistema
454TLS no disponible debido a una razón temporal (respuesta a STARTTLS)
455Los parámetros no pueden ser acomodados
471Error del servidor de email debido al filtro de spam local
500Error de sintaxis (también una línea de comando puede ser demasiado larga). El servidor no puede reconocer el comando
501Error de sintaxis en parámetros o argumentos
502El servidor no ha implementado el comando
503Secuencia de comandos inapropiada
504El servidor no ha implementado un parámetro de comando
510Dirección de email no válida
512Un error de DNS (revisa la dirección de sus destinatarios)
523El tamaño total de su email supera los límites del servidor destinatario
530Problema de autenticación que generalmente requiere que se ejecute el comando STARTTLS
535Autenticación fallida
538Se requiere cifrado para un mecanismo de autenticación solicitado
541Mensaje rechazado por filtro de spam
550El buzón no está disponible. El servidor abortó el comando porque no se encontró el buzón o por razones de políticas. Alternativamente: Se requiere autenticación para el reenvío
551Usuario no local. Se especificará la <forward-path>
552El servidor abortó el comando porque el buzón está lleno
553Dirección de email incorrecta sintácticamente
554La transacción falló debido a un error desconocido o No hay servicio SMTP aquí como respuesta a los intentos del cliente de establecer una conexión
555Parámetros no reconocidos/no implementados (respuesta a MAIL FROM o RCPT TO)

Para obtener más información sobre estos códigos de respuesta, consulte nuestro vídeo dedicado:

Comando-respuesta

Como habrás notado anteriormente, algunos códigos son específicos de los comandos. De hecho, solo tres de ellos, 500, 501 y 421 pueden ser una respuesta a cualquier comando SMTP. Otros pueden ser categorizados como positivos y negativos (el código 354 puede ser considerado como una respuesta intermedia). Veamos a qué comandos pueden referirse.

ComandoRespuesta positivaRespuesta negativa
Handshake SMTP (establecimiento de conexión)220554
STARTTLS220454
EHLO o HELO250502 (respuesta a EHLO para servidores antiguos)
504
550
AUTH235
334
530
535
538
MAIL FROM250    451
452
455
503
550
552
553
555
RCPT TO250
251          
450
451
452
455
503
550
551
552
553
555
DATA250
354 (respuesta intermedia)
                           
450
451
452
503
550 (rechazo por razones de política)
552
554
RSET250
VRFY250
251
252         
502
504
550
551
553 
EXPN250
252
502
504
550
HELP211
214
502
504
NOOP250
QUIT221

Esta es la lista de códigos de respuesta estándar. También se debe mencionar que algunos servidores SMTP pueden generar otros códigos de tres dígitos. En este caso, el cliente SMTP tendrá que interpretar el primer dígito que debe estar en un rango de 2 a 5 inclusive. Esto denota la esencia de la respuesta (exitosa o no).

Ejemplo de una sesión SMTP

Ahora, veamos el ejemplo de un flujo típico de una sesión SMTP. Veremos dos escenarios: una transacción exitosa y una transacción abortada.

Transacción exitosa con verificación

Servidor: 220 server.net Servicio de Transferencia de email Simple Listo

Cliente: EHLO client.org

S: 250-server.net saluda a client.org

S: 250-DSN

S: 250-VRFY

S: 250 HELP

C: VRFY Maverick

S: 250 John Maverick <j.maverick@server.net>

C: MAIL FROM:"usuario1@client.org"

S: 250 OK

C: RCPT TO:"j.maverick@server.net"

S: 250 OK

C: RCPT TO:"s.smith@server.net"

S: 550 No existe tal usuario aquí

C: DATA

S: 354 Inicia la entrada de email; termina con <CRLF>.<CRLF>

C: Fecha: Mie, 30 Jul 2019 06:04:34

C: De: usuario1@client.org

C: Título: Prueba email

C: Para: j.maverick@server.net, s.smith@server.net

C: Hola John y Samantha 

C: .

S: 250 OK

C: QUIT

S: 221 server.net Servicio cerrando canal de transmisión

En este ejemplo, el cliente recibió el código 550 que indicaba que uno de los destinatarios no está disponible. Sin embargo, la transacción no fue abortada como en el ejemplo a continuación.

Transacción abortada

Server: 220 server.net Servicio de Transferencia de email Simple Listo

Cliente: EHLO client.org

S: 250-server.net saluda a client.org

S: 250-DSN

S: 250 HELP

C: MAIL FROM:"usuario1@client.org"

S: 250 OK

C: RCPT TO:"s.smith@server.net"

S: 550 No existe tal usuario aquí

C: RSET

S: 250 OK

C: QUIT

S: 221 server.net Servicio cerrando canal de transmisión

Beneficios de usar un entorno seguro de pruebas SMTP

Una vez que un email ha llegado al servidor SMTP del remitente, aún está al principio de su viaje. Antes de llegar al buzón del destinatario, el email tiene que llegar al servidor SMTP del destinatario, que lo reenvía al servidor IMAP/POP3. Y cada servidor implementa autenticación antes de permitir que el email entre. Para asegurarse de que sus emails cumplen con los requisitos técnicos para un proceso de autenticación rápido, siempre es una buena idea probar y depurarlos en un entorno seguro como el Email Sandbox de Mailtrap.

Usando Email Sandbox, puede analizar datos en bruto, encabezados y otra información técnica sobre sus emails. Además, le permite inspeccionar y validar HTML/CSS, además de obtener informes de spam rápidos que le ayudan a entender qué necesita ser mejorado.

Para obtener más información sobre Email Sandbox, consulte nuestra Guía de Inicio.

Salir de la versión móvil