Resumen

  • RFC 2034 antepone class.subject.detail al texto de casi todas las respuestas SMTP 2xx, 4xx y 5xx. La clase mejorada debe coincidir con la clase del código principal.
  • El servidor envía estos códigos aunque el cliente no use EHLO; no hay solicitud ni exclusión voluntaria. El documento protege este comportamiento como una excepción muy limitada, no como regla general para extensiones silenciosas.
  • La estructura permite clasificar, reintentar y localizar explicaciones. Solo acredita la categoría declarada por un servidor en ese intercambio, no la causa real, la entrega, la lectura ni la legitimidad de una política.

El problema de un texto de error no es que una persona no pueda leerlo. El problema aparece cuando cientos de sistemas deben decidir qué hacer con frases distintas que describen situaciones parecidas. Un 550 ya comunica una negativa permanente en términos generales, pero el operador necesita saber si se trata de una dirección, una política o una restricción de reenvío. Extraer esa diferencia de palabras libres convierte el idioma y el estilo de cada servidor en parte del algoritmo.

RFC 2034, publicada en octubre de 1996, creó una capa intermedia. Conservó el código SMTP de tres dígitos y conservó la explicación humana. Antes de esa explicación añadió un identificador de tres componentes: clase, asunto y detalle. La máquina obtiene una señal más específica; el servidor sigue pudiendo explicar el caso con lenguaje natural.

Una jerarquía que se puede comprobar

La extensión se anuncia como ENHANCEDSTATUSCODES, no acepta parámetros y no añade verbos. Su sintaxis permite clases 2, 4 y 5, seguidas de un asunto y un detalle de uno a tres dígitos cada uno. La primera cifra debe concordar con la respuesta tradicional: 2xx con 2.X.X, 4xx con 4.X.X y 5xx con 5.X.X.

Esa coincidencia evita que dos señales de control contradigan al cliente. El código principal conserva la decisión amplia del estado SMTP; los otros componentes refinan el motivo declarado. Una cola puede separar fallos temporales por capacidad de fallos temporales de configuración, o distinguir rechazos permanentes de dirección y de política, sin depender de palabras en inglés.

También mejora la comunicación humana. La aplicación puede presentar una explicación en español basada en la categoría y conservar el texto remoto como registro. Pero no debe reescribir «el servidor declaró» como «se ha demostrado». La coherencia entre 550 y 5.X.X prueba que la respuesta se clasificó de forma consistente. No prueba que la base remota estuviera correcta ni que la política fuera razonable.

La cobertura no incluye todo SMTP

La obligación comprende las respuestas 2xx, 4xx y 5xx salvo el saludo inicial y las respuestas a HELO o EHLO. Las 3xx quedan fuera. Por eso el ejemplo de la RFC muestra 354 sin código mejorado mientras que aceptación, rechazo y cierre sí lo llevan.

Guardar el contexto es esencial. Si un sistema observa solamente el número y pregunta si apareció un segundo código, convertirá excepciones válidas en alarmas. La evidencia debe incluir el comando que precedió a la respuesta y su posición dentro de la sesión.

Los ejemplos 2.1.0, 2.1.5, 5.1.1, 5.7.1, 2.6.0 y 2.0.0 enseñan la gramática en acción. No establecen una cadena de custodia hasta el destinatario. Aceptar datos durante SMTP es una transición del servidor receptor, no una prueba de que el mensaje se mostró o se leyó.

El servidor actúa sin que el cliente lo pida

El rasgo más inusual es la falta de negociación efectiva. Un servidor compatible adjunta códigos mejorados con EHLO o sin él. El cliente no dispone de una orden para activarlos ni desactivarlos.

La compatibilidad depende de dónde se coloca el cambio. Los clientes antiguos ya tenían que aceptar texto tras el código principal; podían ignorar la estructura adicional como parte de ese texto. Los autores consideraron que la calidad de los errores SMTP era suficientemente pobre como para que todos se beneficiaran de categorías más comprensibles.

El documento no convierte ese razonamiento en una carta blanca. Advierte que es un caso muy especial y que futuras extensiones no pueden cambiar drásticamente la interacción sin anuncio del servidor y habilitación del cliente. Una modificación no solicitada solo resulta defendible aquí porque queda encerrada en una zona sintáctica compatible y no altera la secuencia básica de comandos.

Varias líneas, una sola categoría

Cuando una respuesta ocupa varias líneas, cada línea debe comenzar su texto con el mismo código mejorado. La RFC muestra dos líneas 551 con 5.7.1; las reglas generales de SMTP exigen además que se repita el mismo código principal.

La redundancia mantiene la declaración estable si un registro procesa líneas por separado. También impide que una sola respuesta cambie de categoría a mitad del mensaje. La prosa añade contexto; la señal de control no se mueve.

Sin embargo, el contexto detallado revela información. La sección de seguridad de RFC 2034 reconoce que cada detalle adicional enseña algo sobre el servidor y puede facilitar que se eludan sus protecciones. Una explicación puede filtrar nombres internos, existencia de cuentas, rutas de reenvío o criterios de rechazo.

Por tanto, la consistencia no basta. El operador debe repetir la categoría necesaria y ofrecer una frase útil, pero limitar lo que expone a un interlocutor remoto no autenticado. La posibilidad técnica de transmitir más no crea una obligación de hacerlo.

La declaración sirve para actuar, no para cerrar la investigación

Un 4.X.X puede alimentar una política de reintento. Un 5.X.X puede detenerla. Asunto y detalle pueden asignar el incidente a un equipo y permitir comparar cambios entre versiones. Todo ello responde a un hecho observable: ese servidor emitió esa clasificación.

El salto indebido ocurre cuando la clasificación pasa a llamarse causa. El código no verifica el interior del servidor, no asegura que otro intento reproduzca el resultado y no demuestra que un filtro haya acertado. Un código positivo tampoco prueba entrega final, ubicación en bandeja de entrada, visualización o lectura.

Incluso la transformación posterior puede cambiar la evidencia. El ejemplo de RFC 2034 produce una notificación y señala que el MTA informante omitió códigos mejorados de algunos campos para reducir ruido. La respuesta en vivo, el registro de cola, la notificación y el resumen de interfaz son capas distintas. Cada una requiere procedencia.

RFC 5248 añadió un registro IANA para evitar colisiones semánticas entre códigos. Eso coordina definiciones, no certifica diagnósticos individuales. Un valor registrado puede ser emitido por software defectuoso o asociado a la condición equivocada.

La disciplina operativa consiste en preservar primero el evento: par remoto, hora, comando, código principal, código mejorado, texto completo, estructura multilínea, resultado del analizador y acción local. La forma se puede validar de manera determinista. Para afirmar causa, política legítima o resultado final hacen falta observaciones independientes.

Fuentes