← RFC Reference

RFC 2045: MIME Parte 1 — Formato de Cuerpos de Mensajes de Internet

Por qué existe esto

RFC 5322 (y su predecesor RFC 822) definieron los mensajes de correo electrónico como texto plano US-ASCII con una longitud máxima de línea de 998 caracteres. Eso estaba bien en 1982. No está bien para el correo electrónico moderno, que necesita transportar:

• Texto en juegos de caracteres no ASCII (UTF-8, ISO-8859-*, etc.)
• Contenido HTML con estilos en línea e imágenes
• Archivos adjuntos (PDF, imágenes, archivos)
• Múltiples partes del cuerpo (texto + HTML + adjuntos en un mensaje)

MIME (Multipurpose Internet Mail Extensions) es un conjunto de cinco RFC que extienden el correo electrónico para manejar todo esto manteniendo compatibilidad con la infraestructura ASCII original. RFC 2045 es la Parte 1: define los campos de encabezado y mecanismos de codificación que hacen posible todo lo demás.

Cómo funciona

RFC 2045 introduce tres campos de encabezado críticos y dos esquemas de codificación.

El encabezado MIME-Version

Cada mensaje MIME debe incluir:

MIME-Version: 1.0

Esto señala a los clientes de correo receptores que el mensaje utiliza convenciones MIME. Sin este encabezado, el mensaje se trata como texto plano US-ASCII según RFC 5322. La versión ha sido 1.0 desde 1996 y nunca ha cambiado.

El encabezado Content-Type

Declara el tipo de medio y subtipo del cuerpo, más parámetros opcionales:

Content-Type: type/subtype; parameter=value

Ejemplos:

; Correo de texto plano en UTF-8
Content-Type: text/plain; charset=utf-8

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

; Adjunto PDF
Content-Type: application/pdf; name="invoice.pdf"

; Mensaje multiparte (texto + HTML + adjuntos)
Content-Type: multipart/mixed; boundary="----=_Part_123"

Si no hay Content-Type presente, el predeterminado es text/plain; charset=us-ascii — preservando compatibilidad con mensajes pre-MIME.

El encabezado Content-Transfer-Encoding

SMTP fue diseñado para transportar texto ASCII de 7 bits con líneas no más largas de 998 caracteres. Los datos binarios (imágenes, PDF) y texto de 8 bits (UTF-8) deben codificarse para ajustarse a estas restricciones. RFC 2045 define cinco codificaciones de transferencia:

Codificación Quoted-Printable

Diseñada para texto que es principalmente ASCII con ocasionales caracteres no ASCII. Cada byte no ASCII se codifica como =XX donde XX es el valor hexadecimal. Las líneas más largas que 76 caracteres se envuelven suavemente con = al final.

; Original: "René sent the café menu"
Content-Transfer-Encoding: quoted-printable

Ren=C3=A9 sent the caf=C3=A9 menu

El =C3=A9 es la codificación UTF-8 de é (U+00E9), con cada byte codificado en hexadecimal.

Codificación Base64

Codifica datos binarios arbitrarios en caracteres ASCII (A-Z, a-z, 0-9, +, /). Cada 3 bytes de entrada se convierten en 4 caracteres ASCII. Las líneas se envuelven a 76 caracteres.

Content-Type: image/png; name="logo.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34
AAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAApgAAAKYB
zN+OGwAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBl

Detalles técnicos clave

El encabezado Content-Disposition

Aunque no es parte de RFC 2045 en sí (proviene de RFC 2183), Content-Disposition está estrechamente relacionado y se utiliza universalmente con MIME:

; Mostrar en línea (p. ej., una imagen incrustada)
Content-Disposition: inline

; Ofrecer como adjunto descargable
Content-Disposition: attachment; filename="report.pdf"

Un mensaje MIME completo

Juntándolo todo — un mensaje con cuerpos de texto e HTML, más un adjunto:

MIME-Version: 1.0
From: sender@example.com
To: recipient@example.com
Subject: Invoice attached
Content-Type: multipart/mixed; boundary="----=_outer"

------=_outer
Content-Type: multipart/alternative; boundary="----=_inner"

------=_inner
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Please find your invoice attached.

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

<p>Please find your invoice attached.</p>

------=_inner--
------=_outer
Content-Type: application/pdf; name="invoice.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="invoice.pdf"

JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PCAvVHlwZSAv
Q2F0YWxvZyAvUGFnZXMgMiAwIFIgPj4KZW5kb2JqCg==

------=_outer--

Nota la estructura: multipart/mixed contiene el cuerpo y el adjunto. El cuerpo en sí es multipart/alternative con versiones de texto e HTML. Consulta RFC 2046 para detalles completos sobre tipos multiparte.

Parámetro Charset

El parámetro charset en tipos text/* declara la codificación de caracteres. Para correo electrónico moderno, siempre utiliza utf-8:

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

Los conjuntos de caracteres heredados como iso-8859-1, windows-1252 y shift_jis aún se encuentran pero no deben usarse en mensajes nuevos.

Errores comunes

• Falta de MIME-Version: 1.0. Sin este encabezado, algunos clientes de correo ignoran Content-Type y tratan el cuerpo como texto ASCII plano. Tu correo HTML se mostrará como código fuente sin procesar.
• Content-Transfer-Encoding incorrecto para datos binarios. Enviar un adjunto binario con codificación 7bit lo corromperá — bytes nulos y caracteres de alto bit se alteran. Siempre utiliza base64 para contenido binario.
• Parámetro charset faltante o incorrecto. Omitir charset predetermina us-ascii. Si tu texto contiene caracteres UTF-8, se mostrarán como basura. Siempre declara charset=utf-8.
• Líneas que exceden 998 caracteres. RFC 5322 ordena un límite de línea de 998 caracteres. Base64 envuelve a 76 caracteres. Quoted-printable utiliza saltos de línea suave. El texto 8bit sin procesar también debe respetar este límite, o los servidores intermedios pueden truncar o rechazar el mensaje.
• Usar 8bit sin verificar soporte del servidor. La codificación 8bit requiere que el servidor receptor anuncie 8BITMIME en su respuesta EHLO. Si no lo hace, utiliza quoted-printable o base64 en su lugar.
• Cadena de límite que aparece en contenido del cuerpo. El límite multiparte no debe aparecer en ninguna parte del cuerpo. Utiliza una cadena de límite larga y aleatoria para evitar colisiones.

Impacto en la entregabilidad

• La estructura MIME adecuada es innegociable. MIME malformado dispara filtros de spam. MIME-Version faltante, límites incorrectos o codificaciones incorrectas son todas señales de alerta que buscan los filtros de spam.
• Siempre envía multipart/alternative. Incluye partes text/plain y text/html. Los mensajes solo con HTML son penalizados por muchos filtros de spam. La parte de texto también sirve como alternativa para clientes de texto plano.
• Usa base64 para adjuntos, quoted-printable para texto. Esta es la combinación universalmente compatible. Funciona en cada servidor SMTP y cliente de correo.
• Mantén los tamaños de adjuntos razonables. La codificación base64 añade 33% de sobrecarga. Un archivo de 7.5 MB se convierte en un correo de 10 MB. Muchos servidores rechazan mensajes mayores de 25 MB. Algunos mayores de 10 MB.
• La corrección de charset previene errores de renderización. Declarar charset=utf-8 y codificar realmente en UTF-8 garantiza que tu correo se renderice correctamente en todo el mundo. Las declaraciones de charset desajustadas causan mojibake (texto garbled) y quejas de soporte.

Related RFCs