Ändra datum på ett e-postmeddelande: tekniska begränsningar

Ett e-postmeddelande har tre "datum". Inte ett.

När folk pratar om att "ändra datum på ett mottaget e-postmeddelande" föreställer sig de flesta att man redigerar ett fält någonstans, ungefär som man ändrar skapandedatum på en fil i Windows. Verkligheten är lite mer komplicerad. Ett e-postmeddelande bär faktiskt tre separata datumskikt med sig, vart och ett med egna regler, egna väktare, och egna konsekvenser om man rör dem.

Förstår man dessa tre skikt förstår man också varför vissa korrigeringar är tekniskt sunda, och varför andra antingen är omöjliga eller omedelbart identifierbara som förfalskningar.

Skikt 1: IMAP INTERNALDATE

INTERNALDATE är metadata som lagras på serversidan, utanför själva meddelandet. Den ingår inte i e-postinnehållet. Det är IMAP-servern som sätter den, och det är den de flesta e-postklienter använder för att sortera meddelandena i listan.

Outlook visar som standard meddelanden sorterade efter INTERNALDATE. Gmail gör det också, i vissa sammanhang. Är din INTERNALDATE fel visas alltså alla dina e-postmeddelanden med samma datum i gränssnittet, oavsett vad de interna rubrikerna i meddelandet säger.

INTERNALDATE sätts när meddelandet placeras på servern. Via IMAP-protokollet är det enda sättet att "ändra" den indirekt: man måste använda kommandot APPEND för att lägga in en ny kopia av meddelandet med önskat datum. Det finns inget IMAP-kommando som heter SETINTERNALDATE. Den detaljen kommer ha betydelse om en stund.

Skikt 2: Date:-rubriken (RFC 2822)

Det är fältet Date: i meddelandets råa rubriker. Det sätts av e-postklienten vid sändning och följer med meddelandet från server till server. Det är det avsändningsdatum avsändaren deklarerat.

(Om du aldrig tittat på råa e-postrubriker är det förresten rätt häpnadsväckande läsning. Varje meddelande drar med sig ett tjugotal tekniska rader som 99 % av alla användare aldrig sett.)

Tekniskt sett finns inget som hindrar att man skickar ett e-postmeddelande med ett antedaterat eller postdaterat Date:-fält. SMTP-servrar validerar inte det fältet. Men mottagarservrarna noterar den verkliga ankomsttiden i Received:-rubrikerna, vilket omedelbart skapar en inkonsekvens som syns i vilken e-postklient eller vilket analysverktyg som helst.

Skikt 3: de staplade Received:-rubrikerna

Varje gång en SMTP-server vidarebefordrar ett meddelande lägger den till en Received:-rubrik överst i stapeln, med en tidsstämpel. Ett e-postmeddelande som passerat tre servrar har tre Received:-rubriker. De läses nedifrån och upp: den äldsta ligger längst ned, den senaste längst upp.

Det är precis här migreringsverktyg skapar problemet. När BitTitan MigrationWiz, CloudM, imapsync eller GSMMO migrerar ett e-postmeddelande placerar de om det på den nya servern via IMAP. Det dépôt genererar en ny Received:-post tidsstämplad till migreringstillfället. Resultatet: det äldsta meddelandet i din inkorg, ett e-postmeddelande från 2019, har plötsligt en Received: daterad november 2024. Och eftersom vissa e-postklienter (Outlook i synnerhet) använder den senaste Received:-rubriken som visningsdatum...

Där har du problemet. 15 000 e-postmeddelanden visar alla samma migreringsdatum.

Kan man verkligen "ändra" dessa datum?

Tekniskt ja för INTERNALDATE (med begränsningar). Tekniskt möjligt men meningslöst för Date:. Och för Received: är det värt att gräva lite djupare.

Skriva om en Received:-rubrik är trivialt. Och omedelbart spårbart.

En Received:-rubrik är bara en textrad i meddelandet. Man kan redigera den som vilken textfil som helst. Det är precis lika enkelt som det låter.

Men det är vad som händer sedan som är problemet.

Första problemet: DKIM. DKIM-signaturen (DomainKeys Identified Mail) beräknas på en uppsättning meddelanderubriker, ibland inklusive Received:-rubrikerna. Ändrar man en signerad rubrik ogiltigförklaras signaturen. Vilken mottagarserver som helst som kontrollerar DKIM ser omedelbart att meddelandet har ändrats. Det är ingen subtil förfalskning, det är ett larm.

Andra problemet: interna identifierare. Moderna e-postservrar (Google Workspace, Microsoft 365) tilldelar varje meddelande ett unikt, stigande internt ID. Dessa ID:n är kopplade till INTERNALDATE och mottagningsordningen. Att ändra en Received:-rubrik utan konsekvens för dessa identifierare skapar inkonsekvenser som revisionsverktyg hittar utan svårighet.

Tredje problemet, mer praktiskt: även om du ändrar Received: i meddelandeinnehållet har du inte rört INTERNALDATE, som fortfarande är satt till IMAP-insättningstidpunkten. E-postklienten fortsätter visa fel datum vid sortering. Du har ändrat meddelandet i onödan.

Kort sagt. Att skriva om Received:-rubriker för att förfalska e-postdatum i skadligt syfte: tekniskt trivialt, spårbart på några sekunder av en expert. Det är ingen seriös väg att gå.

Date:-rubriken: ändra det förflutna på pappret

Samma resonemang gäller för Date:. Man kan ändra den i meddelandekroppen. Men Received:-rubrikerna autentiserade av mellanliggande servrar förblir intakta och berättar en annan historia. Den tidsmässiga kedjan är inkonsekvent. Vilken analytiker eller domstol som helst som jämför dessa fält ser det omedelbart.

För att vara precis hindrar det inte vissa e-postklienter från att visa det ändrade Date:-fältet om man presenterar dem direkt med en .eml-fil. Men i en live-e-postserver med autentisering och loggar är ändringen transparent.

IMAP-migrering: det enda sammanhang där datum-korrigering är befogad

Det finns ett fall, och bara ett, där att ändra ett e-postmeddelandes mottagningsdatum inte bara är möjligt utan tekniskt motiverat: att korrigera skador orsakade av en dåligt hanterad IMAP-migrering.

Situationen är konkret. Du har precis migrerat 80 Exchange-postlådor till Microsoft 365. Migreringen avslutades en fredagskväll. Måndag morgon börjar ticketsen trilla in: "Alla mina e-postmeddelanden har samma datum", "Jag kan inte hitta ett mejl från förra året", "Min historik med den här kunden är helt trasig". Du har 80 blockerade användare och din chef som väntar på svar.

I det sammanhanget är problemet dokumenterat, identifierbart, och orsaken tydlig: migreringsverktyget lade till en Received:-rubrik daterad till migreringsdagen, och vissa e-postklienter använder den nya rubriken som visningsdatum. Den ursprungliga Date:-rubriken är däremot intakt i varje meddelande. Den har aldrig ändrats. Den innehåller fortfarande det ursprungliga, korrekta avsändningsdatumet.

Korrigeringen är alltså ingen förfalskning, det är en återställning. Man utgår från sann data (den ursprungliga Date:-rubriken) för att återuppbygga konsekventa metadata. Det är fundamentalt annorlunda än att försöka få ett e-postmeddelande från 2024 att se ut som om det kom 2019.

För mer detaljer om mekanismerna för specifika verktyg finns steg-för-steg-guider här: rätta BitTitan-datum i Microsoft 365, rätta CloudM-datum i Outlook, eller rätta imapsync-datum i Google Workspace.

Varför du inte bör skriva ett eget skript

Grundlogiken är tillgänglig. Vilken IT-admin som helst som tillbringat tid på IMAP-forum kan rekonstruera det allmänna tillvägagångssättet. Det är inte problemet.

Problemet är gapet mellan ett skript som fungerar på 50 testmeddelanden och ett skript som körs på 40 000 meddelanden i produktion utan att tappa ett enda e-postmeddelande, utan att korrumpera en enda bilaga, och utan att förstöra en enda konversationstråd.

Några konkreta fall som hemmagjorda skript vanligtvis inte hanterar:

• S/MIME-signerade e-postmeddelanden: signaturen täcker innehållet och rubrikerna. Varje ändring av meddelandestrukturen ogiltigförklarar signaturen. Ett klumpigt korrigerat signerat meddelande når mottagarna som "ogiltig signatur".
• PGP-krypterade meddelanden: samma typ av problem, med potentiellt värre konsekvenser beroende på implementationen.
• Icke-ASCII-kodningar i rubriker: RFC 2047 beskriver kodning av specialtecken i rubriker. Ett skript som manipulerar rubriker utan att hantera dessa fall korrumperar tyst e-postämnen med accenter, japanska tecken eller arabiska namn.
• API-hastighetsbegränsningar: Google Workspace och Microsoft 365 implementerar aggressiv throttling. Klockan tre på natten, ett batch med 10 000 meddelanden som stöter på ett 429 Too Many Requests-fel utan exponentiell backoff-hantering lämnar hälften av postlådorna halvt korrigerade.
• Korrupta MIME-gränser: multipart-meddelanden med bilagor har exakta MIME-gränser. Att återskapa dem felaktigt gör bilagorna oläsliga.

Och frågan inget hemmagjort skript löser: hur verifierar du att varje korrigerat e-postmeddelande är intakt? Ett skript som ändrar 40 000 meddelanden utan individuell verifiering är ett vågspel. Ett vågspel med data som dina användare ofta betraktar som oersättlig.

En artikel om de tillgängliga alternativen för att korrigera datum efter migrering utforskar olika tillvägagångssätt, inklusive deras respektive begränsningar.

Vad Redate.io gör i det här sammanhanget

Redate.io är byggt specifikt för det här fallet: korrigera datum som korrumperats av en IMAP-migrering, i stor skala, utan risk för meddelandenas integritet.

Tjänsten ansluter direkt till berörda postlådor (Google Workspace via domändelegering, Microsoft 365 via Azure AD, eller direkt IMAP), skannar utan kostnad efter meddelanden med felaktiga datum, och tillämpar sedan en proprietär korrigeringspipeline som hanterar de gränsfall som beskrivs ovan. Varje e-postmeddelande verifieras individuellt efter korrigering. Originalen finns kvar i en synlig säkerhetskopieringsmapp i 30 dagar.

Mönstermatchningen täcker hundratals kända signaturer från migreringsverktyg: BitTitan MigrationWiz, CloudM, imapsync, GSMMO och deras varianter. Detektionen är precis: Redate.io rör inte e-postmeddelanden vars datum redan är korrekt.

Prismodellen är enkel: engångsbetalning per postlåda, utan prenumeration. Diagnostikskanningen är kostnadsfri, vilket gör det möjligt att bedöma skadans omfattning innan man bestämmer sig för något.

Om du hanterar postlådor som drabbats av det här problemet beskriver den här artikeln om felaktiga datum i Outlook efter migrering de vanligaste symptomen och hur man skiljer dem från andra orsaker.

Redo att mäta problemets omfattning i dina postlådor? Starta en kostnadsfri skanning på Redate.io och se exakt hur många e-postmeddelanden som påverkas innan någon korrigering görs.