PST-import i Outlook: varför alla datum blir fel

Symptomet: alla e-postmeddelanden är daterade idag

Du har precis slutfört ett PST-import i Outlook. Förloppsindikatorn nådde 100 %, allt gick bra. Sedan öppnar du inkorgen... och varje importerat meddelande visar dagens datum. Ett e-postmeddelande från 2019, ett annat från 2021, ett arkiv på fem år: alla har samma datum. Datumet för importen.

Det är inte ett visningsfel. Det är inte ett problem med tidszon. Det är ett fullständigt dokumenterat beteende, konsekvent med hur IMAP hanterar datummetadata. Men det är ändå en katastrof för den som behöver hitta gamla e-postmeddelanden efter datum.

Lokal PST och IMAP: två helt olika världar

Innan vi förklarar varför datum går sönder behöver vi förstå vad en PST-fil är ur ett datumhanteringsperspektiv.

En PST-fil (Personal Storage Table) är ett proprietärt Microsoft-format. Det lagrar e-postmeddelanden med fullständiga metadata: avsändningsdatum, mottagningsdatum, bilagor, kategorier, läsindikatorer. Dessa metadata hanteras direkt av Outlook, utanför alla e-postprotokoll. När du öppnar en PST i Outlook utan serveranslutning hämtas de visade datumen direkt från PST-filens interna fält. Hittills är allt bra.

Problemet uppstår när du försöker flytta innehållet till en e-postlåda på en IMAP-server, vare sig det gäller Microsoft 365, Google Workspace eller en vanlig hostingleverantör. Då lämnar du PST-världen och kliver in i IMAP-världen, och reglerna ändras radikalt.

IMAP APPEND och INTERNALDATE: kärnan i problemet

I IMAP har varje meddelande som lagras på servern två typer av datumdata:

• Headern Date: (RFC 2822), som ingår i meddelandets faktiska innehåll. Det är datumet som avsändaren skrev i meddelandet.
• INTERNALDATE, som är en metadata hanterad av IMAP-servern. Den representerar det ögonblick meddelandet placerades på servern. Det är detta värde Outlook använder för att sortera meddelanden i vyn "Mottaget datum".

(Om du någonsin har försökt läsa råa e-postheaders vet du att det inte precis är lättläst. Men det är där allt händer.)

När ett e-postmeddelande normalt anländer till din server ställer e-postservern automatiskt in INTERNALDATE till exakt mottagningsögonblicket. Resultatet: datumet som visas i Outlook stämmer verkligen med när du tog emot meddelandet.

När Outlook importerar en PST-fil till en IMAP-låda använder det kommandot IMAP APPEND för att skicka varje meddelande till servern. IMAP-standarden tillåter att ett explicit INTERNALDATE skickas med vid ett APPEND. Men Outlook gör inte det. Det skickar meddelandena utan att ange något INTERNALDATE. IMAP-servern, utan instruktion, tillämpar då sin standardregel: INTERNALDATE sätts till aktuell tid, det vill säga importögonblicket.

Resultatet: 8000 importerade e-postmeddelanden, 8000 e-postmeddelanden med dagens datum.

Varför Outlook beter sig så här

Det är inget misstag från Microsoft. Det är ett implementationsval som troligen verkade rimligt vid tillfället: i det ursprungliga användningsfallet för PST-import arkiverar användaren meddelanden lokalt och "importerar" dem till sin aktuella låda. Det relevanta datumet för sortering borde vara det ursprungliga mottagningsdatumet... men Microsoft valde att inte överföra INTERNALDATE under importoperationen.

För att vara precis: detta beteende gäller PST-import via Outlooks inbyggda guide (Arkiv > Öppna och exportera > Importera/exportera). Andra importmetoder, som vissa tredjepartsverktyg eller migreringar via Exchange Admin Center, kan bete sig annorlunda beroende på deras implementation av IMAP APPEND.

Det här beteendet är känt och dokumenterat på Microsofts forum sedan många år. Det ändrades inte med Outlook 2016, inte med Outlook 2019 och inte med de aktuella Microsoft 365-versionerna. En användare som importerar en PST idag stöter på exakt samma problem som 2015.

Hur det skiljer sig från en klassisk IMAP-migrering

Det här är där det blir intressant, för PST-import ger ett liknande resultat som en klassisk IMAP-migrering med trasiga datum, men via en annan mekanism.

Vid en typisk IMAP-migrering, till exempel med BitTitan MigrationWiz eller imapsync, förflyttas e-postmeddelanden från en IMAP-källserver till en IMAP-målserver. Migreringsverktyget hämtar meddelandena och återinfogar dem via IMAP APPEND. Vissa verktyg bevarar INTERNALDATE korrekt, andra inte. Men i alla fall har meddelandena redan en Received:-header med migreringsdatumet tillagd, vilket kan störa visningen i Outlook oberoende av INTERNALDATE.

Vid PST-import är mekanismen enklare: det läggs inte till någon Received:-header från migrering (PST-filer passerar inte via en mellanliggande e-postserver), men INTERNALDATE sätts helt enkelt aldrig till rätt värde. Det synliga resultatet är identiskt, den underliggande orsaken skiljer sig något.

Denna skillnad har en direkt konsekvens för korrigeringen: tillvägagångssättet är inte riktigt detsamma beroende på om man hanterar en IMAP-migrering eller ett PST-import. Se också varför INTERNALDATE orsakar trasiga datum för en detaljerad förklaring av båda fallen.

Varför Outlooks visningsalternativ inte hjälper

Den vanliga reaktionen när man upptäcker problemet är att leta igenom Outlook-inställningarna. Det finns faktiskt en inställning som ser lovande ut: möjligheten att sortera e-post efter "Datum" istället för "Mottaget datum".

Sortering på avsändningsdatum är ingen lösning. Det är ett plåster.

Varför? Även om du ändrar sorteringen till att visa kolumnen "Datum" (som motsvarar meddelandets Date:-header, alltså det ursprungliga datumet) kvarstår flera problem:

• Outlooks sökning indexerar på INTERNALDATE. En sökning på "e-post från januari 2020" returnerar inte dina importerade meddelanden från januari 2020, eftersom deras INTERNALDATE säger att de härstammar från importdagen.
• Mapparna "Idag", "Den här veckan", "Den här månaden" i Outlook-gränssnittet baseras på INTERNALDATE, inte på Date:-headern.
• I webbgränssnitt (Outlook Web App, Gmail) och på mobilklienter beror det visade datumet och sorteringsbeteendet nästan alltid på serverns INTERNALDATE.
• Regler och automatiska filter som tillämpas på mottagningsdatum fungerar inte korrekt.

Alltså: att ändra vyn löser visningen för en specifik användare, på en specifik klient, i en specifik konfiguration. Det korrigerar inte problemet vid källan.

OST-omsynkronisering hjälper inte heller

Ett annat klassiskt försök: töm OST-cachen och tvinga fram en fullständig omsynkronisering från servern. Tanken är att problemet kanske finns i Outlooks lokala cache, inte på servern.

Fel spår. OST-filen är en lokal cache som speglar IMAP-serverns tillstånd. Om INTERNALDATE är felaktigt på servern är det felaktigt i OST-filen efter omsynkronisering. Att ta bort OST-filen ändrar ingenting i data som lagras på Exchange Online- eller Google Workspace-servern. Det är servern som är auktoritativ.

Det enda sättet att korrigera datumen är att korrigera metadata direkt på serversidan, meddelande för meddelande. Och det är precis där det blir komplicerat att göra manuellt.

Skalproblemet: 1 e-post är trivialt. 15 000 är en annan historia

Tekniskt sett, om man förstår problemet, kan man tänka sig att skriva ett skript som går igenom lådan, läser varje meddelandes Date:-header och korrigerar INTERNALDATE därefter. Att förstå problemet är en sak. Att korrigera det på 15 000 e-postmeddelanden utan att tappa ett enda är något helt annat.

Några verkliga utmaningar:

• Microsoft Graph API och Gmail API har rate limits. Ett naivt skript utlöser 429 Too Many Requests-fel, avbryter körningen mitt i en korrigering och lämnar dig med en delvis korrigerad låda, utan att veta vilka meddelanden som behandlats och vilka som inte gjort det.
• Vissa e-postmeddelanden i en PST kan ha felaktiga eller saknade Date:-headers. Ett skript utan hantering av dessa edge cases kan korrumpera dessa meddelanden eller hoppa över dem tyst.
• Signerade (S/MIME) eller krypterade (PGP) e-postmeddelanden har extra integritetskrav. Att ändra deras metadata utan försiktighet kan ogiltigförklara den kryptografiska signaturen.
• Strukturer av typen multipart/alternative med komplexa MIME-gränser reagerar ibland oförutsägbart på ändringsoperationer.
• Inget rollback-mekanisme. Om något går fel mitt i behandlingen, hur återgår man till ursprungsläget?

Ett skript som fungerar på 10 teste-postmeddelanden fungerar inte på en produktionslåda med 50 000 meddelanden. För ett år sedan hade en kund med ett PST-arkiv på 40 GB försökt lösa det med ett Python-skript hämtat från Stack Overflow. Resultatet: 3000 dubbletter, 200 meddelanden med otillgängliga bilagor och två veckors manuell städning.

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

Redate.io analyserar metadata för varje meddelande i mållådan, identifierar e-postmeddelanden med felaktiga datum (inklusive sådana från ett PST-import) och tillämpar en korrigering via sitt proprietära korrigeringsmotor. Det flerstegiga analyspipelinet jämför headerskedjan för varje meddelande, extraherar det ursprungliga datumet med RFC-konformitetsvalidering och utför en riktad metadatakorrigering utan att meddelandets innehåll ändras.

Varje korrigerat e-postmeddelande verifieras individuellt. Originalen bevaras i en synlig säkerhetskopieringsmapp i 30 dagar före eventuella definitiva ändringar. Korrigeringen fungerar på de tre huvudplattformarna: Microsoft 365 (via Azure AD), Google Workspace (via domändelegering) och direkt IMAP för vanliga hostingleverantörer.

Den inledande skanningen är gratis. Den visar exakt hur många e-postmeddelanden som påverkas och hur de felaktiga datumen är fördelade, innan du bestämmer dig för något.

Se också:

• Korrigera e-postdatum efter Microsoft 365-migrering
• Outlook: mottaget datum IMAP vs skickat datum
• Kan e-postdatum korrigeras efter migrering?

Har ditt PST-import skrivit över alla datum i dina e-postmeddelanden? Skanna din låda gratis på Redate.io för att mäta problemets omfattning innan du agerar.