Esta es una lista de códigos de estado de respuesta del Protocolo simple de transferencia de correo (SMTP). Los códigos de estado son emitidos por un servidor en respuesta a la solicitud de un cliente realizada al servidor.
A menos que se indique lo contrario, todos los códigos de estado descritos aquí son parte del estándar SMTP actual, RFC 5321 . Las frases de mensaje que se muestran son típicas, pero se puede proporcionar cualquier alternativa legible por humanos.
Código de estado básico
Una respuesta SMTP de "Código de estado básico" consta de un número de tres dígitos (transmitido como tres caracteres numéricos) seguido de un texto. El número es para que lo utilicen los autómatas (por ejemplo, clientes de correo electrónico) para determinar qué estado ingresar a continuación; el texto ("Parte de texto") es para el usuario humano.
El primer dígito indica si la respuesta es buena, mala o incompleta:
- 2yz (Respuesta de finalización positiva): la acción solicitada se ha completado con éxito.
- 3yz (Respuesta positiva intermedia): el comando ha sido aceptado, pero la acción solicitada se mantiene en suspenso, a la espera de recibir más información.
- 4yz (Respuesta de finalización negativa transitoria): el comando no se aceptó y la acción solicitada no se produjo. Sin embargo, la condición de error es temporal y la acción puede solicitarse nuevamente.
- 5yz (respuesta de finalización negativa permanente): el comando no fue aceptado y la acción solicitada no ocurrió. El cliente SMTP NO DEBE repetir la solicitud exacta (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 sintácticamente correctos que no se ajustan a ninguna categoría funcional y comandos no implementados o superfluos.
- x1z (Información): Son respuestas a solicitudes de información.
- x2z (Conexiones): Son respuestas que se refieren al canal de transmisión.
- x3z : Sin especificar.
- x4z : Sin especificar.
- x5z (sistema de correo): estas respuestas indican el estado del sistema de correo del receptor.
Código de estado mejorado
Los códigos de estado básicos han estado en SMTP desde el principio, con RFC 821 en 1982, pero se ampliaron de manera bastante extensa y al azar, de modo que en 2003 RFC 3463 señaló con bastante mal humor que: " SMTP sufre algunas cicatrices de la historia, más notablemente el desafortunado daño al mecanismo de extensión del código de respuesta por uso incontrolado " .
RFC 3463 define una serie separada de códigos de estado del sistema de correo mejorado que está destinado a estar mejor estructurado, que consta de tres campos numéricos separados por ".", De la siguiente manera:
clase "." sujeto "." detalle clase = "2" / "4" / "5" asunto = 1 a 3 dígitos detalle = 1 a 3 dígitos
Las clases se definen de la siguiente manera:
- 2.XXX.XXX Éxito: Informe de una acción de entrega positiva.
- 4.XXX.XXX Fallo transitorio persistente: el mensaje enviado es válido, pero la persistencia de algunas condiciones temporales ha provocado el abandono o la demora.
- 5.XXX.XXX Fallo permanente: No es probable que se resuelva reenviando el mensaje en su forma actual.
En general, el identificador de clase DEBE coincidir con el primer dígito del código de estado básico al que se aplica. [1]
Los temas se definen de la siguiente manera:
- X.0.XXX Otro o estado indefinido
- Estado de direccionamiento X.1.XXX
- Estado del buzón X.2.XXX
- Estado del sistema de correo X.3.XXX
- Estado de enrutamiento y red X.4.XXX
- Estado del protocolo de entrega de correo X.5.XXX
- Contenido del mensaje X.6.XXX o estado de los medios
- Seguridad o estado de la política X.7.XXX
El significado del campo "detalle" depende de la clase y el tema, y se enumeran en RFC 3463 y RFC 5248 .
Un servidor capaz de responder con un código de estado mejorado DEBE anteponer (anteponer) la parte de texto de las respuestas del servidor SMTP con el código de estado mejorado seguido de uno o más espacios. Por ejemplo, la respuesta "221 Adiós" (después del comando SALIR) DEBE enviarse como "221 2.0.0 Adiós" en su lugar. [1]
La Autoridad de Números Asignados de Internet (IANA) mantiene el registro oficial de estos códigos de estado mejorados. [2]
Códigos de estado comunes
Esta sección enumera algunos de los códigos de estado SMTP más comunes. Esta lista no es exhaustiva y el mensaje de texto real (fuera del Código de estado mejorado de 3 campos) puede ser diferente.
- Finalización positiva 2yz
- 211 Estado del sistema o respuesta de ayuda del sistema
- 214 Mensaje de ayuda (una respuesta al comando HELP)
- 220
listo para el servicio
- 220
- 221
Canal de transmisión de cierre del servicio
- 221
- 221 2.0.0 Adiós [1]
- 235 2.7.0 Autenticación exitosa [3]
- 250 Acción de correo solicitada correcta, completada
- 251 Usuario no local; reenviará
- 252 No se puede verificar al usuario, pero intentará entregar el mensaje de todos modos
- Intermedio positivo 3yz
- 334 (Desafío del servidor: la parte de texto contiene el desafío codificado en Base64) [3]
- 354 Iniciar entrada de correo
- Finalización negativa transitoria 4yz
"Transitorio Negativo" significa que la condición de error es temporal y la acción se puede solicitar nuevamente. El remitente debe volver al principio de la secuencia de comandos (si corresponde).
El significado exacto de "transitorio" debe acordarse entre los dos sitios diferentes (agentes SMTP receptores y emisores) deben estar de acuerdo en la interpretación. Cada respuesta en esta categoría puede tener un valor de tiempo diferente, pero el cliente SMTP DEBE intentarlo de nuevo.
- 421 Servicio no disponible, cerrando el canal de transmisión (Esto puede ser una respuesta a cualquier comando si el servicio sabe que debe cerrarse)
- 432 4.7.12 Se necesita una transición de contraseña [3]
- 450 No se ha realizado la acción de correo solicitada: buzón no disponible (p. Ej., Buzón ocupado o bloqueado temporalmente por motivos de política)
- 451 Acción solicitada cancelada: error local en el procesamiento
- 451 4.4.1 Servidor IMAP no disponible [4]
- 452 Acción solicitada no realizada: almacenamiento del sistema insuficiente
- 454 4.7.0 Fallo de autenticación temporal [3]
- 455 El servidor no puede acomodar los parámetros
- 5yz finalización negativa permanente
El cliente SMTP NO DEBE repetir la solicitud exacta (en la misma secuencia). Incluso se pueden corregir algunas condiciones de error "permanentes", por lo que el usuario humano puede querer indicar al cliente SMTP que reinicie la secuencia de comandos mediante acción directa en algún momento en el futuro.
- 500 Error de sintaxis, comando no reconocido (esto puede incluir errores como línea de comando demasiado larga)
- 500 5.5.6 La línea de intercambio de autenticación es demasiado larga [3]
- 501 Error de sintaxis en parámetros o argumentos
- 501 5.5.2 No se pueden decodificar las respuestas del cliente en Base64 [3]
- 501 5.7.0 Intercambio de autenticación iniciado por el cliente (solo cuando el mecanismo SASL especificó que el cliente no inicia el intercambio de autenticación) [3]
- 502 Comando no implementado
- 503 Mala secuencia de comandos
- 504 El parámetro de comando no está implementado
- 504 5.5.4 Tipo de autenticación no reconocido [3]
- 521 El servidor no acepta correo [5]
- 523 Encriptación necesaria [6]
- 530 5.7.0 Se requiere autenticación [3]
- 534 5.7.9 El mecanismo de autenticación es demasiado débil [3]
- 535 5.7.8 Credenciales de autenticación no válidas [3]
- 538 5.7.11 Se requiere cifrado para el mecanismo de autenticación solicitado [3]
- 550 Acción solicitada no realizada: buzón no disponible (p. Ej., Buzón no encontrado, sin acceso o comando rechazado por razones de política)
- 551 Usuario no local; por favor intente
- 551 Usuario no local; por favor intente
- 552 Acción de correo solicitada cancelada: se superó la asignación de almacenamiento
- 553 Acción solicitada no realizada: nombre de buzón no permitido
- 554 La transacción ha fallado (o, en el caso de una respuesta de apertura de conexión, "No hay servicio SMTP aquí")
- 554 5.3.4 Mensaje demasiado grande para el sistema [4]
- 556 El dominio no acepta correo [5]
Ejemplo
A continuación se muestra un ejemplo de conexión SMTP, donde un cliente "C" está enviando al servidor "S":
S: 220 smtp.example.com ESMTP PostfixC: relé HELO.example.comS: 250 smtp.example.com, me alegro de conocerteC: CORREO DESDE:@example.com>S: 250 OkC: RCPT PARA: @example.com>S: 250 OkC: RCPT PARA: @example.com>S: 250 OkC: DATOSS: 354 Finalizar datos con C: De: "Bob Example" . @example.com>C: Para: Alice Ejemplo @example.com>C: Cc: [email protected]C: Fecha: martes, 15 de enero de 2008 16:02:43 -0500C: Asunto: mensaje de pruebaC: C: Hola Alice.C: Este es un mensaje de prueba con 5 campos de encabezado y 4 líneas en el cuerpo del mensaje.C: Tu amigo,C: BobC: .S: 250 Ok: en cola como 12345C: SALIRS: 221 Adiós{El servidor cierra la conexión}
Y a continuación se muestra un ejemplo de una conexión SMTP en la que el servidor SMTP admite el código de estado mejorado, tomado de RFC 2034 :
S: 220 dbc.mtview.ca.us listo para el servicio SMTPC: EHLO ymir.claremont.eduS: 250-dbc.mtview.ca.us dice hola S: 250 CÓDIGOS DE ESTADO MEJORADOSC: CORREO DESDE:@ymir.claremont.edu>S: 250 2.1.0 Originador ok @ymir.claremont.edu>C: RCPT PARA:@dbc.mtview.ca.us>S: 250 2.1.5 Destinatario ok @dbc.mtview.ca.us>C: RCPT PARA:@dbc.mtview.ca.us>S: 550 5.1.1 El buzón "nosuchuser" no existeC: RCPT PARA: @isi.edu>S: 551-5.7.1 Reenvío a hosts remotos deshabilitado S: 551 5.7.1 Seleccione otro host para que actúe como su reenviadorC: DATOSS: 354 Enviar mensaje, terminado en CRLF.CRLF. ...C: .S: 250 2.6.0 Mensaje aceptadoC: SALIRS: 221 2.0.0 Adiós{El servidor cierra la conexión}