Et problem med linjeafslutning er et problem på byteniveau. At kopiere en besked til en editor, se de samme linjer og konkludere, at intet ændret er ikke en pålidelig DKIM undersøgelse. Bevar den originale fremstilling og identificer, om konverteringen fandt sted før underskrivelsen, under transport eller kun under bevisindsamling.
Etabler den forventede form
Internet-mail bruger CRLF linjeseparatorer. RFC 6376 §5.3 kræver, at en underskriver konverterer lokale blottede CR- eller LF-konventioner til SMTP-standard CRLF-sekvensen før signering. Konverteringen bør gælde for den transmitterede meddelelse, ikke kun for en privat kopi, der er videregivet til signeringsalgoritmen. At underskrive en erklæring og sende en anden inviterer til uenighed ved verifikation.
Kanonisering har snævrere regler end generel tekstnormalisering. Simpel krop kanonisering ignorerer efterfølgende tomme linjer og leverer den nødvendige endelige CRLF. Afslappet krop kanonisering fjerner også hvide mellemrum i slutningen af linjen og komprimerer rækker af mellemrum eller tabulatorer inden for en linje. Det sletter generelt ikke meningsfulde linjeskift eller samler indpakket tekst. Overskrifts- og kropsalgoritmerne kan variere, så læs begge dele af c i stedet for at antage en enkelt tilstand.
Beskyt beviserne først
Indsaml rå beskedfiler fra underskriveren og modtageren ved hjælp af metoder, hvis transformationer du forstår. Behold skrivebeskyttede originaler og hashes af disse filer. I en arbejdskopi skal du undersøge CRLF-, bare LF- og bare CR-tællinger ved hjælp af et byte-bevidst værktøj. En tekstfremvisers visning er ikke tilstrækkelig: mange seere gengiver hver formular som et linjeskift.
Spørg hvordan prøven blev opnået. Et arkiv, shell-pipeline eller kildekontrolindstilling kan normalisere slutninger efter levering. En forskel i eksporterede filer fastslår ikke, at selve SMTP meddelelsen er ændret. Sammenlign, hvor det er muligt, uafhængige fangster ved samme grænse og behold eksportproceduren med beviserne.
Brug en lille kontrolleret sag
Illustrativt input: en krop består af alfa, en CRLF, beta, og en sidste CRLF. Tilføjelse af en tom CRLF-kun linje i slutningen normaliseres væk af standard kropsalgoritmerne. At erstatte linjeskiftet mellem alfa og beta med et mellemrum ændrer indholdet og er ikke den samme handling. Tilføjelse af mellemrum i slutningen af alfalinjen adskiller sig ved simpel kropskanonisering, men normaliseres ved afslappet kropskanonisering.
Disse eksempler forklarer reglerne; de er ikke en erstatning for bekræftelse af en fuldstændig signatur. En gyldig kropshash er kun en del af DKIM verifikation. Udvælgelse af header, hentning af offentlig nøgle og den kryptografiske signatur skal også lykkes.
Find og ret den ansvarlige fase
Hvis underskriveren modtager LF-only lokale data, skal du inspicere serialiseringsstadiet før underskrivelse. Hvis underskriveroutput er korrekt, men en senere råoptagelse afviger, skal du undersøge den hops konverterings- eller genopbygningsadfærd. Hvis kun dine eksporterede beviser er forskellige, skal du reparere indfangningsmetoden i stedet for at ændre produktions- DNS eller nøgler.
Foretag en snævert ændring, der sikrer, at underskriveren og den transmitterede meddelelse bruger den samme normaliserede repræsentation. Opfind ikke en tilpasset verifikator, der accepterer vilkårlige linjetransformationer for at få prøven til at bestå. En sådan verifikator ville ikke længere teste de offentliggjorte DKIM regler.
Bekræft mere end én besked
Efter ændringen skal du sende en lille pakke, der dækker almindelig tekst, tomme efterfølgende linjer, HTML og vedhæftede filer. Registrer den valgte kanonisering, de indsamlede råfil-hashes og den betroede modtagers verifikationsresultat. Behold den forventede output-repræsentation som en regressionsarmatur. En nyttig løsning identificerer den ansvarlige konvertering og viser, at nye meddelelser når modtageren i den tilsigtede form.
Hold bytetal adskilt fra konklusioner
Til den syntetiske krop alfa<CRLF>beta<CRLF>, netværksformens krop er 13 oktetter: fem bogstaver, to separatoroktetter, fire bogstaver og to sidste separatoroktetter. En LF-kun eksport af de samme synlige linjer er 11 oktetter. Denne tælleforskel er en grund til at undersøge indsamling eller serialisering, ikke bevis for, at den sendte post var beskadiget. Behold de originale filer og indsamlingsmetoder, og sammenlign derefter med en pålidelig optagelse ved den relevante grænse. CRLF-etiketten i parentes repræsenterer bytes, ikke bogstavelig tekst.