A DKIM pass betyder ikke, at alle viste overskrifter blev underskrevet. Hver signatur vælger overskriftsfelter gennem sin h-tag og anvender en specificeret kanonisering algoritme. For at afgøre, om et emne, modtagerfelt eller anden værdi var beskyttet, skal du inspicere den faktiske dækning af den beståede signatur.
Start med den rigtige signatur
Optag d, s, h og c for hver DKIM-Signature overskrift. Tilknyt modtagerens betroede resultat med den tilsvarende signatur i stedet for at behandle et pass på meddelelsesniveau som bevis for dem alle. En signatur skal indeholde Fra, men ikke hver anden overskrift er obligatorisk. RFC 6376 §5.4 forklarer udvælgelsesreglerne og anbefaler nyttig dækning.
Hvis Emne ikke er valgt, ændrer en ændring til Emne ikke i sig selv de data, der er beskyttet af denne signatur. Den erklæring handler om kryptografisk dækning, ikke om den ændrede meddelelse er acceptabel. En modtagende tjeneste kan stadig anvende uafhængig politik. På samme måde binder signering til ikke SMTP -konvolutmodtageren: den synlige Til-header og RCPT TO-adresse er forskellige data; RFC 5321 §2.3.1 adskiller SMTP kuvert fra besked indhold.
Redegør for gentagne felter
h-tagget er ikke blot et sæt unikke navne. Under RFC 6376 §5.4.2, gentagne navne vælger gentagne fysiske hændelser, der arbejder fra bunden af overskriftsblokken opad. For eksempel, hvis en meddelelse har tre Modtaget-felter og h-lister Modtaget to gange, vælges de to nederste forekomster. Tilføjelse af flere forekomster af et navn til h, end der eksisterer ved signering, kan registrere senere indsættelse af dette felt. Denne teknik kaldes ofte oversignering.
Konkluder ikke, at et felt øverst er underskrevet, blot fordi dets navn optræder én gang i h. Rekonstruer markeringen mod den faktiske overskriftsblok. Duplikerede felter, der normalt bør være ental, rejser også spørgsmål om parsing og meddelelsesgyldighed; en DKIM beregning giver ikke tilladelse til at ignorere disse bekymringer.
Skelne værdiændringer fra normaliseret formatering
Under simpel header-kanonisering skal det valgte felt præsenteres nøjagtigt som underskrevet. Afslappet kanonisering af overskrifter Små bogstaver feltnavne, udfolder fortsættelseslinjer og normaliserer specificeret mellemrum. Det gør ikke feltværdier med små bogstaver eller gør en anden emnetekst ækvivalent. Læs den valgte algoritme, før du tilskriver en fejl til store bogstaver eller omvikling.
Illustrativ testspecifikation: én kontrolleret signatur vælger Fra og Emne. Ændring af emneordene forventes at ugyldiggøre denne signatur. En anden signatur vælger Fra, men udelader Emne; den samme emneændring behøver ikke at gøre den anden signatur ugyldig. Kontrasten forklarer forventet dækning, ikke en godkendelse af at udelade emne.
Forbedre dækningen hos underskriveren
Vælg felter, der påvirker modtagerens fortolkning og kan forblive stabile gennem den understøttede rute. Undersøg anbefalingerne i RFC 6376 §5.4.1 og din underskrivers evner. Undgå tilfældigt at underskrive sporingsfelter, som lovlig transport vil tilføje eller ændre. Test hele ruten med duplikatfelter og formateringssager i et kontrolleret miljø.
Dokumenter den tilsigtede dækningsprofil ved siden af signeringskonfigurationen. En nyttig gennemgang angiver præcis hvilke overskrifter og forekomster der er beskyttet, hvilke normaliseringer der er tilladt og hvilke felter der forbliver uden for signaturen. Det er mere forsvarligt end at beskrive DKIM som et segl over hele budskabet.
Spor et syntetisk headervalg
Forestil dig tre X-eksempel-felter i fysisk top-til-bund rækkefølge: nyeste, mellemste, ældste. En signaturliste h=From:X-Example:X-Example vælger den ældste og derefter den midterste, ikke den nyeste. Med kun ét X-eksempel til stede ved underskrivelsen, inkluderer opførelse af X-eksempel to gange også en fraværende forekomst; senere indsættelse af et andet X-eksempel ændrer det valgte input og kan ugyldiggøre signaturen. Dette er en udvælgelsesøvelse, ikke en udført signaturtest eller en anbefaling om at tillade duplikater af normalt enkeltstående felter.