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:
- handshake – establecimiento de una conexión TCP
- email transfer – manipulaciones con el email
- termination – cierre de la conexión TCP
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:DATA354 (código de respuesta del servidor)Fecha: Mie, 30 Jul 2019 06:04:34De: prueba@cliente.netTítulo: Cómo funciona SMTPPara: usuario@destinatario.netTexto 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 usuario2250 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-email250-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.com250 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 LASTPara: usuario@destinatario.netDe: prueba@cliente.netTítulo: Cómo funciona SMTP250 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.com250 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:
XADR– libera el estado del canal con el que coincide una dirección (cómo se enruta una dirección internamente)XCIR– libera el estado de la instalación de verificación de circuitosXSTA– libera el estado del número de mensajes en colas de canalXGEN– libera el estado de si una configuración compilada y un conjunto de caracteres están en uso
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:
SENDSOMLSAMLRELAYTLSTURN
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:
- Primero (2 a 5) – indica si la solicitud es aceptada, incompleta o rechazada
- Segundo (0 a 5) – indica el tipo de error ocurrido (sintaxis, información, conexiones, sistema de email o no especificado (dos opciones))
- Tercero (0 a 5) – proporciona una descripción más fina (junto con una explicación textual)
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ódigo | Qué significa |
| 101 | Error de conexión con el servidor (nombre de servidor incorrecto o puerto de conexión) |
| 211 | Estado del sistema (respuesta a HELP) |
| 214 | Mensaje de ayuda (respuesta a HELP) |
| 220 | El servidor está listo (respuesta al intento del cliente de establecer una conexión TCP) |
| 221 | El servidor cierra el canal de transmisión |
| 235 | Autenticación exitosa (respuesta a AUTH) |
| 250 | El comando solicitado está completado. Por regla general, el código es seguido por OK |
| 251 | El usuario no es local, pero el servidor reenviará el mensaje a <forward-path> |
| 252 | El servidor no puede verificar al usuario (respuesta a VRFY). El mensaje será aceptado e intentado para la entrega |
| 334 | Respuesta al comando AUTH cuando el mecanismo de seguridad solicitado es aceptado |
| 354 | El 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 ( “.”) |
| 421 | El servidor no está disponible porque cierra el canal de transmisión |
| 422 | El buzón del destinatario ha excedido su límite de almacenamiento |
| 431 | Sobrecarga de archivos (demasiados mensajes enviados a un dominio particular) |
| 441 | No hay respuesta del servidor del destinatario |
| 442 | Conexión interrumpida |
| 446 | Se ha producido un bucle interno |
| 450 | Buzón no disponible (ocupado o temporalmente bloqueado). Acción solicitada abortada |
| 451 | El servidor abortó el comando debido a un error local |
| 452 | El servidor abortó el comando debido a insuficiente almacenamiento del sistema |
| 454 | TLS no disponible debido a una razón temporal (respuesta a STARTTLS) |
| 455 | Los parámetros no pueden ser acomodados |
| 471 | Error del servidor de email debido al filtro de spam local |
| 500 | Error de sintaxis (también una línea de comando puede ser demasiado larga). El servidor no puede reconocer el comando |
| 501 | Error de sintaxis en parámetros o argumentos |
| 502 | El servidor no ha implementado el comando |
| 503 | Secuencia de comandos inapropiada |
| 504 | El servidor no ha implementado un parámetro de comando |
| 510 | Dirección de email no válida |
| 512 | Un error de DNS (revisa la dirección de sus destinatarios) |
| 523 | El tamaño total de su email supera los límites del servidor destinatario |
| 530 | Problema de autenticación que generalmente requiere que se ejecute el comando STARTTLS |
| 535 | Autenticación fallida |
| 538 | Se requiere cifrado para un mecanismo de autenticación solicitado |
| 541 | Mensaje rechazado por filtro de spam |
| 550 | El 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 |
| 551 | Usuario no local. Se especificará la <forward-path> |
| 552 | El servidor abortó el comando porque el buzón está lleno |
| 553 | Dirección de email incorrecta sintácticamente |
| 554 | La 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 |
| 555 | Pará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.
| Comando | Respuesta positiva | Respuesta negativa |
| Handshake SMTP (establecimiento de conexión) | 220 | 554 |
STARTTLS | 220 | 454 |
EHLO o HELO | 250 | 502 (respuesta a EHLO para servidores antiguos) 504 550 |
AUTH | 235 334 | 530 535 538 |
MAIL FROM | 250 | 451 452 455 503 550 552 553 555 |
RCPT TO | 250 251 | 450 451 452 455 503 550 551 552 553 555 |
DATA | 250 354 (respuesta intermedia) | 450 451 452 503 550 (rechazo por razones de política) 552 554 |
RSET | 250 | – |
VRFY | 250 251 252 | 502 504 550 551 553 |
EXPN | 250 252 | 502 504 550 |
HELP | 211 214 | 502 504 |
NOOP | 250 | – |
QUIT | 221 | – |
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.