Antidatere en e-mail: hvad der er muligt og sporbart

Antidatere en e-mail: hvad taler vi egentlig om?

Spørgsmålet dukker jævnligt op i sysadmin-fora og MSP-Slack-grupper: kan man ændre datoen på en e-mail efter afsendelse? Det korte svar er ja, teknisk set. Men det fulde svar er langt mindre beroligende for den, der måtte have lyssky hensigter.

En e-mail er ikke en monolitisk fil. Det er en samling af tekstbaserede headere efterfulgt af et beskedindhold. Blandt disse headere bærer flere datoinformation. Og nogle er lettere at ændre end andre.

Tre lag af datering eksisterer i enhver e-mail:

• Headeren Date: (RFC 2822), skrevet af mailklienten ved afsendelse
• Headerne Received:, tilføjet af hvert server der videresender beskeden
• IMAP INTERNALDATE, en metadata gemt server-side, uafhængig af beskedindholdet

Hvert af disse lag kan modificeres. Intet af dem kan det uden at efterlade spor.

Ændre Date:-headeren: den mest åbenlyse manipulation

Headeren Date: er ren tekst i en .eml-fil. Teknisk set kan enhver hex-editor eller et Python-script omskrive den på få sekunder. Har du nogensinde åbnet de rå headere på en e-mail i Gmail (den lille menu "Vis original"), ved du, at det er læsbart for enhver.

Problemet? Siden 2004 signerer langt de fleste mailservere udgående e-mails med DKIM (DomainKeys Identified Mail). Denne kryptografiske signatur dækker eksplicit flere headere, herunder Date:, From:, Subject: og beskedindholdet. Signaturen gemmes i headeren DKIM-Signature:.

At ændre Date: efter signering ugyldiggør mekanisk DKIM-verifikationen. Enhver modtagerserver kan verificere signaturen ved at hente den offentlige nøgle i afsenderdomænets DNS. Stemmer signaturen ikke længere, markeres beskeden som ændret. Gmail, Outlook.com og alle store udbydere foretager denne kontrol automatisk.

(Vil du se en DKIM-signatur konkret, kan du åbne de rå headere på en e-mail modtaget fra Gmail eller Office 365: der finder du en linje som DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., der ligner støj, men reelt er et kryptografisk hash af hele beskeden.)

Resultat: at ændre Date: på en DKIM-signeret e-mail er at bryde seglet. Ændringen er synlig for enhver administrator, der ved, hvad han skal kigge efter.

Omskrive Received:-headere: en kæde der er svær at forfalske

Headerne Received: sporer den rute, en e-mail har taget fra afsender til modtager. Hver SMTP-server, der rører beskeden, tilføjer én med sit navn, sin IP-adresse og et tidsstempel. En e-mail, der passerer to eller tre relæer, indeholder altså to eller tre stablede Received:-headere.

Kan man ændre dem? Teknisk set, ja, på sin egen kopi af beskeden. Men her er fælden: modtageren har også en kopi. Og dennes server har tilføjet sin egen Received:-header sidst. Denne header er under modtagerens kontrol, ikke afsenderens. Den er umulig at forfalske udefra.

Kædens konsistens kan verificeres. Hvis tidsstemplerne i de successive Received:-headere er inkonsistente (et mellemliggende relæ ville have modtaget beskeden, før afsenderen sendte den, for eksempel), er det øjeblikkeligt mistænkeligt. Forensiske e-mailanalyseværktøjer som MXToolbox eller sikkerhedsteamenes interne værktøjer kontrollerer præcis dette.

Faktisk er det ikke helt præcist at sige, at Received:-headerne er umulige at forfalske fuldstændigt: en angriber der kontrollerer sin egen mailinfrastruktur kan fabrikere troværdige headere for de relæer, han behersker. Men han kontrollerer aldrig det sidste led: modtagerens server.

IMAP INTERNALDATE: det mest tekniske tilfælde

INTERNALDATE er en IMAP-metadata gemt server-side. Det er ikke en header i selve beskeden: det er en værdi, serveren knytter til beskeden i sin interne database. Det er denne værdi, de fleste mailklienter bruger til at sortere beskeder i indbakken.

IMAP-kommandoen APPEND gør det muligt at deponere en besked på en server med eksplicit angivelse af en INTERNALDATE. Det er en legitim protokolfunktion, dokumenteret i RFC 3501. Migrationsværktøjer bruger den konstant: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... alle deponerer e-mails på destinationsserveren med en angivet INTERNALDATE.

Teoretisk set kunne en person med IMAP-adgang til sin egen postkasse deponere en e-mail med en vilkårlig INTERNALDATE. Men denne manipulation ændrer ikke beskedens headere. Den originale Date: forbliver intakt, Received:-headerne forbliver intakte, DKIM-signaturen forbliver intakt. Kun server-side sorteringsmetadataene ændres.

For en ekspert, der undersøger den rå besked, er uoverensstemmelsen mellem INTERNALDATE og Date: øjeblikkeligt synlig. Og er beskeden DKIM-signeret, er den originale dato kryptografisk attesteret.

Message-ID: et fingeraftryk der er svært at forfalske

Hver e-mail genererer et unikt id, headeren Message-ID:. Dette id konstrueres af den afsendende SMTP-server ved afsendelse, typisk ved at kombinere et tidsstempel, et tilfældigt id og serverens domænenavn.

Et typisk Message-ID ser sådan ud: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Tidsstemplet er ofte kodet direkte ind i id'et. At ændre beskedens dato og efterlade et Message-ID med et inkompatibelt tidsstempel skaber en uoverensstemmelse, der er øjeblikkeligt sporbar.

Desuden indekseres Message-ID'er af store meddelelses-systemer. Google, Microsoft og andre aktører vedligeholder logs, der gør det muligt at spore, hvornår en besked faktisk cirkulerede på deres infrastruktur. I en juridisk eller forensisk sammenhæng er disse logs tilgængelige via retslige procedurer.

I praksis: hvem kan opdage et manipulationsforsøg?

Lad os stille spørgsmålet konkret. Du modtager en e-mail, og du har mistanke om, at datoen er blevet ændret. Hvad kan en IT-administrator eller advokat med en smule teknisk baggrund gøre?

• DKIM-verifikation: i Gmail viser menuen "Vis original" direkte resultatet af DKIM-verifikationen øverst på siden. Et "PASS" bekræfter beskedens integritet siden afsendelse. Et "FAIL" eller "SOFTFAIL" signalerer en ændring.
• Header-analyse: værktøjer som MXToolbox Header Analyzer eller Google Admin Toolbox parser automatisk Received:-kæden og markerer tidsmæssige inkonsistenser.
• Message-ID / Date-konsistens: en analytiker kan sammenligne tidsstemplet kodet i Message-ID med værdien i den angivne Date:.
• Server-logs: hvis e-mailen har passeret en server, du administrerer, indeholder SMTP-loggene den reelle dato og tid for beskedens accept, uafhængigt af enhver header.

Kort sagt er detektionsværktøjerne tilgængelige, gratis og kræver ingen avanceret forensisk ekspertise. En nysgerrig IT-admin kan verificere en e-mails integritet på under to minutter.

Det eneste legitime tilfælde af masserettelse af datoer: IMAP-migrering

Der er ét scenarie, hvor hundredtusindvis af e-mails ender med forkerte datoer uden nogen ondsindet hensigt: IMAP-migrering.

Du har netop afsluttet en migrering af 150 Exchange-postkasser til Google Workspace. Mandag morgen ruller tickets ind. Brugerne rapporterer, at alle deres gamle e-mails vises med den samme dato, nemlig migreringsweekenden. Deres indbakker er ulæselige.

Det, der skete, er dokumenteret og forudsigeligt: migrationsværktøjet (BitTitan, CloudM, imapsync, ligegyldigt hvilket) deponerede e-mails på Google Workspace via IMAP APPEND. Det angav en INTERNALDATE svarende til migrationsdatoen, ikke e-mailens originale dato. Resultat: Outlook, der som standard sorterer efter INTERNALDATE, viser migrationsdatoen for alle beskeder. Artiklen om forkerte e-maildatoer efter migrering forklarer denne mekanisme i detaljer.

Den originale Date:-header er intakt i hver besked. DKIM-signaturer er intakte. Indholdet er urørt. Det er udelukkende INTERNALDATE server-side, der er forkert.

Dette problem rammer BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO og alle værktøjer, der bruger IMAP APPEND uden korrekt at bevare INTERNALDATE. Artiklen om BitTitan MigrationWiz dækker dette værktøjs særlige karakteristika. Migreringschecklisten opregner, hvad man bør tjekke før og efter en migrering for at undgå den slags problemer.

Forskellen på at rette og at forfalske

Den rettelse Redate.io foretager er det stik modsatte af et forfalsningsforsøg. Den proprietære korrektionsmotor analyserer header-kæden i hver besked, identificerer den originale dato kodet i Date:-headeren (RFC 2822), der aldrig er blevet ændret, og retter datometadataene for at bringe dem i overensstemmelse med denne autentiske information, der allerede er til stede i beskeden.

Headeren Date: er kilden til sandheden. Den blev skrevet af afsenderens mailklient på afsendelsestidspunktet. Den er dækket af DKIM-signaturen. Den ændres ikke af Redate.io. Det, der rettes, er den uoverensstemmelse, migrationsværktøjet har introduceret, ikke den originale dato.

At rette 47.000 e-mails efter en mislykket migrering uden at miste en eneste, uden at bryde tråde, uden at ødelægge vedhæftede filer, uden at udløse 429-fejl kl. 3 om natten på Google API'et: det kræver en multi-etape analysepipeline med håndtering af kanttilfælde (S/MIME, PGP, ikke-ASCII-kodninger i RFC 2047, komplekse multipart-strukturer). Et Python-script på fem linjer ville ikke overleve den første produktionspostkasse. Artiklen om rettelse af e-maildatoer efter migrering beskriver, hvorfor gør-det-selv er risikabelt ved reelle volumener.

Redate.io scanner postkasser gratis, identificerer e-mails med forkerte datoer og retter via en valideringspipeline, der verificerer hver besked individuelt. Originalerne bevares i en synlig backup-mappe i 30 dage. Går noget galt, er tilbagerulning mulig.

Har din migrering forskudt dine e-mails datoer? Start en gratis scanning på Redate.io for at vurdere problemets omfang, inden du beslutter, hvad du vil gøre.