Ett sparat meddelande är värdefullt bevis, men ett nytt DKIM verifiering är en ny händelse. Den testar den sparade representationen och den tillgängliga nyckeln enligt verifierarens regler vid den tidpunkten. Bevara den ursprungliga mottagarens rapporterade resultat tillsammans med det nya testet så att en uppenbar oenighet kan undersökas istället för att tyst skriva över.
Bevara inmatningen före analys
Spara meddelandet som bytes och beräkna ett SHA-256-fingeravtryck innan du öppnar det i programvara som kan skriva om rubriker, radslut eller MIME struktur. Behåll eventuell analys eller redaktion i en derivatfil. DKIM arbetar på kanoniserat meddelandematerial, inte på en skärmdump eller ett visuellt likvärdigt renderat meddelande. RFC 6376 definierar enkel och avslappnad kanonisering med specifika toleranser. RFC 6376 avsnitt 3.4.
En avslappnad signatur tolererar vissa blankstegsskillnader; den tillåter inte godtycklig omskrivning. Ändringar av signerad text kan fortfarande göra den ogiltig. Kontrollera listan med signerade rubriker och eventuell kroppslängdstagg innan du beskriver vad signaturen skyddar. En signatur med begränsad kroppstäckning skiljer sig från en som täcker hela den kanoniserade kroppen.
Spela in nyckel- och verifieringskontexten
Signaturens d=- och s=-värden identifierar signeringsdomänen och väljare används för att hitta den publika nyckeln. Registrera det efterfrågade namnet, svarstiden, resolverkontext och bibehållna nyckelbytes när de är legitima tillgängliga. En aktuell uppslagning kan skilja sig från nyckeln som fanns vid leverans på grund av rotation, återkallelse eller DNS ändring. Att inte få fram en nyckel nu är inte ett bevis på att mottagaren saknade den då. RFC 6376 avsnitt 3.6 och 6.
Spela in verifierarens namn, version, inställningar och den valda signaturen. Flera signaturer kan ge olika resultat. Beskriv inte en standardkontroll av en signatur som verifiering av alla signaturer. Utgångsdatum, algoritmstöd och lokal policy kan också påverka ett resultat, så behåll diagnostiken istället för att minska varje misslyckande med att "manipulera meddelanden".
Jämför ett hypotetiskt gammalt pass med ett nytt misslyckande
Antag att en betrodd mottagare registrerade DKIM pass vid leverans, men en senare kontroll av sparad fil kan inte få väljarnyckeln. Det nya resultatet fastställer nuvarande verifieringsgränser, inte ett gammalt misslyckande. Behåll frågenamn, uppslagstid och diagnostik; sök auktoriserad historisk nyckel eller DNS bevis om frågan kräver det.
I ett annat fall är den aktuella nyckeln tillgänglig men analytikerns derivata har ändrat undertecknad brödtext. Testa det bevarade originalet separat innan du skyller på ett relä eller avsändare. Om bara den redigerade kopian överlever, förblir det historiska signaturresultatet olöst. Dessa är hypotetiska diagnostiska grenar, inte utförda kryptografiska operationer eller DNS replay.
Om en offentlig nyckel tillhandahålls genom en lokal återuppringning istället för att erhållas från DNS , märk den ingången uttryckligen. Ett pass under en injicerad nyckel fastställer inte att signeringsdomänen publicerade eller auktoriserade nyckeln. Inkludera aldrig en privat signeringsnyckel i bevispaketet.
Förklara oenighet utan att göra överkrav
Om den sparade kopian misslyckas men en betrodd mottagare registreras passerar, jämför artefaktens ursprung, transformationer, nyckeltillgänglighet och verifieringsbeteende. Om den sparade kopian går igenom, etablerar det den testade signaturen under den medföljande nyckeln och reglerna, inte placering i inkorgen, avsändarens avsikt eller aktuella DMARC politik. DKIM :s signeringsidentitet och DMARC inriktning är separata frågor.
Stäng bevisregistret med två rader: vad mottagaren rapporterade vid leverans och vad den oberoende kontrollen observerade nu. Inkludera tidsstämplar, artefakthaschar, signaturidentitet och olösta skillnader. Detta bevarar ett användbart revisionsspår även när den ursprungliga miljön inte kan rekonstrueras.
Håll verifieringsomfånget åtskilt från DMARC
En passerande signatur upprättar det valda DKIM resultatet under den faktiska nyckelkällan, bytes och verifieringsreglerna. DMARC behöver också signeringsdomänens anpassning till From och en tillämplig policyutvärdering. Använd strömmen RFC 9989 avsnitt 5.3 och 5.4 i stället för att behandla varje DKIM pass som DMARC pass eller ett uttalande om säkert innehåll.
Anteckna historiska och aktuella resultat separat
- Bevara de sparade byten och deras fingeravtryck före analys.
- Identifiera den exakta signaturen, d=, s=, kanonisering och signerad täckning.
- Behåll offentlig nyckelkälla, uppslagstid, verifierarversion och diagnostik.
- Jämför transformationer och viktiga förändringar utan att anta manipulering.
- Behåll den ursprungliga mottagarrapporten och den nya utvärderingen som två tidsstämplade observationer.