Resumo

  • A RFC 2047, de Keith Moore, criou uma sintaxe restrita para representar texto não ASCII em posições específicas de cabeçalhos de e-mail; ela não alterou a gramática de endereços nem acrescentou autenticação.
  • A leitura operacional correta conserva camadas distintas: bytes do cabeçalho, estrutura de campo, decodificação de charset, nome exibido, addr-spec, campos cobertos por DKIM e identidade do domínio signatário.

Um auditor abre uma mensagem arquivada. A lista mostra um remetente limpo e acentuado; o painel de detalhes revela uma sequência ASCII de sinais de igual, interrogações e letras. Os dois registros podem ser verdadeiros ao mesmo tempo. O primeiro é o texto que o cliente decidiu exibir depois da decodificação. O segundo é a representação transportada no cabeçalho. Nenhum deles, isoladamente, responde quem controlava a caixa postal ou quem autorizou a mensagem.

Essa diferença parece pequena porque a interface comprime várias operações numa única ficha de remetente. Ela é, porém, uma fronteira importante da infraestrutura. Em 1996, Keith Moore publicou a RFC 2047, que definiu as chamadas encoded-words: unidades ASCII capazes de transportar texto associado a um conjunto de caracteres e codificado pelos mecanismos Q ou B. O objetivo era permitir caracteres além do ASCII em determinados campos de cabeçalho compatíveis com o formato existente. A contribuição não foi uma reinvenção de todo o MIME nem um protocolo de confiança. Foi uma extensão deliberadamente delimitada.

Uma palavra codificada identifica charset, método de codificação e texto codificado. Seu tamanho é limitado a 75 caracteres, enquanto as linhas de cabeçalho obedecem ao limite de 76 caracteres recomendado pelo documento. Essas restrições ajudavam a dobrar linhas e a atravessar implementações antigas, mas também lembram que o objeto é uma unidade de representação, não uma afirmação de identidade. O receptor precisa reconhecer a unidade no contexto correto, converter os bytes segundo o charset indicado e só então apresentar os caracteres.

O contexto é decisivo. A RFC 2047 permite palavras codificadas no corpo de certos campos textuais, em comentários e como palavras de uma frase. Ela não as autoriza dentro de um addr-spec, de uma cadeia já delimitada por aspas, de campos Received ou de parâmetros MIME. A sintaxe não é um passe universal para inserir texto internacional em qualquer trecho do cabeçalho. Primeiro se analisa a estrutura do campo; depois, nas posições permitidas, reconhecem-se e decodificam-se as palavras codificadas.

Essa ordem evita uma confusão de segurança. Se o texto decodificado contiver dois-pontos, arrobas, aspas ou outros sinais especiais, esses caracteres não voltam para o analisador como nova gramática do cabeçalho. São caracteres para exibição dentro da posição já determinada. Decodificar e então reanalisar o resultado como se fosse estrutura original misturaria duas camadas que a especificação mantém separadas.

A mesma disciplina vale para espaços. O espaço linear que separa palavras codificadas adjacentes pode ser ignorado na exibição, permitindo que uma sequência longa seja dividida. Cada palavra, entretanto, continua autocontida: não se deve depender de estado de codificação transferido de uma para outra. O texto visual contínuo pode ter vindo de várias unidades independentes no fio.

Quando charset ou codificação estão ausentes, são desconhecidos ou estão malformados, o resultado varia. Um cliente pode mostrar a forma bruta, substituir caracteres, tentar uma recuperação prudente ou falhar. Portanto, uma captura de tela atual não prova como todo cliente histórico apresentou a mensagem. Para uma investigação reprodutível, é preciso guardar o cabeçalho bruto, a versão do software, a política de decodificação e o texto efetivamente renderizado.

O modelo de mensagem da RFC 5322 deixa a distinção seguinte ainda mais clara. Um endereço pode ter um display-name legível e um addr-spec que contém a caixa postal e o domínio. O nome é uma camada de apresentação. O endereço é uma estrutura de roteamento e identificação sintática. Os campos From e Sender têm funções definidas no formato da mensagem, mas a presença deles não é, por si só, autenticação criptográfica ou prova de uma pessoa.

A RFC 6532 mais tarde permitiu UTF-8 diretamente em cabeçalhos em ambientes internacionalizados e recomendou normalização NFC. Isso muda a representação disponível, não elimina a separação. Caracteres visualmente semelhantes podem ter sequências de pontos de código diferentes; normalização ajuda comparações, mas não transforma um nome em credencial nem um domínio mostrado em autoridade comprovada.

DKIM ocupa outra camada. Pela RFC 6376, a assinatura cobre um corpo canonicalizado e os campos de cabeçalho selecionados no parâmetro correspondente. O domínio de identidade do signatário, ou SDID, é uma afirmação sobre a responsabilidade daquele domínio pela assinatura verificável. Uma assinatura válida não torna o nome exibido uma pessoa verificada, não garante que todo campo visível foi assinado e não prova que o endereço apresentado é controlado pelo domínio que assinou. A primeira pergunta operacional deve ser: quais bytes e quais campos foram cobertos?

Por isso, a cadeia de evidência mais segura não é uma única etiqueta verde. Ela preserva: cabeçalho bruto; tokens e limites estruturais; charset e método declarados; bytes decodificados; pontos de código e normalização; separação entre nome e addr-spec; lista dos campos assinados; resultado criptográfico; SDID; e transformação final da interface. Cada etapa responde a uma pergunta diferente.

A obra de Moore continua relevante exatamente porque não promete demais. Ela torna nomes e assuntos legíveis através de uma infraestrutura originalmente ASCII e, ao mesmo tempo, oferece limites que permitem reconstruir como a exibição surgiu. O erro contemporâneo não é usar a palavra codificada; é pedir que ela prove algo que nunca foi criada para provar.

Fontes