Hispanopedia WikiEsta 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.
Salvo que se indique lo contrario, todos los códigos de estado descritos aquí forman 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 para 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 lo utilizan los sistemas automatizados (por ejemplo, los clientes de correo electrónico) para determinar el siguiente estado; el texto ("Parte de texto") está destinado al 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 intermedia positiva): El comando ha sido aceptado, pero la acción solicitada se encuentra en suspenso, a la espera de recibir más información.
- 4yz (Respuesta de finalización negativa transitoria): El comando no fue aceptado y la acción solicitada no se llevó a cabo. Sin embargo, el 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 se realizó. 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 encajan en ninguna categoría funcional y comandos no implementados o superfluos.
- x1z (Información): Estas son respuestas a solicitudes de información.
- x2z (Conexiones): Estas son respuestas que hacen referencia al canal de transmisión.
- x3z : No especificado.
- x4z : No especificado.
- 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 presentes en SMTP desde sus inicios, con el RFC 821 en 1982, pero se extendieron de forma bastante extensa y desordenada, de tal manera que en 2003 el RFC 3463 señaló con cierto fastidio que: " SMTP sufre algunas secuelas históricas, sobre todo el desafortunado daño al mecanismo de extensión del código de respuesta debido a un uso incontrolado " .
RFC 3463 define una serie separada de códigos de estado mejorados del sistema de correo que pretende estar mejor estructurada, y que consta de tres campos numéricos separados por ".", como sigue:
clase "." tema "." detalle clase = "2" / "4" / "5" sujeto = de 1 a 3 dígitos detalle = de 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 su abandono o retraso.
- 5.XXX.XXX Fallo permanente: Es poco probable que se resuelva reenviando el mensaje en su formato 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 sujetos se definen de la siguiente manera:
- X.0.XXX Otro estado 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 la red y el enrutamiento X.4.XXX
- Estado del protocolo de entrega de correo X.5.XXX
- X.6.XXX Estado del contenido o del contenido multimedia del mensaje
- Estado de seguridad o política X.7.XXX
El significado del campo "detalle" depende de la clase y del tema, y se enumeran en RFC 3463 y RFC 5248 .
Un servidor capaz de responder con un código de estado mejorado DEBE anteponer (empezar) 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 Bye" (después del comando QUIT) DEBE enviarse como "221 2.0.0 Bye" 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 (aparte del código de estado ampliado de 3 campos) puede variar.
— 2yz Finalización positiva
- 211 Estado del sistema o respuesta de ayuda del sistema
- 214 Mensaje de ayuda (Respuesta al comando HELP)
- 220 <dominio> Servicio listo
- 221 <dominio> Servicio cerrando canal de transmisión
- 221 2.0.0 Adiós [ 1 ]
- 235 2.7.0 Autenticación exitosa [ 3 ]
- 240 SALIR
- 250 Solicitud de acción de correo correcta, completada
- 251 Usuario no local; se reenviará
- 252 No se puede verificar al usuario, pero se intentará entregar el mensaje de todos modos.
— 3yz Intermedio positivo
- 334 (Desafío del servidor: la parte de texto contiene el desafío codificado en Base64) [ 3 ]
- 354 Iniciar entrada de correo
— 4yz Finalización negativa transitoria
"Error transitorio" significa que la condición de error es temporal y que la acción puede solicitarse nuevamente. El remitente debe regresar al inicio de la secuencia de comandos (si la hay).
Es necesario que los dos sitios (los agentes SMTP del receptor y del remitente) acuerden el significado exacto de "transitorio". Cada respuesta en esta categoría puede tener un valor temporal diferente, pero el cliente SMTP DEBERÍA 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 apagarse).
- 432 4.7.12 Se necesita una transición de contraseña [ 3 ]
- 450 No se realizó la acción solicitada para el correo: el buzón no está disponible (por ejemplo, el buzón está ocupado o bloqueado temporalmente por motivos de política).
- 451 Acción solicitada abortada: error local en el procesamiento
- 451 4.4.1 Servidor IMAP no disponible [ 4 ]
- 452 Acción solicitada no realizada: almacenamiento insuficiente del sistema
- 454 4.7.0 Fallo de autenticación temporal [ 3 ]
- 455 El servidor no puede procesar los parámetros.
— 5yz Finalización negativa permanente
El cliente SMTP NO DEBE repetir la solicitud exacta (en la misma secuencia). Incluso algunos errores "permanentes" pueden corregirse, por lo que el usuario podría querer indicarle al cliente SMTP que reinicie la secuencia de comandos mediante una acción directa en algún momento posterior.
- 500 Error de sintaxis, comando no reconocido (Esto puede incluir errores como una línea de comandos demasiado larga).
- 500 5.5.6 La línea de intercambio de autenticación es demasiado larga [ 3 ]
- 501 Error de sintaxis en los 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 especifica que el cliente no inicia el intercambio de autenticación) [ 3 ]
- Comando 502 no implementado
- 503 Secuencia de comandos incorrecta
- 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 Se necesita cifrado [ 6 ]
- 530 5.7.0 Autenticación requerida [ 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 Cifrado requerido para el mecanismo de autenticación solicitado [ 3 ]
- 550 Acción solicitada no realizada: buzón no disponible (por ejemplo, buzón no encontrado, sin acceso o comando rechazado por motivos de política).
- 551 Usuario no local; por favor intente <forward-path>
- 552 La acción de correo solicitada fue abortada: 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" envía un mensaje al servidor "S":
S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.com S: 250 smtp.example.com, me alegra conocerte. C: CORREO ELECTRÓNICO DE: <bob@example.com> S: 250 Ok C: RCPT PARA:<alice@example.com> S: 250 Ok C: RCPT PARA:<theboss@example.com> S: 250 Ok C: DATOS S: 354 Finalizar datos con <CR><LF>.<CR><LF> C: De: "Bob Example" <bob@example.com> C: Para: Alice Example <alice@example.com> C: Cc: theboss@example.com C: Fecha: martes 15 de enero de 2008 16:02:43 -0500 C: Asunto: Mensaje de prueba DO: 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: Bob C: . S: 250 Ok: en cola como 12345 C: SALIR S: 221 Adiós {El servidor cierra la conexión}
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 la RFC 2034 :
S: 220 dbc.mtview.ca.us Servicio SMTP listo C: EHLO ymir.claremont.edu S: 250-dbc.mtview.ca.us dice hola S: 250 ENHANCEDSTATUSCODES C: CORREO ELECTRÓNICO DE: <ned@ymir.example.edu> S: 250 2.1.0 Originador <ned@ymir.example.edu> ok C: RCPT TO:<mrose@dbc.mtview.example.us> S: 250 2.1.5 Destinatario <mrose@dbc.mtview.example.us> ok C: RCPT TO:<nosuchuser@dbc.mtview.example.us> S: 550 5.1.1 El buzón "nosuchuser" no existe. C: RCPT TO:<remoteuser@example.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 reenviador C: DATOS S: 354 Enviar mensaje, que termina en CRLF.CRLF. ... C: . S: 250 2.6.0 Mensaje aceptado C: SALIR S: 221 2.0.0 Adiós {El servidor cierra la conexión}
Referencias
- Listas relacionadas con Internet