Analisador de importação EML/MIME

Cole a origem bruta de uma mensagem .eml (RFC 822/MIME) ou selecione um arquivo .eml para ver quais estruturas podem se comportar de forma diferente ou falhar entre clientes e importadores, como Outlook, importação do Gmail, Apple Mail, Thunderbird e ferramentas IMAP genéricas.

Cole o conteúdo que deseja analisar

O processamento é feito localmente no seu navegador. Seu arquivo nunca é enviado.

Como usar esta ferramenta ferramenta

Cole o conteúdo .eml ou selecione um arquivo .eml. A análise acontece no navegador e o conteúdo não é enviado.
Selecione ‘Verificar compatibilidade de importação’.
Confira cada construção sinalizada, por que reduz a portabilidade e quais clientes/importadores podem divergir.
Use reescritas quando disponíveis: normalizar finais de linha para CRLF e codificar cabeçalhos conforme RFC 2047 são alterações mecânicas seguras. Os outros problemas são explicados, pois não há correção automática segura que possa ser adivinhada.

Premissas

Reconhece oito casos específicos: limites multipart ausentes/malformados, MIME-Version ausente em mensagem com estrutura MIME, divergência entre Content-Transfer-Encoding e corpo real, valores de cabeçalho não ASCII sem codificação, linhas acima do limite de 998 octetos da RFC 5322, finais LF sem CR, cabeçalhos críticos duplicados e strings boundary fracas que podem coincidir com o conteúdo.
É um parser RFC 822/MIME com reconhecimento de linhas, criado para esta ferramenta; reconhece dobramento de cabeçalho e estrutura de limites multipart necessários a estas verificações, não mais.
Cabeçalhos críticos verificados quanto a duplicidade: Content-Type, From, To, Subject, MIME-Version, Content-Transfer-Encoding, Message-ID e Date.

Fontes e dados de referência

Metodologia

O texto bruto é analisado em cabeçalhos (desfazendo o dobramento RFC 822) e árvore de partes MIME. Os parâmetros boundary de Content-Type de cada parte localizam delimitadores; em seguida são verificados requisitos documentados das RFC 5322/2045-2049/2047 e diferenças conhecidas de tolerância entre clientes e importadores. Reescrita somente quando mecanicamente segura e inequívoca: normalizar finais de linha para CRLF e codificar em RFC 2047 valor de cabeçalho não ASCII. Os demais casos são sinalizados e explicados sem inventar limites nem escolher entre cabeçalhos duplicados.

Exemplo resolvido

Content-Type multipart sem parâmetro boundary

Dados de entrada: Content-Type: multipart/mixed (sem boundary="...")

Resultado: Todo parser MIME estrito precisa do parâmetro boundary para localizar as partes. É sinalizado como erro porque impede a análise da estrutura; não há correção, pois não é possível inventar o valor correto.

Finais de linha LF sem CR no arquivo inteiro

Dados de entrada: Cabeçalhos e corpo separados por ‘\n’ em vez de ‘\r\n’

Resultado: RFC 5322 exige finais CRLF. Alguns parsers estritos interpretam incorretamente ou rejeitam LF sem CR, embora muitos clientes modernos normalizem automaticamente. É informação e oferece normalização segura para CRLF.

Cabeçalho Subject com caracteres não ASCII sem codificação

Dados de entrada: Subject: Notas da reunião do café

Resultado: Mensagens tradicionais RFC 822/5322 usam cabeçalhos ASCII de 7 bits. A RFC 6532 permite cabeçalhos UTF-8 diretos quando o caminho de recebimento oferece suporte a SMTPUTF8. Palavras codificadas RFC 2047 continuam sendo a opção mais compatível com sistemas legados. O caso é sinalizado como aviso de compatibilidade e oferece uma reescrita RFC 2047 determinística e reversível.

Orientações práticas

Inclua parâmetro boundary em cada Content-Type multipart e confira se o corpo usa ‘--boundary’ e termina com ‘--boundary--’.
Inclua `MIME-Version: 1.0` em mensagens com recursos MIME; isso evita ambiguidades mesmo que alguns clientes infiram o valor.
Use uma string boundary longa e difícil de prever para reduzir o risco de coincidência com o conteúdo real.
Para ampla compatibilidade com sistemas de e-mail legados que aceitam apenas ASCII, codifique texto não ASCII de cabeçalho usando RFC 2047. Cabeçalhos UTF-8 diretos são válidos quando o caminho de recebimento oferece suporte a RFC 6532 e SMTPUTF8.

Erros comuns

Presumir que .eml com finais LF funciona em todos os lugares porque abre em um cliente moderno; alguns parsers estritos/antigos exigem CRLF.
Tratar Content-Transfer-Encoding como decorativo: uma parte declarada como base64 que não contém base64 válido pode falhar na decodificação ou aparecer como dados ilegíveis.

Perguntas frequentes

Por que boundary ausente é erro, mas MIME-Version ausente é aviso?

Sem boundary, parsers estritos não conseguem localizar as partes da mensagem e falham. A ausência de MIME-Version viola RFC 2045, mas muitos clientes tolerantes inferem MIME pelos outros cabeçalhos, então o impacto prático pode ser menor.

Por que a ferramenta codifica cabeçalhos não ASCII, mas não corrige boundary ausente?

Codificar um valor de cabeçalho com RFC 2047 é transformação reversível e determinística dos bytes existentes. Inventar boundary ou decidir qual de dois cabeçalhos duplicados manter exige uma intenção desconhecida.

A ferramenta decodifica anexos ou mostra seu conteúdo?

Não. Inspeciona cabeçalhos e marcadores estruturais — limites, declarações de codificação e tamanho de linhas. Não decodifica nem exibe conteúdo dos anexos, exceto um trecho breve necessário para explicar problema específico, como o primeiro caractere inválido em bloco base64 malformado.

Por que este arquivo EML não abre ou importa no Outlook?

Este verificador procura problemas estruturais específicos, como limites MIME multipart ausentes/malformados e divergências de transferência de conteúdo. Não testa o Outlook nem diagnostica todos os problemas de importação; passar nas verificações não descarta causas externas à estrutura analisada.

Última revisão:

Parser RFC 822/MIME restrito, não biblioteca completa de e-mail: reconhece os oito casos acima e não analisa outros detalhes do mundo real (casos extremos de charset além de UTF-8, assinaturas S/MIME, partes de calendário/iCal, estruturas multipart/related profundamente aninhadas). A verificação do comprimento de linha aproxima octetos pela contagem de bytes UTF-8, exata para a grande maioria das mensagens reais.

Esta ferramenta fornece uma estimativa indicativa com base nas premissas informadas acima.

As preferências de tema e de ferramentas, além das listas de itens salvos e usados recentemente, são armazenadas somente neste navegador.