En huvudanalysator kan inte överensstämma med den ursprungliga mottagaren utan att någon av observationerna tillverkas. De kan ha utvärderat olika meddelandebytes, olika DNS nyckeltillstånd eller olika verifieringspolicyer vid olika tidpunkter. Bevara de ursprungliga bevisen och jämför villkoren innan du bestämmer vad oenigheten innebär.
Ett visat historiskt resultat och en ny kryptografisk verifiering är olika operationer. Vissa verktyg sammanfattar Authentication-Results redan finns i provet. Andra hämtar nycklar och verifierar det aktuella provet. Fastställ vilken operation analysatorn utför innan du jämför dess utdata med det mottagande systemets resultat.
Bevara originalet och identifiera gränsen
Exportera råmeddelandet med en metod som bevarar meddelanderepresentationen. Behåll ett oredigerat original och beräkna en filhash för senare jämförelse. Anteckna insamlingsmetod, leveranstid och källbrevlåda. En filhash kan visa att två exporterade filer skiljer sig åt; den förklarar inte i sig vilken skillnad som är viktig DKIM.
Identifiera de mottagargenererade Authentication-Results och dess betrodda authserv-id. Rubriker som tillhandahålls av en otillförlitlig avsändare är inte auktoritativt mottagarbevis. RFC 8601 §7.1 beskriver denna förtroendegräns. Bestäm också om mottagaren utvärderade meddelandet innan en senare gateway eller exportprocess ändrade det.
Jämför analysatorns faktiska ingångar
För en vanlig helkroppssignatur utelämnar ett kopierat huvudblock den text som behövs för att beräkna dess DKIM body hash. Specialfallet l=0 hashesar noll kroppsoktetter och ger inget kroppsintegritetsskydd; det avstår inte från rubriker, nyckel eller andra verifieringskontroller. Se RFC 6376 §3.5, §3.7 och §5.4.1. Klistra in text kan också ändra vikning eller radslut. Om analysatorn saknar hela meddelandet kan den tolka rapporterade resultat snarare än att självständigt verifiera hela signaturen. Dess gränssnittsetikett ensam avgör inte den frågan.
Jämför de fullständiga proverna när de är tillgängliga. DKIM kanonisering i RFC 6376 §3.4 tolererar specificerade omvandlingar, inte godtycklig ekvivalens av renderat innehåll. En annan filhash betyder inte automatiskt ett DKIM fel, eftersom vissa byteändringar kan normaliseras; en identisk filhash upprättar endast identiska tillhandahållna bytes, inte identisk DNS eller policykontext.
Kontrollera vad som ändrades i DNS och tid
Läs d och s för varje signatur och anteckna nyckelsvaren som observerades under den senare kontrollen. Originalnyckeln kan ha tagits bort, återkallats eller ersatts sedan leverans. RFC 6376 §6.1.2 verifiering förlitar sig på att hämta lämpligt verifieringsmaterial, så ett historiskt pass kan samexistera med ett senare resultat utan nyckel.
Inspektera även eventuellt x-värde för signaturutgång och verifierarens tidshantering. Ett senare verktyg kan utvärderas efter signaturens utgång. RFC 6376 §6.1.1 tillåter verifierare att ignorera utgångna signaturer; ett specifikt verktygs beteende måste kontrolleras snarare än antas. Märk inte det resultatet som ett bevis på att signaturen gick ut när mottagaren ursprungligen behandlade den. Om det gamla DNS svaret inte är tillgängligt, ange att den historiska kryptografiska beräkningen inte helt kan återges från aktuella bevis.
Arbeta igenom två kontrasterande exempel
Belysande exempel ett: mottagarrapporterna passerar för väljare gammal1 på måndag, och avsändaren går i pension gammal1 på fredag. En omkontroll på lördag visar att ingen nyckel saknas. Det senare resultatet raderar inte måndagens pålitliga observation, även om oberoende reproducering av måndagens verifiering kräver relevanta historiska indata.
Illustrativt exempel två: den mottagna originalfilen verifieras, medan en inklistrad kopia misslyckas efter en sidfot eller MIME serialisering ändras. Jämför den täckta representationen och den punkt där förändringen inträffade. Problemet kan ligga i provhantering snarare än avsändarens originalsignatur. Dessa är jämförelsefixturer, inte påståenden om en riktig analysator eller hyresgäst.
Rapportera oenigheten exakt
Skapa en jämförelsepost som innehåller provhaschar, insamlingsmetoder, observationstider, d och s, nyckelsvar, verifierarversioner, rapporterade resultat och kända policyskillnader. Inspektera flera signaturer separat, eftersom verktyg kan markera olika. Håll DKIM giltighet åtskild från DMARC inriktning och slutleverans.
Avsluta endast vad bevisen stöder: olika byte, ändrad DNS , förfluten giltighet, annan vald signatur eller olöst sammanhang. Bevara osäkerheten när de ursprungliga ingångarna saknas. En senare analysator är användbart diagnostiskt bevis, men det är inte en tidsmaskin och bör inte tyst skriva över det betrodda ursprungliga mottagarresultatet.
Bevis som behövs för nästa beslut
Använd en jämförelserad för varje signatur: ursprungligt prov hash/tid, senare prov hash/tid, d/s, observerad nyckel, x om det finns, verktyg/version, operation (rapportanalys eller verifiering), resultat och återstående lucka. Identiska provbytes med otillgänglig historisk DNS lämnar ett nyckel-tillståndsgap, inte ett bevis på att något av verktygen är fel. Om proverna skiljer sig åt, jämför den täckta kanoniska representationen innan du tilldelar kausalitet.