Analysverktyg för e-posthuvuden

Vad ett e-posthuvud kan – och inte kan – visa

Internetbaserad e-post använder namngivna huvudfält följda av en tom rad och meddelandetexten. RFC 5322 definierar formatet, inklusive fältvikning: en rad som börjar med blanksteg fortsätter föregående fält. Analysverktyget vecklar ut dessa fortsättningar innan informationen tolkas. Det stannar vid den första tomma raden, så meddelandetext och bilagor analyseras inte.

Mail transfer agents lägger normalt till ett Received-fält först när meddelandet passerar en server. Fälten visas därför nyast först i råkällan. Rapporten vänder dem till en tidslinje som börjar vid ursprunget. En tidsskillnad visas bara om båda intilliggande tidsstämplarna kan tolkas. En negativ skillnad rapporteras som möjlig klockavvikelse och förhindrar beräkning av total transporttid; den ändras aldrig tyst till noll.

Så läser du autentiseringsdelen

RFC 8601 definierar Authentication-Results, ett fält som mottagarsystemet lägger till för att registrera resultat som spf=pass, dkim=pass eller dmarc=fail. Analysverktyget behåller dubbla Authentication-Results-fält eftersom ett meddelande kan passera flera administrativa domäner. Tillhörande egenskaper som smtp.mailfrom, header.d och header.from behålls såsom de rapporterats.

En DKIM-Signature innehåller metadata som signerande domän (d=), selektor (s=), algoritm (a=), identitet (i=) och långa kryptografiska värden (b= och bh=). Rapporten registrerar användbara taggar och om signaturvärden finns, men utesluter avsiktligt signaturblock från JSON-exporter. Inga DNS-uppslagningar eller kryptografiska verifieringar görs.

RFC 8617 definierar Authenticated Received Chain (ARC). En ARC-instans är strukturellt fullständig när den innehåller ARC-Seal, ARC-Message-Signature och ARC-Authentication-Results med samma i=-värde. ”Fullständig” beskriver bara dessa tre delar; kedjan är inte därmed giltig eller tillförlitlig.

Exempel på en leveransrutt

Anta att råkällan innehåller två Received-fält. Det undre säger att ursprunget lämnade meddelandet till ett relay klockan 10:00:03 +0000; det övre att relayservern nådde mottagaren klockan 10:00:10 +0000. Rapporten visar ursprungshändelsen först och beräknar ett observerat intervall på 7 sekunder. Tidszoner respekteras: 10:00:03 +0000 följt av 12:00:06 +0200 ger 3 sekunder, inte två timmar. Om den andra normaliserade tidsstämpeln ligger fem sekunder tidigare flaggas klockavvikelse och totalen lämnas otillgänglig.

Förtroendegränser och vanliga fallgropar

RFC 5321 beskriver SMTP-transport och spårningsinformationen som servrar lägger till. Huvuden från utanför ett betrott e-postsystem kan vara påhittade. Börja förtroendet vid en mottagare du kontrollerar och arbeta bakåt bara så långt mottagarens loggar och policyer motiverar. Skillnader mellan domänerna i synliga From och Return-Path är vanliga för e-postlistor, vidarebefordringstjänster och transaktionsplattformar; det är en observation, inte bevis på identitetsförfalskning.

Kodade ämnesrader och visningsnamn kan använda RFC 2047-kodade ord. Analysverktyget avkodar vanliga Base64- och quoted-printable-former i UTF-8, ISO-8859-1 och Windows-1252; format som inte stöds förblir synliga med en varning. Mycket stora fält- och hoppsamlingar begränsas för att hålla webbläsaren responsiv. Vid incidenthantering bör du spara originalmeddelandet separat: exporterna är kortfattade rapporter och innehåller avsiktligt inte rådata, meddelandetext, bilagor eller DKIM-signaturblock.

Integritet och exporter

Tolkning, urval, kopiering och export sker lokalt i den aktuella fliken. Trattstegen använder flikbunden sessionslagring, inte en webbadress, så råa huvuddata skickas inte via Livewire eller exponeras i navigeringsparametrar. Indatagränsen är 512 KiB. Tidslinjens CSV använder UTF-8 med byte-order mark och CRLF-rader; celler som börjar med tecken för kalkylbladsformler neutraliseras. JSON innehåller tolkade observationer och rapportens förbehåll, inte originalhuvudet.