Visor de Correo EML

Descripción general

Un archivo .eml es un mensaje guardado en el formato en el que viajó: encabezados, una línea en blanco y después el cuerpo. Los clientes de correo ocultan casi todo eso, y está bien hasta que necesitas saber qué contenía realmente el mensaje: un encabezado que tu cliente no muestra, un asunto que llegó como galimatías, o la estructura de un mensaje que se renderiza mal.

Este visor parte el archivo en la frontera de los encabezados, los despliega, descodifica las palabras codificadas MIME en el juego de caracteres que declaran y te muestra tanto los campos clave como el cuerpo en bruto.

Cómo se usa

1. Guarda el mensaje como .eml, o copia su código fuente en bruto. En Thunderbird, arrastra el mensaje al escritorio; en Apple Mail, Visualización → Mensaje → Fuente sin formato; en Outlook, Guardar como → Formato de mensaje de Outlook y luego exporta, o usa Archivo → Guardar como → Texto.
2. Pega el contenido. Primero los encabezados, después una línea en blanco y después el cuerpo: el formato entero es eso.
3. Lee los campos del resumen y luego recorre el cuerpo en bruto buscando la estructura.

Palabras codificadas: por qué los asuntos llegan rotos

Por especificación, los encabezados solo pueden contener ASCII. El texto no ASCII viaja como palabra codificada: =?charset?encoding?data?=, donde la codificación es B para base64 o Q para una variante de quoted-printable.

El juego de caracteres que va en el medio es lo importante, y es justo donde fallan la mayoría de las herramientas. Los asuntos en japonés se siguen enviando de forma habitual como ISO-2022-JP, una codificación por secuencias de escape anterior a Unicode que sigue siendo el valor por omisión en varios clientes de correo. El correo de Europa occidental todavía usa ISO-8859-1 y windows-1252. Un descodificador que da por hecho UTF-8 convierte todo eso en galimatías, y el resultado parece un archivo corrupto más que un error de descodificación.

Este visor lee el juego de caracteres declarado y descodifica en consecuencia, así que =?ISO-2022-JP?B?…?= se convierte en japonés legible y =?windows-1252?Q?it=92s?= se convierte en it's con el apóstrofo tipográfico correcto. Si el juego de caracteres es desconocido o está mal escrito, se recurre a UTF-8 en lugar de fallar.

Plegado de encabezados

Los encabezados largos se reparten en varias líneas, y las líneas de continuación empiezan por un espacio en blanco. Un encabezado Received, o una lista To con veinte direcciones, ocupará muchas líneas en el archivo, y ese salto no significa nada: es una regla de transporte, no parte del valor.

Los encabezados se despliegan antes de analizarlos, de modo que un valor plegado se lee como una sola cadena. Vale la pena tenerlo presente cuando lees el texto en bruto por tu cuenta: un grep sobre el valor de un encabezado se perderá todo lo que haya quedado partido.

Qué muestra el cuerpo

El cuerpo se muestra exactamente como aparece en el archivo, y es deliberado.

La mayoría de los mensajes reales son multipart/alternative (una versión en texto plano y una versión en HTML del mismo contenido) o multipart/mixed (contenido más adjuntos). Cada parte tiene su propio Content-Type, su propio juego de caracteres y su propio Content-Transfer-Encoding, y las partes van separadas por una cadena de frontera declarada en los encabezados de nivel superior.

Mostrar una sola parte descodificada como si fuera «el mensaje» esconde esa estructura, y la estructura suele ser precisamente lo que venías a ver: qué parte está renderizando un cliente, si la alternativa en texto plano coincide con el HTML, si un adjunto está donde esperas. Por eso el cuerpo en bruto se queda en bruto.

Eso implica que los cuerpos en quoted-printable muestran =3D donde hay un =, y los saltos de línea blandos como un = al final de la línea, y que las partes en base64 se ven como base64. Si necesitas descodificar una de ellas, copia esa parte y pásala por descodificar Base64 o por decodificar URL / porcentaje.

Encabezados que tu cliente no te muestra

El resumen lista los siete campos que normalmente quieres. El texto en bruto que pegaste contiene el resto, y varios de ellos responden preguntas que los clientes tapan.

• Return-Path es el remitente del sobre: adónde van los rebotes. Lo pone el servidor emisor y con mucha frecuencia es distinto del encabezado From:, que es la dirección que ve una persona. Cuando SPF pasa pero DMARC falla, ese desajuste suele ser el motivo.
• List-Unsubscribe y List-Unsubscribe-Post son lo que hace aparecer el botón de baja en un clic en Gmail. El correo masivo que no los lleva se marca como spam con más frecuencia.
• Auto-Submitted marca el correo generado por una máquina. Si falta en un mensaje automático, disparará respuestas de ausencia y bucles de correo.
• In-Reply-To y References son la forma en que los clientes construyen un hilo. Una respuesta que aparece como conversación nueva ha perdido uno de los dos.
• Content-Language y Accept-Language explican por qué un remitente multiidioma eligió la versión que eligió.
• Los encabezados X-* son lo que haya añadido la infraestructura de envío. Puntuaciones de spam, identificadores de campaña y nombres de colas internas aparecen aquí, y son la vía más rápida para identificar qué sistema envió realmente un mensaje.

Ejemplos

• Un asunto que llega como galimatías. Pega el mensaje aquí. Si el asunto se lee bien, el remitente está haciendo las cosas bien y es el cliente receptor el que maltrata el juego de caracteres.
• «El mensaje se ve distinto en Outlook». Mira la estructura de fronteras. Un multipart/alternative cuyas dos partes no coinciden explica la mayoría de estos avisos.
• Un encabezado que falta. Los clientes muestran un subconjunto elegido. List-Unsubscribe, Auto-Submitted, X-Failed-Recipients y similares están en el archivo aunque nada los enseñe.
• Confirmar qué enviaste de verdad. Guarda un mensaje de tu propia carpeta de enviados y vuelve a leerlo. Las sorpresas de codificación se ven mucho mejor en la forma en bruto.

Notas

La separación entre encabezados y cuerpo es la primera línea en blanco, tal como manda el formato. Un archivo sin ninguna línea en blanco se trata como si fuera solo encabezados, que es lo que quieres cuando alguien pega únicamente el bloque de encabezados.

Aquí nada valida el mensaje. Un .eml con un Date mal formado, sin Message-ID o con una frontera que nunca aparece en el cuerpo se mostrará tal cual, porque la idea es ver qué contiene el archivo y no qué debería haber contenido.

Para el camino de entrega, los retardos de cada salto y los veredictos de SPF, DKIM y DMARC, usa el analizador de encabezados de correo. Lee los mismos encabezados con otra pregunta en la cabeza.