Antedatere en e-post: mulig og oppdagbart

Antedatere en e-post: hva snakker vi egentlig om?

Spørsmålet dukker jevnlig opp i sysadmin-forum og MSP-grupper på Slack: er det mulig å endre datoen på en e-post etter at den er sendt? Det korte svaret er ja, teknisk sett. Men det fullstendige svaret er langt mindre betryggende for den som ønsker å gjøre det med tvilsomme formål.

En e-post er ikke én monolittisk fil. Det er en samling tekstbaserte headere etterfulgt av selve meldingsinnholdet. Blant disse headerne finnes det flere som inneholder datoinformasjon. Og noen er lettere å endre enn andre.

Tre lag med datering eksisterer i enhver e-post:

• Headeren Date: (RFC 2822), skrevet av e-postklienten på sendingstidspunktet
• Headerne Received:, lagt til av hver server som videresender meldingen
• IMAP INTERNALDATE, en metadata lagret på serversiden, uavhengig av selve meldingsinnholdet

Hvert av disse lagene kan endres. Ingen av dem kan endres uten å etterlate spor.

Endre Date:-headeren: den mest åpenbare manipulasjonen

Headeren Date: er ren tekst i .eml-filen. Teknisk sett kan et hvilket som helst hex-redigeringsprogram eller Python-skript skrive den om på noen sekunder. Har du noen gang åpnet de rå headerne på en e-post i Gmail (den lille menyen "Vis original"), vet du at dette er lesbart for hvem som helst.

Problemet? Siden 2004 signerer det store flertallet av e-postservere utgående e-poster med DKIM (DomainKeys Identified Mail). Denne kryptografiske signaturen dekker eksplisitt flere headere, blant annet Date:, From:, Subject: og meldingskroppen. Signaturen lagres i headeren DKIM-Signature:.

Å endre Date: etter signering ugyldiggjør mekanisk DKIM-verifiseringen. En hvilken som helst mottaksserver kan verifisere signaturen ved å hente den offentlige nøkkelen fra avsenderdomenes DNS. Hvis signaturen ikke lenger stemmer, markeres meldingen som endret. Gmail, Outlook.com og alle store leverandører gjør denne sjekken automatisk.

(Vil du se en DKIM-signatur i praksis, kan du åpne de rå headerne på en e-post mottatt fra Gmail eller Office 365: du finner en linje som DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., som ser ut som støy, men som faktisk er en kryptografisk hash av hele meldingen.)

Resultatet: å endre Date: på en DKIM-signert e-post er som å bryte seglet. Endringen er synlig for enhver administrator som vet hva han skal se etter.

Omskrive Received:-headere: en kjede som er vanskelig å forfalske

Headerne Received: sporer veien en e-post har tatt fra avsender til mottaker. Hver SMTP-server som håndterer meldingen legger til én, med sitt navn, sin IP-adresse og et tidsstempel. En e-post som passerer gjennom to eller tre releer inneholder altså to eller tre Received:-headere stablet oppå hverandre.

Kan de endres? Teknisk sett ja, på sin egen kopi av meldingen. Men her er fellen: mottakeren har også en kopi. Og mottakerens server har lagt til sin egen Received:-header sist. Den headeren er under mottakerens kontroll, ikke avsenderens. Den er umulig å forfalske utenfra.

Konsistensen i kjeden er verifiserbar. Hvis tidsstemplene i de successive Received:-headerne er inkonsistente (for eksempel at et mellomliggende relé tilsynelatende mottok meldingen før avsenderen sendte den), er det umiddelbart mistenkelig. Verktøy for e-post-forensikk som MXToolbox, eller interne verktøy hos sikkerhetsteam, sjekker nettopp dette.

Altså, det er ikke helt riktig å si at Received:-headere er umulige å forfalske fullstendig: en angriper som kontrollerer sin egen e-postinfrastruktur kan lage troverdige headere for de releene vedkommende behersker. Men det siste leddet kontrollerer han aldri: mottakerens server.

IMAP INTERNALDATE: det mest tekniske tilfellet

INTERNALDATE er en IMAP-metadata lagret på serversiden. Det er ikke en header i selve meldingen, men en verdi serveren knytter til meldingen i sin interne database. Det er denne verdien de fleste e-postklienter bruker for å sortere meldinger i innboksen.

IMAP-kommandoen APPEND gjør det mulig å legge en melding på en server med en eksplisitt angitt INTERNALDATE. Dette er en legitim funksjon i protokollen, dokumentert i RFC 3501. Migrasjonsverktøy bruker det hele tiden: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... alle legger e-poster på destinasjonsserveren med en spesifisert INTERNALDATE.

Teoretisk sett kunne noen med IMAP-tilgang til sin egen postkasse legge inn en e-post med en hvilken som helst INTERNALDATE. Men denne manipulasjonen endrer ikke meldingsheaderne. Den originale Date:-headeren forblir intakt, Received:-headerne forblir intakte, DKIM-signaturen forblir intakt. Det er bare sorteringsmetadataen på serversiden som endres.

For en ekspert som undersøker rå meldingsdata er avviket mellom INTERNALDATE og Date: umiddelbart synlig. Og hvis meldingen er DKIM-signert, er den originale datoen kryptografisk attestert.

Message-ID: et avtrykk som er vanskelig å forfalske

Hver e-post genererer en unik identifikator, headeren Message-ID:. Denne identifikatoren bygges av den avsendende SMTP-serveren på sendingstidspunktet, og kombinerer vanligvis et tidsstempel, en tilfeldig identifikator og serverens domenenavn.

En typisk Message-ID ser slik ut: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Tidsstempelet er ofte kodet direkte inn i identifikatoren. Å endre datoen på meldingen mens man lar Message-ID ha et inkompatibelt tidsstempel skaper en inkonsistens som er umiddelbart synlig.

I tillegg indekseres Message-IDer av store meldingssystemer. Google, Microsoft og andre aktører vedlikeholder logger som gjør det mulig å spore når en melding faktisk sirkulerte gjennom infrastrukturen deres. I en juridisk eller forensisk sammenheng er disse loggene tilgjengelige via rettsprosesser.

I praksis: hvem kan oppdage et manipulasjonsforøk?

La oss stille spørsmålet konkret. Du mottar en e-post der du mistenker at datoen er endret. Hva kan en IT-administrator eller en advokat med litt teknisk bakgrunn gjøre?

• DKIM-verifisering: i Gmail viser menyen "Vis original" direkte resultatet av DKIM-verifiseringen øverst på siden. Et "PASS" bekrefter meldingsintegriteten siden sending. Et "FAIL" eller "SOFTFAIL" signaliserer en endring.
• Header-analyse: verktøy som MXToolbox Header Analyzer eller Google Admin Toolbox parser automatisk Received:-kjeden og rapporterer tidsmessige inkonsistenser.
• Samsvar mellom Message-ID og Date: en analytiker kan sammenligne tidsstempelet kodet i Message-ID med den oppgitte Date:-verdien.
• Serverlogger: hvis e-posten har passert gjennom en server du administrerer, inneholder SMTP-loggene faktisk dato og klokkeslett for mottak av meldingen, uavhengig av alle headere.

Altså: deteksjonsverktøyene er tilgjengelige, gratis og krever ikke avansert forensisk ekspertise. En nysgjerrig IT-admin kan verifisere integriteten til en e-post på under to minutter.

Det eneste legitime tilfellet av massiv datoendring: IMAP-migrering

Det finnes ett scenario der hundretusenvis av e-poster ender opp med feil datoer uten noen som helst ondsinnet hensikt: IMAP-migrering.

Du har nettopp fullført en migrering av 150 Exchange-postkasser til Google Workspace. Mandag morgen strømmer sakene inn. Brukerne rapporterer at alle gamle e-poster vises med samme dato, nemlig migreringsdatoens helg. Innboksene deres er uleselige.

Det som skjedde er dokumentert og forutsigbart: migrasjonsverktøyet (BitTitan, CloudM, imapsync, uansett hvilket) la e-postene inn i Google Workspace via IMAP APPEND. Det spesifiserte en INTERNALDATE tilsvarende migreringsdatoen, ikke den originale datoen på e-posten. Resultat: Outlook, som sorterer etter INTERNALDATE som standard, viser migreringsdatoen for alle meldinger. Hvorfor e-poster viser feil dato etter migrering forklarer denne mekanismen i detalj.

Den originale Date:-headeren er intakt i hver melding. DKIM-signaturene er intakte. Innholdet er urørt. Det er utelukkende INTERNALDATE på serversiden som er feil.

Dette problemet rammer BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO og alle verktøy som bruker IMAP APPEND uten å bevare INTERNALDATE korrekt. Artikkelen dedikert til BitTitan MigrationWiz dekker særegenhetene ved dette verktøyet. Sjekklisten for e-postmigrering lister opp punktene du bør kontrollere før og etter en migrering for å unngå denne typen problemer.

Forskjellen mellom å korrigere og å forfalske

Korrigeringen Redate.io utfører er det stikk motsatte av et forfalskningstiltak. Den proprietære korrigeringsmotoren analyserer header-kjeden i hver melding, identifiserer den originale datoen kodet i Date:-headeren (RFC 2822) som aldri har blitt endret, og korrigerer datometadataene slik at de stemmer overens med denne autentiske informasjonen som allerede finnes i meldingen.

Date:-headeren er kilden til sannhet. Den ble skrevet av avsenderens e-postklient på sendingstidspunktet. Den er dekket av DKIM-signaturen. Den endres ikke av Redate.io. Det som korrigeres er avviket som ble innført av migrasjonsverktøyet, ikke den originale datoen.

Å korrigere 47 000 e-poster etter en mislykket migrering uten å miste én eneste, uten å bryte e-posttråder, uten å korrumpere vedlegg, uten å utløse 429-feil klokken 03:00 på Google-API-et: det krever en flertrinnspipeline for analyse med håndtering av grensetilfeller (S/MIME, PGP, ikke-ASCII-koding i RFC 2047, komplekse multipart-strukturer). Et Python-skript på fem linjer ville ikke overlevd den første produksjonspostkassen. Kan e-postdatoer rettes etter migrering forklarer i detalj hvorfor DIY er risikabelt på reelle volumer.

Redate.io skanner postkasser gratis, identifiserer e-poster med feil datoer, og korrigerer via en valideringspipeline som verifiserer hver enkelt melding individuelt. Originalene bevares i en synlig sikkerhetskopieringsmappe i 30 dager. Hvis noe går galt, er tilbakestilling mulig.

Har migreringen forskjøvet datoene på e-postene dine? Start et gratis skann på Redate.io for å kartlegge omfanget av problemet før du bestemmer deg for hva du vil gjøre.