Defina a questão antes de escolher o software
Um laboratório DKIM2 deve resolver uma incerteza estreita, como se duas implementações reconstroem a mesma mensagem modificada ou classificam uma incompatibilidade de envelope de forma consistente. “Ver se DKIM2 funciona” é muito amplo para produzir um resultado interpretável. Escreva uma pergunta, um escopo de versão e um critério de aprovação/reprovação antes de selecionar um equipamento. Mantenha uma decisão separada sobre se qualquer resultado observado justificaria mais experimentação, e não a adoção automática da produção.
Conforme revisado em 8 de novembro de 2026, especificação principal-09 é um Internet-Draft ativo datado de 1º de novembro, enquanto DNS-03 é datado de 2 de novembro e BCP-01 é datado de 9 de setembro. Fixe todos os documentos dos quais um caso depende. Um rótulo de software dizendo “ DKIM2 ” é insuficiente se seu analisador seguir uma revisão anterior ou um perfil separado com cobertura diferente.
Distinguir uma implementação relatada de uma compilação selecionada
O Rascunho do perfil de implantação Milter -08 relata DarkChain e DarkChains como código beta para esse perfil individual. Sua seção de status rejeita explicitamente a verificação de informações fornecidas pelos contribuidores e o endosso IETF . Essa é uma pista para um avaliador, e não uma recomendação testada de forma independente. As funções limitadas e ampliadas do perfil não devem ser silenciosamente equiparadas a todos os requisitos da versão preliminar do WG.
Antes de executar o software, um plano aprovado deve identificar a origem do repositório, o commit ou lançamento imutável, a configuração da compilação, as bibliotecas criptográficas e a cobertura reivindicada do protocolo/perfil. Registre os recursos não suportados como não suportados, e não como testes com falha de uma promessa de implementação diferente. A instalação e a execução são ações operacionais separadas; nenhuma transação de verificação de origem, construção, instalação ou correio foi realizada para este pacote.
Construa um pequeno conjunto de caixas com contrastes significativos
Comece com uma linha de base DKIM clássica existente para garantir que o equipamento de teste não confunda o tratamento de correspondência comum com comportamento experimental. Em seguida, especifique um caminho DKIM2 fictício inalterado, uma modificação de rodapé declarada e uma alteração não declarada. Mantenha os bytes da mensagem original e modificada no eventual dispositivo controlado. Se um caso alterar diversas variáveis ao mesmo tempo, uma falha poderá revelar pouco sobre o mecanismo que está sendo investigado.
Adicione uma incompatibilidade de envelope, uma receita de corpo nulo e uma falha temporária DNS . Sob núcleo -09 seções 13–14, estes não são casos intercambiáveis de “correspondência inválida”. Uma receita de corpo nula impede a verificação do estado anterior do corpo; um problema de pesquisa de chave temporária tem uma categoria de resultado diferente da verificação concluída que falha. Preserve o diagnóstico exato e a entrada ausente.
Um caso de carimbo de data/hora deve reter o tempo de aceitação SMTP original. Um caso relacionado à repetição deve distinguir distribuição pretendida, entrega subsequente inesperada e observações repetidas da instância original. Marque cada resultado esperado como uma hipótese até que o software realmente produza uma observação. Este pacote fornece um design de caso original, mensagens de amostra não executadas ou uma tabela de resultados com passes fabricados.
Preservar os insumos necessários para a reprodução
Para cada execução autorizada, registre um identificador de caso opaco, hash de byte de mensagem, remetente do envelope e destinatários, tempo de aceitação, versões do assinante e do verificador, instantâneo da chave e registros de políticas relevantes. Armazene mensagens originais e dados privados somente de acordo com o plano de acesso e retenção aprovado. Um hash identifica um artefato; ele não reconstrói bytes ausentes nem prova que um diagnóstico veio do programa reivindicado.
Separe o resultado esperado, o resultado observado e a interpretação do revisor. Mantenha resultados intermediários para falhas de candidatos: reconstrução de receita, verificação de assinatura, verificações de cadeia e correspondência de domínio. Se o chicote nunca alcançou a verificação pretendida porque a análise falhou primeiro, registre esse fato. Não relate um recurso downstream testado apenas porque a execução geral retornou um erro.
Use uma segunda implementação somente depois de verificar se ela tem como alvo o mesmo comportamento fixado. A concordância entre dois programas é útil, mas não é uma prova absoluta de correção; eles podem compartilhar código ou a mesma suposição equivocada. Da mesma forma, o desacordo não é automaticamente um defeito se alguém implementar um rascunho mais antigo. A comparação de versões fica ao lado do resultado, não escondida em uma nota de rodapé.
Revise a segurança e a privacidade antes da execução
As receitas podem preservar o material removido da mensagem visível. O conteúdo sintético é, portanto, preferível para um laboratório inicial: um teste de redação reversível não deve reintroduzir um segredo real no arquivo de evidências. Use destinatários controlados, chaves de assinatura isoladas e um namespace cujo proprietário aprovou o experimento. Defina limites que evitem entregas não intencionais, loops de encaminhamento ou tráfego de repetição não solicitado.
Especifique condições de parada para e-mails enviados inexplicáveis, expansão inesperada de destinatários, impacto DNS de produção ou conteúdo confidencial que aparece nos logs. Não desative a autenticação ou filtragem estabelecida simplesmente para obter um sucesso experimental limpo. A limpeza deve cobrir assinaturas de teste, registros, artefatos e credenciais, com necessidades de retenção documentadas separadamente. Um experimento não está completo apenas porque a última mensagem foi entregue.
Mantenha os relatórios e as conclusões de implantação modestos
O Rascunho BCP-01 discute a operação mista DKIM1 / DKIM2 e deixa aspectos de DMARC integração aberta. Publicado RFC 9989 ainda define seus próprios mecanismos de autenticação. Um resultado de laboratório não pode alterar essa especificação ou estabelecer que cada receptor externo interpreta a mensagem experimental da mesma maneira.
De forma similar, RFC 9990 relatórios agregados e RFC 9991 relatórios de falhas não são transportes genéricos para quaisquer campos experimentais que um desenvolvedor gostaria de coletar. Mantenha os diagnósticos de laboratório locais distintos dos formatos de relatório suportados. Um relatório externo ausente não é prova de rejeição e um relatório recebido não expõe automaticamente o caminho completo de verificação DKIM2 .
Declare claramente as evidências inacabadas
A comissão exata é: Registrar o escopo do laboratório, versões, casos, resultados e a fronteira entre experimento e produção. O escopo, as versões atuais dos documentos e os casos propostos são mantidos aqui. Pinos de software, execuções reais, resultados observados, verificações de reprodutibilidade e limpeza verificada estão ausentes. A porta da evidência original, portanto, permanece aberta; nenhum sucesso de laboratório, garantia de segurança ou capacidade EmailAuth é reivindicado.
Um proprietário técnico deve aprovar a interpretação do protocolo, um proprietário de segurança deve autorizar qualquer experimento real e um revisor independente deve avaliar as evidências resultantes antes de uma decisão do próximo estágio. A aplicabilidade da produção, a aceitação visual e do site e a permissão de publicação permanecem como portas separadas. Um bom laboratório produz uma resposta limitada que outro engenheiro pode desafiar, e não um novo requisito de produção inferido de um padrão inacabado.