Mailformater i forensics: EML, MSG og MBOX, og hvad de bevarer

Forside › E-mail forensics · Gennemgået oktober 2026 · Af John Nielsen

Valget af format afgør, hvilke oplysninger om en mail der overlever sikringen. EML gemmer mailen, som den blev transporteret over internettet, med alle headere og brødteksten byte for byte, hvis den er hentet korrekt. MSG gemmer Outlooks interne repræsentation med MAPI-egenskaber, som rummer oplysninger, der aldrig har været i selve mailen, men ikke altid den oprindelige MIME-struktur. MBOX samler mange mails i én fil og bruges af blandt andet Google Takeout og mange Unix-mailsystemer. Ingen af dem bevarer alt, og en konvertering mellem dem taber altid noget.

Den praktiske vejledning til brugere om at gemme en mail ligger på digitalbevissikring.dk. Her handler det om formaternes indre og konsekvenserne for analysen.

EML: den rå internetmail

En EML-fil er en tekstfil i det format, der er defineret for internetmail (RFC 5322) med MIME-kodning af indhold og vedhæftninger. Den indeholder:

alle headere i den rækkefølge, de blev skrevet, inklusive Received-kæden, Authentication-Results og DKIM-Signature,
brødteksten i de varianter, afsenderen sendte, typisk både ren tekst og HTML,
vedhæftninger kodet i base64 eller lignende.

Den afgørende fordel er, at en korrekt hentet EML-fil er de samme bytes, som modtagerserveren modtog, plus de headere, modtagersiden har tilføjet. Derfor kan DKIM-signaturen efterprøves, og headeranalysen kan bygge på rå data; se Analyse af mail-headere, SPF, DKIM og DMARC.

Men ikke alle EML-filer er rå. Når en mailklient gemmer en mail som EML, kan den genskabe MIME-strukturen ud fra sin egen interne lagring. Resultatet ligner en rå mail, men kodning, linjeskift, grænser mellem MIME-dele og rækkefølgen af headere kan være ændret. Det kan bryde DKIM og give et misvisende billede. Det sikreste er en EML hentet direkte fra serveren, fx via IMAP eller en funktion, der viser den originale kildetekst, og at metoden dokumenteres.

MSG: Outlooks egenskaber

En MSG-fil er en sammensat fil i Microsofts strukturerede lagringsformat, hvor hver MAPI-egenskab gemmes som en strøm. Den indeholder oplysninger, som ikke findes i en EML-fil:

Afsendelsestid fra klienten · Det tidspunkt, afsenderens klient indsendte mailen
Leveringstid · Det tidspunkt, mailen blev leveret i modtagerens postkasse
Oprettelses- og ændringstid · Hvornår emnet blev oprettet i postkassen, og hvornår det sidst blev ændret
Flag og kategorier · Opfølgningsflag, læst/ulæst, kategorier
Samtaleindeks · Placering i en samtaletråd
Transportheadere · Internetheaderne som én tekstværdi, for modtagne mails

Ændringstiden er særlig interessant, fordi den kan vise, at et emne er ændret efter modtagelsen, men den ændres også af harmløse handlinger som at markere som læst eller sætte et flag. Se Redigerede mails.

Svagheden er, at brødteksten i MSG-filen ofte er gemt som RTF, HTML eller ren tekst i Outlooks egen form, ikke som den oprindelige MIME-del. Transportheaderne er bevaret som tekst, men selve brødteksten kan være konverteret, og DKIM kan derfor sjældent efterprøves på en MSG-fil. For sendte mails findes der normalt ingen transportheadere, fordi mailen aldrig er modtaget fra internettet.

MBOX: mange mails i én fil

MBOX er en tekstfil, hvor mails ligger efter hinanden, adskilt af en linje, der begynder med “From ” efterfulgt af en adresse og et tidspunkt. Hver mail er i internetformat, så headere og MIME-struktur er som i EML. Der findes flere varianter, der håndterer linjer i brødteksten, som selv begynder med “From “, forskelligt, enten ved at sætte et større end-tegn foran eller ved at angive længden. Konverteres mellem varianterne, kan brødteksten ændres en smule, og det kan bryde DKIM.

Google Takeout leverer Gmail som MBOX og tilføjer egne headere, fx med Gmail-etiketter. Forskellene på Takeout og Vault er behandlet i Google Takeout eller Vault-eksport.

Hvad der tabes ved konvertering

Server til MSG · Den oprindelige MIME-krop, dermed muligheden for DKIM-kontrol
MSG til EML · MAPI-egenskaber som leveringstid, ændringstid, flag og samtaleindeks
EML til MSG · Rå bytes, rækkefølge af headere, evt. kodning
MBOX til enkelte EML · Separatorlinjens tidspunkt, evt. escaping af brødtekst
Alle til PDF · Alt teknisk: headere, struktur, vedhæftningernes originalfiler

Konsekvensen er, at sikringen bør tage det format, der er tættest på kilden, og at konverterede versioner kun bruges som arbejdskopier eller bilag.

Hvad hver kilde naturligt leverer

Exchange og Microsoft 365: eDiscovery-eksport giver typisk PST eller enkelte mails, ofte som MSG. Rå MIME kan i nogle tilfælde hentes via API. Se Microsoft Purview eDiscovery.
Gmail og Google Workspace: MBOX via Takeout eller Vault, enkelte mails som original kildetekst.
IMAP-servere: rå mails, der kan gemmes som EML.
Outlook lokalt: PST eller OST, hvor enkelte emner kan trækkes ud som MSG; se PST og OST.

Hashværdier

En EML-fil hentet rå to gange fra samme server bør give samme hashværdi, så længe serveren ikke har tilføjet headere imellem. En MSG-fil kan derimod få en anden hashværdi ved hver eksport, fordi filens interne struktur og nogle egenskaber kan skrives forskelligt, selv om indholdet er det samme. Det er ikke tegn på ændring, men det betyder, at hashværdien kun dokumenterer den konkrete eksport. Til produktioner med mange mails bruges et samlet hashmanifest; se Hashmanifest for filsamlinger.

Vedhæftninger og indlejrede mails

Vedhæftninger gemmes forskelligt i formaterne. I EML og MBOX ligger de som MIME-dele kodet i base64, og filen kan afkodes til præcis de bytes, afsenderen vedhæftede. I MSG ligger de som egne strømme med filnavn, størrelse og eventuelt oprettelsestid. I begge tilfælde bør vedhæftningen trækkes ud og hashes for sig, så den kan sammenlignes med filer fundet andre steder, fx på en computer eller i et cloudlager.

En særlig situation er en mail, der er vedhæftet en anden mail. I EML ligger den som en indlejret internetmail med sine egne headere, som kan analyseres på samme måde som hovedmailen. I MSG ligger den som et indlejret MAPI-objekt, hvor de oprindelige headere kan være bevaret eller tabt, afhængigt af hvordan den blev vedhæftet. Når en part videresender en mail som bevis, er det derfor værd at bede om den som vedhæftet fil frem for som videresendt tekst, og at kontrollere, hvilket format den indlejrede mail har.

Praktiske valg

Til headeranalyse og ægthed: rå EML fra serveren eller fra modtagerens postkasse.
Til spørgsmål om håndtering i postkassen: MSG eller PST, der bevarer MAPI-egenskaberne.
Til større mængder: PST eller MBOX fra en eDiscovery- eller arkivfunktion, ikke manuel lagring mail for mail.
I tvivl: sikr i begge formater og dokumentér, hvor hvert eksemplar kommer fra.

Dokumentation

Gem helst det oprindelige eksportformat ved siden af eventuelle konverterede bilag, så en modpart kan efterprøve, at bilaget svarer til kilden.

Notér for hver mail eller samling kilde, eksportmetode, værktøj og version, format og variant, hashværdi og tidspunkt. Er en mail konverteret, skal det fremgå hvorfra og hvortil, og hvilke egenskaber der derved er tabt. Det gør det muligt for en anden at vurdere, om et fund kan bygge på det pågældende eksemplar.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: E-mail forensics

Læs også: PST og OST: struktur, slettede emner og korruption · Message trace og transportlogs: leveringsspor på serversiden

→ E-mail forensics · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik