Återskapa Outlook-profil: varför datum ändras

Felsökningsåtgärden som förstör datum

En användare klagar på att Outlook inte längre synkroniserar. E-post kommer inte in, Skickat-mappen uppdateras inte, snurran snurrar i all evighet. Teknikern diagnostiserar en skadad profil, tar bort OST-filen och återskapar Outlook-profilen från grunden. Resultat: Outlook ansluter igen, e-posten dyker upp, allt verkar fungera.

Tills nästa morgon, när användaren öppnar sin inkorg och inser att 8 års korrespondens visar samma datum: idag.

Det är exakt samma symptom som vid en misslyckad IMAP-migrering. Och av samma anledningar.

Vad som händer tekniskt

För att förstå varför ett återskapande av profilen ger det här resultatet behöver man gå tillbaka till en distinktion som de flesta tekniker inte känner till särskilt väl: skillnaden mellan e-postmeddelandets Date:-huvud och dess IMAP INTERNALDATE.

Varje e-postmeddelande innehåller i sina RFC 2822-huvuden ett Date:-fält som anger när meddelandet skickades. Det fältet skrivs av avsändarens e-postklient vid sändningstillfället och transporteras sedan oförändrat genom alla servrar ända till din inkorg. Det ändras aldrig. Ett e-postmeddelande skickat den 14 mars 2019 kl. 09:32 kommer alltid ha det Date:-fältet intakt, oavsett vad som händer sedan.

IMAP INTERNALDATE är något annat. Det är en metadata som hanteras av e-postservern, helt oberoende av meddelandets innehåll. Den anger när meddelandet "levererades" till inkorgen. Under normala omständigheter, när ett e-postmeddelande anländer via SMTP, registrerar servern mottagningsögonblicket som INTERNALDATE. Ett meddelande mottaget den 14 mars 2019 får alltså ett INTERNALDATE som stämmer med avsändningsdatumet.

Outlook sorterar och visar som standard e-post utifrån det INTERNALDATE som IMAP-servern skickar, inte utifrån meddelandets eget Date:-fält. (Och om du någon gång öppnat ett e-postmeddelandes fullständiga egenskaper i Outlook för att se råa huvuden vet du att det inte precis är strandläsning.)

Vad som händer när OST-filen tas bort

När Outlook använder ett IMAP-konto underhåller det en lokal databas: OST-filen (Offline Storage Table). Den filen är en lokal spegel av e-posten som lagras på servern, med metadata, lässtatus, kategorier och så vidare.

Att ta bort OST-filen innebär att den lokala spegeln raderas. Outlook måste alltså ladda ner allt på nytt från IMAP-servern.

Problemet? När Outlook laddar ner ett meddelande via IMAP använder det kommandot FETCH för att hämta innehållet. Men det använder inte konsekvent FETCH INTERNALDATE för att hämta och bevara det ursprungliga IMAP-datumet. I vissa konfigurationer och versioner av Outlook bygger klienten upp sitt lokala index med det datum då meddelandet laddades ner på nytt, snarare än det INTERNALDATE som finns lagrat på servern.

Och då visas plötsligt alla e-postmeddelanden i inkorgen med nedladdningsdagen som datum.

Alla versioner av Outlook beter sig inte likadant

Faktiskt: det här beteendet drabbar inte alla versioner av Outlook på samma sätt, och det är där diagnostiken börjar bli komplicerad.

Outlook 2016 och 2019 i IMAP-läge har dokumenterade beteenden med felaktig indexåterbyggnad efter att cachen tagits bort. Det nya Outlook (webbaserat, som rullas ut gradvis sedan slutet av 2023) hanterar cachen annorlunda och kan ge varierande resultat. Outlook via Exchange/Microsoft 365 med ett konto konfigurerat i Exchange-läge är mindre utsatt för det här specifika problemet, eftersom MAPI/Exchange-protokollet hanterar synkronisering på ett annat sätt än IMAP.

Men om din användare har ett IMAP-konto konfigurerat i klassiska Outlook och en tekniker tagit bort OST-filen eller återskapar profilen: risken är verklig.

Hur man skiljer det här fallet från en riktig migrering

En IT-admin som får ärenden om "fel datum" efter ett profilåterskapande kan felaktigt tro att det rör sig om ett migreringsproblem. Så här skiljer man på de två fallen.

Fallet med IMAP-migrering

Vid en IMAP-migrering (BitTitan, CloudM, imapsync osv.) kopierar migreringsverktyget e-post från en server till en annan. För varje kopierat meddelande skapas en ny post på målservern via kommandot IMAP APPEND. Om verktyget inte uttryckligen anger ursprunglig INTERNALDATE i det kommandot registrerar målservern aktuell tid som INTERNALDATE. Vissa verktyg lägger dessutom till ett Received:-huvud med migreringsdatumet, vilket förvärrar problemet i vissa klienter. Du kan läsa mer om det här i artikeln om IMAP INTERNALDATE och trasiga datum.

Fallet med profilåterskapande

Här finns e-posten fortfarande på samma server, med samma ursprungliga INTERNALDATE. Ingenting har förändrats på serversidan. Det är enbart Outlooks lokala cache som byggts om med felaktiga datum. Det synliga symptomet är identiskt (alla e-postmeddelanden visar samma färska datum), men orsaken är en annan.

Bekräfta diagnosen: logga in på inkorgen via webmail (Gmail, Outlook.com eller din hostingleverantörs webbgränssnitt). Om datumen i webmail är korrekta är problemet rent lokalt i Outlook. Om datumen också är felaktiga i webmail sitter problemet på serversidan, antingen via en migrering eller en direkt ändring av INTERNALDATE på servern.

Varför ursprungsdatum alltid går att återställa

Goda nyheter: i båda fallen (migrering eller profilåterskapande) är de ursprungliga datumen inte förlorade.

RFC 2822-huvudet Date: är en integrerad del av meddelandet. Det är lika oföränderligt som brödtexten eller bilagorna. Ett e-postmeddelande skickat 2017 innehåller i sin råtext något i stil med:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Den raden finns i meddelandet som lagras på servern. Den har inte ändrats. Det Outlook visar (felaktigt) är en metadata som är extern i förhållande till meddelandets innehåll.

Det är det som gör korrigering möjlig. Redate.io:s motor analyserar varje medelandes huvudkedja för att extrahera det verkliga ursprungsdatumet, och utför sedan en riktad korrigering av metadata utan att förändra meddelandets innehåll. Det INTERNALDATE som Outlook ser rekonstrueras utifrån den autentiska informationen som alltid finns kvar i meddelandet.

Fällan med den "rena" återuppbyggnaden

Du har precis löst ett synkroniseringsproblem för en användare. Outlook fungerar igen, nya e-postmeddelanden anländer. Du stänger ärendet.

Tre dagar senare ringer användaren tillbaka: han letar efter ett e-postmeddelande från en leverantör från förra året, men i Outlook visas alla hans meddelanden från 2023 som mottagna "igår". Han hittar ingenting. Den automatiska arkiveringen kan ha klassat nyliga meddelanden som gamla. Och chefen frågar efter en e-postkonversation från september 2022 inför en tvist.

Det här scenariot uppstår regelbundet. Inte för att teknikern gjort något fel, utan för att det här Outlook-beteendet inte dokumenteras tydligt i de vanliga felsökningsguiderna.

Falska lösningar som inte löser någonting

Att sortera e-post på "Skickat datum" istället för "Mottaget datum" i Outlook är det första användare provar. Och det verkar fungera... tills de märker att sortering på skickat datum bara är tillgänglig i vissa mappar, att det försvinner när man byter vy, och att andra appar (mobil, webmail, automatiska sorteringsregler) fortsätter använda det felaktiga INTERNALDATE.

Att sortera på skickat datum är inte en lösning. Det är ett plåster som döljer symptomet utan att röra det verkliga problemet. Vi förklarar det utförligt i artikeln Sortera på avsändningsdatum löser ingenting.

Återskapa profilen en andra gång? Det förändrar ingenting om Outlook ändå bygger om sin cache med aktuellt datum.

Exportera och återimportera via PST? Var försiktig. En PST-export från en Outlook med skadade datum exporterar de skadade metadatan. PST-filen innehåller de felaktiga datumen. Att återimportera filen korrigerar ingenting, och kan till och med förvärra situationen genom att skapa dubbletter med inkonsekventa datum. Det ämnet behandlas i artikeln om PST-import i Outlook och varför alla datum blir fel.

Vad Redate.io gör i det här specifika fallet

Oavsett om problemet beror på en IMAP-migrering eller ett Outlook-profilåterskapande är resultatet på serversidan liknande: e-postmeddelanden vars datummetadata inte stämmer överens med det faktiska innehållet.

Redate.io ansluter direkt till inkorgen (Google Workspace, Microsoft 365 eller direkt IMAP), skannar samtliga meddelanden för att identifiera de med felaktiga metadata, och kör sedan sin flerstegspipeline för att korrigera varje e-postmeddelande individuellt. Varje korrigering verifieras. Originalmeddelanden raderas aldrig: de sparas i en synlig säkerhetskopieringsmapp i din egen inkorg tills du själv väljer att ta bort dem.

Processen hanterar kantfall som hemmagjorda skript missar systematiskt: S/MIME-signerade meddelanden, e-post med icke-ASCII-kodning i huvuden (RFC 2047), komplexa multipart-strukturer, Date:-huvuden med icke-standardiserade eller felaktiga tidszoner. Ett skript som fungerar korrekt på 50 testmeddelanden i en utvecklingsinkorg kan oåterkalleligen skada 2 000 meddelanden i produktion. Det finns ingen inbyggd rollback i IMAP när ett meddelande väl ersatts utan föregående säkerhetskopiering.

För fall specifikt kopplade till Outlook beskriver fix-sidan åtgärda manuella IMAP-kopieringsdatum i Outlook stegen för att ansluta din inkorg och starta analysen.

Förebygg problemet vid nästa insats

Om du är tekniker eller IT-admin och regelbundet arbetar med Outlook-profiler finns det några reflexer som hjälper dig undvika den här situationen.

Innan du tar bort en OST-fil eller återskapar en profil, kontrollera datumen i webmail. Om de är korrekta, notera det i ditt ärende. Efter återuppbyggnaden, logga in i webmail igen och jämför datumen med vad Outlook visar. Dyker en avvikelse upp identifieras problemet direkt, innan användaren hör av sig tre dagar senare.

För planerade migreringar listar checklistan för e-postmigrering de kontroller du bör göra före och efter för att fånga upp den här typen av problem direkt när operationen är klar.

Har du återskapatt en Outlook-profil och alla datum i din inkorg är nu fel? Kör en gratis skanning på Redate.io för att identifiera berörda e-postmeddelanden och rätta till metadata utan att röra innehållet i dina meddelanden.