Comprobador de nombres de adjuntos MIME
Pega el contenido .eml (RFC 822 / MIME) o selecciona un archivo .eml para ver qué nombres de adjuntos declarados podrían no guardarse, alterarse sin aviso o variar entre clientes cuando se guarden en Windows, macOS o Linux.
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 navegador lo procesa localmente; no se carga.
- Selecciona «Comprobar nombres de adjuntos».
- Revisa cada nombre señalado y los sistemas o clientes que pueden verse afectados.
- Usa las reescrituras ofrecidas cuando estén disponibles: sustituir caracteres, añadir un sufijo a nombres de dispositivos reservados, quitar puntos/espacios finales y codificar RFC 2231 son cambios mecánicos. Las discrepancias de encabezados y heurísticas se explican, no se corrigen adivinando.
Supuestos
- Reconoce ocho problemas concretos: caracteres reservados de Windows, nombres de dispositivos reservados de Windows, puntos o espacios finales, ausencia de alternativa de nombre simple para el formato extendido RFC 2231, nombres superiores al límite común de 255 bytes, desacuerdo entre nombres Content-Disposition/Content-Type, patrón de doble extensión y nombres con bytes no ASCII sin codificación RFC 2231/2047.
- Reutiliza el analizador .eml/MIME acotado de este micrositio para localizar los nombres declarados de cada parte; no vuelve a implementar el análisis MIME.
- Si filename de Content-Disposition y name de Content-Type coinciden, se considera que Content-Disposition es el nombre que normalmente usaría el cliente para guardar. Si discrepan, se muestran y señalan ambos.
- Un mensaje sin adjuntos —sin Content-Disposition: attachment ni parámetros filename/name— produce cero problemas; no es un problema que esta herramienta deba señalar.
Fuentes y datos de referencia
Metodología
El texto se interpreta como árbol de partes MIME y se inspeccionan los parámetros filename/name de Content-Disposition y Content-Type. Cada nombre se contrasta con reglas documentadas de sistemas de archivos Windows/macOS/Linux y requisitos de encabezados RFC 2183/2231/6266. Solo se reescribe cuando el cambio es mecánico e inequívoco: sustituir caracteres reservados, añadir sufijo a un nombre de dispositivo reservado, quitar puntos/espacios finales, añadir una alternativa simple cuando el nombre RFC 2231 se decodifica como ASCII y codificar un nombre no ASCII con RFC 2231. Las discrepancias y el patrón de doble extensión se explican sin decidir qué nombre era el previsto ni renombrar basándose en una heurística.
Ejemplo resuelto
Nombre de adjunto PDF con dos puntos y signo de interrogación
Datos de entrada: Content-Disposition: attachment; filename="Informe Q3: borrador?.pdf"
Resultado: Windows (NTFS/exFAT) no permite < > : " / \ | ? *, aunque Linux/macOS sí. Se señala como error y se ofrece sustituir cada carácter reservado por «_».
Un adjunto .txt llamado exactamente con.txt
Datos de entrada: Content-Disposition: attachment; filename="con.txt"
Resultado: Windows reserva CON, PRN, AUX, NUL, COM1-COM9 y LPT1-LPT9, con independencia de la extensión. Se señala como error y se ofrece añadir un guion bajo al nombre reservado: «con_.txt».
Un ejecutable oculto tras una extensión que parece de documento
Datos de entrada: Content-Disposition: attachment; filename="factura.pdf.exe"
Resultado: Una extensión aparentemente segura seguida de una extensión ejecutable es un patrón conocido de ocultación de malware. Se señala como aviso heurístico, no como certeza, y no se renombra automáticamente.
Orientación práctica
- Evita caracteres reservados de Windows (< > : " / \ | ? *) y nombres de dispositivos reservados (CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9) en nombres de adjuntos que controles.
- Para caracteres no ASCII, usa la forma extendida RFC 2231 («filename*=UTF-8''percent-encoded») y añade una alternativa ASCII simple «filename=» para clientes antiguos o sencillos.
- No confíes solo en Content-Type para identificar un adjunto de forma segura: una extensión aparentemente segura seguida de una ejecutable es una técnica documentada de ocultación.
- Mantén los nombres de adjuntos muy por debajo de 255 bytes UTF-8; algunas pasarelas y sistemas antiguos truncan antes.
Errores comunes
- Suponer que un nombre que se ve bien en el cliente emisor se guardará correctamente: los caracteres o nombres reservados fallan cuando el sistema del destinatario crea el archivo.
- Tratar «filename*=» y «filename=» como equivalentes: un cliente que no entiende RFC 2231 puede mostrar un nombre vacío o ilegible si no hay alternativa simple.
Preguntas frecuentes
¿Por qué un carácter reservado es un error y una discrepancia de encabezados solo un aviso?
Un carácter o nombre de dispositivo reservado no se puede guardar en Windows. Una discrepancia entre Content-Disposition y Content-Type es ambigua: distintos clientes pueden elegir valores distintos, así que existe un riesgo, pero no un fallo garantizado.
¿Por qué la herramienta no cambia el nombre señalado por la comprobación de doble extensión?
Es una heurística que puede dar falsos positivos en nombres legítimos, como «resumen.pdf.bak». Renombrar un adjunto real basándose en una conjetura es una decisión que corresponde al destinatario.
¿La herramienta decodifica o muestra el contenido del adjunto?
No. Solo inspecciona Content-Disposition y Content-Type para leer el nombre declarado. No decodifica ni muestra el cuerpo real del adjunto.
¿Por qué el nombre de un adjunto de correo aparece ilegible o cambia al guardarlo?
Los clientes gestionan de forma distinta los parámetros de nombre MIME, especialmente nombres RFC 2231, alternativas simples ausentes, texto no ASCII sin codificar o declaraciones contradictorias en Content-Disposition y Content-Type. Esta comprobación analiza esos problemas declarados; no inspecciona el contenido del adjunto ni predice el nombre exacto que guardará cada cliente.
Última revisión:
Comprueba las declaraciones de nombres, no el contenido de los adjuntos, y reutiliza un analizador .eml/MIME acotado, no una biblioteca completa. No analiza estructuras MIME muy inusuales más allá de la anidación multipart habitual. La longitud aproxima el límite común de 255 bytes con el conteo UTF-8; algunos sistemas y pasarelas truncan antes, pero no se señala un límite distinto para cada sistema.
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.