Visualizador de arquivos mbox

Como usar

1. Solte o arquivo .mbox sobre a caixa. Nada é enviado: a leitura acontece nesta aba, então uma exportação de vários gigabytes depende só da sua máquina.
2. Leia primeiro a linha da convenção. Ela diz se o arquivo escapa os corpos (mboxo/mboxrd) ou os delimita com Content-Length (mboxcl), e com que indício isso foi decidido.
3. Confira os achados. Mensagens sem nenhum cabeçalho legível são linhas "From " sem escape que partiram uma mensagem real em duas, e a contagem de limites que outra convenção traçaria mostra o quanto o arquivo é frágil.
4. Olhe os deslocamentos e comprimentos da tabela. São posições em bytes dentro do arquivo que você soltou, então dá para recortar uma mensagem com dd ou um editor hexadecimal e conferir por fora.
5. Clique no número de uma linha para abrir uma mensagem: a linha From_, os cabeçalhos decodificados e a árvore MIME com a codificação, o nome e o tamanho decodificado de cada parte.

Perguntas frequentes

Por que meu arquivo tem mais mensagens do que eu recebi?

Porque uma linha do corpo de alguém começava com "From " e o programa que escreveu o arquivo não a escapou. Um leitor não tem como distingui-la de um separador real: as duas são uma linha começando por "From " no início da linha. O resultado é que uma mensagem fica partida em duas; a segunda metade vira uma "mensagem" sem nenhum cabeçalho e a primeira perde o fim. Esta ferramenta sinaliza exatamente esse caso: uma mensagem com bloco de cabeçalhos vazio quase nunca é uma mensagem de verdade. A correção precisa vir de quem escreve: o escape mboxrd e o enquadramento por Content-Length evitam isso, e o mboxo puro em geral não.

O que de fato distingue mboxo, mboxrd, mboxcl e mboxcl2?

Apenas como o fim de uma mensagem é protegido. O mboxo prefixa ">" a uma linha do corpo que comece exatamente por "From ", o que perde informação, porque o leitor não distingue um escape de uma linha genuinamente citada. O mboxrd prefixa ">" a qualquer linha que case com ">*From ", então ">From " veio de "From " e ">>From " veio de ">From ", e a transformação é reversível. O mboxcl deixa os corpos intactos e acrescenta um Content-Length com o tamanho do corpo em bytes; o mboxcl2 é igual, mas guarda a mensagem na codificação original e sem escape algum. A divisão é idêntica em mboxo e mboxrd — muda só o que o leitor precisa desfazer —, e por isso aqui só se informa divisão divergente em arquivos com Content-Length.

Por que o comprimento de uma mensagem às vezes é um byte menor do que eu esperava?

A linha em branco entre duas mensagens não pertence a nenhuma delas. Um leitor que a consuma como parte da mensagem anterior termina com uma quebra de linha sobrando em todos os corpos, então as implementações clássicas a descartam — mas só quando essa linha em branco é um LF sozinho. Um arquivo escrito com finais CRLF tem uma linha em branco de dois bytes, que a regra histórica não reconhece, e ela continua colada à mensagem anterior. Esta ferramenta reproduz esse comportamento em vez de melhorá-lo em silêncio, para que seus deslocamentos e comprimentos batam com o que as implementações de referência informam para o mesmo arquivo.

Por que um assunto aparece aqui diferente do que está no arquivo bruto?

Cabeçalhos só aceitam ASCII, então o resto vem embrulhado como palavra codificada de RFC 2047, do tipo =?UTF-8?B?SGVsbG8=?= ou =?ISO-8859-1?Q?Caf=E9?=. Este visualizador as decodifica e, antes de decodificar, junta os bytes de palavras codificadas vizinhas que compartilham o mesmo conjunto de caracteres. Esse segundo passo importa mais do que parece: um codificador pode partir um caractere multibyte entre duas palavras, e decodificar cada palavra sozinha o transforma em caracteres de substituição. Um rótulo de conjunto de caracteres desconhecido — um erro de digitação ou um nome privado com x- — também não é fatal: a carga é decodificada como UTF-8, exato para tudo que é ASCII, e só o que realmente não dá para ler fica marcado.

Por que a parte HTML é mostrada como código e não renderizada?

Porque um arquivo de correspondência é entrada não confiável. Renderizar um corpo HTML dentro desta página executaria a marcação e os estilos dele contra a página em volta, e qualquer imagem, fundo ou fonte remota referenciada seria buscada onde o remetente escolheu hospedar — é assim que um pixel de rastreamento confirma um endereço e que uma carga XSS armazenada num arquivo de webmail encontra um navegador. Mostrar o código custa apenas a formatação: o texto, os links e a estrutura continuam lá, e o tamanho decodificado de cada parte diz se a versão bonita tinha algum conteúdo.

Message-ID duplicados e mensagens sem nenhum: devo me preocupar?

Um Message-ID deve ser único no mundo e é atribuído uma única vez, pelo primeiro sistema que trata a mensagem. O mesmo identificador duas vezes num arquivo costuma significar que duas cópias da mesma mensagem foram mescladas, vindas de um backup e de uma pasta viva, ou de duas pastas que a continham. Deduplicar pelo identificador em geral é seguro, mas confira antes os comprimentos em bytes, porque uma cópia que passou por uma lista difere no rodapé. Um Message-ID ausente é outra história: rascunhos, alguns remetentes automáticos e mensagens montadas por scripts nunca tiveram um. Não dá para encadeá-las nem deduplicá-las, então uma contagem alta mostra quanto do arquivo é invisível para qualquer ferramenta que trabalhe por identificador.

Ferramentas relacionadas