RFC 2049: Parte 5 de MIME — Criterios de Conformidad y Ejemplos

Standards Track MIME — Multipurpose Internet Mail Extensions Published March 2026

ELI5: Los RFC 2045–2047 definen las reglas de MIME. RFC 2049 es el examen: especifica exactamente qué debe hacer tu software para ser "compatible con MIME" y proporciona ejemplos desarrollados para verificar tu implementación. Si MIME fuera un código de construcción, esto sería la lista de verificación de inspección.

Por qué existe

La especificación MIME abarca cuatro RFCs técnicos (2045, 2046, 2047 y 2048). Los implementadores necesitan una respuesta clara a: "¿cuál es lo mínimo que mi software debe manejar para ser conforme a MIME?" RFC 2049 proporciona esa respuesta, junto con mensajes de prueba canónicos que los implementadores pueden usar para verificar sus analizadores.

Sin un documento de conformidad, diferentes implementaciones soportarían diferentes subconjuntos de MIME, lo que causaría fallos de interoperabilidad. RFC 2049 establece el mínimo: cada sistema compatible con MIME debe manejar al menos estos tipos de contenido, codificaciones y estructuras.

Cómo funciona

RFC 2049 define dos niveles de conformidad, cada uno con requisitos específicos.

Requisitos del agente de envío

Un agente de envío conforme a MIME (MUA o biblioteca de correo) debe:

Incluir siempre MIME-Version: 1.0 en cada mensaje que utilice características MIME.
Incluir un encabezado Content-Type cuando el cuerpo sea algo distinto a texto ASCII simple.
Usar una Content-Transfer-Encoding válida que garantice que el cuerpo del mensaje pueda atravesar puertas de enlace SMTP de 7 bits (base64 o quoted-printable para contenido no ASCII).
Codificar correctamente los campos de encabezado usando palabras codificadas RFC 2047 cuando aparezcan caracteres no ASCII en encabezados como Subject o nombres para mostrar From.
Generar límites multipart válidos que no aparezcan en ninguna parte del cuerpo incluida.

Requisitos del agente receptor

Un agente receptor conforme a MIME debe:

Reconocer MIME-Version: 1.0 y tratar el mensaje como codificado en MIME.
Analizar encabezados Content-Type y Content-Transfer-Encoding, incluidos todos los parámetros.
Decodificar base64 y quoted-printable de las codificaciones de transferencia de contenido.
Manejar todos los tipos multipart — como mínimo multipart/mixed, multipart/alternative, multipart/digest y multipart/parallel. Los subtipos multipart desconocidos deben tratarse como multipart/mixed.
Manejar message/rfc822 — mostrar el mensaje encapsulado u ofrecer al menos guardarlo.
Manejar tipos de contenido no reconocidos con elegancia — ofrecer guardar la parte del cuerpo como archivo en lugar de fallar o descartar silenciosamente. Los tipos no reconocidos deben tratarse como application/octet-stream.
Decodificar palabras codificadas RFC 2047 en campos de encabezado.
Manejar el parámetro charset en tipos de texto, soportando al menos US-ASCII e ISO-8859-1, e idealmente UTF-8.

Principio de robustez

RFC 2049 refuerza la Ley de Postel para MIME: sé estricto en lo que envías, liberal en lo que aceptas. Un receptor conforme debe hacer un esfuerzo máximo por mostrar incluso mensajes MIME ligeramente malformados en lugar de rechazarlos categóricamente.

Detalles técnicos clave

Ejemplos canónicos

RFC 2049 incluye ejemplos elaborados de mensajes MIME. Aquí está el patrón para un mensaje multipart/alternative bien formado con texto plano e HTML:

MIME-Version: 1.0
From: sender@example.com
To: recipient@example.com
Subject: MIME conformance test
Content-Type: multipart/alternative; boundary="boundary42"

--boundary42
Content-Type: text/plain; charset=us-ascii

This is the plain text version.

--boundary42
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><p>This is the <strong>HTML</strong> version.</p></body></html>

--boundary42--

Manejo de tipos desconocidos

Un requisito de conformidad clave: cuando un agente receptor encuentra un Content-Type que no entiende, debe tratarlo como application/octet-stream y ofrecer guardarlo. Esta regla garantiza compatibilidad hacia adelante: se pueden definir nuevos tipos de medios sin romper clientes existentes.

; Unknown type encountered by a client
Content-Type: application/vnd.custom-format
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="data.custom"

; Conformant client treats this as application/octet-stream
; and offers the user a "Save As" dialog

Subtipos multipart desconocidos

De manera similar, los subtipos multipart desconocidos deben tratarse como multipart/mixed. Esto significa que el cliente muestra cada parte secuencialmente. Por ejemplo, multipart/report (definido más tarde en RFC 3462) seguirá mostrándose correctamente en clientes antiguos que lo traten como mixto.

Soporte de charset mínimo

Las implementaciones conformes deben soportar al menos:

US-ASCII — la línea base
ISO-8859-1 — caracteres de Europa Occidental (Latin-1)

En la práctica, cualquier implementación moderna debe soportar UTF-8. No hacerlo en 2024+ es un incumplimiento de conformidad en espíritu, incluso si la especificación de 1996 no lo exigía.

El límite MIME/no-MIME

Los mensajes sin encabezado MIME-Version: 1.0 se tratan como texto ASCII simple pre-MIME, independientemente de si sucede que contengan encabezados Content-Type. El encabezado MIME-Version es el guardián: sin él, el procesamiento MIME no se activa.

Errores comunes

Fallar con Content-Types desconocidos. La especificación es explícita: trata los tipos desconocidos como application/octet-stream. Las bibliotecas que lanzan excepciones con tipos desconocidos no son conformes y se romperán a medida que se registren nuevos tipos de medios.
Tratar subtipos multipart desconocidos como errores. Deben tratarse como multipart/mixed. Un error común es rechazar u omitir multipart/report, multipart/signed u otros tipos de extensión.
Ignorar charset en tipos text/*. El contenido de texto sin declaración de charset por defecto es US-ASCII. Mostrarlo como UTF-8 puede funcionar para contenido ASCII pero produce salida corrupta para mensajes heredados ISO-8859-1.
Eliminar MIME-Version de mensajes reenviados. Al reenviar o reenviar, el encabezado MIME-Version debe preservarse. Sin él, el cliente receptor puede no procesar la estructura MIME en absoluto.
Decodificación parcial de base64/QP. Ambos decodificadores deben manejar casos especiales: relleno base64, saltos de línea suave QP (=\r\n) y espacios en blanco finales. Los decodificadores incompletos producen salida corrupta para mensajes legítimos.
No ofrecer opción de guardado para partes no renderizables. Un cliente conforme debe permitir al usuario guardar cualquier parte del cuerpo, incluso si no puede mostrarla. Descartar partes silenciosamente viola la especificación y pierde datos.

Impacto en la entregabilidad

La estructura MIME conforme es una línea base de entregabilidad. Los mensajes no conformes —MIME-Version faltante, límites multipart rotos, codificaciones incorrectas— son características distintivas de herramientas de spam. Los filtros de spam usan la conformidad MIME como señal de calidad.
Incluir tanto text/plain como text/html. Los ejemplos de RFC 2049 demuestran multipart/alternative con ambos formatos. Esto no es solo una buena práctica; muchos filtros de spam penalizan mensajes solo en HTML. La parte text/plain debe tener contenido significativo, no solo "Ver este correo en tu navegador".
Una Content-Transfer-Encoding válida previene corrupción. Un mensaje que declara quoted-printable pero contiene datos sin procesar de 8 bits será destrozado por puertas de enlace SMTP de 7 bits. Esto causa fallos de renderización en el destinatario, incluso si el mensaje llega a la bandeja de entrada.
Las declaraciones correctas de charset previenen mojibake. Declarar charset=us-ascii para contenido UTF-8 hace que los caracteres acentuados sean ilegibles. Los destinatarios pueden reportar el mensaje como spam en lugar de intentar decodificarlo.
MIME bien formado mejora el renderizado en clientes. Un mensaje conforme a MIME se renderiza correctamente en Gmail, Outlook, Apple Mail, Thunderbird y clientes móviles. Los mensajes no conformes pueden renderizarse en un cliente pero romperse en otro, causando quejas y desuscripciones.