En bunntekst kan gjøre en riktig signert utgående melding til en DKIM feil. Reparasjonen starter med behandlingssekvensen: identifiser hvilket system som signerte meldingen, hvilket system som satte inn bunnteksten og hvilken signatur mottakeren evaluerte. Å publisere en annen DNS nøkkel kan ikke legge til en signaturomslagstekst etter at den ble opprettet.
Bevis hvilke byte som ble endret
Lagre en kontrollert melding umiddelbart etter signering og en annen etter gatewayen, ved å bruke rå meldingseksport i stedet for kopiert tekst fra en e-postklient. Ta vare på de originale filene. Ta opp hver signaturs d, s, c, h og enhver l-tag. En melding kan ha flere signaturer med ulik dekning og utfall.
DKIM beregner en hash av den kanoniserte kroppen. Under vanlig dekning av hele kroppen, legger en ny bunntekst til innhold og endringer i hashen. Avslappet kropp kanonisering fjerner visse mellomromsforskjeller; den fjerner ikke en ansvarsfraskrivelse, HTML-blokk eller ny MIME del. En body-hash-mismatch gjelder de sammenlignede body-hash-inndataene og -verdiene: kroppsrepresentasjonen, c/l-innstillinger og bh-verdi. En skadet eller feil generert bh, eller en signer/verifikator implementeringsfeil, kan også forklare et misforhold. Sammenligningen i RFC 6376 avsnitt 6.1.3 beviser ikke i seg selv at en gateway endret kroppen. En generell signaturfeil kan i stedet involvere en signert overskrift, nøkkeloppslag eller signatursyntaks. RFC 6376 §3.4, RFC 6376 §3.7 og RFC 6376 §6.1 beskriv disse separate kontrollene.
Sammenlign prøvene ved grensen der bunnteksten er brukt. Inspiser både tekst/ren og tekst/html deler, MIME grenser og overføringskoding. En tilsynelatende identisk synlig bunntekst kan serialiseres annerledes. Hvis gatewayen også endrer emne, inspiser om emne er oppført i h: reparasjon av kroppen alene vil ikke gjenopprette en signatur over en endret overskrift.
Test bestillingen i stedet for å gjette
Illustrerende scenario: en applikasjon oppretter en faktura, den utgående serveren signerer den, og en gateway legger deretter til et juridisk varsel. Mottakeren rapporterer en body-hash mismatch for applikasjonens signatur. I et kontrollert alternativ legger gatewayen til varselet først og en autorisert underskriver signerer den endelige serialiserte meldingen. Et bestått resultat på den andre banen støtter bestillingsdiagnosen. Dette er foreslåtte prøveobservasjoner, ikke resultater fra en reell leietaker.
Bruk de samme meldingsvariantene gjennom begge banene, inkludert HTML, ren tekst og et vedlegg. Registrer mottakerautentisering er resultatet av en klarert grense, signaturdomenet og det synlige Fra-domenet. DKIM pass alene er ikke tilstrekkelig for DMARC hvis den beståtte signaturen ikke stemmer overens med forfatterdomenet. En urelatert gatewaysignatur kan verifiseres riktig uten å oppgi den justerte banen.
Velg en eid signeringsgrense
Den vanlige holdbare utformingen er å utføre nødvendige innholdsendringer før den endelige autoriserte signeringsoperasjonen. Det kan bety å flytte underskriveren senere, flytte innsetting av bunntekst tidligere eller konfigurere gatewayen til å signere den endelige meldingen ved hjelp av et domene organisasjonen kontrollerer. Bekreft støttet atferd og nøkkeleierskap før du velger et design. Ikke anta at hver gateway støtter egendefinert domenesignering.
Hvis en eksisterende signatur er ødelagt, vil ikke det å legge til en ny gyldig signatur reparere den tidligere. Vurder den nye signaturen på sine egne fordeler og verifiser justering separat. Ikke aktiver body-length l-taggen bare for å få bunntekst til å forsvinne fra hash-beregningen: den etterlater et usignert suffiks og skaper sikkerhetsavveiningen beskrevet i RFC 6376 §8.2.
Avslutt med en regresjonssjekk
Hold et rutediagram som viser den siste kroppsforandrende komponenten og signeren umiddelbart etter den. Test på nytt når ansvarsfraskrivelsesregler, antivirus-omskriving eller utgående ruting endres. Suksess betyr at den nødvendige bunnteksten er til stede, den tiltenkte signaturen verifiserer, domenet oppfyller den tiltenkte innrettingspolicyen, og kritiske meldinger fortsatt kommer gjennom den forventede ruten. Behold en tilbakeføringsplan for konfigurasjonsendringen uten å behandle fjerning av et påkrevd juridisk varsel som en automatisk løsning.
Bruk en regresjonsgodkjenningspost
For hver syntetisk ren tekst, HTML og vedleggsvariant, noter: bunntekst til stede; siste kroppsendrende humle; endelig underskriver d/s; valgt c/h/l; pålitelig mottakerresultat; Forfatter Domene og justering; og resultatet av forretningsruten. Mangler bunnteksten oppfylles ikke varselkravet selv når DKIM består. Hvis bunnteksten er til stede, men bare et ikke-relatert gateway-domene passerer, oppfylles ikke det tiltenkte DKIM-justeringskravet. Dette er akseptkriterier, ikke fullførte sjekker.