En hodeanalysator kan være uenig med den originale mottakeren uten at noen av observasjonene er fabrikkert. De kan ha evaluert forskjellige meldingsbyte, forskjellige DNS nøkkeltilstander eller forskjellige bekreftelsespolicyer til forskjellige tider. Ta vare på det opprinnelige beviset og sammenlign betingelsene før du bestemmer deg for hva uenigheten betyr.
Et vist historisk resultat og en ny kryptografisk verifisering er forskjellige operasjoner. Noen verktøy oppsummerer Authentication-Results allerede til stede i prøven. Andre henter nøkler og verifiserer gjeldende prøve. Fastslå hvilken operasjon analysatoren utfører før du sammenligner utgangen med mottakssystemets resultat.
Ta vare på originalen og identifiser grensen
Eksporter råmeldingen ved å bruke en metode som bevarer meldingsrepresentasjonen. Behold en uredigert original og beregn en filhash for senere sammenligning. Registrer innsamlingsmetode, leveringstid og kildepostkasse. En filhash kan vise at to eksporterte filer er forskjellige; den forklarer ikke i seg selv hvilken forskjell som betyr noe for DKIM.
Identifiser de mottakergenererte Authentication-Results og dens pålitelige authserv-ID. Overskrifter levert av en ikke-klarert avsender er ikke autoritativ mottakerbevis. RFC 8601 §7.1 beskriver denne tillitsgrensen. Bestem også om mottakeren evaluerte meldingen før en senere gateway eller eksportprosess endret den.
Sammenlign analysatorens faktiske innganger
For en vanlig fullkroppssignatur utelater en kopiert overskriftsblokk hovedteksten som trengs for å beregne DKIM på nytt kroppshasj. Spesialtilfellet l=0 hasheser null kroppsoktetter og gir ingen kroppsintegritetsbeskyttelse; den gir ikke avkall på overskrift, nøkkel eller andre verifikasjonskontroller. Se RFC 6376 §3.5, §3.7 og §5.4.1. Å lime inn tekst kan også endre bretting eller linjeavslutninger. Hvis analysatoren mangler den fullstendige meldingen, kan den tolke rapporterte resultater i stedet for uavhengig å bekrefte hele signaturen. Grensesnittetiketten alene avgjør ikke det spørsmålet.
Sammenlign de fullstendige prøvene når de er tilgjengelige. DKIM kanonisering i RFC 6376 §3.4 tolererer spesifiserte transformasjoner, ikke vilkårlig ekvivalens av gjengitt innhold. En annen filhash betyr ikke automatisk en DKIM feil, siden noen byteendringer kan normaliseres bort; en identisk filhash etablerer bare identiske leverte bytes, ikke identisk DNS eller policykontekst.
Sjekk hva som endret seg i DNS og tid
Les d og s for hver signatur og noter nøkkelsvarene som ble observert under den senere kontrollen. Den originale nøkkelen kan ha blitt trukket tilbake, tilbakekalt eller erstattet siden levering. RFC 6376 §6.1.2 verifisering er avhengig av å hente passende verifikasjonsmateriale, slik at et historisk pass kan eksistere side om side med et senere resultat uten nøkkel.
Inspiser også eventuell x-verdi for signaturutløp og verifikatorens tidshåndtering. Et senere verktøy kan evalueres etter signaturens utløp. RFC 6376 §6.1.1 tillater verifikatorer å ignorere utløpte signaturer; et spesifikt verktøys oppførsel må kontrolleres i stedet for å antas. Ikke merk det resultatet som bevis på at signaturen var utløpt da mottakeren opprinnelig behandlet den. Der det gamle DNS svaret ikke er tilgjengelig, oppgi at den historiske kryptografiske beregningen ikke kan reproduseres fullstendig fra gjeldende bevis.
Arbeid gjennom to kontrasterende eksempler
Illustrerende eksempel en: mottakerrapportene passer for velger gammel1 på mandag, og avsender trekker seg gammel1 på fredag. En ny sjekk på lørdag viser ingen nøkkel. Det senere resultatet sletter ikke mandagens pålitelige observasjon, selv om uavhengig reprodusering av mandagens verifisering krever relevante historiske inndata.
Illustrerende eksempel to: den opprinnelige mottatte filen verifiserer, mens en limt kopi mislykkes etter at en bunntekst eller MIME serialisering endres. Sammenlign den dekkede representasjonen og punktet der endringen skjedde. Problemet kan ligge i prøvehåndtering i stedet for avsenderens originale signatur. Dette er sammenligningsarmaturer, ikke påstander om en ekte analysator eller leietaker.
Rapporter uenigheten nøyaktig
Lag en sammenligningspost som inneholder prøve-hasher, innsamlingsmetoder, observasjonstider, d og s, nøkkelsvar, verifikatorversjoner, rapporterte resultater og kjente policyforskjeller. Inspiser flere signaturer separat, siden verktøy kan fremheve forskjellige. Hold DKIM gyldigheten forskjellig fra DMARC justering og endelig levering.
Konkluder bare det bevisene støtter: forskjellige byte, endret DNS , forløpt gyldighet, annen valgt signatur eller uløst kontekst. Bevar usikkerhet når de originale inngangene mangler. En senere analysator er nyttig diagnostisk bevis, men den er ikke en tidsmaskin og bør ikke stille over det pålitelige originale mottakerresultatet.
Bevis nødvendig for neste avgjørelse
Bruk en sammenligningsrad for hver signatur: original sample hash/tid, senere sample hash/tid, d/s, observert nøkkel, x hvis tilstede, verktøy/versjon, operasjon (rapportparsing eller verifisering), resultat og gjenværende gap. Identiske prøvebyte med utilgjengelig historisk DNS etterlater et nøkkeltilstandsgap, ikke et bevis på at noen av verktøyene er feil. Hvis prøvene er forskjellige, sammenligne den dekkede kanoniske representasjonen før du tildeler kausalitet.