Verificador de nomes de anexos MIME
Cole a origem bruta .eml (RFC 822/MIME) ou selecione um arquivo .eml para ver quais nomes de anexos declarados podem não ser salvos, ser alterados silenciosamente ou divergir entre clientes quando o destinatário os salvar no Windows, macOS ou Linux.
O processamento é feito localmente no seu navegador. Seu arquivo nunca é enviado.
Como usar esta ferramenta ferramenta
- Cole a origem .eml ou selecione um arquivo .eml. O navegador o processa localmente; não é enviado.
- Selecione ‘Verificar nomes de anexos’.
- Confira cada nome sinalizado e quais sistemas operacionais/clientes podem ser afetados.
- Use reescritas disponíveis: substituir caracteres, acrescentar sufixo a nome de dispositivo reservado, remover pontos/espaços finais e codificar RFC 2231 são mudanças mecânicas. Divergências de cabeçalhos e heurísticas são explicadas, não corrigidas por adivinhação.
Premissas
- Reconhece oito problemas específicos de portabilidade de nomes de anexos: caracteres reservados do Windows, nomes de dispositivos reservados do Windows, pontos/espaços finais, ausência de alternativa simples ao formato estendido RFC 2231, nomes acima do limite comum de 255 bytes, divergência entre nomes Content-Disposition/Content-Type, padrão de extensão dupla que mascara extensão e bytes de nome não ASCII sem codificação RFC 2231/2047.
- Reutiliza o parser .eml/MIME existente deste microsite (o mesmo usado pelo Analisador de importação EML/MIME) para localizar nomes declarados em cada parte MIME; não reimplementa a análise MIME.
- Se filename de Content-Disposition e name de Content-Type estão presentes e são iguais, filename é tratado como o nome normalmente usado pelo cliente ao salvar (precedência que a maioria segue). Se divergem, ambos são exibidos e sinalizados, sem preferência silenciosa.
- Mensagem sem anexos (sem Content-Disposition: attachment nem parâmetros filename/name) resulta em zero problemas; não é um problema a sinalizar.
Fontes e dados de referência
Metodologia
O texto bruto é analisado como árvore de partes MIME; os parâmetros filename/name dos cabeçalhos Content-Disposition e Content-Type são inspecionados. Cada nome é comparado a regras documentadas de sistemas de arquivos Windows/macOS/Linux e requisitos RFC 2183/2231/6266. Reescrita somente quando mecanicamente segura e inequívoca: substituir caracteres reservados, acrescentar sufixo a nome de dispositivo reservado, remover pontos/espaços finais, adicionar alternativa simples quando o nome RFC 2231 decodifica para ASCII simples e codificar nome não ASCII com RFC 2231. Divergências de cabeçalho e padrão de extensão dupla são apenas sinalizados e explicados; a ferramenta não decide qual nome era pretendido nem renomeia por heurística.
Exemplo resolvido
Nome de anexo PDF com dois-pontos e ponto de interrogação
Dados de entrada: Content-Disposition: attachment; filename="Q3 report: draft?.pdf"
Resultado: Windows (NTFS/exFAT) não permite < > : " / \ | ? *, embora sejam válidos no Linux/macOS. É sinalizado como erro e oferece substituição segura de cada caractere reservado por ‘_’.
Anexo .txt chamado exatamente ‘con.txt’
Dados de entrada: Content-Disposition: attachment; filename="con.txt"
Resultado: Windows reserva CON, PRN, AUX, NUL, COM1-COM9 e LPT1-LPT9 independentemente da extensão. É sinalizado como erro e oferece acrescentar sublinhado ao nome reservado (`con_.txt`).
Executável disfarçado com extensão que parece documento
Dados de entrada: Content-Disposition: attachment; filename="invoice.pdf.exe"
Resultado: Extensão aparentemente segura seguida imediatamente por extensão de executável é padrão conhecido de disfarce de malware. É sinalizada como aviso heurístico, não certeza, e não é renomeada automaticamente.
Orientações práticas
- Evite caracteres reservados do Windows (< > : " / \ | ? *) e nomes de dispositivos reservados (CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9) em nomes de anexos sob seu controle; eles falham ao salvar no Windows independentemente do cliente remetente.
- Se o nome precisa de caracteres não ASCII, use a forma estendida RFC 2231 (`filename*=UTF-8''percent-encoded`) e inclua também uma alternativa ASCII simples `filename=` para clientes antigos/simples.
- Não confie apenas na declaração Content-Type para identificar um anexo com segurança: extensão aparentemente segura seguida por extensão executável é técnica documentada de disfarce.
- Mantenha nomes de anexos bem abaixo de 255 bytes UTF-8; alguns gateways e sistemas antigos truncam antes.
Erros comuns
- Presumir que um nome exibido corretamente no cliente remetente será salvo corretamente em todos os lugares: caractere ou dispositivo reservado só falha quando o sistema do destinatário cria o arquivo.
- Tratar `filename*=` e `filename=` como equivalentes: um cliente sem suporte a RFC 2231 pode mostrar nome vazio ou ilegível se não houver alternativa simples.
Perguntas frequentes
Por que caractere reservado é erro, mas divergência de cabeçalhos é apenas aviso?
Caractere ou nome de dispositivo reservado definitivamente não será salvo no Windows. Divergência entre Content-Disposition e Content-Type é ambígua: clientes reais diferentes escolhem valores distintos, então há risco, mas não falha garantida.
Por que a ferramenta não renomeia arquivo sinalizado pela verificação de extensão dupla?
O padrão é heurístico e pode gerar falso positivo em nomes legítimos, como `summary.pdf.bak`. Renomear anexo real com base em suposição cabe ao destinatário.
A ferramenta decodifica ou exibe o conteúdo do anexo?
Não. Inspeciona apenas os cabeçalhos Content-Disposition e Content-Type que declaram o nome. Nunca decodifica nem exibe o corpo real do anexo.
Por que o nome de anexo de e-mail aparece ilegível ou muda ao ser salvo?
Clientes de e-mail tratam parâmetros de nome MIME de formas diferentes, principalmente nomes RFC 2231 codificados, ausência de alternativa simples, nomes não ASCII brutos ou declarações conflitantes em Content-Disposition e Content-Type. O verificador inspeciona esses problemas declarados de portabilidade; não analisa o conteúdo nem prevê o nome exato salvo por cada cliente.
Última revisão:
Verifica somente declarações de nomes, não conteúdo dos anexos, e reutiliza parser .eml/MIME restrito deste microsite, não biblioteca completa de e-mail; estruturas MIME profundamente incomuns além de aninhamento multipart comum não são analisadas. A verificação de tamanho aproxima o limite comum de 255 bytes contando bytes UTF-8; alguns sistemas/gateways truncam antes, indicado nas orientações, mas não sinalizado separadamente por sistema.
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.