Resumen

  • RFC 5248 convirtió los códigos SMTP mejorados en un vocabulario con tablas, referencias, solicitantes y controladores de cambios identificables.
  • Ese orden prueba qué significado está registrado; no prueba que el emisor diagnosticara bien, que el receptor conservara el contexto ni que el mensaje llegara o dejara de llegar.

El mismo número puede cargar demasiada autoridad

Un código de estado entra en un panel como dato técnico y suele salir convertido en veredicto. El sistema de tickets lo llama causa raíz. El programador de reintentos lo trata como futuro cierto. El informe al cliente lo usa como prueba de no entrega. En cada paso, el número conserva su forma pero gana una autoridad que su registro nunca le concedió.

RFC 3463 había creado una estructura extensible para describir estados de correo. Faltaba, sin embargo, un procedimiento explícito que registrara y siguiera nuevas asignaciones. Cuando aparecieron definiciones conflictivas, RFC 5248 respondió con una institución: un registro IANA, una política de incorporación y reglas de modificación. Como BCP 138, también actualizó especificaciones que ya habían ampliado el vocabulario, entre ellas RFC 4468 y RFC 4954.

La solución no pretendía observar servidores. Pretendía evitar que dos comunidades llamaran cosas distintas por el mismo código o inventaran códigos incompatibles sin una referencia pública. Esa diferencia entre coordinación y constatación debe permanecer visible en cualquier modelo de datos de entrega.

Tres tablas, varias responsabilidades

La notación clase.asunto.detalle resume tres decisiones. RFC 5248 las reparte entre una tabla de subcódigos de clase, otra de asunto y una tercera de códigos enumerados. En esta última, asunto y detalle forman la asignación, mientras la clase aparece como comodín. La razón es práctica: una condición puede combinarse con más de una clase cuando la especificación que la define lo permite.

El registro guarda el código, un resumen o texto de muestra, una descripción, la referencia y su condición normativa, quién lo solicitó y quién controla sus cambios. Para las entradas enumeradas añade un código SMTP básico asociado. El conjunto permite seguir la procedencia de un significado y saber quién puede mantenerlo.

“Asociado” no significa “único”. RFC 5248 declara que el código básico de tres dígitos no es exclusivo. La presencia de uno no impide otras combinaciones; la tabla puede indicar Any o Not given. Usar esa columna como validador uno-a-uno produciría falsos positivos precisamente porque borraría la flexibilidad que el registro documenta.

También hay una forma honrada de no saber: X.0.0. Es el único código indefinido y sirve cuando solo se conoce la clase de la respuesta. No autoriza a rellenar la causa, inferir el componente culpable o fabricar precisión a partir de una categoría general.

Registrar es gobernar una propuesta

Las nuevas asignaciones siguen Specification Required. RFC 5248 exige que una especificación no normativa sea accesible y sitúa el objetivo en evitar confusiones y colisiones sin imponer barreras innecesarias. RFC 8126, referencia actual para estas políticas, combina una especificación pública permanente con la revisión de un experto designado que valora claridad, estabilidad y calidad técnica.

El objeto de esa revisión es una definición reutilizable. No es el software que la emitirá. El experto no observa una sesión SMTP de producción, no autentica la identidad del servidor, no inspecciona el buzón de destino y no certifica la lógica de reintento. Por tanto, “código registrado” y “diagnóstico verificado” son hechos de clases diferentes.

Las reglas de cambio preservan esa genealogía. Una asignación normativa suele modificarse actualizando la norma. Una asignación no normativa depende del controlador nombrado. Los cambios ordinarios corrigen descripción o referencia y no deberían reasignar silenciosamente el número o el texto de muestra. La IESG conserva una capacidad excepcional para resolver conflictos.

El contenido inicial del registro demuestra que la procedencia no era uniforme. Incluyó valores de RFC publicados, pero también valores usados por la industria sin especificación disponible. Algunos códigos de seguridad quedaron bajo control de la IESG. La condición “Trust Relationship Required” pasó de un uso anterior de X.7.8 a X.7.14. La autoridad registral puede corregir el mapa. No puede asegurar que todos los emisores desplegaron la corrección, ni interpretar de forma retroactiva cada registro histórico.

La clase orienta; el tiempo decide

RFC 3463 describe la clase 2 como éxito dentro de una notificación de estado de entrega. La clase 4 representa un fallo transitorio persistente para el que un intento futuro puede funcionar. La clase 5 representa un fallo permanente que, por regla general, requiere cambiar el mensaje o el destino.

Estas distinciones son indispensables para la interoperabilidad y, aun así, no predicen el mundo. RFC 5321 ordena al cliente actuar sobre el código de respuesta y no sobre el texto explicativo. Un 4yz invita a intentarlo más tarde cuando corresponda. Un 5yz dice que no se repita sin cambios la petición exacta. La propia norma admite que una condición presentada como permanente puede corregirse después.

La política necesita, además del código, una línea temporal. Debe saber qué mensaje, qué destinatario, qué intento, qué servidor y qué configuración participaron. Debe limitar el número y duración de los reintentos y conservar la respuesta posterior. 4.x.x no reserva un éxito futuro. 5.x.x no congela la realidad para siempre.

RFC 2034 se ocupa de cómo transportar códigos mejorados en respuestas SMTP. RFC 5248 se ocupa de cómo compartir sus significados. La lógica que selecciona el código, el analizador que lo recibe, el almacenamiento que lo conserva y el agente que actúa forman superficies adicionales. Tras una aceptación SMTP todavía queda por establecer qué hizo el siguiente sistema y, en último término, el destino.

Revelar más no siempre informa mejor

La sección de seguridad de RFC 5248 introduce una tensión importante. Los códigos mejorados pueden exponer detalles de la implementación interna. En autenticación, distinguir entre usuario inexistente y contraseña equivocada ofrece a un atacante una señal útil. Por ello, las especificaciones deben explicar cuándo limitar el detalle que devuelve el servidor.

Una respuesta pública genérica puede ser compatible con un diagnóstico interno específico. El equipo de seguridad necesita conservar ambos y registrar la política que los separa. Si obliga a que la superficie pública repita toda la causa interna, crea un oráculo. Si reemplaza el diagnóstico interno por la respuesta reducida, pierde evidencia. La precisión, la divulgación y la verdad son tres decisiones, no una sola.

Separar nombre, afirmación y corroboración

Una escalera de evidencia comienza con la sintaxis: el código se puede analizar. Después viene el registro: la versión observada contiene esa asignación. El siguiente escalón no deja de ser una afirmación de implementación: el servidor dice que ocurrió la condición. Hace falta comprobar la relación con el código básico, conservar comando, respuesta y destinatario, y buscar corroboración en la cola, el sistema receptor o una observación independiente.

Por encima están la acción y el resultado. ¿La política reintentó el mensaje correcto? ¿Hubo otra transferencia? ¿El destino lo aceptó? ¿La aplicación lo depositó o descartó? ¿Una persona lo vio? Cada pregunta necesita un recibo distinto. Ni siquiera una respuesta registrada y correctamente formada las contesta en bloque.

La primacía del código en funcionamiento de Lu Heng no invita a despreciar los registros; obliga a no confundir su capa. El registro hace posible que programas distintos compartan un significado. El código ejecutado muestra cómo lo aplicaron. La evidencia operativa muestra qué transición ocurrió. La gobernanza madura enlaza esas tres realidades sin permitir que la primera suplante a las demás.

Fuentes