Estructura MIME de un correo electrónico: multipart/alternative, la parte de texto plano y las codificaciones

Qué es

Un correo electrónico consta de un bloque de cabeceras seguido de un cuerpo; MIME permite que el cuerpo sea un árbol de partes, cada una con su propio Content-Type. Un mensaje con versiones en texto y en HTML usa multipart/alternative. RFC 2046 exige que las partes se coloquen en orden creciente de preferencia, con el formato preferido al final, de modo que text/plain va primero y text/html al final; los clientes muestran la última parte que sepan renderizar. Las imágenes incrustadas van en un contenedor multipart/related que envuelve la parte HTML; los adjuntos van en un multipart/mixed exterior. Los cuerpos con bytes no ASCII declaran un Content-Transfer-Encoding: quoted-printable para texto mayoritariamente ASCII (las líneas codificadas se limitan a 76 caracteres, con saltos suaves) o base64 para datos binarios. Los campos de cabecera como Subject y los nombres visibles no pueden contener UTF-8 sin codificar en el correo clásico; se envuelven en encoded-words de RFC 2047 (=?utf-8?q?...?=, de 75 caracteres como máximo cada una).

Por qué importa

Un correo sin parte de texto, con una parte de texto que dice "view this in an HTML client" o con un asunto cuyas vocales con diéresis llegan como signos de interrogación, parece spam tanto a los filtros como a las personas. La mayoría de los errores de plantillas se originan en esta capa (escape, codificación y longitud de línea), no en el contenido del mensaje.

Cómo aplicarlo

• Genera la parte de texto plano a partir de los mismos datos que el HTML en lugar de eliminar etiquetas: los encabezados como líneas, los enlaces como label: URL y las tablas como listas. Mantén ambas plantillas en un mismo lugar, de modo que cambiar una implique cambiar la otra.
• Construye los mensajes con la biblioteca MIME de la plataforma (por ejemplo, el paquete email de Python); nunca concatenes los límites (boundaries) a mano.
• Escapa cada variable insertada en la parte HTML con las mismas reglas que para las páginas web, y mantén la parte de texto libre de entidades HTML.
• Deja que la biblioteca elija quoted-printable para el texto y base64 para los adjuntos; mantén cortas las líneas de origen, porque el formato de mensaje (RFC 5322) limita las líneas a 998 caracteres y recomienda 78.
• Pasa los asuntos y nombres visibles con caracteres no ASCII por encoded-words; prueba con un nombre que contenga diéresis y un emoji.
• Usa URL HTTPS absolutas y CSS en línea; los clientes de correo ignoran o bloquean las hojas de estilo externas y los scripts.

Trampas

Una parte de texto que se escribe una vez y se olvida cuando cambia el HTML. Partes alternativas en el orden equivocado, de modo que los clientes que prefieren texto muestran la parte incorrecta. Un charset declarado como UTF-8 cuando los bytes son Latin-1. Imágenes en multipart/related sin referencias a Content-ID, que llegan como adjuntos. Redirectores de seguimiento en la parte de texto, donde la URL en bruto es lo que ve el lector.