En sidefod kan forvandle en korrekt signeret udgående besked til en DKIM fiasko. Reparationen starter med behandlingssekvensen: Identificer hvilket system der signerede beskeden, hvilket system der indsatte sidefoden, og hvilken signatur modtageren evaluerede. Udgivelse af en anden DNS nøgle kan ikke tilføje en signaturomslagstekst, efter den blev oprettet.
Bevis hvilke bytes der er ændret
Gem en kontrolleret besked umiddelbart efter signering og en anden efter gatewayen ved at bruge rå beskedeksport i stedet for kopieret tekst fra en mailklient. Bevar de originale filer. Optag hver signaturs d, s, c, h og enhver l-tag. En besked kan have flere signaturer med forskellig dækning og forskellige resultater.
DKIM beregner en hash af den kanoniserede krop. Under almindelig dækning af hele kroppen tilføjer en ny sidefod væsentligt indhold og ændringer i denne hash. Afslappet krop kanonisering fjerner visse mellemrumsforskelle; det fjerner ikke en ansvarsfraskrivelse, HTML-blok eller ny MIME del. En body-hash mismatch vedrører de sammenlignede body-hash input og værdier: kropsrepræsentationen, c/l indstillinger og bh værdi. En beskadiget eller forkert genereret bh eller en underskriver/verifikator implementeringsfejl kan også forklare et misforhold. Sammenligningen i RFC 6376 afsnit 6.1.3 beviser ikke i sig selv, at en gateway ændrede kroppen. En generel signaturfejl kan i stedet involvere en signeret header, nøgleopslag eller signatursyntaks. RFC 6376 §3.4, RFC 6376 §3.7 og RFC 6376 §6.1 beskriv disse separate kontroller.
Sammenlign prøverne ved grænsen, hvor sidefoden er anvendt. Undersøg både tekst/almindelig og tekst/html dele, MIME grænser og overførselskodning. En tilsyneladende identisk synlig sidefod kan serialiseres forskelligt. Hvis gatewayen også skifter Emne, skal du kontrollere, om Emne er angivet i h: reparation af kroppen alene vil ikke genoprette en signatur over en ændret header.
Test bestillingen i stedet for at gætte
Illustrativt scenario: en applikation opretter en faktura, den udgående server underskriver den, og en gateway tilføjer derefter en juridisk meddelelse. Modtageren rapporterer et body-hash-mismatch for applikationens signatur. I et kontrolleret alternativ tilføjer gatewayen meddelelsen først, og en autoriseret underskriver underskriver den endelige serialiserede meddelelse. Et bestået resultat på den anden vej understøtter bestillingsdiagnosen. Disse er foreslåede testobservationer, ikke resultater fra en rigtig lejer.
Brug de samme meddelelsesvarianter gennem begge stier, inklusive HTML, almindelig tekst og en vedhæftet fil. Registrer modtagergodkendelse er resultatet af en betroet grænse, signaturdomænet og det synlige Fra-domæne. DKIM pas alene er utilstrækkeligt til DMARC hvis den beståede signatur ikke stemmer overens med forfatterdomænet. En ikke-relateret gateway-signatur kan verificere korrekt uden at angive den justerede sti.
Vælg en ejet signeringsgrænse
Det sædvanlige holdbare design er at udføre nødvendige indholdsændringer før den endelige autoriserede signeringsoperation. Det kan betyde, at underskriveren flyttes senere, at indsætte sidefod tidligere eller at konfigurere gatewayen til at signere den endelige meddelelse ved hjælp af et domæne, som organisationen kontrollerer. Bekræft understøttet adfærd og nøgleejerskab, før du vælger et design. Gå ikke ud fra, at hver gateway understøtter signering af tilpasset domæne.
Hvis en eksisterende signatur er brudt, reparerer tilføjelse af en ny gyldig signatur ikke den tidligere. Evaluer den nye signatur på dens egne fordele og bekræft justering separat. Aktiver ikke body-længde-l-tagget bare for at få sidefødder til at forsvinde fra hash-beregningen: det efterlader et usigneret suffiks og skaber sikkerhedsafvejningen beskrevet i RFC 6376 §8.2.
Afslut med et regressionstjek
Hold et rutediagram, der viser den sidste kropsskiftende komponent og underskriveren umiddelbart efter den. Test igen, når ansvarsfraskrivelsesregler, antivirus-omskrivning eller udgående routing ændres. Succes betyder, at den påkrævede sidefod er til stede, den tilsigtede signatur verificerer, dens domæne overholder den tilsigtede tilpasningspolitik, og kritiske beskeder ankommer stadig via den forventede rute. Bevar en tilbagerulningsplan for konfigurationsændringen uden at behandle fjernelse af en påkrævet juridisk meddelelse som en automatisk afhjælpning.
Brug en registrering af regressionsaccept
For hver syntetisk almindelig tekst-, HTML- og vedhæftningsvariant skal du registrere: sidefod til stede; sidste kropsændrende humle; endelig underskriver d/s; valgt c/h/l; betroet modtager resultat; Forfatter Domæne og justering; og forretningsrutens resultat. Hvis sidefoden mangler, er varselkravet ikke opfyldt, selv når DKIM består. Hvis sidefoden er til stede, men kun et ikke-relateret gateway-domæne passerer, er det tilsigtede DKIM-justeringskrav ikke opfyldt. Disse er acceptkriterier, ikke gennemførte kontroller.