Resumo

  • A revisão 00 propõe um único resultado legível por máquina para toda a cadeia DKIM2, com o domínio originador e, em falhas atribuíveis, o número da assinatura onde a verificação parou.
  • O próprio DKIM2 não protege esse resultado. Ele só é confiável no ADMD que o gerou e não pode ser copiado para servir de prova no próximo sistema.
  • Fora de pass, header.d pode ajudar no diagnóstico sem ser identidade autenticada; o comentário por saltos é texto influenciado pelo atacante, não uma interface para políticas.

Um filtro interno recebe duas informações no mesmo e-mail: a cadeia de assinaturas DKIM2 e uma linha dizendo que ela passou. Para o filtro, a linha é conveniente. Para uma organização posterior, ela é apenas a afirmação de outro sistema. A matemática está na cadeia; a confiança na linha depende de quem a escreveu e de como chegou ao consumidor.

Essa diferença é o centro do rascunho inicial de Authentication-Results para DKIM2, anunciado em 5 de setembro de 2026. Ele especifica como apresentar o resultado da verificação, não uma nova proteção para o relatório. A ficha do Datatracker via API registra um Internet-Draft individual, sem endosso formal do IETF. A fonte XML fixa a revisão e o anúncio I-D comprova o evento de publicação. “Standards Track” é a intenção declarada, não o resultado do processo.

O rascunho de base DKIM2 revision 06 fornece quatro saídas de uma verificação tentada: PASS, FAIL, PERMERROR e TEMPERROR. O novo texto propõe as formas minúsculas e acrescenta none, quando não há assinatura DKIM2 e a verificação não ocorreu. A ficha API do documento do WG pertence ao mecanismo subjacente e não muda o estatuto individual deste complemento.

Há apenas um resultado para a mensagem inteira. Em DKIM1, assinaturas independentes podem produzir resultados separados. Em DKIM2, o objeto avaliado é a Chain of Custody. O verificador começa pela assinatura mais recente, com maior i=, e pode parar diante de uma falha. As anteriores ficam como skipped no comentário: não reprovaram, mas também não foram verificadas.

header.d carrega o domínio da assinatura originadora i=1. Pode aparecer em qualquer resultado para facilitar uma investigação. Mas o rascunho é explícito: o domínio só é identidade autenticada quando o resultado geral é pass. Usá-lo em reputação ou disposição junto de fail, permerror ou temperror converte um valor extraído em uma identidade que a verificação não confirmou.

header.i exige tipagem semelhante. No método DKIM2, ele identifica a sequência da assinatura à qual uma falha foi atribuída. No método DKIM1, a mesma grafia representa Agent or User Identifier. Um pipeline que guarda a propriedade sem guardar o método mistura posição numérica com identidade.

A origem da confiança está em RFC 8601. Authentication-Results foi projetado para circular entre componentes de validação e avaliação dentro do mesmo Administrative Management Domain. O campo normalmente não traz integridade própria. Por isso o MTA de borda deve apagar ocorrências não confiáveis que aleguem ter sido criadas por seus próprios serviços antes de acrescentar o resultado local.

O authserv-id identifica o serviço alegado; não assina a alegação. A lista aceita e o caminho interno são decisões locais. DKIM2 exclui deliberadamente Authentication-Results do conjunto assinado porque o campo nasce depois da verificação e costuma ser removido em fronteiras. Qualquer manipulador pode alterá-lo sem que DKIM2 detecte.

A transação SMTP completa o limite. A assinatura DKIM2 mais recente está vinculada aos MAIL FROM e RCPT TO recebidos pelo verificador. Seu pass descreve aquela entrega até aquele ponto. Um encaminhamento cria outro contexto. O encaminhador não deve copiar o resultado para beneficiar o destino seguinte. Ele adiciona sua própria assinatura DKIM2; o próximo receptor verifica a nova cadeia e produz seu relatório local.

Assim, evidência e parecer seguem regras diferentes. A cadeia pode atravessar a fronteira porque pode ser recalculada. O rótulo verde não informa quais chaves, envelope, versão de software e política sustentaram a conclusão.

O comentário recomendado guarda a narrativa por salto. Ele pode listar sequências, domínios, resultados e diagnóstico, mas um parser conforme pode descartá-lo. A aparência regular existe para o leitor humano. Software decisório deve usar apenas resultado e propriedades definidos.

Os valores inseridos no comentário incluem seletores, domínios, MAIL FROM e RCPT TO, todos influenciáveis por remetentes ou intermediários. Em RFC 5322, parênteses e barra invertida controlam a sintaxe. O rascunho exige escape e recomenda limite de tamanho. Sem isso, texto hostil pode fechar o comentário e parecer um novo resultado dentro de um campo considerado interno. A interface também deve tratá-lo como texto não confiável, nunca como marcação.

O mesmo detalhe pode expor domínios intermediários, relações de encaminhamento e endereços de destinatários. Retenção indiscriminada cria risco de privacidade sem melhorar a verificabilidade.

A estrutura segue o precedente de ARC: poucos atributos estáveis para máquinas, detalhe de instância para pessoas. DKIM fornece o significado antigo de header.i, e a arquitetura do correio da Internet delimita o ADMD como responsabilidade operacional.

Na consulta feita para esta matéria, o registro IANA não continha dkim2. A revisão 00 pede o método, duas propriedades e cinco resultados. O pedido não é uma atribuição concluída.

A Especificação Inicial Mínima de Heng Lu permite coordenar vocabulário sem centralizar decisões futuras. As camadas da realidade separam assinatura, verificação, relatório e ação. A primazia do código em execução verifica se o MTA realmente limpou a entrada e refez o cálculo.

O relatório pode ser padronizado. Sua autoridade continua local.