Alla gamla e-postmeddelanden har samma datum - vad händer?

Symptomen: alla gamla e-postmeddelanden klumpade på samma datum

Du öppnar Outlook, Gmail eller Apple Mail en morgon. Något stämmer inte. Hundratals, ibland tusentals gamla e-postmeddelanden visar alla samma datum: för några dagar sedan, eller för några veckor sedan. Meddelanden från 2021, 2019, 2016 ser ut som om de kom igår. Sorteringen efter datum är meningslös. Du söker ett viktigt e-postmeddelande från förra året, och det dränks i ett block med tusentals meddelanden som alla verkar ha anlänt samma dag.

Nya e-postmeddelanden visar korrekta datum. Det är bara de gamla meddelandena som drabbats.

Vad har egentligen hänt?

Det första man gör: skylla på programvaran

Naturligtvis tänker man på ett fel. Outlook som kraschat. En uppdatering som gått snett. En skadad fil. Och det är ofta här en riktig labyrint börjar: man söker "felaktigt datum Outlook", hamnar på forum som pratar om OST-filer, SCANPST.exe, att återskapa Outlook-profilen från grunden...

Man lägger två timmar på att testa allt. Problemet kvarstår.

SCANPST är förresten ett reparationsverktyg för lokala Outlook-datafiler. Det kan fixa vissa filkorruptioner, men det rör inte data som lagras på e-postservern. Alltså: även om du reparerar din OST-fil till perfektion förblir datumen felaktiga, för problemet finns inte hos dig.

Problemet sitter i e-postmeddelandena själva, på servern.

Vad som faktiskt hänt: en migrering

I nästan alla fall dyker det här symptomet upp efter en e-postmigrering. Ditt företag har bytt från ett gammalt system till Google Workspace, Microsoft 365 eller en ny server. Någon, någonstans, använde ett verktyg för att flytta alla dina e-postmeddelanden från ett ställe till ett annat.

Du kanske inte ens blivit informerad om det. Eller så visste du om det, men kopplade inte ihop det med datumproblemet. Det är helt normalt.

De här migreringsverktygen gör ett enormt jobb: de kopierar tusentals meddelanden, hela mappar, bilagor. Men de har en ganska otrevlig bieffekt. När ett e-postmeddelande överförs från en server till en annan lägger verktyget till en liten teknisk rad i meddelandet, en så kallad "Received:"-header, som anger när meddelandet anlände till den nya servern. Det vill säga: migreringsdatumet.

Och där har vi problemets kärna.

Hur din e-postklient bestämmer vilket datum som visas

Ett e-postmeddelande innehåller faktiskt flera olika datum, dolda i de tekniska data. Det finns det ursprungliga sändningsdatumet (det du normalt ser), men också "Received:"-headers som registrerar varje steg i meddelandets resa på internet.

(Om du någonsin klickat på "Visa källa" eller "Visa fullständiga headers" i ett e-postmeddelande har du kanske sett de där kryptiska raderna som ser ut som ett obegripligt textblock. Det är precis det vi pratar om.)

Under normala omständigheter tittar din e-postklient på den senaste "Received:"-headern för att avgöra när meddelandet ska visas. Den logiken fungerar utmärkt: den sista "Received:" motsvarar alltid när meddelandet anlände i din brevlåda, alltså några sekunder efter att det skickades.

Men efter en migrering vänds den logiken mot dig. Migreringsverktyget lade till en ny "Received:"-header längst upp, med datumet för överföringen. Din e-postklient läser den headern först, ser migreringsdatumet och visar det. Det ursprungliga sändningsdatumet finns fortfarande kvar, intakt, längre ned i e-postmeddelandets data. Men din klient ser det inte, för den stannar vid den första headern.

Resultatet: 8 000 e-postmeddelanden som alla ser ut att ha anlänt samma tisdag i november.

Vilka verktyg orsakar det här?

De vanligaste migreringsverktygen beter sig alla på det här sättet. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Googles gratisverktyg för att migrera från Outlook) och många andra. Det är egentligen inte ett fel på deras sida: det är en konsekvens av hur e-postprotokollet fungerar tekniskt. Verktygen lägger till den här headern för att det är vad protokollet föreskriver när ett meddelande överförs från en server till en annan.

Problemet är att ingen varnar användarna om att det kommer att hända.

Om ditt företag nyligen bytt e-postsystem, eller om IT-avdelningen genomfört en "molnmigrering", är det med största sannolikhet orsaken till problemet. Du kan verifiera det genom att titta på de påverkade datumen: stämmer de alla ungefär överens med samma period? I så fall är den perioden migreringsdatumet.

Falska spår att undvika

Några lösningar som ofta dyker upp på forum, och som inte fungerar:

Reparera datafilen med SCANPST

Som nämnts ovan: SCANPST reparerar lokala Outlook-filer (de .pst- eller .ost-filer som lagras på din dator). Det ändrar inte e-postmeddelanden på servern. Efter reparationen har dina meddelanden fortfarande samma felaktiga datum, för de datumen sitter i meddelandena själva, inte i den lokala filen.

Återskapa Outlook-profilen

Samma logik. Att återskapa en Outlook-profil innebär att börja om lokalt och sedan ladda ned alla dina e-postmeddelanden från servern på nytt. De hämtade meddelandena har exakt samma felaktiga datum som förut. Du har bara lagt tid på att konfigurera om allt.

Sortera på "sändningsdatum" i stället för "mottagnsdatum"

Vissa forum föreslår att man ändrar sorteringsordningen i Outlook, från mottagningsdatum till sändningsdatum. Det kan hjälpa i vissa fall... men inte alltid. Och det löser ingenting för andra enheter, andra program, eller andra personer som har tillgång till din brevlåda. Grundorsaken finns kvar. Att sortera efter sändningsdatum är ett plåster, inte en lösning.

Installera om e-postklienten

Nej. E-postmeddelandena finns på servern, inte i klienten. Att installera om Outlook, Gmail-appen, Apple Mail eller Thunderbird ändrar ingenting i de data som lagras online.

Den goda nyheten: de riktiga datumen finns fortfarande kvar

Här är något viktigt att förstå, och som gör korrigering möjlig: det ursprungliga sändningsdatumet för varje e-postmeddelande har inte raderats. Det finns fortfarande kvar i meddelandet, i en header som kallas "Date:" och som motsvarar det datum avsändaren valde. Det är en e-poststandard (definierad i en teknisk specifikation kallad RFC 2822) som alla migreringsverktyg respekterar, eftersom att ändra den skulle vara ett allvarligt brott mot standarderna.

Konkret: om du fick ett e-postmeddelande den 14 mars 2022 innehåller det meddelandet fortfarande det datumet någonstans i sin data. Det är bara inte det datum din klient visar först.

Det är precis det som gör korrigering möjlig. Problemet är inte en dataförlust. Det handlar om hur metadata läses: din e-postklient läser fel datum, medan det korrekta datumet fortfarande finns kvar.

Varför du inte bör försöka åtgärda det själv

Du undrar kanske om en IT-person kan skriva ett skript för att fixa problemet. Att förstå vad som hänt är en sak. Att korrigera det ordentligt på tusentals e-postmeddelanden utan att förlora ett enda är en helt annan sak.

Ett e-postmeddelande är inte en enkel textfil. Det kan innehålla bilagor, digitala signaturer, innehåll kodat i komplexa format. Att ändra metadata i ett sådant meddelande utan att förstöra det kräver hantering av dussintals specialfall: elektroniskt signerade meddelanden (S/MIME), krypterad e-post (PGP), icke-standardiserade kodningar, flerdelad struktur... Ett hemmagjort skript som fungerar på 20 testmeddelanden kommer med stor sannolikhet inte fungera korrekt på en produktionsbrevlåda med 15 000 meddelanden. Och om något går fel, hur säkerställer du att inga meddelanden skadats eller försvunnit? Med ett hemmagjort skript: omöjligt.

Utan en mekanism för säkerhetskopiering och individuell verifiering av varje meddelande är risken för oavsiktliga skador verklig.

Vad Redate.io gör

Redate.io är en tjänst byggd specifikt för det här problemet. Den ansluter till din brevlåda (Google Workspace, Microsoft 365 eller en IMAP-server), identifierar e-postmeddelanden vars datum ändrats av en migrering och korrigerar dem via en proprietär analysmotor som undersöker hela headerkedjan och rekonstruerar datummetadata för varje enskilt meddelande.

Varje korrigerat e-postmeddelande verifieras individuellt. Originalen bevaras i en synlig säkerhetskopieringsmapp i 30 dagar. Om något inte stämmer kan du gå tillbaka.

Den inledande skanningen är gratis: Redate.io analyserar din brevlåda och visar dig exakt hur många e-postmeddelanden som påverkats innan du bestämmer dig för något. Inga överraskningar.

Prissättningen är en engångsbetalning baserad på volymen e-postmeddelanden som ska korrigeras. Ingen prenumeration. Du betalar en gång, problemet är löst.

Vill du se skadeomfattningen innan du bestämmer dig? Kör en gratis skanning av din brevlåda på Redate.io och se inom några minuter hur många e-postmeddelanden som påverkats.