Resumen

  • RFC 3462 exigía que multipart/report fuese el contenedor MIME exterior y ordenaba dos piezas obligatorias: una explicación destinada a personas y un registro tipado para máquinas. Una tercera pieza podía devolver el mensaje original o una fracción útil.
  • El formato facilitaba reconocer un informe, no creerlo. report-type anunciaba el subtipo de la segunda parte, pero un informe falsificado podía conservar una sintaxis perfecta y aun así inducir acciones automáticas dañinas.

El mismo incidente tenía dos lectores

Cuando un mensaje no llegaba, su autor necesitaba una explicación inteligible. Un sistema de correo necesitaba campos con significados estables para clasificar, correlacionar o actuar. El texto libre servía al primero y frustraba al segundo; una tabla de códigos hacía lo contrario. La solución histórica no fue sacrificar una representación, sino colocarlas juntas y asignarles papeles diferentes.

El RFC 3462, publicado en enero de 2003, fijó esa arquitectura. El texto plano, el registro del RFC Editor, la ficha de Datatracker, su historial, las referencias, las citas posteriores y la búsqueda de erratas forman el expediente público. Sustituyó al RFC 1892 y convirtió una convención para avisos en una familia general de informes MIME.

multipart/report debía ocupar el nivel más externo del contenido MIME. Además del boundary propio de los multipartes del RFC 2046, llevaba report-type. El valor de ese parámetro indicaba el subtipo MIME de la segunda parte. Un agente podía mirar la cabecera exterior, reconocer que tenía un informe y anticipar qué registro automático iba a encontrar.

La posición también era información

La primera parte era obligatoria y legible por una persona. Podía usar cualquier tipo MIME definido en una norma, el idioma y juego de caracteres adecuados, o incluso multipart/alternative para ofrecer varias versiones. El estándar dejaba aquí espacio editorial porque explicar una incidencia depende del destinatario.

La segunda parte era obligatoria y procesable por máquina. Registraba un acontecimiento de tratamiento del mensaje en un tipo de medios inscrito. Los avisos de estado de entrega del RFC 3464 usaban message/delivery-status. Sin embargo, el contenedor no definía la negociación SMTP de un aviso, que pertenecía al RFC 3461, ni los códigos mejorados del RFC 3463. RFC 3462 respondía «dónde está el registro y de qué clase es», no «qué entrega ocurrió».

La tercera parte era opcional: el mensaje original o una porción suficiente para diagnosticar y correlacionar. Si el remitente no había pedido un nivel de retorno, la recomendación era devolver el mensaje completo. Ese contexto podía consumir ancho de banda y revelar contenido. Ante una ruta incierta para ocho bits o binario, el generador podía recodificar de forma MIME legal en siete bits o devolver solo text/rfc822-headers. Esas cabeceras, dentro de la tradición del RFC 822, no eran el mensaje entero y no debían presentarse como message/rfc822.

La anatomía imponía una disciplina sencilla: la primera parte explicaba, la segunda permitía calcular y la tercera ayudaba a comprobar el contexto. Una narración convincente no se convertía por ello en un dato estructurado. Un dato estructurado no era una copia de la comunicación. Una lista de cabeceras no equivalía al objeto original.

Parsear no era autenticar

La posición exterior ayudaba a detectar el informe sin recorrer todo su interior. El registro de tipos de medios de IANA mantenía el vocabulario común. La misma familia sostuvo después notificaciones de disposición del RFC 3798, revisadas por el RFC 8098, y estados de entrega internacionalizados del RFC 6533.

La conveniencia abría un riesgo. La norma advertía que multipart/report no autenticaba el contenido. Un informe negativo falso podía hacer que una lista de correo o un directorio eliminase una dirección válida, convirtiendo una rutina administrativa en denegación de servicio. Un positivo falso podía crear la seguridad equivocada de que algo había llegado. Firmar la estructura completa podía aportar protección, pero el mecanismo quedaba fuera del alcance del RFC.

La sintaxis solo demuestra que ciertos bytes encajan en una gramática. No establece quién generó el objeto, si el evento sucedió ni si una persona leyó la explicación. Cuando una automatización borra esas diferencias, concede poder operativo a una forma reconocible.

La posterior reflexión de Heng Lu sobre las capas de realidad permite distinguir documento, interpretación del parser, hecho del sistema y decisión administrativa. Su defensa del código que realmente se ejecuta lleva a revisar el árbol MIME, el generador, la verificación y el consumidor automático. Son lentes editoriales posteriores, no pruebas de una intención privada de los autores.

RFC 3462 no hizo verdadero un informe. Hizo visible qué parte hablaba a una persona, cuál afirmaba algo para una máquina y qué material se devolvía para contrastar. Compartir sobre no significaba compartir autoridad.

Fuentes