Adskil en gyldig underskrift fra en påtænkt levering
Genafspilning er mulig, når signeret materiale genbruges i en leveringssammenhæng, som den oprindelige underskriver ikke havde til hensigt. Signaturen kan forblive matematisk gyldig, fordi de dækkede bytes ikke er ændret. Det betyder ikke, at underskriveren har godkendt ubegrænset omfordeling, og det gør ikke hver gentagne besked til et angreb. En nyttig analyse spørger, hvilken kontekst der er autentificeret, hvilken part der udførte den videre levering, og hvad en modtager faktisk kan observere.
RFC 6376 afsnit 8.6 diskuterer genafspilning og spam som begrænsninger, der kræver operationel bedømmelse. DKIM2 arbejdet foreslår yderligere rute- og modtagerkontekst i stedet for at behandle en stærkere signaturalgoritme som hele svaret. Denne artikel bruger kerneudkast -09, dateret 1. november 2026. Det er igangværende arbejde, ikke en offentliggjort anti-genspilningsgaranti.
Sammenlign to fiktive leveringskontekster
I en klassisk-DKIM-undervisningscase signerer en tjeneste en besked sendt til en enkelt tiltænkt postkasse. En tredjepart får beskeden og sender uændret signeret indhold til andre modtagere. Forudsat at det signerede materiale og verifikationsbetingelserne forbliver intakte, kan signaturen stadig bekræftes. Problemet er genbrug af den signerede artefakt, ikke nødvendigvis ændring af dens krop eller kompromittering af signeringsnøglen.
Antag for DKIM2 sammenligningen, at den originale seneste signatur beskriver levering til én fiktiv adresse på birch.example . Genbrug af de samme underskrevne konvolutoplysninger, mens du leverer til en anden adresse, skulle mislykkes i udkastets sammenligning af de seneste hop-modtagere. Afsnit 14.4 kræver, at hver faktisk RCPT TO-adresse vises i den signerede rt-værdi, selvom rt kan indeholde yderligere modtagere. Domæner sammenligner forskellen mellem store og små bogstaver; lokale dele kræver nøjagtig matchning i henhold til de specificerede regler.
Dette er en fastlagt sammenligning, ikke et udskrift fra en mailserver. Det isolerer den yderligere kontekst, som forslaget kontrollerer. Den hævder ikke, at blot udgivelse af en DKIM2 nøgle får en eksisterende modtager til at udføre disse sammenligninger, eller at en ældre modtager afviser den genbrugte besked.
Følg ansvaret, når en mellemmand tilføjer et hop
Et genafspilningssystem kan i stedet tilføje et nyt gyldigt hop. Den foreslåede kæde registrerer derefter en underskriftsidentitet forbundet med videre håndtering, underlagt alle kædekontroller. Det er nyttig tilskrivning, men det betegner ikke automatisk handlingen som ondsindet. En legitim speditør tilføjer også leveringsansvar. Modtageren skal stadig evaluere ruteforventninger og mellemmandens omdømme eller rolle.
Afsnit 15.1 beskriver brug af gentagne observationer af den originale Message-Instance m=1 header og body hashes, sammen med mellemliggende tilstedeværelse og det eksploderede flag. Den definerer ikke en universel global database eller en fast volumentærskel, som enhver implementering skal bruge. En modtager med kun én observeret besked kan ikke etablere gentagen levering ved at tælle usete kopier.
Det eksploderede flag rapporterer, at et system sender til flere adresser. Det hjælper med at identificere, hvor fan-out hævdes; det er ikke et bevis på, at fan-out var velkommen. Bevar, hvilken signatur der bærer den, og om den adfærd var forventet for ruten. Et dashboard, der reducerer flaget til "afspil sikkert", ville kassere den beslutningskontekst, som udkastet har til hensigt at afsløre.
Hold legitim duplikering i sammenligningen
En stor modtagetjeneste kan støde på identiske beskeder fra almindelig massedistribution. Flere modtagere kan også videresende kopier, der samles igen på den samme tjeneste. Protokolforsøg kan lejlighedsvis producere dubletter. Udkastet diskuterer udtrykkeligt disse sondringer. At tælle lige store hashes er derfor et input til vurdering, ikke en selvstændig dom om, at enhver anden kopi skal blokeres.
En original laboratorieplan bør indeholde mindst fire tilfælde: direkte tilsigtet distribution, videre omfordeling med en ikke-erklæret modtagerændring, en korrekt erklæret mellemliggende fan-out og legitim rekonvergens. Hold beskedindholdet fast, hvor det er muligt, så forklaringen isolerer rutekonteksten. Varier derefter modtagerens synlighed: en kopi, flere kopier og ufuldstændige historiske observationer. Det er foreslåede tilfælde, ikke eksperimenter, der er gennemført for denne artikel.
Bevar den originale urkontekst
Afsnit 14.3 afviser fuld verifikationsberettigelse, når en underskrift er mere end fjorten dage ældre end SMTP accept eller mere end én dag i fremtiden i forhold til accept. Udkastet kræver nøjagtig viden om denne accepttid. Gentjekning af en arkiveret besked i forhold til dagens ur kan besvare et andet spørgsmål end at kontrollere, hvad der var gyldigt, da det ankom.
En retrospektiv undersøgelse har derfor brug for de originale ankomstmetadata, ikke kun en gemt beskedfil. Bevar den observerede tidskilde, tidsstempelværdier, relevant DNS /nøglekontekst og verifikatorversion. En senere manglende nøgle eller ændret registrering fastslår heller ikke, hvad den oprindelige verifikator så. Adskil "kan ikke gengive historisk verifikation" fra "den originale signatur var ugyldig", medmindre beviserne understøtter den stærkere konklusion.
Undgå spekulative replay-kontroller
Udkastets valgfri nonce er tilgængelig for en skabers brug, såsom at korrelere senere leveringsstatusoplysninger. Det er ikke i sig selv en standardiseret engangshåndhævelsestjeneste. Tilsvarende tidligere auth= sender-policy discussion vedrører et særskilt forslag og spørgsmål om blandet udbredelse. Det må ikke præsenteres som fastlagt kerne -09-syntaks eller som bevis på, at enhver speditør reklamerer for kompatibel adfærd.
Behandl en implementerings replay-påstand som et afgrænset spørgsmål: hvilke input bevares, hvor længe, på tværs af hvilke modtagende noder, med hvilke falsk-positive kontroller? Bed om bevis for gentagne observationer og ruteanalyse, ikke kun en vellykket kryptografisk kontrol. Privatlivs- og lagringsimplikationer hører hjemme i den gennemgang, fordi detektionskontekst kan akkumulere leveringsmetadata på tværs af meddelelser.
Angiv, hvad denne sammenligning gør og ikke fastslår
Den nøjagtige kommission er: Sammenlign en klassiker DKIM genspil scenarie med udkastets specifikke foreslåede detektionsmodel. Den fiktive sammenligning ovenfor forklarer konvolutbinding, mellemliggende tilskrivning, gentagne observationer af originale forekomster, timing og synlighedsgrænser. Det er dokumentarisk analyse, ikke en målt detektionshastighed, et reproduceret angreb eller et resultat af modtagerens interoperabilitet.
Faktiske sager, versionerede implementeringer, bevarede verifikator-output og specialistaccept forbliver åbne. En sikkerhedsejer skal godkende ethvert fremtidigt kontrolleret eksperiment uden uopfordret trafik eller ændringer i produktionspolitikken. Site-, visuelle- og publikationsporte forbliver også fremragende. Den forsvarlige konklusion er, at forslaget tilføjer kontekst til at opdage og tilskrive genbrug, mens den faktiske effektivitet afhænger af implementering, observationer og modtagerens vurdering.