← RFC Reference

RFC 2046: MIME Parte 2 — Tipos de Medios

Por qué existe

RFC 2045 introdujo Content-Type y codificaciones de transferencia, pero no definió qué tipos de contenido existen ni cómo se comportan. RFC 2046 llena ese vacío al definir:

• Los tipos de medios de nivel superior (texto, imagen, audio, vídeo, aplicación, multlparte, mensaje).
• El mecanismo multiparte que permite que un único correo contenga múltiples partes del cuerpo con un delimitador de límite.
• Subtipos multiparte específicos que controlan cómo los clientes de correo muestran las partes (mezclado, alternativo, resumen, paralelo).

Este es el RFC que hace posible el correo electrónico moderno. Sin él, cada correo sería un bloque único de texto.

Cómo funciona

Los tipos de medios de nivel superior

El mecanismo multiparte

Los tipos multiparte son el corazón de RFC 2046. Un mensaje multiparte contiene un parámetro boundary que delimita cada parte:

Content-Type: multipart/mixed; boundary="----=_boundary_001"

------ preámbulo (ignorado por clientes MIME) ------

------=_boundary_001
Content-Type: text/plain; charset=utf-8

This is the first part.

------=_boundary_001
Content-Type: text/plain; charset=utf-8

This is the second part.

------=_boundary_001--
^^^ nótese los -- finales que marcan el fin

Reglas clave para los límites:

• Cada parte es precedida por -- + la cadena de límite en su propia línea.
• El límite final tiene -- añadido después de él también (p. ej., --boundary--).
• La cadena de límite no debe aparecer en ninguna parte del cuerpo. Usa una cadena larga y aleatoria.
• El contenido antes del primer límite (el preámbulo) y después del límite final (el epílogo) son ignorados por clientes compatibles con MIME.

Subtipos multiparte

El subtipo le dice al cliente de correo cómo mostrar las partes. Aquí es donde radica la sutileza.

multipart/mixed — Partes secuenciales

El tipo multiparte más común. Las partes se muestran en orden. Se utiliza para "cuerpo del mensaje + archivos adjuntos":

Content-Type: multipart/mixed; boundary="----=_mixed"

------=_mixed
Content-Type: text/plain; charset=utf-8

Here's the report you requested.

------=_mixed
Content-Type: application/pdf; name="report.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.pdf"

JVBERi0xLjQKJeLjz9MK...

------=_mixed--

multipart/alternative — El mismo contenido, diferentes formatos

Contiene múltiples versiones del mismo contenido. El cliente de correo elige la mejor que pueda mostrar. Las partes se ordenan de la más simple a la más rica — la última parte es preferida:

Content-Type: multipart/alternative; boundary="----=_alt"

------=_alt
Content-Type: text/plain; charset=utf-8

Welcome to our service!

------=_alt
Content-Type: text/html; charset=utf-8

<h1>Welcome to our service!</h1>
<p>We're glad to have you.</p>

------=_alt--

Así es cómo funciona cada correo HTML bien formado: la alternativa text/plain viene primero, la versión text/html viene última. Un cliente que soporta HTML muestra el HTML; un cliente de texto plano muestra el texto.

multipart/related — Partes vinculadas

Se utiliza cuando las partes se hacen referencia mutuamente. El caso de uso más común es correo HTML con imágenes insertadas. El HTML hace referencia a imágenes por Content-ID (URLs cid:):

Content-Type: multipart/related; boundary="----=_rel"

------=_rel
Content-Type: text/html; charset=utf-8

<p>Check out our logo:</p>
<img src="cid:logo@example.com" alt="Logo" />

------=_rel
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-ID: <logo@example.com>

iVBORw0KGgoAAAANSUhEU...

------=_rel--

multipart/digest — Colección de mensajes

Una variante de mezclado donde el tipo de contenido predeterminado para cada parte es message/rfc822 en lugar de text/plain. Utilizado por resúmenes de listas de correo. Raramente se ve en correo electrónico moderno.

Detalles técnicos clave

Anidar tipos multiparte

El verdadero poder de MIME proviene del anidamiento. Un correo de marketing típico con imágenes insertadas y un archivo adjunto se parece a esto:

; La estructura estándar para correo HTML con imágenes insertadas + archivos adjuntos

Content-Type: multipart/mixed           ← externo: cuerpo + archivos adjuntos
  |
  |-- multipart/alternative              ← cuerpo: texto o HTML
  |     |-- text/plain                    ← alternativa de texto plano
  |     |-- multipart/related             ← HTML + imágenes insertadas
  |           |-- text/html               ← el cuerpo HTML
  |           |-- image/png (cid:logo)    ← imagen insertada
  |
  |-- application/pdf (attachment)       ← archivo adjunto

Este anidamiento de tres niveles es el patrón estándar utilizado por prácticamente todas las bibliotecas de correo y proveedores de servicios de correo electrónico.

El tipo message/rfc822

Encapsula un mensaje de correo electrónico completo como parte del cuerpo. Se utiliza para reenviar mensajes como archivos adjuntos y en notificaciones de rechazo (RFC 3462 multipart/report). El mensaje encapsulado tiene sus propios encabezados (De, Para, Asunto, etc.) y cuerpo.

El respaldo application/octet-stream

Cuando el tipo de contenido de un archivo es desconocido, usa application/octet-stream. Esto le indica al cliente que lo trate como datos binarios genéricos y normalmente activa un mensaje de descarga. Es el equivalente de MIME de "No sé qué es esto; guárdalo y averigúalo tú mismo".

Requisitos de límites

La cadena de límite tiene reglas específicas:

• Máximo 70 caracteres.
• Compuesta de alfanuméricos ASCII más un conjunto limitado de caracteres especiales: '()+_,-./:=? y espacio.
• No debe aparecer en ninguna parte del cuerpo encerrada.
• En la práctica, usa una cadena larga aleatoria como ----=_Part_12345_67890.1234567890.

Errores comunes

• Usar multipart/mixed en lugar de multipart/alternative para texto+HTML. Si pones text/plain y text/html en un contenedor mezclado, el cliente mostrará ambos (u ofrecerá HTML como descarga). Usa alternativo para que el cliente elija el mejor formato.
• Orden de partes incorrecto en multipart/alternative. Formato más simple primero, más rico último. Si pones HTML antes del texto plano, algunos clientes mostrarán la versión de texto plano aunque HTML esté disponible.
• Imágenes insertadas sin multipart/related. Si haces referencia a una URL cid: en HTML pero la imagen está en una parte hermana multipart/mixed en lugar de un contenedor multipart/related, muchos clientes no resolverán la referencia.
• Falta Content-ID con paréntesis angulares. El valor del encabezado Content-ID debe estar envuelto en paréntesis angulares: <image001@example.com>. La referencia cid: en HTML los omite: src="cid:image001@example.com".
• Colisiones de límites. Usar una cadena de límite corta o predecible (como boundary o ---) corre el riesgo de aparecer en el contenido del cuerpo, lo que corromperá la estructura del mensaje. Usa siempre límites aleatorios.
• Olvidar el final --. El límite de cierre debe terminar con -- (p. ej., --boundary--). Si falta esto, los analizadores esperarán más partes y pueden resultar en un mensaje desordenado o incompleto.

Impacto en la entrega

• multipart/alternative correcto es esencial. Los filtros de spam esperan que los correos HTML bien formados incluyan una alternativa text/plain. La falta de ella es una señal de spam. Las partes de texto e HTML deben tener contenido aproximadamente equivalente — una parte de texto de una línea con una parte HTML de 50 KB se ve sospechosa.
• Las imágenes insertadas aumentan la puntuación de spam. El uso intensivo de multipart/related con muchas imágenes insertadas (especialmente cuando el correo es principalmente imágenes con poco texto) activa heurísticas de spam de imágenes. Prefiere imágenes alojadas con URLs https:// sobre referencias cid: para correos de marketing.
• Los tipos de archivos adjuntos importan. Los archivos ejecutables (.exe, .js, .bat) son bloqueados o puestos en cuarentena por casi todos los proveedores de correo. Incluso los archivos .zip que contienen ejecutables serán marcados. Mantente con tipos seguros: PDF, formatos de imagen comunes, documentos de oficina.
• Los mensajes demasiado grandes rebotan. Muchos proveedores rechazan mensajes mayores de 25 MB (algunos mayores de 10 MB). Recuerda que la codificación base64 añade un 33% de sobrecarga. Un archivo adjunto de 20 MB se convierte en un correo de ~27 MB.
• MIME correctamente estructurado señala legitimidad. MIME bien formado con anidamiento correcto, límites válidos y declaraciones Content-Type adecuadas le dice a los filtros de spam que este mensaje fue generado por software de correo legítimo, no por una herramienta de spam manual.

Related RFCs