Separe uma assinatura válida de uma entrega pretendida
A reprodução é possível quando o material assinado é reutilizado num contexto de entrega que o signatário original não pretendia. A assinatura pode permanecer matematicamente válida porque os bytes cobertos não foram alterados. Isso não significa que o signatário autorizou a redistribuição ilimitada e não torna cada mensagem repetida um ataque. Uma análise útil pergunta qual contexto é autenticado, qual parte realizou a entrega subsequente e o que um destinatário pode realmente observar.
RFC 6376 seção 8.6 discute replay e spam como limitações que exigem julgamento operacional. O trabalho DKIM2 propõe rota adicional e contexto de destinatário, em vez de tratar um algoritmo de assinatura mais forte como a resposta completa. Este artigo usa rascunho principal -09, datado de 1º de novembro de 2026. É um trabalho em andamento, não uma garantia anti-replay publicada.
Compare dois contextos de entrega fictícios
Em um caso de ensino DKIM clássico, um serviço assina uma mensagem enviada para uma única caixa de correio pretendida. Um terceiro obtém a mensagem e envia o conteúdo assinado inalterado para outros destinatários. Supondo que o material assinado e as condições de verificação permaneçam intactos, a assinatura ainda poderá ser verificada. O problema é a reutilização desse artefato assinado, não necessariamente a alteração do seu corpo ou o comprometimento da chave de assinatura.
Para a comparação DKIM2 , suponha que a última assinatura original descreva a entrega para um endereço fictício em birch.example . A reutilização das mesmas informações do envelope assinado durante a entrega em um endereço diferente deve falhar na comparação do destinatário do último salto do rascunho. A Seção 14.4 exige que cada endereço RCPT TO real apareça no valor rt assinado, embora rt possa conter destinatários adicionais. Os domínios são comparados sem distinção entre maiúsculas e minúsculas; as partes locais exigem correspondência exata de acordo com as regras especificadas.
Esta é uma comparação estipulada, não uma transcrição de um servidor de correio. Isola o contexto adicional que a proposta verifica. Ele não afirma que a simples publicação de uma chave DKIM2 faça com que um receptor existente realize essas comparações, ou que um receptor legado rejeite a mensagem reutilizada.
Siga a responsabilidade quando um intermediário adiciona um salto
Em vez disso, um sistema de reprodução pode adicionar um novo salto válido. A cadeia proposta regista então uma identidade de assinatura associada ao tratamento posterior, sujeita a todas as verificações da cadeia. Essa é uma atribuição útil, mas não rotula automaticamente a ação como maliciosa. Um despachante legítimo também adiciona responsabilidade de entrega. O receptor ainda precisa avaliar as expectativas da rota e a reputação ou papel do intermediário.
Seção 15.1 descreve o uso de observações repetidas do cabeçalho Message-Instance m=1 original e hashes de corpo, juntamente com a presença intermediária e o sinalizador explodido. Ele não define um banco de dados global universal ou um limite de volume fixo que toda implementação deve usar. Um receptor com apenas uma mensagem observada não pode estabelecer entregas repetidas contando cópias não vistas.
O sinalizador explodido informa que um sistema está enviando para vários endereços. Ajuda a identificar onde a distribuição é reivindicada; não é um certificado de que o fan-out foi bem-vindo. Preservar qual assinatura o carrega e se esse comportamento era esperado para a rota. Um painel que reduza o sinalizador para “reprodução segura” descartaria o contexto de decisão que o rascunho pretende expor.
Mantenha a duplicação legítima na comparação
Um grande serviço de recebimento pode encontrar mensagens idênticas provenientes de distribuição em massa comum. Vários destinatários também poderão encaminhar cópias que reconverjam no mesmo serviço. As novas tentativas de protocolo podem ocasionalmente produzir duplicatas. O projeto discute expressamente essas distinções. A contagem de hashes iguais é, portanto, uma entrada para a avaliação, e não um veredicto independente de que qualquer segunda cópia deve ser bloqueada.
Um plano de laboratório original deve conter pelo menos quatro casos: distribuição direta pretendida, redistribuição subsequente com mudança de destinatário não declarada, distribuição intermediária devidamente declarada e reconvergência legítima. Mantenha o conteúdo da mensagem fixo sempre que possível para que a explicação isole o contexto da rota. Depois varie a visibilidade do receptor: uma cópia, várias cópias e observações históricas incompletas. Esses são casos propostos, não experimentos concluídos para este artigo.
Preservar o contexto original do relógio
Seção 14.3 rejeita a elegibilidade para verificação completa quando qualquer assinatura tiver mais de quatorze dias antes da aceitação SMTP ou mais de um dia no futuro em relação à aceitação. O rascunho requer conhecimento preciso desse tempo de aceitação. Verificar novamente uma mensagem arquivada em relação ao relógio de hoje pode responder a uma pergunta diferente de verificar o que era válido quando ela chegou.
Uma investigação retrospectiva, portanto, precisa dos metadados originais de chegada, e não apenas de um arquivo de mensagem salvo. Retenha a fonte de tempo observada, os valores de carimbo de data/hora, o contexto relevante DNS /chave e a versão do verificador. Uma chave perdida posteriormente ou um registro alterado também não estabelece o que o verificador original viu. Separe “não é possível reproduzir a verificação histórica” de “a assinatura original era inválida”, a menos que a evidência apoie a conclusão mais forte.
Evite controles de repetição especulativos
O nonce opcional do rascunho está disponível para uso do criador, como correlacionar informações posteriores de status de entrega. Não é, por si só, um serviço padronizado de aplicação única. Da mesma forma, anteriormente auth= sender-policy discussion diz respeito a uma proposta separada e a questões de utilização mista. Não deve ser apresentado como sintaxe core -09 estabelecida ou como prova de que todo encaminhador anuncia comportamento compatível.
Trate a reivindicação de repetição de uma implementação como uma questão limitada: quais entradas são retidas, por quanto tempo, em quais nós receptores, com quais controles de falsos positivos? Peça evidências de observações repetidas e análises de rotas, não apenas de uma verificação criptográfica bem-sucedida. As implicações de privacidade e armazenamento pertencem a essa revisão porque o contexto de detecção pode acumular metadados de entrega nas mensagens.
Indique o que esta comparação estabelece e o que não estabelece
A comissão exata é: Compare um clássico DKIM cenário de repetição com o modelo de detecção proposto específico do rascunho. A comparação fictícia acima explica a encadernação de envelopes, atribuição intermediária, observações repetidas da instância original, tempo e limites de visibilidade. É uma análise documental, não uma taxa de detecção medida, um ataque reproduzido ou um resultado de interoperabilidade do receptor.
Casos reais, implementações versionadas, resultados retidos do verificador e aceitação de especialistas permanecem em aberto. O proprietário da segurança deve aprovar qualquer experimento controlado futuro, sem tráfego não solicitado ou alterações na política de produção. As portas do site, visuais e de publicação também permanecem pendentes. A conclusão defensável é que a proposta acrescenta contexto para detectar e atribuir reutilização, enquanto a eficácia real depende da implementação, das observações e do julgamento do receptor.