En sidfot kan förvandla ett korrekt signerat utgående meddelande till ett DKIM fel. Reparationen börjar med bearbetningssekvensen: identifiera vilket system som signerade meddelandet, vilket system som infogade sidfoten och vilken signatur mottagaren utvärderade. Att publicera en annan DNS nyckel kan inte göra att en signaturomslagstext läggs till efter att den skapades.
Bevisa vilka bytes som ändrades
Spara ett kontrollerat meddelande direkt efter signering och ett annat efter gatewayen, använd råmeddelandeexport istället för kopierad text från en e-postklient. Bevara originalfilerna. Spela in varje signaturs d, s, c, h och valfri l-tagg. Ett meddelande kan ha flera signaturer med olika täckning och olika resultat.
DKIM beräknar en hash av den kanoniserade kroppen. Under vanlig täckning för hela kroppen lägger en ny sidfot till innehåll och ändringar av hash. Avslappnad kropp kanonisering tar bort vissa blankstegsskillnader; det tar inte bort en ansvarsfriskrivning, HTML-block eller ny MIME del. En body-hash-felmatchning gäller jämförda body-hash-ingångar och värden: kroppsrepresentationen, c/l-inställningar och bh-värde. En skadad eller felaktigt genererad bh, eller ett implementeringsfel undertecknare/verifierare, kan också förklara en missmatchning. Jämförelsen i RFC 6376 avsnitt 6.1.3 bevisar inte i sig att en gateway förändrade kroppen. Ett allmänt signaturfel kan istället involvera en signerad rubrik, nyckeluppslag eller signatursyntax. RFC 6376 §3.4, RFC 6376 §3.7 och RFC 6376 §6.1 beskriv dessa separata kontroller.
Jämför proverna vid gränsen där sidfoten appliceras. Inspektera både text/oformaterad och text/html delar, MIME gränser och överföringskodning. En till synes identisk synlig sidfot kan serialiseras på olika sätt. Om gatewayen också byter Ämne, kontrollera om Ämne är listad i h: endast reparation av kroppen kommer inte att återställa en signatur över en ändrad rubrik.
Testa beställningen istället för att gissa
Illustrativt scenario: ett program skapar en faktura, den utgående servern signerar den och en gateway lägger sedan till ett juridiskt meddelande. Mottagaren rapporterar en body-hash-felmatchning för applikationens signatur. I ett kontrollerat alternativ lägger gatewayen till meddelandet först och en auktoriserad undertecknare undertecknar det slutliga serialiserade meddelandet. Ett passerande resultat på den andra vägen stöder beställningsdiagnosen. Dessa är föreslagna testobservationer, inte resultat från en riktig hyresgäst.
Använd samma meddelandevarianter genom båda sökvägarna, inklusive HTML, vanlig text och en bilaga. Spela in mottagarautentisering är resultatet av en betrodd gräns, signaturdomänen och den synliga From-domänen. Enbart DKIM pass är otillräckligt för DMARC om den passerande signaturen inte överensstämmer med författarens domän. En icke-relaterad gatewaysignatur kan verifieras korrekt utan att tillhandahålla den justerade sökvägen.
Välj en ägd signeringsgräns
Den vanliga hållbara designen är att utföra nödvändiga innehållsändringar innan den slutliga auktoriserade signeringsoperationen. Det kan innebära att undertecknaren flyttas senare, flytta sidfotsinfogningen tidigare eller konfigurera gatewayen för att signera det slutliga meddelandet med en domän som organisationen kontrollerar. Bekräfta stödbeteende och nyckelägande innan du väljer en design. Anta inte att varje gateway stöder anpassad domänsignering.
Om en befintlig signatur är trasig reparerar inte den tidigare signaturen att lägga till en ny giltig signatur. Utvärdera den nya signaturen på sina egna meriter och verifiera inriktning separat. Aktivera inte body-length l-taggen bara för att få sidfötter att försvinna från hashberäkningen: den lämnar ett osignerat suffix och skapar säkerhetsavvägningen som beskrivs i RFC 6376 §8.2.
Avsluta med en regressionskontroll
Håll ett ruttdiagram som visar den sista kroppsförändrande komponenten och undertecknaren omedelbart efter den. Testa igen när friskrivningsregler, antivirus-omskrivning eller utgående routing ändras. Framgång betyder att den nödvändiga sidfoten finns, den avsedda signaturen verifierar, dess domän uppfyller den avsedda anpassningspolicyn och viktiga meddelanden fortfarande kommer via den förväntade vägen. Behåll en återställningsplan för konfigurationsändringen utan att ta bort ett obligatoriskt juridiskt meddelande som en automatisk åtgärd.
Använd en regressionsacceptanspost
För varje syntetisk oformaterad text, HTML och bilaga variant, registrera: sidfot närvarande; sista kroppsförändrande humlet; slutlig undertecknare d/s; valt c/h/l; resultat av betrodd mottagare; Författare Domän och anpassning; och resultatet av affärsvägen. Saknas sidfoten uppfylls inte meddelandekravet även när DKIM passerar. Om sidfoten finns men bara en icke-relaterad gatewaydomän passerar, uppfylls inte det avsedda DKIM-anpassningskravet. Dessa är acceptanskriterier, inte genomförda kontroller.