Kan man ændre datoen på en modtaget e-mail?

Det spørgsmål alle stiller (og hvorfor det dækker over to helt forskellige situationer)

Skriv "ændre dato på modtaget e-mail" i Google. Du finder snesevis af tråde på Microsoft Q&A-forums, Reddit-diskussioner og Quora-spørgsmål. Ønsket er klart, men baggrunden er vidt forskellig afhængig af, hvem der spørger.

Der er dem, der vil forfalske en dato med tilbagevirkende kraft, af årsager man helst ikke vil forestille sig. Og så er der IT-administratorer, der efter en IMAP-migrering ser alle deres e-mails vise samme dag (migrationsdagen), og som simpelthen vil genskabe de rigtige datoer. De to situationer har intet med hinanden at gøre, men de deler den samme søgeformulering.

Denne artikel svarer på begge. Spoiler: i det første tilfælde er ændringen ikke mulig på en måde, der ikke kan opdages. I det andet er den helt legitim, og det er præcis hvad Redate.io gør.

Først: hvad er egentlig "datoen" på en e-mail?

En e-mail indeholder ikke kun én dato. Den indeholder flere, gemt på forskellige steder og kontrolleret af forskellige parter.

Date:-headeren (RFC 2822)

Det er den dato, som afsenderens e-mailklient skriver ind i beskeden, når den sendes. Den er synlig i de rå headers som:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Denne header er en del af selve beskedens indhold. Den kan teknisk set ændres, hvis du har adgang til den rå fil. Men "teknisk set" er det vigtige ord her.

Received:-headerne

Hver mailserver, som en e-mail passerer igennem, tilføjer sin egen Received:-header med et tidsstempel. Disse headers danner en kronologisk kæde fra afsenderens server til din indbakke. (Har du nogensinde prøvet at læse de rå headers på en e-mail, ved du, at det ikke ligefrem er strandlæsning. Adskillige linjer tekniske metadata, i en rækkefølge der går fra nyeste til ældste.)

IMAP INTERNALDATE

Det er den vigtigste metadata for at forstå, hvorfor visse ændringer ikke har nogen synlig effekt. INTERNALDATE er en attribut gemt på IMAP-serveren, uafhængigt af beskedens indhold. Det er den, de fleste e-mailklienter bruger til at sortere e-mails i mapper. Outlook bruger den. Gmail også. Apple Mail ligeså, i langt de fleste tilfælde.

INTERNALDATE er ikke inde i beskeden. Den ligger i serverens database. Du kan ikke ændre den ved at redigere en .eml-fil på din lokale disk.

Hvad der faktisk sker, når du redigerer lokalt

Redigere en .eml-fil

Teknisk set er en .eml-fil en tekstfil. Du kan åbne den i en editor, ændre Date:-linjen og gemme. Hvis du genimporterer filen i en lokal e-mailklient, kan den viste dato skifte, afhængig af klienten.

Men her er hvad det ikke ændrer:

• INTERNALDATE på IMAP-serveren (altid uberørt)
• Received:-headers tilføjet af mellemliggende servere
• Leveringslogfiler hos Google, Microsoft eller din udbyder
• DKIM-signaturen, hvis beskeden havde en

Resultat: på din lokale maskine ser du måske en anden dato. Fra Outlook forbundet til Exchange Online, eller Gmail i en browser, er intet ændret.

Ændre systemuret

Nogle forums foreslår at ændre arbejdsstationens ur for at "narre" e-mailklienten. Det virker ikke. Outlook og Gmail læser ikke systemuret for at vise datoer på modtagne e-mails. De læser INTERNALDATE fra serveren eller beskedens headers. Det lokale ur spiller ingen rolle i den proces.

Manipulation via Thunderbird

Thunderbird giver mere fleksibilitet end de fleste klienter. Med extensions eller ved direkte manipulation af profilen (mbox-filer, .msf-filer) forsøger nogle at ændre datovisningen. Det kan fungere i Thunderbird selv, for e-mails gemt lokalt i POP3-tilstand. Men så snart Thunderbird er forbundet via IMAP, synkroniserer den med serveren. "Rettelsen" forsvinder ved næste synkronisering.

DKIM: den usynlige barriere ingen nævner

De fleste e-mails sendt siden 2018 er signeret med DKIM (DomainKeys Identified Mail). En DKIM-signatur ser sådan ud i headerne:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

h=-feltet viser, hvilke headers der er dækket af signaturen. I eksemplet ovenfor er Date signeret. Ændrer du Date:-headeren, fejler DKIM-verifikationen. En hvilken som helst mailserver eller retsmedicinsk analyseværktøj kan opdage ændringen ved at genberegne signaturen.

Det er ikke en perfekt beskyttelse (en ondsindet afsender kontrollerer sin egen DKIM-nøgle og kan signere hvad som helst ved afsendelse). Men for en e-mail, der allerede er modtaget og signeret, efterlader ændring af Date:-headeren et sporbart spor.

Serverlogfiler: den egentlige kilde til sandhed

Selv hvis du lykkedes med at ændre alle synlige metadata i en e-mail (headers, INTERNALDATE, det hele), beholder udbyderne deres egne logfiler.

Google Workspace logger hver besked i Admin Console-revisionslogs. Microsoft 365 gør det samme i Purview Compliance Center. Disse logs indeholder leveringstidsstempler uafhængigt af, hvad der vises i klienterne. En advokat, en juridisk afdeling eller et IT-sikkerhedsteam kan hente disse data. Den dato, der vises i Outlook, har ingen beviskraft i retten eller ved en sikkerhedsrevision.

For at præcisere: selv en administrator med adgang til postkassen via domain-delegation kan ikke overskrive disse logs med tilbagevirkende kraft. De er uden for rækkevidde for alle brugere, selv privilegerede.

Det legitime tilfælde: korrektion efter migrering

Du har netop afsluttet en migrering af 150 postkasser fra en Exchange on-premise til Microsoft 365. Mandag morgen tikker tickets ind: "alle mine gamle e-mails er dateret fredag i sidste uge". Migrationsdatoen.

Det er et velkendt problem, der er fuldstændig forskelligt fra det, vi netop har beskrevet. Her forsøger ingen at forfalske noget som helst. De ægte originale datoer findes stadig, intakte, i Date:-headeren i hver enkelt besked. Problemet stammer et andet sted fra: migreringsværktøjet (BitTitan MigrationWiz, CloudM, imapsync eller et andet) har indsat en Received:-header med migrationsdatoen øverst i kæden. Outlook, der i visse sammenhænge stoler på de nyeste Received:-headers frem for INTERNALDATE, viser denne dato i stedet.

I dette tilfælde handler "korrektionen" om at genskabe sammenhæng mellem hvad beskeden siger (den originale Date:-header, stadig til stede) og hvad serveren tror (INTERNALDATE, fastsat ved migreringstidspunktet). Det er ikke forfalskning. Det er gendannelse.

Det er præcis det problem, som en fejlkonfigureret migrering påfører tusindvis af postkasser. Og det er hvad Redate.io løser.

Hvorfor "gør-det-selv" fejler i stor skala

At forstå problemet er én ting. At rette det på 40.000 e-mails fordelt på 150 postkasser uden at miste en eneste, er noget helt andet.

De scripts, man finder på GitHub eller Stack Overflow, fungerer på 20 test-e-mails. I produktion løber de ind i problemer, som scriptforfatteren ikke havde forudset:

• S/MIME-signerede eller PGP-krypterede e-mails har strukturer, der ikke kan manipuleres som almindelige beskeder
• Multipart-beskeder med ikke-standard MIME-boundaries giver parsingfejl
• Headers encodet med RFC 2047 (ikke-ASCII-tegn i From:- eller Subject:-felter) ødelægger naive parsere
• Google og Microsofts API'er pålægger rate limits: klokken 03.00 under et batch på 30.000 e-mails bliver fejl 429 Too Many Requests ikke håndteret, scriptet stopper, og ingen ved præcis hvor
• Ingen rollback-mekanisme: hvis en besked bliver beskadiget under behandlingen, er der intet at gå tilbage til

Redate.io gemmer en kopi af hver original e-mail i en synlig backup-mappe i 30 dage. Hver korrektion verificeres individuelt. Analysepipelinen håndterer hundredvis af signaturer fra kendte migreringsværktøjer samt alle de edge-cases, et hjemmelavet script ikke ville klare.

Vil du vide mere om specifikke værktøjer? Se BitTitan MigrationWiz og e-maildatoer eller CloudM Migrate: ret forkerte e-maildatoer.

Hvad der ændres, og hvad der aldrig gør

Skellet er tydeligt. De tre første rækker i tabellen beskriver overfladiske eller sporbare ændringer. Den sidste beskriver en legitim korrektion af metadata, der er i overensstemmelse med beskedens originale indhold, efter en migrering der har skabt en inkonsistens.

Er du i den situation, der beskrives i den nederste række, efter en migrering med imapsync, BitTitan, CloudM eller et andet værktøj, er Redate.io lavet til netop det.

Viser dine e-mails migrationsdatoen i stedet for de rigtige datoer? Scan dine postkasser gratis med Redate.io og se præcis, hvor mange e-mails der er berørt, inden du beslutter dig.