← RFC Reference

RFC 6522: Tipo de Medio Multipart/Report (Actualizado)

Por Qué Existe

El correo electrónico genera muchos tipos de reportes automatizados: notificaciones de rechazo (RFC 3464), quejas de spam (RFC 5965), reportes de fallos de autenticación (RFC 6591) y reportes de fallos de TLS (RFC 8460). Todos estos necesitan un formato de contenedor común que pueda llevar tanto un resumen legible por humanos como un reporte analizable por máquinas.

multipart/report es ese contenedor. Fue definido originalmente en RFC 3462, que a su vez actualizó RFC 1892. RFC 6522 es la versión actual, alineando la especificación con los procedimientos modernos de registro MIME y aclarando ambigüedades de los borradores anteriores.

Los cambios clave de RFC 3462 a 6522:

• Actualización del registro de tipo MIME para seguir el formato de plantilla IANA actual
• Aclaración de que el parámetro report-type es requerido, no opcional
• Restricción del lenguaje de especificación para eliminar ambigüedades sobre el orden de partes
• Alineación con el marco MIME actualizado en RFC 6838

Cómo Funciona

Un mensaje multipart/report es un mensaje MIME multiparte con un parámetro report-type requerido que identifica el tipo de reporte dentro. Contiene dos o tres partes MIME en un orden específico:

1. Parte legible por humanos (text/plain o text/html) — un resumen para humanos que abren el mensaje en un cliente de correo.
2. Reporte analizable por máquinas — los datos estructurados. El tipo de contenido depende de report-type:
   • delivery-status → message/delivery-status (RFC 3464)
   • feedback-report → message/feedback-report (RFC 5965)
   • tlsrpt → application/tlsrpt+json (RFC 8460)
3. Mensaje original (opcional) — message/rfc822 (mensaje completo) o text/rfc822-headers (solo encabezados) del mensaje que desencadenó el reporte.

Ejemplo de Estructura: Rechazo DSN

From: mailer-daemon@mail.example.org
To: sender@example.com
Subject: Delivery Status Notification (Failure)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY-001"

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

Your message to user@example.org could not be delivered.
The mailbox does not exist.

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

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue, 10 Mar 2026 14:22:00 -0500

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 Mailbox not found

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

From: sender@example.com
To: user@example.org
Subject: Invoice #1234
Message-ID: <inv-1234@example.com>

--REPORT-BOUNDARY-001--

Ejemplo de Estructura: Queja ARF

Content-Type: multipart/report; report-type=feedback-report;
    boundary="ARF-BOUNDARY-001"

--ARF-BOUNDARY-001
Content-Type: text/plain

This is a spam complaint for a message from 203.0.113.10.

--ARF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: FBL/1.0
Version: 1
Source-IP: 203.0.113.10

--ARF-BOUNDARY-001
Content-Type: message/rfc822

[original message]

--ARF-BOUNDARY-001--

Detalles Técnicos Clave

El Parámetro report-type

El parámetro report-type en el encabezado Content-Type es requerido e indica a los analizadores qué tipo de datos analizable por máquinas esperar en la segunda parte MIME:

Reglas de Orden de Partes

• La primera parte siempre debe ser legible por humanos (text/plain o similar).
• La segunda parte debe ser el reporte analizable por máquinas con el tipo de contenido coincidiendo con report-type.
• La tercera parte opcional contiene el mensaje original o sus encabezados. Debe usar message/rfc822, text/rfc822-headers o message/global (para mensajes internacionalizados).

Internacionalización

RFC 6522 añade soporte para message/global y message/global-headers como alternativas para la tercera parte, acomodando direcciones de correo electrónico internacionalizadas y encabezados según RFC 6531/6532.

Errores Comunes

• Omitir el parámetro report-type. Sin report-type, los analizadores no pueden determinar qué contiene la segunda parte MIME. RFC 6522 hace este parámetro obligatorio; siempre inclúyalo.
• Orden de partes incorrecto. Algunas implementaciones ponen la parte analizable por máquinas primero. La parte legible por humanos debe ir primero para que los clientes de correo que no entienden el tipo de reporte aún muestren algo útil.
• Analizar solo por Content-Type. No intente detectar el tipo de reporte escaneando el Content-Type de la segunda parte. Use el parámetro report-type en el Content-Type de multipart/report exterior — para eso existe.
• Tratar multipart/report como multipart/mixed. Aunque estructuralmente similares, multipart/report tiene un orden de partes y semántica estrictos. Un analizador MIME genérico puede mostrarlo, pero un procesador de reportes debe respetar la estructura definida.
• Confundir RFC 3462 y RFC 6522. Ambas definen el mismo tipo de contenido. RFC 6522 obsoleta 3462. Si ve referencias a RFC 3462 en código existente, el comportamiento es equivalente — pero cite 6522 en implementaciones nuevas.

Impacto en Entregabilidad

• Fundación de todos los reportes de correo electrónico. Cada DSN, queja ARF, reporte agregado DMARC y reporte de fallo TLS usan multipart/report. Si su analizador no puede manejar este contenedor, no puede procesar ningún comentario de correo electrónico automatizado.
• El procesamiento de rechazos depende del análisis correcto. Su procesador de rechazos debe primero reconocer multipart/report, luego verificar report-type=delivery-status, luego extraer la parte message/delivery-status. Equivocarse en cualquier paso significa rechazos perdidos e higiene de lista degradada.
• Procesamiento de bucle de quejas. Los reportes de bucle de comentarios de proveedores de buzones usan report-type=feedback-report. Analizar el contenedor correctamente es el primer paso para extraer datos de quejas y suprimir destinatarios.
• Reportes TLS. SMTP TLS Reporting entrega cargas JSON dentro de multipart/report con report-type=tlsrpt. Estos reportes revelan fallos de negociación TLS que silenciosamente impiden que su correo se entregue de forma segura.

Related RFCs