To beskeder kan se identiske ud i en mailklient og stadig producere forskellige DKIM krops-hash. DKIM verificerer den transmitterede repræsentation efter dens specificerede kanonisering, ikke læserens afkodede visning. MIME genopbygning, indholdsoverførselskonvertering og grænseændringer hører derfor til tidligt i undersøgelsen, når en besked først fejler efter en behandlingstjeneste.
Adskil udseende fra repræsentation
En MIME meddelelse kan indeholde almindelig tekst, HTML, vedhæftede filer og indlejrede flerdelte strukturer. RFC 2046 §5.1.1 placerer MIME deloverskrifter og grænseafgrænsningslinjer inde i den flerdelte krop. Omkodning af en tekstdel fra citeret-udskrivbar til base64 kan bevare, hvad en bruger læser, mens de bytes, der præsenteres for DKIM ændres. Genindpakning af kodede linjer kan også ændre disse bytes. Afslappet kanonisering er en defineret blanktegnstransformation, ikke en MIME dekoder eller en ækvivalenstest for gengivet indhold.
RFC 6376 §5.3 anbefaler konvertering til en passende MIME overførselskodning før underskrift for at reducere transportkonverteringer. Det kræver specifikt, at lokale repræsentationer, der vil ændre sig før transmission, normaliseres før underskrivelse. Princippet er operativt enkelt: Underskriv den formular, som modtageren forventes at se.
Find serialiseringsændringen
Få rå beskeder ved underskriverudgang, formodet gatewayudgang og endelig modtager. Gem originaler uden at åbne og gemme dem gennem en editor, der normaliserer linjeafslutninger. Bemærk indsamlingsmetoden, fordi et eksportværktøj selv kan ændre repræsentationen.
Sammenlign felterne Content-Type og Content-Transfer-Encoding ved den ydre meddelelse og hver relevant MIME del. Tjek grænsestrenge, vedhæftningskodning, foldede linjer og tegnsætkonvertering. Bestem, om en ændret ydre sidehoved var inkluderet i h, og om ændrede deloverskrifter fandt sted inde i den signerede krop. Behandl de to steder separat: en ydre header kan forårsage signaturbekræftelsesfejl, mens en MIME del header normalt deltager i kropshash.
Gennemfør et kodningseksempel
Illustrativ testspecifikation: en tekstdel, der indeholder et ikke-ASCII-tegn, er udarbejdet ved hjælp af citeret-printbar, før applikationen underskriver meddelelsen. En downstream-tjeneste afkoder den del og serialiserer den som base64. Den viste sætning forbliver den samme, men den kanoniserede krop kan afvige, og den originale signatur kan mislykkes. Kør kun dette med kontrolleret indhold, og inspicér faktiske byte-forskelle i stedet for at antage, at hver tjeneste udfører denne konvertering.
Opret et lille testsæt, der indeholder almindelig tekst, der kun indeholder ASCII, ikke-ASCII-tekst, flerdelt HTML og en lille vedhæftet fil. Send hver gennem en direkte kontrolsti og den produktionsækvivalente behandlingssti. Hvis kun sidstnævnte ændrer repræsentation, identificerer grænsesammenligningen den komponent, der skal undersøges. Hvis begge fejler, skal du først undersøge underskriverens egen serialisering og normalisering.
Reparer grænsen
Foretrækker endelig MIME konstruktion og valg af overførselskodning før underskrivelse. Hvis en sikkerhedstjeneste skal omskrive indhold, skal du arrangere et autoriseret signeringstrin efter dets endelige serialisering. Bekræft dets tilpassede domænesupport og ejerskabsmodel; en signatur under et ikke-relateret tjenestedomæne kan passere DKIM uden at tilpasse sig DMARC under RFC 9989 §4.4.1.
Reparer ikke en prøve på plads og fremvis den som bevis på, at produktionen er fast. En modificeret prøve tester kun en hypotese. Skift den ansvarlige konfiguration, send nye kontrollerede beskeder og indfang deres originale modtagerresultater. Undgå brede omgåelser af indholdsinspektion udelukkende for at bevare en signatur uden at gennemgå sikkerhedskonsekvensen.
Bevar en nyttig hændelsesoptegnelse
Registrer den første grænse, hvor serialiseret indhold afviger, MIME feltet eller delen påvirket, underskriveren og vælger, og resultater for hver testvariant. Hold testmeddelelserne fri for kundedata. Kør pakken igen efter gateway-opgraderinger og ændringer i vedhæftningsbehandling. Den fuldførte rettelse forklarer, hvorfor den gamle repræsentation fejlede, og viser, at nyudsendt post overlever den fulde understøttede rute.
Sammenlign en konkret kodet repræsentation
For UTF-8-bytes C3 A9, der repræsenterer é, er en citeret-udskrivbar repræsentation =C3=A9; en base64-repræsentation er w6k=. Med passende MIME headers afkoder begge til det samme tegn, men de kodede strenge er forskellige. RFC 2045 §6.7 og RFC 2045 §6.8 definere kodningerne; RFC 6376 §3.7 kræver hashing efter overførselskodning og før afkodning under verifikation. Dette isolerede repræsentationseksempel er ikke en komplet MIME meddelelse eller en udført signaturtest. Hvis der bruges en kropslængdegrænse, skal du bestemme, om de ændrede bytes er inden for dækning i stedet for at antage, at hver del er beskyttet.