Resumo

  • draft-gondwana-dkim2-debug-header-01 padroniza a forma da trilha X-DKIM2-Info usada nos primeiros testes de DKIM2; ele não cria um novo resultado de verificação.
  • O campo fica deliberadamente fora de hashes e assinaturas. Ele pode levar uma pessoa às evidências, mas não autentica o emissor, a ação, o snapshot nem a completude do relato.

Uma mensagem problemática chega parecendo trazer o próprio laudo. Uma linha informa qual revisão de DKIM2 o filtro de entrada implementava, seu repositório e programa. Outra afirma que o gerenciador da lista criou a Message-Instance m=2, enumera os cabeçalhos incluídos no hash e aponta para uma cópia anterior. O filtro de saída, por fim, diz que não assinou porque a cadeia estava quebrada.

Para quem compara implementações, esse roteiro pode economizar uma longa sessão de tentativa e erro. Para um sistema que entrega, bloqueia ou atribui responsabilidade, ele não prova nada. Cada linha pode ser inserida, editada, reposicionada ou removida enquanto as partes realmente protegidas por DKIM2 continuam verificando corretamente.

Essa é a escolha de A Diagnostic Header Field for DKIM2 Implementations. A revisão 01 entrou no histórico em 30 de setembro de 2026 no horário do Pacífico, já 1º de outubro em Xangai e UTC. Trata-se de um Internet-Draft individual, com status pretendido Informational e marcado como I-D Exists. Não é adoção do grupo DKIM, RFC, registro da IANA ou dependência normativa do DKIM2. O texto o apresenta como auxílio aos testes iniciais e diz que provavelmente não será publicado.

Um idioma comum para localizar divergências

O DKIM2 procura manter uma cadeia verificável através de transformações, inclusive as de listas de discussão. Campos Message-Instance carregam hashes e Recipes para reconstruir estados anteriores; campos DKIM2-Signature ligam esses registros protegidos. Quando duas implementações discordam, o resultado final pode ser simples demais para indicar o ponto em que seus comportamentos se separaram.

X-DKIM2-Info cria um lugar repetível para os detalhes. Cada ocorrência traz cinco etiquetas obrigatórias e ordenadas: draft, repo, date, sw e action. A primeira informa a revisão de DKIM2 implementada. Repositório e programa distinguem um componente ou fork. A data deve mudar quando mudar o comportamento DKIM2 do emissor. Um campo representa uma ação; várias ações geram vários campos.

O vocabulário cobre verificação, criação de Message-Instance, assinatura e recusa de assinar. verify=pass ou verify=fail pode receber uma explicação livre. mi-m=<N> pode registrar contagem e ordem dos cabeçalhos no hash, além dos identificadores do snapshot recuperado e do snapshot armazenado. sign declara domínio e algoritmo. not-signed recebe uma razão escolhida pela implementação, como broken-mi-chain.

A revisão 01 reduz diferenças superficiais entre protótipos: usa exatamente a gramática de etiquetas de extensão do DKIM2, exige ponto e vírgula após todas elas e troca mi-m<N> por mi-m=<N>. Isso melhora a comparação sintática, sem transformar uma autodescrição em prova.

A flexibilidade existe porque a proteção não alcança o campo

O rascunho-base do DKIM2 exclui do hash de cabeçalhos da Message-Instance os nomes iniciados por X-. O documento de depuração também proíbe que o emissor inclua X-DKIM2-Info em qualquer coisa que assine ou submeta a hash. Assim, o sistema pode colocar uma nota ao lado do cabeçalho descrito sem mudar a Message-Instance protegida ou invalidar uma assinatura DKIM2.

A mesma característica elimina a autoridade da nota. O rascunho afirma que ela não é resultado de verificação; o resultado autorizado deve estar em Authentication-Results. O campo registra somente o que o emissor diz ter feito, e nenhum software deve tomar decisão sobre a mensagem com base nele. Qualquer participante do caminho pode acrescentar, mudar ou apagar uma ocorrência sem detecção.

O limite difere daquele examinado no artigo BTW sobre Authentication-Results. Ali, a questão era quando um consumidor pode confiar num authserv-id local dentro de um domínio administrativo e de uma transação SMTP. X-DKIM2-Info fica abaixo até dessa camada de veredito. Sua função é oferecer a uma pessoa a próxima pergunta, não autorizar uma ação automática.

Proximidade visual não assina uma causa

O documento orienta o emissor a inserir primeiro o cabeçalho operacional ou protegido e depois colocar imediatamente acima dele a linha de depuração. Também diz que um emissor conforme não deve alterar nem remover linhas já presentes. A ordem do bloco passa a contar uma cronologia legível.

Mas adjacência não é causalidade autenticada. Um manipulador posterior pode acrescentar um action=sign convincente, mover uma linha para junto de outra Message-Instance ou apagar a explicação que revelaria a falha. Caminho de repositório e nome do programa são autodeclarações, não atestados do binário. A data de comportamento não é hash de commit. Faltam identificador de evento, chave da instância, número de sequência, confirmação do receptor e declaração de completude.

O silêncio também não é informativo. Se a Message-Instance superior ainda corresponder e o emissor nada acrescentar, nenhuma ação aparece. A ausência de mi-m=<N> não comprova que a verificação rodou, que nenhuma mudança ocorreu ou que um intermediário preservou toda a trilha.

O ponteiro operacional não contém a cópia

snapf identifica a mensagem anterior usada no cálculo de uma Recipe; snaps identifica a mensagem atual guardada para comparação futura. Esses são talvez os dados mais úteis ao suporte, mas o rascunho esclarece que só têm significado para o emissor que os escreveu. Um exemplo se parece com chave de banco de dados ou caminho de armazenamento.

O identificador pode encurtar o atendimento: leve-o ao operador do componente e peça bytes, logs e política de retenção. Fora daquele sistema, ele não comprova o conteúdo, a custódia, o período de preservação nem a disponibilidade atual. Sem digest de conteúdo e recibo de recuperação independentes, uma string copiada não é objeto de evidência portátil.

Há também custo de exposição. O cabeçalho pode revelar repositório, programa, revisão, organização de armazenamento, inventário de cabeçalhos e comportamento do parser em explicações livres. É possível removê-lo na borda de saída sem afetar DKIM2. Isso protege a arquitetura, mas elimina o indício que o testador remoto procurava. Retenção interna e divulgação externa precisam formar uma única política.

O parsing guarda uma armadilha. A RFC 5322 permite ponto e vírgula no nome de um cabeçalho; a nova gramática usa o mesmo sinal para encerrar etiquetas e não possui mecanismo de citação. O rascunho orienta a omitir nomes perigosos de hn, limitar seu tamanho e substituir ou remover pontos e vírgulas em valores interpolados. As regras reduzem ambiguidade, mas não provam que todos os primeiros protótipos as executam de modo uniforme.

A RFC 6648 descreve o risco geral dos nomes X-: extensões privadas escapam, viram interfaces de fato e criam incerteza na migração. Aqui o prefixo é um compromisso consciente para deixar a depuração fora do significado e da cobertura criptográfica do DKIM2. Uma fronteira de protocolo bem desenhada não garante confinamento operacional.

Da pista ao recibo verificável

Uma investigação confiável separa a identidade de software alegada, a ação alegada, o campo efetivamente recebido, a borda que o reteve ou retirou, a verificação DKIM2 real, o Authentication-Results local, o build e seus logs, os snapshots, o julgamento de causa raiz, a correção e o resultado de entrega observado. Pular qualquer etapa transforma conveniência em conclusão não sustentada.

A doutrina de especificação inicial mínima de Heng Lu favorece essa separação. Um formato compartilhado deve facilitar testes independentes sem fingir que contém a verdade de execução local. A primazia do código em funcionamento exige observar o build, recuperar a cópia, reproduzir a falha e medir o resultado depois do reparo.

X-DKIM2-Info é valioso porque deixa impressões legíveis perto do problema. O risco surge quando a pista vira proveniência, política ou veredito. A automação correta não decide a partir dela; usa-a para buscar a evidência que pode ser verificada.

Fontes