Separare una firma valida da una consegna prevista
La riproduzione è possibile quando il materiale firmato viene riutilizzato in un contesto di consegna non previsto dal firmatario originale. La firma può rimanere matematicamente valida perché i byte coperti non sono cambiati. Ciò non significa che il firmatario abbia autorizzato una ridistribuzione illimitata e non rende ogni messaggio ripetuto un attacco. Un'analisi utile chiede quale contesto è autenticato, quale parte ha eseguito la consegna successiva e cosa può effettivamente osservare un destinatario.
RFC 6376 sezione 8.6 tratta la riproduzione e lo spam come limitazioni che richiedono un giudizio operativo. Il lavoro DKIM2 propone percorsi aggiuntivi e contesto del destinatario piuttosto che considerare un algoritmo di firma più forte come la risposta completa. Questo articolo utilizza progetto di base -09, datato 1 novembre 2026. Si tratta di lavori in corso, non di una garanzia anti-replay pubblicata.
Confronta due contesti di consegna immaginari
In un caso didattico DKIM classico, un servizio firma un messaggio inviato a una singola casella di posta prevista. Una terza parte ottiene il messaggio e invia il contenuto firmato invariato ad altri destinatari. Supponendo che il materiale firmato e le condizioni di verifica rimangano intatti, la firma può ancora essere verificata. Il problema è il riutilizzo dell'artefatto firmato, non necessariamente l'alterazione del suo corpo o la compromissione della chiave di firma.
Per il confronto DKIM2 , supponiamo che l'ultima firma originale descriva la consegna a un indirizzo fittizio su birch.example . Il riutilizzo delle stesse informazioni sulla busta firmata durante la consegna a un indirizzo diverso dovrebbe fallire nel confronto dell'ultimo salto dei destinatari della bozza. La sezione 14.4 richiede che ogni indirizzo RCPT TO effettivo appaia nel valore rt firmato, sebbene rt possa contenere destinatari aggiuntivi. I domini vengono confrontati senza distinzione tra maiuscole e minuscole; le parti locali richiedono una corrispondenza esatta in base alle regole specificate.
Si tratta di un confronto previsto, non di una trascrizione da un server di posta. Isola il contesto aggiuntivo controllato dalla proposta. Non afferma che la semplice pubblicazione di una chiave DKIM2 faccia sì che un ricevitore esistente esegua tali confronti o che un ricevitore legacy rifiuti il messaggio riutilizzato.
Segui la responsabilità quando un intermediario aggiunge un salto
Un sistema di riproduzione potrebbe invece aggiungere un nuovo hop valido. La catena proposta registra quindi un'identità di firma associata alla lavorazione successiva, soggetta a tutti i controlli della catena. Si tratta di un'attribuzione utile, ma non etichetta automaticamente l'azione dannosa. Uno spedizioniere legittimo aggiunge anche la responsabilità della consegna. Il destinatario deve ancora valutare le aspettative sul percorso e la reputazione o il ruolo dell'intermediario.
Sezione 15.1 descrive l'utilizzo di osservazioni ripetute dell'intestazione e degli hash del corpo dell'istanza del messaggio originale m=1 , insieme alla presenza dell'intermediario e al flag esploso. Non definisce un database globale universale o una soglia di volume fissa che ogni implementazione deve utilizzare. Un destinatario con un solo messaggio osservato non può stabilire una consegna ripetuta contando le copie non viste.
Il flag esploso segnala che un sistema sta inviando a più indirizzi. Aiuta a identificare dove viene richiesto il fan-out; non è un certificato che il fan-out sia stato gradito. Conserva quale firma lo trasporta e se tale comportamento era previsto per il percorso. Una dashboard che riduce il flag a “replay sicuro” scarterebbe il contesto decisionale che la bozza intende esporre.
Mantenere la legittima duplicazione nel confronto
Un servizio di ricezione di grandi dimensioni può incontrare messaggi identici provenienti dalla normale distribuzione in massa. Più destinatari possono anche inoltrare copie che riconvergono allo stesso servizio. I tentativi di protocollo possono occasionalmente produrre duplicati. Il progetto discute espressamente queste distinzioni. Il conteggio degli hash uguali è quindi un input per la valutazione, non un verdetto autonomo secondo cui qualsiasi seconda copia deve essere bloccata.
Un piano di laboratorio originale dovrebbe contenere almeno quattro casi: distribuzione diretta prevista, ridistribuzione successiva con un cambio di destinatario non dichiarato, un fan-out intermedio adeguatamente dichiarato e riconvergenza legittima. Mantieni fisso il contenuto del messaggio ove possibile in modo che la spiegazione isoli il contesto del percorso. Quindi variare la visibilità del destinatario: una copia, più copie e osservazioni storiche incomplete. Questi sono casi proposti, non esperimenti completati per questo articolo.
Conserva il contesto dell'orologio originale
Sezione 14.3 rifiuta l'idoneità alla verifica completa quando una firma è più vecchia di più di quattordici giorni rispetto all'accettazione SMTP o più di un giorno nel futuro rispetto all'accettazione. La bozza richiede una conoscenza precisa di tale momento di accettazione. Ricontrollare un messaggio archiviato rispetto all'orologio odierno può rispondere a una domanda diversa dal verificare cosa era valido quando è arrivato.
Un'indagine retrospettiva necessita quindi dei metadati di arrivo originali, non solo di un file di messaggi salvato. Conserva l'origine temporale osservata, i valori di timestamp, il contesto DNS /chiave pertinente e la versione del verificatore. Inoltre, una chiave mancante o un record modificato successivamente non stabiliscono ciò che ha visto il verificatore originale. Separare “impossibile riprodurre la verifica storica” da “la firma originale non era valida” a meno che le prove non supportino la conclusione più forte.
Evita controlli di riproduzione speculativi
Il nonce facoltativo della bozza è disponibile per gli usi del creatore, come la correlazione di informazioni successive sullo stato della consegna. Di per sé non è un servizio di controllo standardizzato monouso. Allo stesso modo, prima auth= sender-policy discussion riguarda una proposta separata e questioni relative all'impiego misto. Non deve essere presentato come una sintassi core -09 consolidata o come prova che ogni spedizioniere pubblicizza un comportamento compatibile.
Trattate la richiesta di replay di un'implementazione come una domanda limitata: quali input vengono conservati, per quanto tempo, attraverso quali nodi riceventi, con quali controlli falsi positivi? Richiedi prove di osservazioni ripetute e analisi del percorso, non solo di un controllo crittografico riuscito. Le implicazioni sulla privacy e sull'archiviazione rientrano in tale revisione perché il contesto di rilevamento può accumulare metadati di consegna tra i messaggi.
Indica cosa stabilisce e cosa non stabilisce questo confronto
La commissione esatta è: confronta un classico DKIM riprodurre lo scenario con il modello di rilevamento proposto specifico nella bozza. Il confronto fittizio di cui sopra spiega la rilegatura della busta, l'attribuzione dell'intermediario, le osservazioni ripetute dell'istanza originale, i tempi e i limiti di visibilità. Si tratta di un'analisi documentale, non di un tasso di rilevamento misurato, di un attacco riprodotto o di un risultato di interoperabilità del ricevitore.
I casi reali, le implementazioni con versione, i risultati del verificatore conservati e l'accettazione specialistica rimangono aperti. Il proprietario della sicurezza deve approvare qualsiasi futuro esperimento controllato, senza traffico non richiesto o modifiche alla politica di produzione. Anche i cancelli del sito, della visualizzazione e della pubblicazione rimangono eccezionali. La conclusione difendibile è che la proposta aggiunge contesto per individuare e attribuire il riutilizzo, mentre l’effettiva efficacia dipende dall’implementazione, dalle osservazioni e dal giudizio del destinatario.