Visor de archivos mbox

Cómo usar

1. Suelta el archivo .mbox sobre el recuadro. No se sube nada: se lee en esta pestaña, así que una exportación de varios gigabytes solo depende de tu máquina.
2. Lee primero la línea de convención. Dice si el archivo escapa los cuerpos (mboxo/mboxrd) o los delimita con Content-Length (mboxcl), y con qué indicio se ha decidido.
3. Revisa los hallazgos. Los mensajes sin ninguna cabecera legible son líneas "From " sin escapar que han partido un mensaje real en dos, y el recuento de límites que trazaría otra convención te dice lo frágil que es el archivo.
4. Mira los desplazamientos y longitudes de la tabla. Son posiciones en bytes dentro del archivo que soltaste, así que puedes recortar un mensaje con dd o un editor hexadecimal y comprobarlo por tu cuenta.
5. Pulsa el número de una fila para abrir un mensaje: su línea From_, las cabeceras decodificadas y el árbol MIME con la codificación, el nombre y el tamaño decodificado de cada parte.

Preguntas frecuentes

¿Por qué mi archivo contiene más mensajes de los que recibí?

Porque una línea del cuerpo de alguien empezaba por "From " y el programa que escribió el archivo no la escapó. Un lector no tiene forma de distinguirla de un separador real: ambas son una línea que empieza por "From " al principio de línea. El resultado es que un mensaje queda partido en dos; la segunda mitad se convierte en un "mensaje" sin ninguna cabecera y la primera pierde su cola. Esta herramienta señala exactamente ese caso: un mensaje con el bloque de cabeceras vacío casi nunca es un mensaje de verdad. La solución tiene que estar en el lado que escribe: el escapado mboxrd y el marco por Content-Length lo evitan, y el mboxo puro casi nunca.

¿Qué diferencia realmente a mboxo, mboxrd, mboxcl y mboxcl2?

Solo cómo se protege el final de un mensaje. mboxo antepone ">" a una línea del cuerpo que empiece exactamente por "From ", lo cual pierde información, porque el lector no puede distinguir un escape de una línea citada de verdad. mboxrd antepone ">" a toda línea que encaje en ">*From ", así que ">From " venía de "From " y ">>From " venía de ">From ", y la transformación es reversible. mboxcl deja los cuerpos intactos y añade una cabecera Content-Length con el tamaño del cuerpo en bytes; mboxcl2 es igual pero guarda el mensaje en su codificación original sin escapar nada. La división es idéntica en mboxo y mboxrd — solo cambia lo que el lector debe deshacer —, y por eso aquí solo se informa de una división divergente en los archivos con Content-Length.

¿Por qué a veces la longitud de un mensaje es un byte menor de lo que espero?

La línea en blanco entre dos mensajes no pertenece a ninguno de los dos. Un lector que la consuma como parte del mensaje anterior acaba con un salto de línea sobrante en todos los cuerpos, así que las implementaciones clásicas la descartan, pero solo cuando esa línea en blanco es un LF suelto. Un archivo escrito con finales CRLF tiene una línea en blanco de dos bytes, que la regla histórica no reconoce, de modo que sigue pegada al mensaje anterior. Esta herramienta reproduce ese comportamiento en lugar de mejorarlo en silencio, para que sus desplazamientos y longitudes coincidan con los que informan las implementaciones de referencia sobre el mismo archivo.

¿Por qué un asunto se ve aquí distinto de lo que hay en el archivo crudo?

Las cabeceras solo admiten ASCII, así que todo lo demás se envuelve como palabra codificada de RFC 2047, del estilo =?UTF-8?B?SGVsbG8=?= o =?ISO-8859-1?Q?Caf=E9?=. Este visor las decodifica y, antes de decodificar, une los bytes de palabras codificadas contiguas que comparten juego de caracteres. Ese segundo paso importa más de lo que parece: un codificador puede partir un carácter multibyte entre dos palabras, y decodificar cada palabra por separado lo convierte en caracteres de reemplazo. Una etiqueta de juego de caracteres desconocida — una errata, o un nombre privado con x- — tampoco es fatal: la carga se decodifica como UTF-8, exacto para todo lo ASCII, y solo se marca lo que de verdad no puede leerse.

¿Por qué la parte HTML se muestra como código y no renderizada?

Porque un archivo de correo es entrada no confiable. Renderizar un cuerpo HTML dentro de esta página ejecutaría su marcado y sus estilos contra la página que lo rodea, y cualquier imagen, fondo o tipografía remota que referencie se descargaría de donde el remitente decidiera alojarla: así es como un píxel de rastreo confirma una dirección y como una carga XSS almacenada en un archivo de correo web encuentra un navegador. Mostrar el código solo te cuesta el formato: el texto, los enlaces y la estructura siguen ahí, y el tamaño decodificado de cada parte te dice si la versión bonita valía algo.

Message-ID duplicados y mensajes sin ninguno: ¿cuánto debería preocuparme?

Un Message-ID debe ser único en el mundo y lo asigna una sola vez el primer sistema que trata el mensaje. El mismo identificador dos veces en un archivo suele significar que se fusionaron dos copias del mismo mensaje, de una copia de seguridad y de una carpeta viva, o de dos carpetas que lo contenían. Deduplicar por identificador suele ser seguro, aunque conviene mirar antes las longitudes en bytes, porque una copia que pasó por una lista difiere en su pie. Un Message-ID ausente es otra cosa: los borradores, algunos remitentes automáticos y los mensajes montados por scripts nunca tuvieron uno. No se pueden enhebrar ni deduplicar, así que un recuento alto te dice qué parte del archivo es invisible para cualquier herramienta que trabaje por identificador.

Herramientas relacionadas