Resumo

  • l= limita opcionalmente o hash DKIM aos primeiros octetos do corpo após a canonização. Tudo o que vier depois fica sem validação por aquela assinatura, ainda que o cálculo termine em sucesso.
  • h= estabelece uma fronteira independente para cabeçalhos e preserva uma ordem. Quando há campos repetidos, saber apenas o nome não revela qual instância foi assinada.
  • Um comprovante reproduzível guarda mensagem, assinatura escolhida, canonização, seleção de cabeçalhos, comprimentos e hashes do prefixo e da cauda, chave DNS observada, verificador e origem confiável de Authentication-Results.

O corpo tinha mais bytes do que o resultado contou

Um relatório de autenticação pode mostrar dkim=pass sem dizer que o corpo canonizado tinha 20.700 octetos e que a assinatura declarava l=16.000. O verificador analisou o prefixo. A cauda de 4.700 octetos ficou fora do hash.

Não se trata de uma falha oculta. A RFC 6376 define o comportamento. Sem l=, todo o corpo canonizado participa. Com a tag, apenas a quantidade informada desde o começo entra no cálculo. Dados posteriores não são validados por DKIM. Se o valor for zero, o corpo inteiro fica sem assinatura.

A cauda pode ser legítima: uma lista de e-mail acrescenta instruções de saída, por exemplo. Pode ser um marcador de uma infraestrutura interna. Também pode alterar MIME, explorar um cliente permissivo ou introduzir texto que ocupa a tela. O fato de existir não escolhe intenção; o pass do prefixo também não oferece integridade por herança.

O receptor pode adotar política que rejeita assinatura parcial. É preciso registrar separadamente “verificação criptográfica do escopo” e “decisão local”. Misturar ambos impede distinguir atualização de política, erro de implementação e alteração real da mensagem.

Murray Kucherawy aparece nessa história por atribuição documental delimitada. A RFC 6376 lista Dave Crocker, Tony Hansen e Murray S. Kucherawy em conjunto. A RFC 8601 o apresenta como autor. Na captura de 2 de setembro de 2026, a tabela do perfil oficial da IETF mostrava 34 RFCs e a biografia ainda dizia 33. Autoria coletiva não é propriedade do protocolo, e perfil público não prova operação de um signer ou verifier específico.

Canonizar vem antes de contar

O número de l= não é um offset no arquivo bruto. O algoritmo aplica primeiro a canonização de corpo escolhida em c=. simple e relaxed tratam espaços e linhas vazias de modo diferente. Por isso o tamanho do .eml menos l= não calcula necessariamente a cauda criptográfica.

O caminho reproduzível é: preservar o arquivo original; escolher uma instância exata de DKIM-Signature; extrair a=, c=, d=, s=, h=, l= e bh=; canonizar; medir; cortar o prefixo quando necessário; comparar o body hash; e verificar a parte de cabeçalhos com a chave observada.

Registrar três regiões evita ambiguidade: corpo canonizado completo, prefixo assinado e sufixo não assinado. Cada região recebe comprimento e hash. Sufixo positivo significa apenas que a fronteira terminou cedo. Se l= não existe, o registro diz cobertura completa, em vez de inventar um valor numérico.

A consulta de chave precisa de data. d= aponta para o domínio assinante e s= para o selector no DNS. Rotação e revogação mudam a resposta. Uma auditoria posterior precisa da chave realmente observada, horário, resolver e falhas; estado DNSSEC só entra se tiver sido medido naquela decisão.

A mesma tolerância serve a dois atores

Listas explicam por que l= existe. Ao acrescentar um rodapé, elas quebrariam uma assinatura de corpo inteiro. Um prefixo permite reconhecer a porção original e deixar o receptor decidir sobre o material extra.

O problema é de agência: a tag abre espaço, mas não nomeia quem poderá usá-lo. A RFC 6376 alerta que um intermediário malicioso pode anexar conteúdo em benefício próprio. Mudanças na estrutura MIME, parsing HTML relaxado e interferência na detecção de duplicatas podem fazer a adição dominar o que o usuário enxerga.

A resposta madura não acusa todos os rodapés nem autentica todos eles. Identifica o intermediário, compara a transformação com sua função declarada, reconstrói a árvore MIME e observa a parte que o cliente apresentou. A evidência de bytes e a evidência de tela permanecem ligadas, não confundidas.

O princípio de running code de Heng Lu impede usar a autoridade do texto como log de uma máquina. A RFC define o procedimento. A mensagem capturada, a versão do verificador e o rastro do renderer mostram o que de fato aconteceu.

O alcance de cabeçalhos tem ordem

h= lista os nomes dos campos assinados em sequência. Em presença de duplicatas, DKIM resolve as instâncias de baixo para cima. Transformar essa sequência num conjunto elimina a resposta à pergunta “qual Subject foi assinado?”.

From é obrigatório. Date, Subject, Reply-To, Sender e campos MIME são fortemente recomendados por influenciarem apresentação ou processamento. Com l=, Content-Type ganha peso: uma troca não coberta pode fazer o mesmo prefixo ser interpretado de maneira completamente diferente.

O mapa de cobertura lista todos os cabeçalhos brutos em ordem, marca os selecionados e destaca campos de apresentação deixados de fora. Oversigning de nomes ausentes também deve aparecer, pois pode impedir inserção posterior silenciosa. Cada assinatura recebe seu próprio mapa; assinatura do domínio, da lista e do gateway não são um resultado coletivo.

Pass não é autoria, verdade nem segurança

DKIM pass significa que uma assinatura verificou com uma chave publicada sob certo domínio e selector, sobre o material escolhido. Não significa que a pessoa visível em From escreveu o conteúdo, que o serviço de assinatura foi autorizado, que a mensagem é verdadeira, que o anexo é seguro ou que haverá entrega.

A RFC 5585 limita a propriedade à não alteração do conteúdo assinado. A RFC 5863 orienta considerar autenticada apenas a parte dentro do escopo e cita l=. A RFC 8301 atualiza algoritmos e tamanhos de chave. Uma chave aceitável resolve resistência criptográfica, não o comprimento da cobertura.

DMARC trata de alinhamento entre identidades SPF ou DKIM e o domínio visível de From, além de política do receptor. Não amplia h= nem l=. Alinhamento, validade, reputação, segurança, disposition e renderização precisam ser campos distintos.

O cabeçalho de resultado depende de quem o escreveu

Sistemas a jusante frequentemente leem Authentication-Results em vez de repetir a verificação. A RFC 8601 define a comunicação entre produtor e consumidor dentro de uma fronteira administrativa. O campo em geral não se autentica sozinho.

O consumidor confia em authserv-id configurados. Na entrada, resultados forjados que aleguem vir de dentro devem ser removidos ou neutralizados antes de o sistema inserir os seus. Qualquer remetente consegue digitar dkim=pass; só a arquitetura receptora transforma a linha em observação confiável.

O receipt guarda o campo bruto, posição, produtor, regra de confiança e assinatura correspondente. Resumir várias assinaturas num pass anônimo destrói a ligação com domínio, selector, cabeçalhos e limite de corpo.

Também registra resultado e tratamento. Um verifier pode confirmar o cálculo e rejeitar conteúdo parcial por política. Outro pode aceitar com alerta. Essa diferença não deve desaparecer numa única cor.

Um ledger pequeno, mas suficiente

O primeiro bloco guarda mensagem bruta por hash e todas as DKIM-Signature na ordem, com d=, s=, i= quando existir, a=, c=, h=, l=, bh=, valor da assinatura e tempos opcionais.

O segundo bloco contém chave DNS e hora, procedimento de canonização, instâncias de cabeçalhos resolvidas, medidas e hashes de corpo, prefixo e cauda, implementação do verificador, resultado e motivo. O terceiro documenta produtor e fronteira de Authentication-Results. O quarto descreve árvore MIME, parte escolhida e versão do renderer, com retenção proporcional à privacidade.

Pelo princípio de agência, autores do padrão definem sintaxe; custodiante de chave escolhe escopo; intermediário transforma; verifier calcula; domínio administrativo garante o canal; cliente renderiza. Nenhum deles pode prometer o que todos os outros fariam.

A conclusão auditável diz: esta assinatura cobriu estas instâncias ordenadas e os primeiros N octetos canonizados com esta chave; esta cauda ficou de fora; este produtor confiável registrou o resultado; este cliente mostrou estas partes. Autoria humana, segurança, intenção e entrega exigem fontes próprias.

Fontes