Ändra datum på ett mottaget e-postmeddelande : sant eller falskt ?

Frågan alla ställer (och varför den döljer två helt olika situationer)

Skriv "ändra datum på mottaget e-postmeddelande" i Google. Du hittar dussintals trådar på Microsoft Q&A-forum, Reddit-diskussioner, Quora-frågor. Önskan är tydlig, men skälen bakom den är radikalt olika beroende på vem som frågar.

Det finns de som vill förfalska ett datum i efterhand, av skäl man helst inte vill föreställa sig. Och det finns IT-administratörer som, efter en IMAP-migrering, ser alla sina e-postmeddelanden visa samma dag (migreringsdagen), och som helt enkelt vill återfå de riktiga datumen. De två situationerna har ingenting med varandra att göra, men de delar samma sökfras.

Den här artikeln svarar på båda. Spoiler: i det första fallet är ändringen inte riktigt möjlig på ett ospårbart sätt. I det andra är den helt legitim och det är precis vad Redate.io gör.

Först: vad är egentligen "datumet" på ett e-postmeddelande?

Ett e-postmeddelande innehåller inte bara ett enda datum. Det innehåller flera, lagrade på olika platser, kontrollerade av olika aktörer.

Rubriken Date: (RFC 2822)

Det är datumet som avsändarens e-postklient skriver in i meddelandet när det skickas. Det syns i råformatet under:

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

Den här rubriken är en del av meddelandekroppen. Den kan tekniskt sett ändras om du har tillgång till råfilen. Men "tekniskt sett" är det viktiga ordet här.

Rubrikerna Received:

Varje e-postserver som ett meddelande passerar lägger till sin egen Received:-rubrik med en tidsstämpel. Dessa rubriker bildar en kronologisk kedja, från avsändarens server till din inkorg. (Förresten, om du någonsin försökt läsa råformatet på ett e-postmeddelande vet du att det inte precis är lättsam läsning. Flera dussin rader tekniska metadata, i en ordning som går från nyast till äldst.)

IMAP INTERNALDATE

Det här är den viktigaste metadata för att förstå varför vissa ändringar inte har någon synlig effekt. INTERNALDATE är ett attribut lagrat på IMAP-serversidan, oberoende av meddelandets innehåll. Det är detta som de flesta e-postklienter använder för att sortera e-post i mappar. Outlook använder det. Gmail med. Apple Mail, i de flesta fall, likaså.

INTERNALDATE finns inte i meddelandet. Det finns i serverns databas. Du kan inte ändra det genom att redigera en .eml-fil på din dator.

Vad som faktiskt händer när du ändrar lokalt

Redigera en .eml-fil

Tekniskt sett är en .eml-fil en textfil. Du kan öppna den i en textredigerare, ändra raden Date:, spara. Om du importerar om filen i en lokal e-postklient kan det visade datumet ändras, beroende på klient.

Men det här ändras inte:

• INTERNALDATE på IMAP-servern (alltid oförändrat)
• Rubrikerna Received: som lagts till av mellanliggande servrar
• Leveransloggarna hos Google, Microsoft, eller din leverantör
• DKIM-signaturen, om meddelandet hade en

Resultat: på din lokala dator ser du kanske ett annat datum. Via Outlook anslutet till Exchange Online, eller Gmail i en webbläsare, har ingenting förändrats.

Ändra systemklockan

En del forum föreslår att man ändrar systemklockan för att "lura" e-postklienten. Det fungerar inte. Outlook och Gmail läser inte systemtiden för att visa datum på mottagna e-postmeddelanden. De läser INTERNALDATE från servern, eller rubrikerna i meddelandet. Den lokala klockan spelar ingen roll i den processen.

Manipulation via Thunderbird

Thunderbird erbjuder mer flexibilitet än de flesta klienter. Med tillägg eller genom att direkt manipulera profilen (mbox-filer, .msf-filer) försöker vissa ändra datumvisningen. Det kan fungera i Thunderbird självt, för e-post lagrad lokalt i POP3-läge. Men så fort Thunderbird är anslutet via IMAP synkroniserar det om med servern. "Korrigeringen" försvinner vid nästa synkronisering.

DKIM: den osynliga barriären ingen nämner

De flesta e-postmeddelanden skickade sedan 2018 är signerade med DKIM (DomainKeys Identified Mail). En DKIM-signatur ser ut så här i rubrikerna:

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...

Fältet h= listar de rubriker som täcks av signaturen. I exemplet ovan är Date signerat. Om du ändrar rubrikern Date: i meddelandet misslyckas DKIM-verifieringen. Vilken e-postserver eller forensiskt analysverktyg som helst kan upptäcka ändringen genom att räkna om signaturen.

Det är inte ett perfekt skydd (en illvillig avsändare kontrollerar sin egen DKIM-nyckel och kan signera vad som helst vid sändningstillfället). Men för ett redan mottaget och signerat e-postmeddelande lämnar en ändring av Date:-rubriken ett spårbart spår.

Serverloggarna: den verkliga sanningskällan

Även om du lyckas ändra alla synliga metadata i ett e-postmeddelande (rubriker, INTERNALDATE, allt), behåller leverantörerna sina egna loggar.

Google Workspace loggar varje meddelande i Admin Console-granskningsloggarna. Microsoft 365 gör detsamma i Purview Compliance Center. Dessa loggar innehåller leveranstidsstämplar, oberoende av vad som visas i klienterna. En jurist, en juridisk avdelning, eller ett IT-säkerhetsteam kan hämta dessa uppgifter. Det datum som visas i Outlook gäller inte inför en domstol eller vid en säkerhetsrevision.

För att vara precis: inte ens en administratör med tillgång till postlådan via domändelegerng kan skriva om dessa loggar i efterhand. De är utom räckhåll för användare, även privilegierade.

Det legitima fallet: korrigering efter migrering

Du har precis avslutat en migrering av 150 postlådor från Exchange on-premises till Microsoft 365. Måndag morgon börjar ärendena strömma in: "alla mina gamla e-postmeddelanden är daterade till förra fredagen". Migreringsdagen.

Det är ett väldokumenterat problem och det skiljer sig fullständigt från vad vi just beskrivit. Här försöker ingen förfalska något. De riktiga originaldatumen finns fortfarande kvar, intakta, i varje meddelandes Date:-rubrik. Problemet ligger på ett annat ställe: migreringsverktyget (BitTitan MigrationWiz, CloudM, imapsync, eller ett annat) infogade en Received:-rubrik med migreringsdatumet i toppen av kedjan. Outlook, som i vissa sammanhang förlitar sig på de senaste Received:-rubrikerna snarare än INTERNALDATE, visar det datumet i stället.

I det här fallet handlar "korrigeringen" om att återställa konsistensen mellan vad meddelandet säger (den ursprungliga Date:-rubriken, som fortfarande finns) och vad servern tror (INTERNALDATE, satt vid migreringen). Det är inte förfalskning. Det är återställning.

Det är precis det problem som en dåligt konfigurerad migrering kan ge tusentals postlådor. Och det är vad Redate.io löser.

Varför "gör-det-själv" misslyckas i stor skala

Att förstå problemet är en sak. Att korrigera det på 40 000 e-postmeddelanden fördelade på 150 postlådor utan att förlora ett enda är en helt annan sak.

De skript man hittar på GitHub eller Stack Overflow fungerar på 20 testmejl. De stöter på problem i produktion av skäl som skriptets upphovsman inte förutsåg:

• S/MIME-signerade eller PGP-krypterade e-postmeddelanden har strukturer som inte hanteras som vanliga meddelanden
• Multipart-meddelanden med icke-standardiserade MIME-gränser orsakar tolkningsfel
• Rubriker kodade enligt RFC 2047 (icke-ASCII-tecken i From:- eller Subject:-fält) förstör naiva tolkar
• Google- och Microsoft-APIer inför hastighetsbegränsningar (rate limiting): klockan 03:00 under ett batch-jobb på 30 000 e-postmeddelanden hanteras inte felet 429 Too Many Requests, skriptet stannar och ingen vet var det stannade
• Ingen återställningsmekanism: om ett meddelande skadas under behandlingen finns inget sätt att gå tillbaka

Redate.io sparar en kopia av varje originalt e-postmeddelande i en synlig säkerhetskopieringsmapp i 30 dagar. Varje korrigering verifieras individuellt. Analyspipelinen hanterar hundratals signaturer från kända migreringsverktyg, inklusive alla kantfall som ett hemmagjort skript inte skulle klara av.

För mer information om de specifika problemen per verktyg: BitTitan MigrationWiz och e-postdatum, eller CloudM Migrate: åtgärda felaktiga datum.

Vad som ändras och vad som aldrig ändras

Skillnaden är tydlig. De tre första raderna i tabellen beskriver ytliga eller spårbara ändringar. Den sista beskriver en legitim korrigering av metadata, i linje med meddelandets ursprungliga innehåll, efter en migrering som introducerade en inkonsekvens.

Om du befinner dig i situationen som beskrivs i sista raden, efter en migrering med imapsync, BitTitan, CloudM eller ett annat verktyg, är Redate.io gjort för det.

Visar dina e-postmeddelanden migreringsdatumet i stället för de riktiga datumen? Skanna dina postlådor gratis med Redate.io och se exakt hur många e-postmeddelanden som berörs innan du bestämmer dig.