DKIM canonização define como os bytes da mensagem são preparados para hashing e verificação de assinatura. Permite normalizações específicas; isso não torna inofensiva a edição arbitrária de mensagens. Diagnosticar as configurações reais da assinatura e o conteúdo bruto antes de alterar a configuração do remetente.
Leia as duas configurações separadamente
A assinatura c= tag nomeia cabeçalho e canonização do corpo nessa ordem. Por exemplo, descontraído/simples usa processamento relaxado para cabeçalhos e processamento simples para o corpo. RFC 6376 §3.5 define simples/simples como padrão quando a tag está ausente; se apenas o algoritmo do cabeçalho for declarado, o algoritmo do corpo será padronizado como simples.
Registro c=, a lista de cabeçalhos assinados h=, o hash de corpo bh= e qualquer limite de comprimento corporal l= ao lado d= e s=. Uma incompatibilidade de hash de corpo, uma incompatibilidade de assinatura de cabeçalho e uma chave pública ausente precisam de investigações diferentes. Não deduza a configuração de canonização a partir do que o cliente de e-mail exibe.
Entenda a normalização permitida
A canonização simples do cabeçalho preserva os campos do cabeçalho conforme apresentados ao algoritmo. O processamento de cabeçalho relaxado coloca nomes de campos em minúsculas, desdobra linhas de continuação e normaliza espaços em branco especificados. Não coloca os valores dos campos em minúsculas nem autoriza a alteração das palavras do Assunto.
A canonização simples do corpo remove as linhas vazias no final e garante o CRLF final necessário, enquanto retém outros conteúdos do corpo. O processamento de corpo relaxado também reduz a quantidade de espaços e tabulações dentro de uma linha e remove espaços em branco nas extremidades da linha antes de manipular as linhas vazias finais. Ele não combina linhas arbitrárias, reescreve URLs, remove limites MIME ou ignora texto adicionado. RFC 6376 §3.4 especifica a ordem exata e os casos extremos, incluindo tratamento diferente de um corpo vazio.
Use uma implementação conforme para testes exatos. Uma aproximação editada manualmente que altera os finais de linha antes da verificação pode criar a falha que deveria investigar.
Aplicar um exemplo controlado
Considere a linha corporal sintética Pague<SP><SP>agora<SP><CRLF>, onde os rótulos entre colchetes indicam bytes em vez de texto literal. A canonização corporal relaxada produz Pague<SP>agora<CRLF> para essa linha. O processamento simples do corpo mantém os espaços internos e finais. Uma mudança desse tipo apenas com espaços em branco pode, portanto, ter resultados diferentes nos algoritmos dos dois corpos.
Agora anexe uma nova frase após a mensagem assinada. O processamento relaxado não descarta essa adição substantiva. Assumindo a cobertura de corpo inteiro e nenhuma outra alteração no teste, o corpo canônico difere, assim como o hash corporal esperado. Uma regra de rodapé não pode ser declarada segura apenas porque o remetente usa relaxado/relaxado.
O exemplo explica a normalização esperada, não um incidente capturado ou um teste executado. Na produção, leve em consideração a codificação MIME , os cabeçalhos assinados e o tratamento real do comprimento da assinatura. Duas mensagens podem ser renderizadas de forma idêntica enquanto seus bytes assinados são diferentes.
Localize a transformação antes de alterar a política
Preserve a mensagem original e obtenha amostras de comparação autorizadas antes e depois dos modificadores suspeitos. Use cópias para análise. Compare um teste equivalente com e sem o recurso suspeito de rodapé, reescrita de link ou recodificação, mantendo a mesma rota de transporte.
Se a arquitetura suportada permitir, execute as alterações de conteúdo necessárias antes do estágio final de assinatura apropriado. Se um intermediário assinar novamente, avalie sua nova identidade e alinhamento. Não desative o processamento de gateway de proteção nem enfraqueça a política de domínio apenas para tornar verde um teste de diagnóstico.
Como RFC 6376 §8.2 avisa, um comprimento de corpo l= o limite altera a quantidade de cobertura do corpo canonizado. Não é uma solução alternativa geral para modificação pós-assinatura e pode deixar o conteúdo anexado fora da parte assinada. Revise as implicações de segurança e o suporte do provedor em vez de adicioná-lo para suprimir uma falha.
Prove a correção nos níveis de byte e rota
Retenha a falha original, as configurações de canonização, a comparação controlada e um resultado recebido da rota corrigida. Se a alteração da canonização for a solução suportada escolhida, confirme se a operação de modificação real está dentro das transformações permitidas. Uma nova assinatura relaxada pode tolerar algumas alterações de espaço em branco, permanecendo vulnerável à reescrita substantiva original. Encerre o problema somente quando a mudança observada e o resultado da verificação concordarem.
Verifique o caso extremo de corpo vazio
Sob RFC 6376 §3.4.3, um corpo completamente vazio ou ausente torna-se um CRLF, ou dois octetos, na canonização simples do corpo. Sob RFC 6376 §3.4.4, a canonização do corpo relaxado produz zero octetos para um corpo vazio. Uma ferramenta que faz hash de CRLF em ambos os casos discordará do padrão, mesmo que ambas as mensagens apareçam em branco. Este é um exemplo de especificação, não uma verificação DKIM completa ou um teste de email executado.
Leitura relacionada
Sintaxe de chave pública DKIM : identifique valores DNS truncados ou malformados · Múltiplas assinaturas DKIM : encontre a assinatura de passagem alinhada.