En forsinket besked kan fejle en tidsrelateret DKIM tjek selv når ingen har ændret indholdet. Diagnostiser signaturens tidsfelter og verifikatorens beslutning, før du roterer nøgler eller giver skylden for en gateway. Meddelelsen Datoheader, signaturoprettelsestidspunkt og modtagerens ankomsttid beskriver forskellige hændelser.
Læs t og x rigtigt
I en DKIM-Signature header, t er signaturens oprettelsestidsstempel, og x er det absolutte udløbstidsstempel, begge udtrykt som sekunder siden Unix-epoken i UTC. RFC 6376 afsnit 3.5 markerer formelt begge tags ANBEFALET. De kan være fraværende, men denne godtgørelse må ikke forveksles med et VALGFRI kravniveau. x-værdien er ikke en varighed, der skal lægges til det aktuelle tidspunkt. Når begge er til stede, skal x være større end t. Manglende t betyder et ukendt oprettelsestidspunkt; manglende x betyder, at ingen signaturudløb er angivet af det tag. DNS TTL er et andet koncept og sætter ikke x. t-tagget i en DNS DKIM nøglepost er et sæt flag, ikke dette signaturtidsstempel.
RFC 6376 afsnit 3.5 tillader implementeringer at ignorere en signatur med et fremtidigt tidsstempel. Det tillader også, at en signatur betragtes som ugyldig, når verifikationen er udløbet. Til sammenligningen skal verifikationstidspunktet være det tidspunkt, hvor verifikatorens administrative domæne første gang modtog meddelelsen, hvis det er pålideligt tilgængeligt, ellers det aktuelle tidspunkt. Dette efterlader implementeringsvalg, som en hændelsespost skal skelne fra en universel afvisningsregel.
Byg en tidslinje med tre ur
Indfang den nøjagtige signatur og rå modtagerbevis. Konverter t og x til læsbar UTC, mens du beholder de originale heltal. Registrer underskriverens ur, første pålidelige modtagelsestidspunkt på det verificerende administrative domæne og tidspunktet for den diagnostiske genkontrol. Tilføj relevante køforsinkelser. Brug ikke en upålidelig Dato-header som bevis på, hvornår et system modtog en besked.
Illustrativt scenario: en signatur oprettes kl. 10:00 UTC med udløb kl. 12:00 UTC. Beskeden når frem til modtageren kl. 11:50, men undersøges igen kl. 12:15. En verifikator med pålidelige oplysninger om første kvittering kan bruge 11:50; et senere selvstændigt værktøj har muligvis kun sin nuværende tid. Forskellige resultater viser ikke i sig selv beskadiget indhold. Eksemplet beskriver protokollens tidsforskel, ikke et løfte om en bestemt udbyder.
Skelne urskævhed fra et stramt vindue
Hvis nyligt udsendte signaturer ser ud til at komme fra fremtiden, skal du inspicere underskriverens ursynkronisering og tidsstemplingsgenerering. Hvis værdierne er fornuftige, men der kommer mail regelmæssigt efter x, skal du undersøge kødannelse, prøve ruter igen og det valgte gyldighedsinterval. RFC 6376 foreskriver ikke en universel ideel levetid. Indstil en ved at bruge dine faktiske leveringskrav og understøttede underskriverindstillinger.
Et kort udløb er ikke et komplet genspilsforsvar. RFC 6376 afsnit 3.5 siger udtrykkeligt, at x ikke er beregnet til det formål. Det erstatter heller ikke nøglebeskyttelse eller overvågning af misbrug. Fjernelse af en gammel offentlig nøgle kan gøre forsinket verifikation umulig uafhængigt af x, så koordiner udløbspolitikken med nøgleopbevaring.
Afprøv reparationen og behold udmærkelsen
Efter at have rettet ur- eller politikkonfigurationen, send nye kontrollerede meddelelser gennem de langsomme og normale stier. Bekræft deres tidsstempler og modtagerresultater. Opbevar beviser, der viser, om den tidligere fejl vedrørte tid, nøgletilgængelighed, kropshash eller signaturbekræftelse. Rediger ikke t eller x på en eksisterende signeret besked: disse værdier er dækket af signaturen, og det er ikke en reparation at ændre dem.
Arbejd et epokeeksempel
Syntetiske værdier t=1794132000 og x=1794139200 svarer til 8. november 2026 kl. 10.00 UTC og 12.00 UTC. Deres forskel er 7.200 sekunder eller to timer, men selve x forbliver et absolut tidsstempel. En pålidelig første kvittering kl. 11:50 er før udløb; et selvstændigt gentjek kl. 12:15 er efter det. Verifikatorens valgte referencetid og tilladte udløbshåndtering forklarer den mulige forskel. Derimod overtræder x=t den påkrævede rækkefølge, når begge tags er til stede. Disse værdier illustrerer aritmetiske og protokolregler, ikke en udført mailtest.
Før en kompakt undersøgelsesjournal
Brug dette foreslåede arbejdsark til ruten under gennemgang. Det er en planlægningshjælp, ikke bevis på en udført test.
- Signatur: originale t- og x-værdier, deres UTC-konverteringer, d og vælger.
- Tidslinje: underskriverur, først pålidelig kvittering og senere gentjek, med tidszoner.
- Find: fremtidigt tidsstempel, udløbet signatur, utilgængelig nøgle eller en anden bekræftelsesfejl.
- Reparation: Understøttet ur- eller levetidsændring og resultater fra nyligt afsendte normale og forsinkede tests.