Analizador de importación EML/MIME
Pega el contenido sin procesar de un mensaje .eml (RFC 822 / MIME) o selecciona un archivo .eml para ver qué estructuras pueden comportarse de forma distinta o fallar entre clientes e importadores, como Outlook, la importación de Gmail, Apple Mail, Thunderbird y herramientas IMAP genéricas.
El análisis se realiza localmente en tu navegador. El archivo nunca se carga al servidor.
Cómo usar esta herramienta
- Pega el contenido .eml o selecciona un archivo .eml. El análisis se realiza en el navegador y el contenido no se envía.
- Selecciona «Comprobar compatibilidad de importación».
- Revisa cada elemento señalado, por qué reduce la portabilidad y qué clientes o importadores pueden discrepar.
- Usa las reescrituras ofrecidas cuando estén disponibles: normalizar finales de línea a CRLF y codificar encabezados según RFC 2047 son cambios mecánicos seguros. Los demás problemas se explican, pues no se puede inferir una corrección segura.
Supuestos
- Reconoce ocho casos concretos: límites multipart ausentes o mal formados, falta de MIME-Version en mensajes con estructura MIME, discrepancia entre Content-Transfer-Encoding y el cuerpo real, valores de encabezado no ASCII sin codificar, líneas que superan el límite de 998 octetos de RFC 5322, finales LF sin CR, encabezados críticos duplicados y cadenas de límite débiles que podrían coincidir con el contenido.
- Es un analizador RFC 822/MIME con conocimiento de líneas, creado para esta herramienta; reconoce el plegado de encabezados y la estructura de límites multipart necesarios para estas comprobaciones, no más.
- Se comprueba si están duplicados Content-Type, From, To, Subject, MIME-Version, Content-Transfer-Encoding, Message-ID y Date.
Fuentes y datos de referencia
Metodología
El texto sin procesar se interpreta como encabezados, desplegando el plegado RFC 822, y como un árbol de partes MIME. Se usan los parámetros boundary de Content-Type de cada parte para localizar delimitadores; después se comprueban requisitos documentados de RFC 5322/2045-2049/2047 y diferencias conocidas de tolerancia entre clientes e importadores. Solo se reescriben transformaciones seguras y deterministas: normalizar finales de línea a CRLF y codificar en RFC 2047 un valor de encabezado no ASCII. Los demás casos se señalan y explican, sin inventar límites ni elegir entre encabezados duplicados.
Ejemplo resuelto
Content-Type multipart sin parámetro boundary
Datos de entrada: Content-Type: multipart/mixed (sin boundary="...")
Resultado: Un analizador MIME estricto necesita boundary para localizar las partes. Se señala como error porque impide analizar la estructura; no se ofrece arreglo, ya que no se puede inventar el valor correcto.
Finales de línea LF sin CR en todo el archivo
Datos de entrada: Encabezados y cuerpo separados por «\n» en vez de «\r\n»
Resultado: RFC 5322 requiere finales CRLF. Algunos analizadores estrictos interpretan mal o rechazan LF sin CR, aunque muchos clientes modernos lo normalizan. Se señala como información y se ofrece normalizar a CRLF.
Un encabezado Subject con caracteres no ASCII sin codificar
Datos de entrada: Subject: Notas de la reunión del café
Resultado: Los mensajes RFC 822/5322 tradicionales usan encabezados ASCII de 7 bits. RFC 6532 permite encabezados UTF-8 directos cuando la ruta receptora admite SMTPUTF8. Las palabras codificadas RFC 2047 siguen siendo la opción más compatible con sistemas antiguos. Se señala como aviso de compatibilidad y se ofrece una conversión determinista y reversible a RFC 2047.
Orientación práctica
- Incluye un parámetro boundary en cada Content-Type multipart y asegúrate de que el cuerpo use «--boundary» y cierre con «--boundary--».
- Incluye «MIME-Version: 1.0» en mensajes que utilicen funciones MIME; evita ambigüedades aunque algunos clientes lo infieran.
- Usa una cadena boundary larga y poco predecible para reducir el riesgo de que coincida con el contenido real.
- Para una amplia compatibilidad con sistemas de correo antiguos que solo admiten ASCII, codifica el texto no ASCII del encabezado según RFC 2047. Los encabezados UTF-8 directos son válidos cuando la ruta receptora admite RFC 6532 y SMTPUTF8.
Errores comunes
- Dar por hecho que un .eml con finales LF funcionará en todas partes porque se abre en un cliente moderno: algunos analizadores estrictos requieren CRLF.
- Tratar Content-Transfer-Encoding como decorativo: una parte declarada como base64 que no contiene base64 válido puede fallar al decodificarse o mostrarse como datos ilegibles.
Preguntas frecuentes
¿Por qué la falta de boundary es un error y la falta de MIME-Version solo un aviso?
Sin boundary, un analizador estricto no puede localizar las partes del mensaje y falla directamente. La falta de MIME-Version infringe RFC 2045, pero muchos clientes tolerantes infieren MIME a partir de otros encabezados, así que el efecto práctico puede ser menor.
¿Por qué la herramienta codifica encabezados no ASCII, pero no corrige un boundary ausente?
Codificar un valor de encabezado con RFC 2047 es una transformación reversible y determinista de los datos existentes. Inventar un boundary o decidir cuál de dos encabezados duplicados conservar exige conocer una intención que la herramienta no puede inferir.
¿La herramienta decodifica adjuntos o muestra su contenido?
No. Inspecciona encabezados y marcadores estructurales —límites, declaraciones de codificación y longitudes de línea—. No decodifica ni muestra el contenido de los adjuntos, salvo un fragmento breve necesario para explicar un problema concreto, como el primer carácter no válido de un bloque base64 mal formado.
¿Por qué Outlook no abre o importa este archivo EML?
Este comprobador busca problemas estructurales específicos, como límites MIME multipart ausentes o mal formados y discrepancias de transferencia de contenido. No prueba Outlook ni diagnostica todos los problemas de importación; pasar estas comprobaciones no descarta causas ajenas a la estructura analizada.
Última revisión:
Es un analizador RFC 822/MIME acotado, no una biblioteca completa: reconoce los ocho casos indicados y no analiza otros problemas, como casos límite de juegos de caracteres más allá de UTF-8, firmas S/MIME, partes de calendario/iCal o estructuras multipart/related profundamente anidadas. La longitud de línea aproxima octetos mediante bytes UTF-8, exacto para la gran mayoría de los mensajes reales.
Esta herramienta ofrece una estimación orientativa basada en los supuestos indicados arriba.
Las preferencias de tema y de herramientas, junto con las listas de herramientas guardadas y recientes, se almacenan solo en este navegador.