En skärmdump för inkorgen innehåller sällan tillräckligt med bevis för att diagnostisera ett autentiseringsproblem. Börja med det exakta mottagna meddelandet i den berörda brevlådan. Spara när och var den erhölls och samla sedan in hela originalmeddelandevyn. Detta håller en senare analys knuten till den faktiska kopian som producerade den rapporterade upplevelsen.
Skaffa bevis på meddelandenivå
Referenser: RFC 6376 §3.7.
Googles webbläsarinstruktioner är att öppna e-postmeddelandet, använda Mer bredvid Svara, välja Visa original och kopiera hela rubriken. Välj det berörda meddelandet i stället för ett annat objekt i samma konversation. Spara den tillgängliga originalmeddelandeartefakten separat när en bytebevarande export är tillgänglig; en kopierad rubrik innehåller inte enbart allt som behövs för att återverifiera DKIM. Instruktioner för Gmail -huvudet.
Spela in brevlådekontext, insamlingstid och om artefakten är en råexport, kopierad text eller skärmdump. En analytiker bör veta om radslut, vikning eller MIME innehåll kan ha ändrats under insamlingen. Vidarebefordra inte meddelandet inline och beskriv det resulterande nya meddelandet som ett orört original.
Läs identiteter såväl som resultat
Referenser: RFC 8601 §5.
Google förklarar att informationen som skickats av och undertecknad av kan hjälpa till att inspektera autentisering, medan ett oautentiserat meddelande inte automatiskt är skräppost och ett autentiserat meddelande inte automatiskt är säkert. Behandla de visuella indikatorerna som en ingångspunkt och behåll sedan alla bevis för teknisk analys. Hjälp för Gmail -autentisering.
I den betrodda Authentication-Results fältet, bevara SPF resultat och dess utvärderade identitet, DKIM -resultatet och signeringsdomänen och DMARC resultat och synlig från domän. Kombinera inte resultat från orelaterade hopp till en tänkt mottagardom. Ett meddelande kan ha flera signaturer eller autentiseringsresultatfält, så registrera deras ordning och omfattning. RFC 8601.
Håll mottagna bevis åtskilda från omkontroll
Referenser: RFC 6376 §3.6, RFC 6376 §6.
Mottagarens resultat beskriver dess utvärdering vid handläggningstidpunkten. En lokal DKIM kontroll idag utvärderar de bytes och nyckelmaterial som finns tillgängligt idag. En nyckelrotation, ett ändrat DNS svar eller en modifierad export kan ge ett annat resultat utan att bevisa att den ursprungliga mottagaren hade fel. Rubriktext registrerar en påstådd observation; det är inte i sig en ny kryptografisk verifiering. RFC 6376 avsnitt 3 och 6.
Det medföljande syntetiska meddelandet har två fält Authentication-Results . Parsern returnerar båda istället för att tyst välja den första. Det här är ett extraktionstest, inte en Gmail infångning eller en förtroendealgoritm. I en verklig utredning måste den mottagande tjänsten och den betrodda vägen fastställa vilket resultat som är relevant.
Dela den minsta användbara artefakten
Referenser: RFC 8601 §7.
Behåll originalet begränsat. Skapa en separat märkt diagnostisk kopia när fullständigt meddelandeinnehåll eller personliga adresser är onödiga. Bevara domänrelationer och tidsstämplar som behövs för frågan och avslöja eventuella ändringar. För signaturverifiering, arrangera en auktoriserad säker överföring av de omodifierade byten istället för att låtsas som att en redigerad kopia alltid kan kontrolleras.
Google beskriver också en rubrikanalysator online, men genom att klistra in bevis i valfri analysator överförs det till den tjänsten. Granska reglerna för mottagare, data och organisationsdelning innan du gör det. Avsluta med ett tydligt uttalande om vad som observerades i Gmail , vad som antogs och vad som förblir oprövat.
Läs det kommenterade provet utan att ge förtroende
Referenser: RFC 8601 §5.
Det bibehållna anteckningsregistret listar varje råfält i ordning med dess faktiska generator, påstådda ursprung och förtroendegräns. Från är en identitet som tillhandahålls av författaren; Till är en visad mottagare snarare än bevis på SMTP kuvertet. Meddelande-ID, Datum och Ämne är avsändarkontrollerade sammanhang. Varje fält Authentication-Results gör anspråk på en rapporttjänst och ett resultat, men varken trusted.example eller untrusted.example fastställer äkta mottagarhärkomst. List-ID namnger listan med anspråk; Avregistreringsfälten beskriver en åtgärdsmekanism, inte listägande. I klassificeringsprovet är CAT, DIR, SCL och BCL uppfunna Microsoft-liknande domar, inte observationer från Microsoft. Ingen mottagen kedja, SPF -kuvertidentitet eller anslutande IP har upprättats.
Använd den här kartan som ett kommenterat undervisningsexempel. För ett verkligt meddelande, byt ut varje antaget ursprung med insamlings- och mottagarbevis och lämna alla overifierade gränser uttryckligen olösta.