Códigos de status principales (SMTP)

La forma en que los servidores MTA se comunican entre sí en cada estado de la transferencia del correo es a través de códigos numéricos de 3 dígitos, cada uno con un significado específico que permite a los sistemas tomar las decisiones apropiadas. Cualquier sistema podría determinar su siguiente acción después de examinar el primer dígito; si el sistema quiere una aproximación más certera puede examinar el segundo dígito y para información más granular se puede revisar el tercer dígito.
La definición de estos códigos se encuentra en el RFC 2821 bajo la sección 4.2.1:
4.2.1.  Severidades del Código de Respuesta y Teoría
[…]
Existen cuatro valores para el primer dígito de un código de respuesta:

   2yz  Respuesta de Terminación Positiva
La acción solicitada se ha completado satisfactoriamente. Se puede
comenzar una nueva solicitud.

   3yz  Respuesta Intermedia Positiva
El comando ha sido aceptado, pero la acción solicitada está
suspendida, esperando la recepción de información adicional. El
SMTP Client debe enviar otro comando especificando esta
información. Esta respuesta es utilizada en grupos de secuencias
de comandos (por ejemplo, en el comando DATA).

   4yz  Respuesta de Terminación Negativa Transitoria
El comando no fue aceptado, y la acción solicitada no se ejecutó.
sin embargo, la condición del error es temporal, y la acción se
puede solicitar nuevamente. El SMTP Client debería regresar al
principio de la secuencia de comando (de haber alguna). Es difícil
asignar un significado al término “transitorio” cuando ambos
SMTP Client y Server deben estar de acuerdo en la interpretación.

Cada respuesta en esta categoría puede tener un valor de tiempo
diferente, pero el SMTP Client DEBERIA volver a intentar la
entrega. Como regla general para determinar si una respuesta
cae en el ámbito de una categoría 4yz ó 5yz es que las respuestas
4yz corresponden a acciones que pueden ser completadas
satisfactoriamente si se repiten sin ningún cambio en la forma
de mandar sus comandos ó en las propiedades del remitente /
destinatario (esto es, el comando se repite de forma idéntica y
y el SMTP Server no modifica la implementación de la recepción
del correo).

   5yz  Respuesta de Terminación Negativa Permanente
El comando no fue aceptado y la acción solicitada no se
Ejecutó. El SMTP Client NO DEBERIA repetir exactamente la
misma solicitud (en la misma secuencia).
[…]
El segundo dígito codifica las respuestas en categorías específicas:

   x0z  Sintaxis: Estas respuestas se refieren a errores de sintaxis,
comandos corrector sintácticamente que no entran en ninguna
categoría funcional y comandos superfluos o no implementados.

   x1z  Información: Estas son respuestas  a solicitudes de
información, como estatus o ayuda.

   x2z  Conexiones: Estas son respuestas que hacen referencia al
canal de transmisión.

   x3z  Sin especificar.

   x4z  Sin especificar.

   x5z  Sistema de Correo: Estas respuestas indican el estatus del
sistema de correo receptor, la transferencia solicitada ó
cualquier otra acción del sistema de correo.

El tercer dígito brinda un grado más fino en el significado de
Cada categoría especificada por el segundo dígito. La lista de
respuestas ilustra esto. Cada texto en la respuesta es más una
recomendación que una obligación, y muchos pueden incluso cambiar
de acuerdo al comando con el que están asociados. Por otro lado,
los códigos de respuesta deben seguir las especificaciones en
esta sección de forma estricta. Las implementaciones del sistema
receptor no deben inventar nuevos códigos para situaciones
ligeramente diferentes a las descritas aquí, más bien deben
adaptar los códigos ya definidos.

El RFC permite que los códigos de error muestren texto para la interpretación humana inclusive en más de una línea cuando el texto así lo requiera siempre y cuando se siga la siguiente sintaxis:
Se requiere que cada línea, excepto la última, comience con el código de respuesta  seguido de un guión “-“ y seguido por texto. La última línea comenzará con el código de respuesta seguido inmediatamente de un <SP> (espacio), opcionalmente texto y un <CRLF>. Debido a esta definición, en la última línea el servidor siembre DEBERA enviar un <SP> pero el SMTP Client debe estar preparado para recibir o no, una cadena de texto final.
Un ejemplo de esta implementación es el saludo con el comando EHLO:
250-hub.rskala.com Hello [192.168.0.89]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XRDST

Todas estas líneas deben considerarse como un sólo mensaje por parte del SMTP Server que las originó. Es decir se trata en todas ellas del mismo reply code 250. En este ejemplo se comprueba la sintaxis. Observe que la última línea no contiene el carácter “-“. Por lo tanto todas las líneas corresponden a una sola respuesta.

La siguiente tabla muestra los códigos de error en orden numérico del RFC 2821 tal y como aparecen en el estándar:

Código    Descripción  
211    System status, or system help reply
214    Help message (Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user)
220    <domain> Service ready
221    <domain> Service closing transmission channel
250    Requested mail action okay, completed
251    User not local; will forward to <forward-path>
252    Cannot VRFY user, but will accept message and attempt delivery
354    Start mail input; end with <CRLF>.<CRLF>
421    <domain> Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down)
450    Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons)
451    Requested action aborted: local error in processing
452    Requested action not taken: insufficient system storage
455    Server unable to accommodate parameters
500    Syntax error, command unrecognized (This may include errors such as command line too long)
501    Syntax error in parameters or arguments
502    Command not implemented
503    Bad sequence of commands
504    Command parameter not implemented
550    Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)
551    User not local; please try <forward-path>
552    Requested mail action aborted: exceeded storage allocation
553    Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect)
554    Transaction failed (Or, in the case of a connection-opening response, “No SMTP service here”)
555    MAIL FROM/RCPT TO parameters not recognized or not implemented

Para obtener información sobre el formato e interpretación de los códigos de status principales en SMTP te recomendamos leer nuestro artículo Códigos de Status principales (SMTP).

Para mayor información sobre la forma de transmitir e interpretar una conversación SMTP, te recomendamos nuestra publicación Fundamentos de Correo Electrónico.

Recuerda que puedes seguirnos en nuestra cuenta de Twitter: @redinskala donde podrás encontrar más información y tips de seguridad.

One thought on “Códigos de status principales (SMTP)

  1. Pingback: Códigos de status extendidos (SMTP) | RedinSkala

Comments are closed.