← RFC Reference

RFC 3462: Tipo de contenido Multipart/Report

Por Qué Existe

Cuando el marco DSN (Notificación de Estado de Entrega) fue creado a mediados de los años 90, los autores necesitaban un contenedor MIME que pudiera llevar contenido legible por humanos y legible por máquinas en el mismo mensaje. Regular multipart/mixed funcionaría estructuralmente, pero no proporciona señal semántica de que el mensaje es un informe automatizado con un formato interno específico.

multipart/report resuelve esto por:

• Señalizar a los clientes de correo que el mensaje es un informe automatizado, permitiendo tratamiento especial de UI (muchos clientes muestran rechazos de forma diferente al correo regular)
• Incluir un parámetro report-type para que los analizadores sepan qué formato legible por máquinas esperar dentro
• Definir un orden estricto de partes: legible por humanos primero, legible por máquinas segundo, mensaje original tercero

RFC 3462 fue la segunda revisión de esta especificación (después de RFC 1892). Fue obsoleta posteriormente por RFC 6522, que endurecció el lenguaje y actualizó el registro IANA. El formato real del cable no cambió — los mensajes que se conforman a RFC 3462 también se conforman a RFC 6522.

Cómo Funciona

El tipo de contenido multipart/report funciona como cualquier MIME multipart, con restricciones añadidas:

Declaración Content-Type

Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY"

El parámetro report-type le dice al destinatario qué tipo de informe es. El parámetro boundary separa las partes MIME, como con cualquier mensaje multipart.

Estructura de Tres Partes

--REPORT-BOUNDARY
Content-Type: text/plain

; Parte 1: Resumen legible por humanos
La entrega a user@example.org falló permanentemente.
El buzón del destinatario no existe.

--REPORT-BOUNDARY
Content-Type: message/delivery-status

; Parte 2: Informe legible por máquinas
Reporting-MTA: dns; mx.example.com

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1

--REPORT-BOUNDARY
Content-Type: text/rfc822-headers

; Parte 3: Encabezados del mensaje original (opcional)
From: sender@example.com
To: user@example.org
Subject: Hello
Message-ID: <msg-001@example.com>

--REPORT-BOUNDARY--

Detalles Técnicos Clave

Tipos de Informe Definidos a lo Largo del Tiempo

Cuando RFC 3462 fue publicado, solo delivery-status existía. RFC posteriores añadieron más tipos de informe que todos usan el mismo contenedor multipart/report:

Partes Mínimas Requeridas

RFC 3462 requiere al menos dos partes: el resumen legible por humanos y el informe legible por máquinas. La tercera parte (mensaje original) es opcional pero fuertemente recomendada para DSN, ya que permite al remitente identificar qué mensaje fue rechazado.

Relación con RFC 6522

RFC 6522 obsoleta este documento. Los cambios son editoriales, no comportamentales:

• El parámetro report-type está explícitamente marcado como requerido (3462 era ambiguo)
• La plantilla de registro IANA fue actualizada a estándares actuales
• Se añadió soporte para tipos de mensaje internacionalizados (message/global)

Si tu código ya maneja RFC 3462 correctamente, también maneja RFC 6522. El formato del cable es sin cambios.

Errores Comunes

• Tratar la parte legible por humanos como autoritativa. La primera parte es solo para visualización. Los sistemas automatizados deben analizar la segunda parte (legible por máquinas). El texto legible por humanos puede no coincidir con los datos estructurados.
• Asumir solo tres partes. Aunque la mayoría de informes tienen exactamente tres partes, la especificación permite dos (sin mensaje original). Tu analizador no debe fallar cuando la tercera parte está ausente.
• Ignorar multipart/report completamente. Algunos procesadores de rechazo intentan analizar todos los mensajes de rechazo como texto libre. Esto funciona mal. Siempre verifica multipart/report primero y usa los datos estructurados cuando estén disponibles.
• No verificar el report-type. Un multipart/report con report-type=feedback-report es una queja de spam, no un rechazo. Tratarlo como un rechazo (y eliminar la dirección de tu lista) es incorrecto — la dirección es válida, el destinatario simplemente no quiere tu correo.
• Generar informes sin la tercera parte. Aunque técnicamente válido, omitir los encabezados del mensaje original hace mucho más difícil para el remitente identificar qué mensaje desencadenó el informe. Siempre incluye al menos los encabezados.

Impacto de Entregabilidad

• Todos los flujos de retroalimentación de correo automatizado pasan por este formato. Ya sea un rechazo, una queja de spam, una confirmación de lectura o un informe TLS, el contenedor externo es multipart/report. Entender este formato es requisito previo para procesar cualquiera de ellos.
• La clasificación correcta de rechazo comienza aquí. Al verificar primero report-type, tu sistema puede enrutar mensajes delivery-status a tu procesador de rechazo y mensajes feedback-report a tu controlador de quejas — dos flujos de trabajo fundamentalmente diferentes.
• Visualización en cliente de correo. Muchos clientes de correo reconocen multipart/report y lo renderizan especialmente (p.ej., mostrando un banner "entrega fallida"). Generar informes bien formados mejora la experiencia del usuario cuando tu servidor envía rechazos.
• Correlación de Message-ID. La tercera parte (mensaje original o encabezados) es cómo haces coincidir un rechazo con el mensaje que lo causó. Sin ella, estás adivinando basándote solo en la dirección del destinatario, lo cual es poco fiable con reenvío y alias.

Related RFCs