Analysere e-postheadere uten å laste opp e-posten: lokalt i nettleseren i stedet for i et nettverktøy

Den vanlige måten å analysere en e-postheader på, ser slik ut: Kopier headeren fra e-postklienten, lim den inn i et nettverktøy og la den analyseres. Det er praktisk, men hele headeren sendes da til serveren til verktøyleverandøren. De færreste er klar over nøyaktig hva de overfører med dette.

Hva en header faktisk inneholder

En komplett header fra en e-post i et bedriftsmiljø inneholder vanligvis:

• Interne vertsnavn og IP-adresser: Hver Received-linje dokumenterer en server på leveringsveien, inkludert interne Exchange-servere, gatewayer og lastbalanserere med FQDN og ofte privat IP-adresse. Til sammen gir dette en skisse av e-postinfrastrukturen.
• Personopplysninger: Avsender- og mottakeradresser, visningsnavn, emne, Message-IDs og, avhengig av klienten, IP-adressen til den opprinnelige avsenderen.
• Programvare og versjoner: Received-linjer og produktspesifikke headere oppgir produktene som brukes, delvis med versjonsnumre.
• Organisasjonsintern vurdering: I Microsoft 365 for eksempel hele spam- og autentiseringsvurderingen, tenant-identifikatorer og den interne klassifiseringen av meldingen.

For en angriper er dette nyttig materiale til forberedelser, og for personvernet er det personopplysninger: avsender, mottaker og emne for en konkret melding. Etter den reviderte personvernloven er behandlingen i et utenlandsk nettverktøy fortsatt en utlevering til en tredjepart, i tvilstilfeller til utlandet. For en header fra en kundes support-sak blir spørsmålet enda mer alvorlig: Å lime inn kundens data i et eksternt nettverktøy er vanskelig å begrunne uten rettslig grunnlag eller samtykke.

Analysen trenger ingen server

Det avgjørende poenget: En header er ren tekst, og analysen av den er ren parsing. Å sortere Received-kjeden kronologisk, beregne tidsforskjeller, dekode Authentication-Results og sammenligne domener: Ingenting av dette krever en serverkomponent. Alt kjører i JavaScript i nettleseren, uten at headeren forlater enheten.

Et verktøy som er bygget slik, skiller seg grunnleggende fra en klassisk nettbasert analyzer når det gjelder personvern: Ingen overføring, ingen lagring hos leverandøren, ingen loggfiler med andres headere. Analysen av en kundes header blir dermed på samme nivå som å åpne filen i en lokal editor, bare mer lesbar.

Hva et lokalt verktøy kan gjøre

Mail-Header-Analyzer på dette nettstedet er bygget etter dette prinsippet. Headeren som limes inn, analyseres utelukkende lokalt i nettleseren. Funksjonsomfanget viser at ingenting går tapt:

• Leveringsvei med behandlingstider: Received-kjeden sorteres kronologisk, oppholdstiden per stasjon beregnes og den lengste delen markeres. Slik blir det synlig hvor en langsom levering faktisk hang. Klokkeavvik mellom servere oppdages og vises.
• Transportkryptering per hop: TLS-versjon og cipher leses fra Received-linjene der den mottakende serveren logger dem; Microsoft, Postfix og Exim skriver ulike formater.
• Autentisering: SPF-, DKIM- og DMARC-resultater fra Authentication-Results (RFC 8601), inkludert detaljer som header.d, smtp.mailfrom og Microsofts compauth med Reason-Code.
• DMARC-alignment: From-domene, Envelope-From og DKIM-domene vises ved siden av hverandre, vurdert etter strict og relaxed alignment.
• ARC- og DKIM-integritet: Egne spor i flytdiagrammet viser hvorfra til hvor DKIM-hashen var intakt, og fra hvilken stasjon ARC-kjeden bevarer kontrollresultatene.
• Microsoft-miljøer: Spamfilterfeltene (X-Forefront-Antispam-Report, SCL, CAT) dekodes, tenant-overganger og hybridklassifiseringen i leveringsveien markeres.

Én begrensning gjelder for alle headerverktøy, lokalt eller ikke: Det viser den dokumenterte vurderingen fra mottaksserveren, ikke en egen etterkontroll. Om en SPF-record fortsatt ser slik ut i dag som på mottakstidspunktet, kan headeren ikke svare på.

Vurdering av de øvrige verktøyene

Også enkelte andre leverandører analyserer nå på klientsiden; en titt på personvernerklæringen og nettverkskonsollen i nettleseren avklarer om det faktisk ikke sendes noen forespørsel med headerinnholdet når det limes inn. For klassiske serverbaserte analysatorer gjelder den enkle regelen: Ikke lim inn headere fra produksjonsmiljøer eller fra tredjeparter, men høyst anonymiserte eksempler.

For regelmessige analyser av incident- eller support-headere er et lokalt kjørende verktøy derfor det nærliggende valget: Spørsmålet om hvor dataene har havnet, oppstår ikke.