Endre datoen på en mottatt e-post: mulig eller ikke?

Spørsmålet alle stiller (og hvorfor det egentlig dekker to helt ulike situasjoner)

Søk på "endre datoen på en mottatt e-post" i Google. Du finner dusinvis av tråder på Microsoft Q&A-forumet, Reddit-diskusjoner, Quora-spørsmål. Behovet er tydelig, men årsakene bak er radikalt forskjellige avhengig av hvem som spør.

Noen ønsker å forfalske en dato i ettertid, av grunner vi helst ikke tenker på. Og så er det IT-administratorer som, etter en IMAP-migrering, ser at alle e-poster viser samme dato (migreringsdatoen), og som bare vil ha tilbake de riktige datoene. Disse to situasjonene har ingenting med hverandre å gjøre, men de bruker nøyaktig samme søkeord.

Denne artikkelen svarer på begge. Spoiler: i det første tilfellet er endringen ikke mulig å gjøre uoppdagbart. I det andre er den helt legitim, og det er akkurat det Redate.io gjør.

Hva er egentlig "datoen" på en e-post?

En e-post inneholder ikke én dato. Den inneholder flere, lagret på forskjellige steder, kontrollert av forskjellige parter.

Date:-headeren (RFC 2822)

Dette er datoen som avsenderens e-postklient skriver inn i meldingen når den sendes. Den er synlig i rådata-headerne slik:

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

Denne headeren er en del av meldingskroppen. Den kan teknisk sett endres hvis du har tilgang til råfilen. Men "teknisk sett" er det viktige ordet her.

Received:-headerne

Hver e-postserver som en melding passerer gjennom, legger til sin egen Received:-header med et tidsstempel. Disse headerne danner en kronologisk kjede, fra avsenderens server til innboksen din. (Forresten, hvis du noen gang har prøvd å lese rådata-headerne til en e-post, vet du at det ikke akkurat er strandlektyre. Gjerne femti linjer med tekniske metadata, i en rekkefølge som går fra nyest til eldst.)

IMAP INTERNALDATE

Dette er den viktigste metadataen for å forstå hvorfor noen endringer ikke har noen synlig effekt. INTERNALDATE er et attributt lagret på IMAP-serveren, uavhengig av meldingsinnholdet. Det er denne de fleste e-postklienter bruker til å sortere e-poster i mapper. Outlook bruker den. Gmail også. Apple Mail gjør det i de fleste tilfeller.

INTERNALDATE er ikke inne i meldingen. Den ligger i serverdatabasen. Du kan ikke endre den ved å redigere en .eml-fil på disken din.

Hva som faktisk skjer når du redigerer lokalt

Redigere en .eml-fil

Teknisk sett er en .eml-fil en tekstfil. Du kan åpne den i en editor, endre Date:-linjen, lagre. Hvis du reimporterer filen i en lokal e-postklient, kan den viste datoen endre seg, avhengig av klienten.

Men her er hva det ikke endrer:

• INTERNALDATE på IMAP-serveren (alltid intakt)
• Received:-headerne lagt til av mellomservere
• Leveringslogger hos Google, Microsoft eller din leverandør
• DKIM-signaturen, hvis meldingen hadde en

Resultatet: på din lokale maskin ser du kanskje en annen dato. I Outlook koblet til Exchange Online, eller Gmail i en nettleser, har ingenting endret seg.

Endre systemklokken

Noen forum foreslår å endre klokkeslettet på datamaskinen for å "lure" e-postklienten. Det fungerer ikke. Outlook og Gmail leser ikke systemklokken for å vise datoer på mottatte e-poster. De leser INTERNALDATE fra serveren, eller meldingsheaderne. Den lokale klokken er ikke involvert i den prosessen.

Thunderbird-manipulasjon

Thunderbird er mer fleksibelt enn de fleste klienter. Med utvidelser eller ved å manipulere profilen direkte (mbox-filer, .msf-filer) forsøker noen å endre datovisningen. Det kan fungere i Thunderbird selv, for e-poster lagret lokalt i POP3-modus. Men så snart Thunderbird er koblet til via IMAP, synkroniserer det med serveren. "Korrigeringen" forsvinner ved neste synkronisering.

DKIM: den usynlige barrieren ingen nevner

De fleste e-poster sendt siden 2018 er signert med DKIM (DomainKeys Identified Mail). En DKIM-signatur ser slik ut 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 lister opp headerne som er dekket av signaturen. I eksemplet over er Date signert. Hvis du endrer Date:-headeren i meldingen, feiler DKIM-verifikasjonen. Enhver e-postserver, ethvert kriminalteknisk analyseverktøy, kan oppdage endringen ved å beregne signaturen på nytt.

Dette er ikke en perfekt beskyttelse (en ondsinnet avsender kontrollerer sin egen DKIM-nøkkel og kan signere hva som helst ved sending). Men for en e-post som allerede er mottatt og signert, etterlater endring av Date:-headeren et sporbart avtrykk.

Serverlogger: den virkelige kilden til sannhet

Selv om du klarte å endre alle synlige metadata i en e-post (headere, INTERNALDATE, alt), beholder leverandørene sine egne logger.

Google Workspace logger hver melding i revisjonsloggene i Admin Console. Microsoft 365 gjør det samme i samsvarssenter (Purview). Disse loggene inkluderer leveringstidsstempler, uavhengig av hva som vises i klientene. En advokat, en juridisk avdeling eller et IT-sikkerhetsteam kan hente disse dataene. Datoen som vises i Outlook har ingen beviskraft i retten eller ved en sikkerhetsrevisjon.

For å være presis: selv en administrator med tilgang til postboksen via domenedelegasjon kan ikke skrive om disse loggene i ettertid. De er utenfor rekkevidde for brukere, selv privilegerte.

Det legitime tilfellet: korrigering etter migrering

Du har akkurat fullført en migrering av 150 postbokser fra en lokal Exchange-server til Microsoft 365. Mandagen etter strømmer billettene inn: "alle mine gamle e-poster er datert forrige fredag". Migreringsdatoen.

Dette er et godt dokumentert problem, og det er fundamentalt forskjellig fra det vi nettopp beskrev. Her forsøker ingen å forfalske noe som helst. De virkelige originale datoene finnes fortsatt, intakte, i Date:-headeren til hver melding. Problemet ligger et annet sted: migreringverktøyet (BitTitan MigrationWiz, CloudM, imapsync eller et annet) har satt inn en Received:-header med migreringsdatoen øverst i kjeden. Outlook, som i visse sammenhenger stoler mer på de nyeste Received:-headerne enn på INTERNALDATE, viser denne datoen i stedet.

I dette tilfellet handler "korrigeringen" om å gjenopprette samsvar mellom hva meldingen sier (den originale Date:-headeren, fremdeles til stede) og hva serveren tror (INTERNALDATE, satt ved migreringstidspunktet). Det er ikke forfalskning. Det er gjenoppretting.

Det er nøyaktig det en dårlig konfigurert migrering kan påføre tusenvis av postbokser. Og det er det Redate.io løser.

Hvorfor "gjør det selv" feiler i stor skala

Å forstå problemet er én ting. Å korrigere det på 40 000 e-poster fordelt på 150 postbokser uten å miste én eneste melding, er noe helt annet.

Skript fra GitHub eller Stack Overflow fungerer på 20 test-e-poster. I produksjon støter de på problemer som skriptforfatteren ikke hadde forutsett:

• E-poster signert med S/MIME eller kryptert med PGP har strukturer som ikke håndteres som vanlige meldinger
• Multipart-meldinger med ikke-standard MIME-grenser gir parsing-feil
• Headere kodet i RFC 2047 (ikke-ASCII-tegn i From:- eller Subject:-felt) bryter naive parsere
• Google- og Microsoft-API-er har ratebegrensninger: klokken 03:00 under en batch med 30 000 e-poster er ikke 429 Too Many Requests-feilen håndtert, skriptet stopper, og ingen vet hvor det stoppet
• Ingen rollback-mekanisme: hvis en melding blir ødelagt under behandlingen, finnes det ingenting for å gå tilbake

Redate.io beholder en kopi av hver originale e-post i en synlig sikkerhetskopmappe i 30 dager. Hver korrigering verifiseres individuelt. Analysepipelinen håndterer hundrevis av signaturer fra kjente migreringsverktøy, samt alle kanttilfellene et hjemmelaget skript ikke ville taklet.

For mer om det spesifikke for hvert verktøy: BitTitan MigrationWiz og e-postdatoer, eller CloudM Migrate: rett feil e-postdatoer.

Hva som endres, og hva som aldri endres

Skillet er tydelig. De tre første radene i tabellen beskriver overfladiske eller oppdagbare endringer. Den siste beskriver en legitim korrigering av metadata, i samsvar med det originale meldingsinnholdet, etter en migrering som introduserte en inkonsistens.

Hvis du befinner deg i situasjonen beskrevet nederst i tabellen, etter en migrering med imapsync, BitTitan, CloudM eller et annet verktøy, er Redate.io laget for akkurat det.

Viser e-postene dine migreringsdatoen i stedet for de riktige datoene? Skann postboksene dine gratis med Redate.io og se nøyaktig hvor mange e-poster som er berørt, før du bestemmer deg.