Antidatera e-post: vad som är möjligt och spårbart

Antidatera e-post: vad pratar vi egentligen om?

Frågan dyker upp regelbundet i systemadministratörsforum och MSP-grupper på Slack: går det att ändra datumet på ett e-postmeddelande efter att det skickats? Det korta svaret är ja, tekniskt sett. Men det fullständiga svaret är betydligt mindre uppmuntrande för den som vill göra det i tvivelaktiga syften.

Ett e-postmeddelande är inte en monolitisk fil. Det är en samling texthuvuden följt av ett meddelandeinnehåll. Bland dessa huvuden finns flera som bär datuminformation. Och vissa är lättare att ändra än andra.

Tre datalager samexisterar i varje e-postmeddelande:

• Huvudet Date: (RFC 2822), skrivet av e-postklienten vid sändningstillfället
• Huvudena Received:, tillagda av varje server som vidarebefordrar meddelandet
• IMAP INTERNALDATE, ett serverlagrat metadata oberoende av meddelandets innehåll

Vart och ett av dessa lager kan ändras. Inget av dem kan ändras utan att lämna spår.

Ändra Date:-huvudet: den mest uppenbara manipulationen

Huvudet Date: är ren text i .eml-filen. Tekniskt kan vilken hexadecimalredigerare eller vilket Python-skript som helst skriva om det på några sekunder. Om du någon gång öppnat råhuvudena för ett e-postmeddelande i Gmail (den lilla menyn "Visa original") vet du att det är läsbart för vem som helst.

Problemet? Sedan 2004 signerar den stora majoriteten av e-postservrar utgående e-post med DKIM (DomainKeys Identified Mail). Denna kryptografiska signatur täcker explicit flera huvuden, däribland Date:, From:, Subject: och meddelandets brödtext. Signaturen lagras i huvudet DKIM-Signature:.

Att ändra Date: efter signering ogiltigförklarar mekaniskt DKIM-verifieringen. Vilken mottagarserver som helst kan kontrollera signaturen genom att hämta den offentliga nyckeln från avsändardomänens DNS. Om signaturen inte längre stämmer markeras meddelandet som manipulerat. Gmail, Outlook.com och alla stora leverantörer gör denna kontroll automatiskt.

(Om du vill se en DKIM-signatur i praktiken: öppna råhuvudena på ett e-postmeddelande från Gmail eller Office 365. Du hittar en rad som börjar med DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... som ser ut som brus men i själva verket är en kryptografisk hash av hela meddelandet.)

Slutsats: att ändra Date: på ett DKIM-signerat e-postmeddelande är att bryta sigillet. Ändringen är synlig för vilken administratör som helst som vet var den ska leta.

Skriva om Received:-huvuden: en svårförfalskad kedja

Huvudena Received: spårar vägen ett e-postmeddelande tar mellan avsändare och mottagare. Varje SMTP-server som hanterar meddelandet lägger till ett, med sitt namn, sin IP-adress och en tidsstämpel. Ett e-postmeddelande som passerar två eller tre reläer innehåller alltså två eller tre staplade Received:-huvuden.

Kan man ändra dem? Tekniskt, ja, på sin egen kopia av meddelandet. Men här är fällan: mottagaren har också en kopia. Och mottagarens server lade till sitt eget Received:-huvud sist. Det huvudet är under mottagarens kontroll, inte avsändarens. Det går inte att förfalska utifrån.

Kedjans koherens kan verifieras. Om tidsstämplarna i de successiva Received:-huvuden är inkonsekenta (ett mellanliggande relä skulle ha tagit emot meddelandet innan avsändaren skickade det, till exempel) är det omedelbart misstänkt. Forensiska e-postanalysverktyg som MXToolbox eller säkerhetsteams interna verktyg kontrollerar precis det.

Faktiskt är det inte helt korrekt att säga att Received:-huvuden är omöjliga att förfalska fullständigt: en angripare som kontrollerar sin egen e-postinfrastruktur kan fabricera trovärdiga huvuden för de reläer den kontrollerar. Men den sista länken kontrollerar den aldrig: mottagarens server.

IMAP INTERNALDATE: det mest tekniska fallet

INTERNALDATE är ett IMAP-metadata lagrat på serversidan. Det är inte ett huvud i själva meddelandet: det är ett värde som servern kopplar till meddelandet i sin interna databas. Det är detta värde som de flesta e-postklienter använder för att sortera meddelanden i inkorgen.

IMAP-kommandot APPEND gör det möjligt att lägga ett meddelande på en server med ett explicit angivet INTERNALDATE. Det är en legitim protokollfunktion, dokumenterad i RFC 3501. Migreringsverktyg använder den hela tiden: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... alla placerar e-postmeddelanden på målservern med ett specificerat INTERNALDATE.

Teoretiskt skulle någon med IMAP-åtkomst till sin egen brevlåda kunna placera ett e-postmeddelande med vilket INTERNALDATE som helst. Men den manipulationen ändrar inte meddelandets huvuden. Det ursprungliga Date: är intakt, Received:-huvuden är intakta, DKIM-signaturen är intakt. Bara sorteringsmetadatat på serversidan ändras.

För en expert som undersöker råmeddelandet är diskrepansen mellan INTERNALDATE och Date: omedelbart synlig. Och om meddelandet är DKIM-signerat är det ursprungliga datumet kryptografiskt styrkt.

Message-ID: ett svårförfalskat fingeravtryck

Varje e-postmeddelande genererar en unik identifierare, huvudet Message-ID:. Denna identifierare konstrueras av den avsändande SMTP-servern vid sändningstillfället, vanligtvis genom att kombinera en tidsstämpel, en slumpmässig identifierare och serverns domännamn.

Ett typiskt Message-ID ser ut så här: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Tidsstämpeln är ofta direkt inbäddad i identifieraren. Att ändra meddelandets datum men lämna kvar ett Message-ID med en inkompatibel tidsstämpel skapar en inkonsistens som är omedelbart synlig.

Dessutom indexeras Message-ID:n av stora meddelandesystem. Google, Microsoft och andra aktörer underhåller loggar som gör det möjligt att spåra när ett meddelande faktiskt cirkulerade i deras infrastrukturer. I ett juridiskt eller forensiskt sammanhang är dessa loggar tillgängliga via rättsliga förfaranden.

I praktiken: vem kan upptäcka ett manipulationsförsök?

Låt oss ställa frågan konkret. Du har fått ett e-postmeddelande och misstänker att datumet har ändrats. Vad kan en IT-administratör eller en jurist med lite teknisk bakgrund göra?

• DKIM-verifiering: i Gmail visar menyn "Visa original" direkt resultatet av DKIM-verifieringen längst upp. Ett "PASS" bekräftar meddelandets integritet sedan det skickades. Ett "FAIL" eller "SOFTFAIL" signalerar en förändring.
• Huvudanalys: verktyg som MXToolbox Header Analyzer eller Google Admin Toolbox analyserar automatiskt Received:-kedjan och flaggar tidsmässiga inkonsistenser.
• Message-ID / Date-koherens: en analytiker kan jämföra tidsstämpeln inbäddad i Message-ID med det deklarerade Date:-värdet.
• Serverloggar: om e-postmeddelandet passerade en server du administrerar innehåller SMTP-loggarna det faktiska datumet och klockslaget för meddelandets acceptans, oberoende av alla huvuden.

Detektionsverktygen är alltså tillgängliga, gratis och kräver ingen avancerad forensisk expertis. En lite nyfiken IT-admin kan verifiera ett e-postmeddelandes integritet på under två minuter.

Det enda legitima fallet med massiv datumändring: IMAP-migrering

Det finns ett scenario där hundratusentals e-postmeddelanden hamnar med fel datum utan någon som helst illvillig avsikt: IMAP-migrering.

Du har precis avslutat en migrering av 150 Exchange-brevlådor till Google Workspace. Måndag morgon börjar ärendena strömma in. Användarna rapporterar att alla deras gamla e-postmeddelanden visas med samma datum, det datum då migreringen gjordes under helgen. Deras inkorgar är oläsliga.

Det som hände är dokumenterat och förutsägbart: migreringsverktyget (BitTitan, CloudM, imapsync, spelar ingen roll) lade e-postmeddelandena på Google Workspace via IMAP APPEND. Det angav ett INTERNALDATE som motsvarade migreringsdatumet, inte det ursprungliga datumet för e-postmeddelandet. Resultat: Outlook, som som standard sorterar efter INTERNALDATE, visar migreringsdatumet för alla meddelanden. Varför e-post visar fel datum efter migrering förklarar detta i detalj.

Det ursprungliga Date:-huvudet är intakt i varje meddelande. DKIM-signaturerna är intakta. Innehållet har inte rörts. Det är enbart INTERNALDATE på serversidan som är felaktigt.

Det här problemet drabbar BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO och alla verktyg som använder IMAP APPEND utan att korrekt bevara INTERNALDATE. Artikeln om BitTitan MigrationWiz täcker det verktygets särdrag. Checklistan för e-postmigrering listar vad du bör kontrollera före och efter en migrering för att undvika den här typen av problem.

Skillnaden mellan att korrigera och att förfalska

Den korrigering Redate.io utför är raka motsatsen till ett förfalskningsförsök. Den proprietära korrektionsmotorn analyserar huvudkedjan i varje meddelande, identifierar det ursprungliga datumet kodat i Date:-huvudet (RFC 2822) som aldrig har rörts, och korrigerar datummetadata för att anpassa dem till den autentiska information som redan finns i meddelandet.

Huvudet Date: är sanningskällan. Det skrevs av avsändarens e-postklient vid sändningstillfället. Det täcks av DKIM-signaturen. Redate.io ändrar det inte. Det som korrigeras är den diskrepans som migreringsverktyget introducerat, inte det ursprungliga datumet.

Att korrigera 47 000 e-postmeddelanden efter en misslyckad migrering utan att förlora ett enda, utan att bryta konversationstrådar, utan att skada bilagor, utan att utlösa 429-fel klockan 3 på natten mot Google API:et: det kräver ett flerstegigt analyspipeline med hantering av kantfall (S/MIME, PGP, icke-ASCII-kodningar enligt RFC 2047, komplexa multipart-strukturer). Ett Python-skript på fem rader skulle inte överleva den första produktionsbrevlådan. Kan e-postdatum korrigeras efter migrering beskriver varför gör-det-själv-lösningar är riskabla vid verkliga volymer.

Redate.io skannar brevlådor gratis, identifierar e-postmeddelanden med felaktiga datum och korrigerar via ett valideringspipeline som kontrollerar varje meddelande individuellt. Originalmeddelanden sparas i en synlig säkerhetskopieringsmapp i 30 dagar. Om något går fel är en återställning möjlig.

Har din migrering förskjutit datumen i dina e-postmeddelanden? Starta en gratis skanning på Redate.io för att se hur stor skadan är innan du bestämmer dig för vad du ska göra.