MailHeaderAnalyzer: analysere e-posthoder i PowerShell uten nettverkstilgang

MailHeaderAnalyzer er en PowerShell-modul med to cmdleter. Get-MailHeaderAnalysis analyserer hodet i en e-post: leveringskjede med forsinkelser og TLS-informasjon, SPF-, DKIM-, DMARC- og ARC-resultater inkludert opprinnelseskontroll mot authserv-id-en til gatewayen din, DMARC-alignment, hybridklassifiseringen til Exchange Online, vurderingene fra Microsoft Defender, SpamAssassin og Rspamd samt avvik som doble From-linjer eller Unicode-kontrolltegn. ConvertTo-MailHeaderReport oppretter en rapport for saker. Modulen arbeider helt frakoblet: ingen DNS-oppslag, ingen HTTP-forbindelser. Den er kommandolinjeutgaven av Header Analyzer på dette nettstedet og bruker samme analyselogikk.

Parameteroversikt

Begge cmdletene støtter Common Parameters -Verbose, -ErrorAction, -ErrorVariable, -OutVariable og de øvrige fra about_CommonParameters.

Installasjon

Install-Module -Name MailHeaderAnalyzer -Scope CurrentUser

På et system uten internettforbindelse laster du ned modulen på en annen maskin med Save-Module -Name MailHeaderAnalyzer -Path C:\Temp og kopierer mappen MailHeaderAnalyzer til en katalog fra $env:PSModulePath, for eksempel %USERPROFILE%\Documents\WindowsPowerShell\Modules (Windows PowerShell 5.1) eller %USERPROFILE%\Documents\PowerShell\Modules (PowerShell 7). Oppdateringer henter Update-Module -Name MailHeaderAnalyzer, og installert versjon vises av Get-Module -Name MailHeaderAnalyzer -ListAvailable.

Get-MailHeaderAnalysis

Analyserer hodet i en e-post og returnerer et analyseobjekt.

Syntaks

Text (standard)

Get-MailHeaderAnalysis
    [-Header] <String[]>
    [-TrustedAuthServId <String[]>]
    [<CommonParameters>]

Path

Get-MailHeaderAnalysis
    -Path <String[]>
    [-TrustedAuthServId <String[]>]
    [<CommonParameters>]

Clipboard

Get-MailHeaderAnalysis
    -FromClipboard
    [-TrustedAuthServId <String[]>]
    [<CommonParameters>]

Beskrivelse

Cmdleten deler råhodet inn i felt, folder ut RFC 5322-linjeskift og dekoder RFC 2047-verdier i emne og adresser. Fra Received-linjene danner den leveringskjeden i kronologisk rekkefølge, beregner forsinkelsen per stasjon og leser TLS-versjon, chiffer og protokollklasse etter RFC 3848. Fra Authentication-Results, Received-SPF, DKIM-Signature og ARC-kjeden fastslår den autentiseringsresultatene og tilordner hver kontrollinje en opprinnelse (RFC 8601, avsnitt 5): dokumentert dersom authserv-id-en finnes i -TrustedAuthServId, ellers kun plausibel eller udokumentert, se AuthTrust. I tillegg kommer DMARC-alignment, hybridklassifiseringen av Exchange Online, spamfiltervurderinger og en liste over avvik.

Cmdleten utfører ingen DNS-oppslag og åpner ingen nettverkstilkobling. Spf, Dkim, Dmarc og Arc er derfor alltid mottakerserverens vurdering. DKIM- og ARC-signaturer etterberegnes ikke kryptografisk; for ARC-kjeden kontrollerer cmdleten bare strukturen (ArcStructure).

Inndata leses tolerant: En tom linje avslutter hodet, og etterfølgende meldingstekst ignoreres. Linjer uten feltnavn og uten innledende mellomrom, slik de oppstår ved kopiering fra klientdialoger, hører til forrige felt. En mbox-skillelinje From ... før første felt hoppes over, og et byteordningsmerke fjernes. Maksimalt 200 Received-linjer analyseres, telt fra leveringen.

Eksempler

Eksempel 1

Get-MailHeaderAnalysis -FromClipboard

Analyserer hodet som ligger på utklippstavlen. I Outlook for Windows finner du hodet under Fil, Egenskaper, Internett-hodelinjer; i Outlook på nettet under meldingsalternativene, under «Vis meldingsdetaljer».

Subject     : Service-Report für März
From        : Beispiel Newsletter <news@example.org>
Date        : 2026-08-03 09:14:27Z
SPF         : pass
DKIM        : pass
DMARC       : pass
ARC         : -
CompAuth    : pass (reason 100)
AuthTrust   : Absent (no authserv-id, Microsoft 365 style)
Hops        : 3 (total 00:00:42)
DeliveredBy : zr0p278mb0570.chep278.prod.outlook.com
Findings    : none

Eksempel 2

Get-MailHeaderAnalysis -Path .\nachricht.eml

Analyserer en lagret melding. Filen kan inneholde bare hodet eller hele meldingen; meldingsteksten ignoreres.

Eksempel 3

(Get-MailHeaderAnalysis -Path .\nachricht.eml).Hops

Viser leveringskjeden som tabell, med første hop først.

#   From                 IP              By                                     Protocol   TLS      Time (UTC)           Delay
-   ----                 --              --                                     --------   ---      ----------           -----
1   client.example.net   198.51.100.34   mail.example.org                       ESMTPSA    -        2026-08-03 09:14:28  -
2   mail.example.org     203.0.113.25    mx.eur02.prod.protection.outlook.com   Microsoft… TLS 1.3  2026-08-03 09:15:09  41 s
3   AM0EUR02FT056.eop…   -               ZR0P278MB0570.CHEP278.PROD.OUTLOOK.COM Microsoft… TLS 1.2  2026-08-03 09:15:10  1 s

Eksempel 4

Get-Content -Path .\header.txt | Get-MailHeaderAnalysis | Select-Object -ExpandProperty Findings

Leser hodet linje for linje fra en tekstfil og viser bare avvikene. -Raw ved Get-Content er ikke nødvendig; cmdleten setter selv sammen linjene.

Eksempel 5

Get-ChildItem -Path .\export\*.eml |
    Get-MailHeaderAnalysis |
    Select-Object Source, Subject, Spf, Dkim, Dmarc, AuthTrust, HopCount,
        @{ Name = 'Findings'; Expression = { ($_.Findings.Code | Sort-Object -Unique) -join ',' } } |
    Export-Csv -Path .\auswertung.csv -NoTypeInformation -Encoding UTF8

Analyserer alle meldinger i en mappe og skriver en CSV-fil med én linje per melding. Den beregnede kolonnen oppsummerer funnkodene.

Eksempel 6

Get-ChildItem .\export\*.eml |
    Get-MailHeaderAnalysis -TrustedAuthServId 'mx.example.org' |
    Where-Object AuthTrust -ne 'Trusted' |
    Select-Object Source, AuthTrust, AuthServId, DeliveredBy

Lister meldinger der kontrollresultatene ikke kommer fra egen inngangsgateway mx.example.org. Ved phishing-analyser er dette et første filter. Uten -TrustedAuthServId kan du bare filtrere etter Unmatched; en forfalskning som i tillegg inneholder en passende Received-linje, vises da som Matched og slipper gjennom filteret.

Eksempel 7

$a = Get-MailHeaderAnalysis -Path .\nachricht.eml
$a.Hops[$a.SlowestHopIndex - 1] | Format-List Index, FromHost, ByHost, Delay

Viser stasjonen med størst forsinkelse. SlowestHopIndex er 1-basert, arrayet Hops er 0-basert.

Eksempel 8

Get-MailHeaderAnalysis -Path .\nachricht.eml | ConvertTo-Json -Depth 6 | Set-Content .\analyse.json

Skriver hele analysen som JSON. -Depth 6 er nødvendig fordi Hops, DkimSignatures og Exchange er nestede objekter; standardverdien 2 ville bare vise dem som typenavn.

Parametere

-Header

Hodet som tekst. Parameteren godtar én enkelt streng med hele hodet eller flere strenger; pipeline-inndata samles inn og settes sammen til ett hode til slutt, derfor fungerer Get-Content datei | Get-MailHeaderAnalysis uten -Raw. Hvis flere hoder skal analyseres separat, bruker du -Path med flere filer.

Aliaser: Text, Raw, InputObject

-Path

Bane til en fil som inneholder hodet eller en fullstendig .eml-melding. Relative baner løses mot gjeldende katalog. Filen leses med [System.IO.File]::ReadAllText: Et byteordningsmerke tas hensyn til, uten BOM brukes UTF-8. Det opprettes et eget resultatobjekt for hver fil; manglende filer gir en ikke-terminerende feil.

Aliaser: FullName, PSPath, LiteralPath

-FromClipboard

Leser hodet fra utklippstavlen med Get-Clipboard -Raw. Parameteren er bare tilgjengelig på Windows; på Linux og macOS avslutter cmdleten med en feilmelding, og det samme skjer når utklippstavlen er tom.

-TrustedAuthServId

Authserv-id-en eller authserv-id-ene som inngangsgatewayen din skriver i Authentication-Results, for eksempel mx.example.org. Cmdleten sammenligner eksakt, uten hensyn til store og små bokstaver og uten underdomener. Kontrollinjer med én av disse ID-ene får AuthTrust = Trusted, og bare disse inngår deretter i Spf, Dkim, Dmarc og Arc. Det samme gjelder receiver= i en Received-SPF-linje.

Resultatet er bare så pålitelig som gatewayen: Den må fjerne innkommende Authentication-Results-linjer som hevder å ha dens egen authserv-id (RFC 8601, avsnitt 5). Om den gjør dette, kan ikke leses ut av et hode. Hvis to linjer med klarert ID motsier hverandre, rapporterer cmdleten AuthTrustedConflict. Microsoft 365 skriver ingen authserv-id i kontrollinjen sin; hvis Exchange Online mottar e-posten din, lar du parameteren være utelatt.

For en hel økt kan verdien lagres som standard, for eksempel i PowerShell-profilen:

$PSDefaultParameterValues['Get-MailHeaderAnalysis:TrustedAuthServId'] = 'mx.example.org'

Inndata

System.String: Hodelinjer eller hele hodet, til -Header.

System.IO.FileInfo: Filobjekter fra Get-ChildItem, hvis FullName bindes til -Path.

Utdata

MailHeaderAnalyzer.Analysis: ett objekt per analysert hode. Egenskapene er beskrevet i avsnittet Utdataobjekt.

Merknader

Analyseteksten (forklaringer i Findings, CompAuthReasonMeaning og betydningsfeltene) er på engelsk, slik at den kan settes uendret inn i internasjonale saker. Utdataene i standardvisningen kan vises fullt ut med Format-List *.

ConvertTo-MailHeaderReport

Oppretter en rapport fra et analyseobjekt som Markdown eller tekst.

Syntaks

ConvertTo-MailHeaderReport
    [-Analysis] <Object>
    [-Format <String>]
    [<CommonParameters>]

Beskrivelse

Rapporten omfatter emne, avsender, dato og Message-ID, autentiseringsresultatene med opprinnelsesinformasjon og alignment, alle funn, leveringskjeden, Exchange-klassifiseringen og verdiene fra spamfiltrene. Unicode-kontrolltegn for skriveretning forblir synlige i rapporten som <U+...>, slik at de ikke kan komme inn i et sakssystem via rapporten. Den siste linjen angir modulversjonen.

Eksempler

Eksempel 1

Get-MailHeaderAnalysis -Path .\nachricht.eml | ConvertTo-MailHeaderReport | Set-Clipboard

Oppretter en Markdown-rapport og legger den på utklippstavlen.

# Email header analysis

- Subject: Service-Report für März
- From: Beispiel Newsletter <news@example.org>
- Date: 2026-08-03T09:14:27Z
- Message-ID: <20260803091427.4Wq2Wx5RbTz@mail.example.org>

## Authentication

- spf: pass
- dkim: pass
- dmarc: pass
- compauth: pass (reason=100: passed authentication)
- Results without authserv-id (Microsoft 365 style)
- DMARC alignment: SPF Strict, DKIM Strict

## Delivery chain (total: 42 s)

| # | From | By | Protocol | TLS | Time (UTC) | Delay |
|---|---|---|---|---|---|---|
| 1 | client.example.net (198.51.100.34) | mail.example.org | ESMTPSA | - | 2026-08-03T09:14:28Z | - |
| 2 | mail.example.org (203.0.113.25) | mx.eur02.prod.protection.outlook.com | Microsoft SMTP Server | TLS 1.3 | 2026-08-03T09:15:09Z | 41 s |
| 3 | AM0EUR02FT056.eop-EUR02.prod.protection.outlook.com | ZR0P278MB0570.CHEP278.PROD.OUTLOOK.COM | Microsoft SMTP Server | TLS 1.2 | 2026-08-03T09:15:10Z | 1 s |

Eksempel 2

Get-MailHeaderAnalysis -FromClipboard | ConvertTo-MailHeaderReport -Format Text

Gir ut rapporten som tekst uten Markdown-formatering, for eksempel for e-post eller konsolllogger.

Eksempel 3

Import-Module MailHeaderAnalyzer
Get-MailHeaderAnalysis -Path 'C:\Temp\bounce.eml' | ConvertTo-MailHeaderReport -Format Text

Bruk i Exchange Management Shell. Hvis $env:PSModulePath der er begrenset av gruppepolicyer, laster du modulen med Import-Module og hele banen til .psd1-filen.

Parametere

-Analysis

Analyseobjektet fra Get-MailHeaderAnalysis. Cmdleten avviser andre objekttyper med en bindingsfeil.

-Format

Utdataformatet. Gyldige verdier:

• Markdown: Overskrifter, punktlister og leveringskjeden som tabell. Standard.
• Text: Overskrifter med store bokstaver, innrykkede linjer, leveringskjeden som nummerert liste.

Inndata

MailHeaderAnalyzer.Analysis: resultatet fra Get-MailHeaderAnalysis.

Utdata

System.String: rapporten, én streng per analyseobjekt.

Utdataobjekt

Get-MailHeaderAnalysis returnerer ett objekt av typen MailHeaderAnalyzer.Analysis per inndata. Standardvisningen viser sammendraget fra eksempel 1; alle egenskaper er tilgjengelige via Select-Object, Format-List * eller ConvertTo-Json.

MailHeaderAnalyzer.Analysis

MailHeaderAnalyzer.Hop

Hver oppføring i Hops tilsvarer en Received-linje. Rekkefølgen er kronologisk, altså motsatt av rekkefølgen i hodet.

AuthTrust: opprinnelse til kontrollresultatene

En Authentication-Results-linje kan enhver avsender selv skrive i en melding, og det samme gjelder en passende Received-linje. Bare fra hodet kan det derfor ikke dokumenteres hvem som skrev en kontrollinje. Ifølge RFC 8601, avsnitt 5, er bare linjen avgjørende dersom authserv-id-en er kjent av den mottakende organisasjonen som dens egen, og inngangsgatewayen må fjerne innkommende linjer med denne ID-en. Cmdleten gjengir denne regelen med -TrustedAuthServId. Uten denne parameteren sammenligner den authserv-id-en bare med by-vertene i Received-kjeden (samme domene eller underdomene, alltid ved punktgrensen, ikke delstreng); dette er en plausibilitetskontroll.

Hvis hodet inneholder kontrollinjer fra flere opprinnelser, rapporterer funnet AuthMixedOrigins forholdet. Mangler det en kontrollinje, men det finnes en Received-SPF-linje, overtas resultatet som Spf og merkes med ReceivedSpfOnly.

Med -TrustedAuthServId kommer to funn i tillegg: AuthNotTrusted, hvis ingen kontrollinje har en klarert ID, og AuthTrustedConflict, hvis to slike linjer rapporterer ulike resultater for spf, dmarc, arc eller compauth. Det andre tilfellet betyr at minst én linje ikke stammer fra gatewayen og at gatewayen ikke har fjernet den. Cmdleten overtar i dette tilfellet den øverste linjen; hvilken av de to som er ekte, kan ikke avgjøres fra hodet. DKIM er unntatt fra denne sammenligningen, ettersom flere signaturer legitimt kan ha ulike resultater.

ARC-kjede: struktur og vurdering

For ARC leverer cmdleten to separate opplysninger. Arc er resultatet arc= fra den avgjørende kontrollinjen, altså vurderingen fra mottakeren som kontrollerte signaturene i kjeden. ArcStructure er modulens egen kontroll og gjelder bare strukturen etter RFC 8617: fortløpende instansnumre i=1 til i=n (maksimalt 50), nøyaktig én ARC-Seal, én ARC-Message-Signature og én ARC-Authentication-Results per instans, samt cv=none i instans 1 og cv=pass i alle påfølgende. Modulen etterberegner ikke signaturer; Consistent sier derfor ingenting om hvorvidt kjeden er ekte. Avvik vises i ArcStructureIssues og i funnet ArcStructureInconsistent.

Opplysningene i ARC-Authentication-Results er uttalelser fra den aktuelle videresendingen. Funnet DkimBrokenAfterForward vurderer derfor bare en DKIM-feil som følge av videresending dersom mottakeren selv rapporterer arc=pass og en tidligere instans har registrert DKIM-pass for samme domene.

DMARC-alignment

SpfAlignment sammenligner konvoluttavsenderdomenet med From-domenet, DkimAlignment sammenligner d=-domenet til den kontrollerte signaturen med From-domenet. Strict betyr identisk domene, Relaxed samme organisasjonsdomene, None ingen samsvar. Organisasjonsdomenet bestemmes heuristisk: De to siste etikettene, eller de tre siste ved kjente sammensatte endelser som co.uk eller com.au. En komplett Public Suffix List er ikke inkludert.

MailHeaderAnalyzer.ExchangeClassification

Hvis hodet inneholder feltene X-MS-Exchange-Organization-*, X-OriginatorOrg eller X-MS-Exchange-CrossTenant-*, fyller cmdleten egenskapen Exchange. Betydningene følger Exchange-teamets artikkel «Demystifying hybrid mail flow»; bakgrunnen finnes i artikkelen Exchange-hybridhoder: internt eller eksternt?.

MailHeaderAnalyzer.SpamAssessment

Egenskapen Spam oppsummerer vurderingene fra de kjente filtrene. Verdiene stammer fra eksterne systemer og dekodes, men vurderes ikke.

Den fullstendige listen over compauth-Reason Codes finnes i artikkelen Microsoft 365 compauth: Reason Codes.

Findings

Cmdleten leverer avvik som objekter i Findings, hver med Severity (Info, Warning, Fail), en stabil Code for filtre og skript samt en forklaring i Message.

Virkemåte og begrensninger

Modulen leser det som står i hodet, og utleder fra dette hva som kan dokumenteres uten eksterne oppslag. Dette medfører noen begrensninger:

• Ingen kryptografisk kontroll. DKIM- og ARC-signaturer etterberegnes ikke, og DNS-poster slås ikke opp. Spf, Dkim, Dmarc og Arc er alltid mottakerserverens vurdering; ArcStructure kontrollerer bare kjedens struktur.
• Opprinnelse kan bare dokumenteres med kjennskap til gatewayen. Uten -TrustedAuthServId er AuthTrust en plausibilitetskontroll. Med parameteren avhenger utsagnet av at gatewayen fjerner fremmede kontrollinjer med sin authserv-id; modulen kan ikke kontrollere dette.
• Bare den siste Received-linjen er dokumentert. Alle linjer under den ble levert av avsenderen og kan være utformet vilkårlig. Attested markerer forskjellen; forsinkelsene for tidligere hopp bygger på opplysningene i disse linjene.
• Organisasjonsdomener er heuristiske. For Relaxed Alignment bruker modulen en kort liste over sammensatte endelser, ikke en komplett Public Suffix List.
• AuthMechanism er bare delvis dokumentert. Bortsett fra verdien 10 har Microsoft ikke offentliggjort kodene; modulen finner ikke på betydninger.
• Tegnsett. RFC 2047-verdier dekodes med kodingene .NET kjenner på det aktuelle systemet. Ukjente tegnsett forblir uendret.

Personvern

Et fullstendig hode inneholder interne vertsnavn, IP-adresser, avsender, mottaker og emne. Hvorfor disse opplysningene ikke hører hjemme i et nettbasert verktøy, forklares i artikkelen Analyser e-posthoder uten å laste opp e-posten. For modulen gjelder samme løfte som for nettleserversjonen: ingen nettverkstilgang. Testpakken til modulen inneholder en test som feiler så snart en nettverks- eller DNS-cmdlet dukker opp i kildekoden.

Kildekode og versjoner

Kildekoden er tilgjengelig under MIT-lisensen på GitHub. Analyselogikken er en portering av biblioteket som også Header Analyzer på dette nettstedet bruker; begge deler testtilfellene. Kontinuerlig integrasjon kontrollerer hver endring med PSScriptAnalyzer og Pester på Windows PowerShell 5.1, PowerShell 7 under Windows, Ubuntu og macOS. Publiseringer i PowerShell Gallery skjer automatisk fra versjonerte tagger; endringene for hver versjon finnes i Changelog.

Versjon 0.2.0 fra 26. september 2026 skjerpet opprinnelsesmodellen etter en merknad i en gjennomgang fra @saltyslugga: parameteren -TrustedAuthServId, nivået Trusted, Matched kun som plausibilitet. Egenskapen ArcValid er fjernet og erstattet med ArcStructure og ArcStructureIssues; skript som evaluerer ArcValid må tilpasses.

Feil og ønsker om utvidelser mottar jeg som Issue på GitHub. Anonymiser testhoder for feilrapporter på forhånd; de medfølgende testtilfellene bruker utelukkende eksempeldomener etter RFC 2606 og adresser etter RFC 5737.

Endringslogg

• 25. oktober 2026: Kilden RFC 7489 erstattet med RFC 9989, som har erstattet DMARC-spesifikasjonen siden mai 2026.