A DKIM body-hash-fejl betyder, at verifikatoren ikke reproducerede kropshash medtages i signaturen, efter anvendelse af signaturens relevante regler. Den identificerer ikke, hvilket system der har ændret meddelelsen, og det er ikke den samme diagnose som en manglende offentlig nøgle.
Start med at bevare den oprindelige modtagne besked. Kopiering af den synlige tekst fra en mailklient mister MIME struktur, kodning og andre bytes, der har betydning for verifikationen.
Bekræft den nøjagtige fejl
Undersøg den betroede modtagers resultat og signaturen, der vurderes. En besked kan have mere end én DKIM signatur, og hver kan have et andet signeringsdomæne eller resultat.
Optag d=, s=, algoritmen, den c= kanoniseringsindstilling og enhver l= kropslængde-tag. Behold den nøjagtige bekræftelsesårsag. Et nøgleopslagstimeout, en ikke-understøttet algoritme, en header-signatur-mismatch og en body-hash-mismatch kræver forskellige undersøgelser.
I RFC 6376 §3.5, bh=-værdien er den kodede hash af den kanoniserede krop, underlagt den definerede længdebehandling. b=-værdien hører til signaturberegningen. At behandle disse som udskiftelige skjuler hvilken kontrol mislykkedes.
Bevar beviser, der kan gengive resultatet
Gem den rå meddelelse gennem en godkendt eksportsti og begræns adgangen i henhold til dens indhold. Hold den modtagne original intakt, med en hash og afhentningstid, hvis undersøgelsesprocessen understøtter dem.
Opret analysekopier separat. Redigering af en adresse, ændring af en vedhæftet fil eller lagring af en rekonstrueret meddelelse kan ændre materiale, der er relevant for verifikation. En sikker delingskopi kan være nyttig, men den svarer ikke automatisk til den bevarede original.
Registrer kilden til ethvert verifikationsoutput. Et værktøj, der normaliserer linjeafslutninger ved import, vurderer muligvis ikke de samme bytes som den modtagende server. Hvis to værktøjer er uenige, skal du først etablere deres input og understøttet adfærd.
Sammenlign meddelelsen før og efter sandsynlige modifikatorer
Kortlæg den faktiske rute fra afsenderen gennem gateways, relæer, postlister og modtagetjenester. Søg kontrolleret fangst umiddelbart før og efter en formodet transformation.
Almindelige efterforskningskandidater omfatter en sidefod indsat efter signering, URL-omskrivning, MIME -genkodning, vedhæftningsbehandling og reparationer af forkert udformet indhold. Disse er hypoteser, indtil bevis placerer en relevant ændring ved et hop.
Brug en kontrolleret test, der følger samme rute og udøver den formodede funktion. Sammenlign f.eks. en ellers tilsvarende besked med og uden gatewayens sidefodsregel. Generaliser ikke fra en direkte test, der omgår produktionsgatewayen.
I et syntetisk tilfælde verificeres afsenderens lagrede output med succes, mens den opfangede besked efter en disclaimer-gateway har en body-hash-mismatch. Gatewayen tilføjer en sidefod efter afsenderen har underskrevet. Under de nævnte hypotetiske observationer identificerer det en konfigurationsafhængighed, der skal adresseres, snarere end en grund til at erstatte den offentlige DKIM nøgle.
Forstå, hvad kanonisering kan tolerere
DKIM kanoniseringsregler tillader særlige normaliseringer. De gør ikke vilkårlig indholdsredigering sikker. Afslappet krop kanonisering er ikke tilladelse til at omskrive links eller tilføje et afsnit efter underskrivelse.
Undersøg algoritmen specificeret af signaturen, og brug en verifikator, der implementerer den korrekt. Diagnostiser ikke ud fra en visuelt identisk gengivelse: To viste meddelelser kan indeholde forskellige signerede oktetter.
Under RFC 6376 §3.5, en l=-værdi begrænser de kanoniserede kropsoktetter, der er omfattet af den definerede beregning. Det er ikke en generel rettelse til en modificerende gateway, og bevidst at efterlade indhold uden for beskyttelsen ændrer sikkerhedsvurderingen. Brug understøttede konfigurationer og gennemgå implikationerne i stedet for at tilføje en længdegrænse for at undertrykke et symptom.
Ret den ændrende rute, og revurder derefter justeringen
Hvor organisationen kontrollerer ruten, skal du arrangere nødvendige ændringer før den sidste passende signeringsfase. Hvis en tjeneste gensigner mail, skal du kontrollere den nye signeringsidentitet og hvad den beviser. En videregivelsessignatur fra en ikke-relateret mellemmand stemmer ikke automatisk overens med det originale, synlige Fra-domæne; RFC 9989 §4.4.1 kræver, at den autentificerede signeringsidentitet er tilpasset.
For legitime indirekte ruter uden for afsenderens kontrol, vurdere den gældende interoperabilitetsvejledning. Deaktiver ikke sikkerhedsbehandling eller svække en domænepolitik, udelukkende fordi en test mislykkes.
Gentag den berørte virksomheds arbejdsgang og behold før-og-efter-beviser. Brug derefter DMARC alignment diagnose for at fastslå, om en passerende linjeret sti forbliver. Hændelsen afsluttes, når den relevante transformation og dens effekt er forstået, og den påtænkte rute er verificeret.
Vælg det næste diagnostiske trin
Brug denne foreslåede beslutningssekvens; den registrerer ingen udført test:
- Ingen brugbar nøgle eller timeout for nøgleforespørgsel: følg opslagsresultatet under RFC 6376 §6.1.2 i stedet for at diagnosticere en sidefod.
- Genberegnet kropshash adskiller sig fra bh: sammenlign kropsrepræsentationen, faktiske c/l-indstillinger og registreret bh-værdi under RFC 6376 §6.1.3. En beskadiget eller forkert genereret bh, eller en underskriver/verifikator implementeringsfejl, er også en mulig årsag; mismatchet alene beviser ikke kropsændring.
- Brødtekst-hash matcher, men signaturen mislykkes: undersøg signerede overskrifter, signaturberegningen og nøgle-til-underskriver-forholdet; matchende bh alene er ikke et DKIM pas.
- Flere signaturer er uenige: Hold hvert resultat bundet til sine egne d og s, før du beslutter, om en passerende justeret sti forbliver.