PST-import i Outlook: derfor får alle mails dagens dato

Symptomet: alle dine e-mails har fået dagens dato

Du har netop afsluttet et PST-import i Outlook. Statuslinjen nåede 100 %, alt gik tilsyneladende glat. Så åbner du indbakken... og hver eneste importerede e-mail viser dagens dato. En besked fra 2019, en anden fra 2021, et arkiv på fem år: alle bærer den samme dato. Dagen for importen.

Det er ikke en visningsfejl. Det er ikke et tidszoneeproblem. Det er en fuldt dokumenteret adfærd, der hænger sammen med den måde, IMAP håndterer datometadata på. Men det er stadig en katastrofe for alle, der skal finde gamle e-mails sorteret efter dato.

Lokal PST og IMAP: to vidt forskellige verdener

Inden vi forklarer, hvorfor datoerne går i stykker, er det nødvendigt at forstå, hvad en PST-fil er, set fra et datostyringsperspektiv.

En PST-fil (Personal Storage Table) er et proprietært Microsoft-format. Den gemmer e-mails med alle deres metadata: afsendelsesdato, modtagelsesdato, vedhæftede filer, kategorier og læsestatus. Disse metadata håndteres direkte af Outlook, uden for enhver e-mailprotokol. Når du åbner en PST i Outlook uden serveropkobling, kommer de viste datoer direkte fra PST-filens interne felter. Så langt, så godt.

Problemet opstår, når du forsøger at overføre indholdet til en postkasse på en IMAP-server, hvad enten det er Microsoft 365, Google Workspace eller en klassisk udbyder. Dér forlader du PST-verdenen og træder ind i IMAP-verdenen, og reglerne ændrer sig markant.

IMAP APPEND og INTERNALDATE: problemets kerne

I IMAP har hver besked på serveren to typer datodata:

• Date:-headeren (RFC 2822), som er en del af selve beskedindholdet. Det er den dato, afsender har skrevet i beskeden.
• INTERNALDATE, som er en metadata styret af IMAP-serveren. Den angiver, hvornår beskeden blev lagt på serveren. Det er denne værdi, Outlook bruger til at sortere beskeder i visningen "Modtagelsesdato".

(Hvis du nogensinde har prøvet at læse en e-mails rå headers, ved du, at det ikke er ligefrem strandlæsning. Men det er altså der, det hele foregår.)

Når en e-mail ankommer normalt til din server, sætter mailserveren automatisk INTERNALDATE til det nøjagtige modtagelsestidspunkt. Resultatet: den dato, Outlook viser, svarer til, hvornår du faktisk modtog beskeden.

Når Outlook importerer en PST-fil til en IMAP-postkasse, bruger den kommandoen IMAP APPEND til at sende hver besked til serveren. IMAP-standarden tillader, at man angiver en eksplicit INTERNALDATE ved et APPEND. Men det gør Outlook ikke. Den sender beskederne uden at specificere INTERNALDATE. IMAP-serveren anvender da sin standardregel i mangel på instruktion: INTERNALDATE sættes til det aktuelle tidspunkt, altså importøjeblikket.

Resultatet: 8.000 importerede e-mails, 8.000 e-mails med dagens dato.

Hvorfor Outlook opfører sig sådan

Det er ikke en forglemmelse fra Microsofts side. Det er et implementeringsvalg, der sandsynligvis virkede fornuftigt dengang: i den oprindelige use case for PST-import arkiverede brugeren beskeder lokalt og "importerede" dem til sin aktuelle postkasse. Den relevante dato for sortering burde være den originale modtagelsesdato... men Microsoft valgte altså ikke at propagere INTERNALDATE under importoperationen.

For at være præcis: denne adfærd gælder PST-import via Outlooks native assistent (Filer > Åbn og eksporter > Importér/Eksportér). Andre importmetoder, såsom visse tredjepartsværktøjer eller migreringer via Exchange Administration Center, kan opføre sig anderledes afhængigt af deres implementering af IMAP APPEND.

Denne adfærd er velkendt og dokumenteret på Microsofts fora i årevis. Den ændrede sig ikke med Outlook 2016, ikke med Outlook 2019, og heller ikke med de nuværende Microsoft 365-versioner. En bruger, der importerer en PST i dag, støder på præcis det samme problem som i 2015.

Hvad der adskiller det fra en klassisk IMAP-migrering

Her bliver det interessant, for PST-import giver et resultat, der ligner en klassisk IMAP-migrering med ødelagte datoer, men via en anden mekanisme.

Ved en typisk IMAP-migrering, eksempelvis med BitTitan MigrationWiz eller imapsync, flyttes e-mails fra en IMAP-kildeserver til en IMAP-destinationsserver. Migreringsværktøjet henter beskederne og genindsætter dem via IMAP APPEND. Nogle værktøjer bevarer INTERNALDATE korrekt, andre ikke. Men i alle tilfælde er der allerede tilføjet en Received:-header med migreringsdatoen, som kan forstyrre visningen i Outlook uafhængigt af INTERNALDATE.

Med et PST-import er mekanismen enklere: der tilføjes ingen migrerings-Received:-header (PST-filer passerer ikke igennem en mellemliggende mailserver), men INTERNALDATE sættes simpelthen aldrig til den korrekte værdi. Det synlige resultat er det samme, den underliggende årsag er lidt anderledes.

Denne forskel har direkte konsekvenser for rettelsen: tilgangen er ikke helt den samme, afhængigt af om man behandler en IMAP-migrering eller et PST-import. Se også hvorfor INTERNALDATE ødelægger datoer for en detaljeret forklaring af begge tilfælde.

Hvorfor Outlooks visningsindstillinger ikke løser noget

Den typiske reaktion, når man opdager problemet, er at dykke ned i Outlooks indstillinger. Og der er faktisk en indstilling, der ser lovende ud: muligheden for at sortere e-mails efter "Dato" frem for "Modtagelsesdato".

Sortering efter afsendelsesdato er ikke en løsning. Det er et plaster.

Her er hvorfor: selv hvis du skifter sortering til kolonnen "Dato" (som svarer til beskedens Date:-header, altså den originale dato), består flere problemer:

• Outlooks søgning indekserer på INTERNALDATE. En søgning efter "e-mails fra januar 2020" returnerer ikke dine importerede e-mails fra januar 2020, fordi deres INTERNALDATE siger, de stammer fra importdagen.
• Mapperne "I dag", "Denne uge", "Denne måned" i Outlooks grænseflade er baseret på INTERNALDATE, ikke på Date:-headeren.
• I webgrænseflader (Outlook Web App, Gmail) og på mobilklienter afhænger den viste dato og sorteringsadfærden næsten altid af serverens INTERNALDATE.
• Automatiske regler og filtre, der anvendes på modtagelsesdatoen, fungerer ikke korrekt.

Kort sagt løser et visningsskift problemet for én bestemt bruger, på én bestemt klient, i én bestemt konfiguration. Det retter ikke problemet ved kilden.

OST-gensynkronisering hjælper heller ikke

Et andet klassisk forsøg: tøm OST-cachen og tving en fuld gensynkronisering fra serveren. Ideen er, at problemet måske stammer fra Outlooks lokale cache og ikke fra serveren.

Forkert spor. OST-filen er en lokal cache, der afspejler IMAP-serverens tilstand. Hvis INTERNALDATE er forkert på serveren, vil den være forkert i OST'en efter gensynkronisering. Sletning af OST'en ændrer ikke de data, der er gemt på Exchange Online- eller Google Workspace-serveren. Det er serveren, der er autoritativ.

Den eneste måde at rette datoerne på er at korrigere metadata direkte på serversiden, besked for besked. Og det er præcis her, det bliver kompliceret at gøre manuelt.

Skalaproblemet: 1 e-mail er trivielt. 15.000 er en anden sag

Teknisk set, hvis man forstår problemet, kunne man forestille sig at skrive et script, der gennemgår postkassen, læser hver beskeds Date:-header og retter INTERNALDATE tilsvarende. At forstå problemet er én ting. At rette det på 15.000 e-mails uden at miste en eneste, er noget helt andet.

Lidt virkelighed fra praksis:

• Microsoft Graph API og Gmail pålægger rate limits. Et naivt script udløser 429 Too Many Requests-fejl, afbryder sin kørsel midt i en rettelse og efterlader dig med en delvist rettet postkasse, uden at du ved, hvilke e-mails der er behandlet, og hvilke der ikke er.
• Nogle e-mails i en PST kan have misformede eller manglende Date:-headers. Et script uden håndtering af disse edge cases kan korrupte disse beskeder eller stille og roligt springe dem over.
• Signerede (S/MIME) eller krypterede (PGP) e-mails har yderligere integritetsbegrænsninger. Ændring af deres metadata uden forsigtighed kan ugyldiggøre den kryptografiske signatur.
• Multipart/alternative-strukturer med komplekse MIME-grænser reagerer sommetider uforudsigeligt på ændringsoperationer.
• Ingen rollback-mekanisme. Hvis noget går galt midt i behandlingen, hvordan vender du så tilbage til udgangstilstanden?

Et script, der virker på 10 teste-mails, virker ikke på en produktionspostkasse med 50.000 beskeder. For et par år siden forsøgte en kunde med et 40 GB PST-arkiv at rette det med et Python-script fundet på Stack Overflow. Resultatet: 3.000 dubletter, 200 beskeder med utilgængelige vedhæftede filer og to ugers manuel oprydning.

Hvad Redate.io gør i dette konkrete tilfælde

Redate.io analyserer metadata for hver besked i målpostkassen, identificerer e-mails med forkerte datoer (herunder dem fra et PST-import) og anvender en rettelse via sin proprietære korrigationsmotor. Den flertrinsdatabehandlingspipeline sammenligner header-kæden for hver besked, udtrækker den originale dato med RFC-overensstemmelsesvalidering og foretager en målrettet metadatarettelse uden at ændre beskedens indhold.

Hver rettet e-mail verificeres individuelt. De originale beskeder bevares i en synlig sikkerhedskopimappe i 30 dage, inden nogen endelig ændring foretages. Rettelsen fungerer på de tre primære platforme: Microsoft 365 (via Azure AD), Google Workspace (via domænedelegering) og direkte IMAP til klassiske udbydere.

Det indledende scan er gratis. Det viser præcis, hvor mange e-mails der er berørt, og hvordan de forkerte datoer er fordelt, inden du beslutter dig for noget.

Se også:

• Ret e-maildatoer efter migrering til Microsoft 365
• Outlook: modtagelsesdato IMAP vs afsendelsesdato
• Kan e-maildatoer rettes efter en migrering?

Har dit PST-import overskrevet alle dine e-maildatoer? Scan din postkasse gratis på Redate.io og få overblik over problemets omfang, inden du handler.