En header-analysator kan være uenig med den originale modtager, uden at nogen af observationerne er fremstillet. De kan have evalueret forskellige meddelelsesbytes, forskellige DNS nøgletilstande eller forskellige bekræftelsespolitikker på forskellige tidspunkter. Bevar det originale bevis og sammenlign betingelserne, før du beslutter, hvad uenigheden betyder.
Et vist historisk resultat og en ny kryptografisk verifikation er forskellige operationer. Nogle værktøjer opsummerer Authentication-Results allerede findes i prøven. Andre henter nøgler og verificerer den aktuelle prøve. Bestem, hvilken operation analysatoren udfører, før dens output sammenlignes med det modtagende systems resultat.
Bevar originalen og identificer grænsen
Eksporter den rå meddelelse ved hjælp af en metode, der bevarer meddelelsesrepræsentationen. Behold en uredigeret original og beregn en filhash til senere sammenligning. Registrer afhentningsmetode, leveringstid og kildepostkasse. En filhash kan vise, at to eksporterede filer er forskellige; den forklarer ikke i sig selv, hvilken forskel der har betydning for DKIM.
Identificer de modtagergenererede Authentication-Results og dets betroede authserv-id. Headere leveret af en ikke-pålidelig afsender er ikke autoritativ modtagerbevis. RFC 8601 §7.1 beskriver denne tillidsgrænse. Bestem også, om modtageren har evalueret beskeden, før en senere gateway eller eksportproces ændrede den.
Sammenlign analysatorens faktiske input
For en almindelig helkropssignatur udelader en kopieret overskriftsblok den tekst, der er nødvendig for at genberegne sin DKIM kropshash. Det specielle tilfælde l=0 hasheser nul kropsoktetter og giver ingen kropsintegritetsbeskyttelse; det giver ikke afkald på overskrift, nøgle eller andre verifikationstjek. Se RFC 6376 §3.5, §3.7 og §5.4.1. Indsættelse af tekst kan også ændre foldning eller linjeafslutninger. Hvis analysatoren mangler den fulde meddelelse, kan den fortolke rapporterede resultater i stedet for uafhængigt at verificere hele signaturen. Dens grænseflademærke alene afgør ikke dette spørgsmål.
Sammenlign de fulde prøver, når de er tilgængelige. DKIM kanonisering i RFC 6376 §3.4 tolererer specificerede transformationer, ikke vilkårlig ækvivalens af gengivet indhold. En anden fil-hash betyder ikke automatisk en DKIM fejl, da nogle byteændringer kan normalisere sig; en identisk filhash etablerer kun identiske leverede bytes, ikke identiske DNS eller politikkontekst.
Tjek hvad der er ændret i DNS og tid
Læs d og s for hver signatur og noter de vigtigste svar, der blev observeret under den senere kontrol. Den originale nøgle kan være blevet trukket tilbage, tilbagekaldt eller udskiftet siden levering. RFC 6376 §6.1.2 verifikation er afhængig af at hente passende verifikationsmateriale, så et historisk pass kan eksistere side om side med et senere no-key resultat.
Undersøg også enhver signaturudløbsværdi x-værdi og verifikatorens tidshåndtering. Et senere værktøj kan evaluere efter signaturens udløb. RFC 6376 §6.1.1 tillader verifikatorer at ignorere udløbne signaturer; et specifikt værktøjs adfærd skal kontrolleres snarere end antages. Mærk ikke dette resultat som bevis på, at signaturen var udløbet, da modtageren oprindeligt behandlede den. Hvor det gamle DNS svar ikke er tilgængeligt, angiv, at den historiske kryptografiske beregning ikke kan gengives fuldt ud fra aktuelle beviser.
Arbejd gennem to kontrasterende eksempler
Illustrerende eksempel et: modtagerrapporterne passerer for vælger gammel1 om mandagen, og afsenderen trækker sig gammel1 fredag. Et gentjek på lørdag viser ingen nøgle. Det senere resultat sletter ikke mandagens betroede observation, selvom uafhængig gengivelse af mandagens verifikation kræver de relevante historiske input.
Illustrativt eksempel to: den oprindelige modtagne fil bekræfter, mens en indsat kopi mislykkes efter en sidefod eller MIME serialiseringsændringer. Sammenlign den dækkede repræsentation og det punkt, hvor ændringen skete. Problemet kan ligge i prøvehåndtering snarere end afsenderens originale signatur. Disse er sammenligningsarmaturer, ikke påstande om en rigtig analysator eller lejer.
Rapporter uenigheden præcist
Opret en sammenligningspost, der indeholder prøve-hash, indsamlingsmetoder, observationstider, d og s, nøglesvar, verifikatorversioner, rapporterede resultater og kendte politiske forskelle. Undersøg flere signaturer separat, da værktøjer kan fremhæve forskellige. Hold DKIM gyldigheden adskilt fra DMARC justering og endelig levering.
Konkluder kun, hvad beviserne understøtter: forskellige bytes, ændret DNS , forløbet gyldighed, forskellig valgt signatur eller uafklaret kontekst. Bevar usikkerheden, når de originale input mangler. En senere analysator er nyttigt diagnostisk bevis, men det er ikke en tidsmaskine og bør ikke stille overskrive det pålidelige originale modtagerresultat.
Beviser nødvendig for den næste beslutning
Brug en sammenligningsrække for hver signatur: original prøvehash/tid, senere prøvehash/tid, d/s, observeret nøgle, x hvis den er til stede, værktøj/version, operation (rapportparsing eller verifikation), resultat og resterende mellemrum. Identiske prøvebytes med utilgængelig historisk DNS efterlader et nøgletilstandshul, ikke et bevis på, at begge værktøjer er forkerte. Hvis prøverne er forskellige, skal du sammenligne den dækkede kanoniske repræsentation, før du tildeler kausalitet.