PST-import i Outlook: hvorfor alle datoer blir feil

Symptomet: alle e-postene dine er datert til i dag

Du har nettopp fullført en PST-import i Outlook. Fremdriftslinjen nådde 100 %, alt gikk smertefritt. Så åpner du innboksen... og hver eneste importerte e-post viser dagens dato. En melding fra 2019, en annen fra 2021, et arkiv på fem år: alle bærer samme dato. Dagen for importen.

Dette er ikke en visningsfeil. Det er ikke et tidssone-problem. Det er en fullt dokumentert oppførsel, helt i tråd med hvordan IMAP håndterer datometadata. Men det er fortsatt en katastrofe for alle som trenger å finne gamle e-poster etter dato.

Lokal PST og IMAP: to vidt forskjellige verdener

Før vi forklarer hvorfor datoene brekker, må vi forstå hva en PST-fil egentlig er sett fra et datostyringsperspektiv.

En PST-fil (Personal Storage Table) er et proprietært Microsoft-format. Den lagrer e-poster med fullstendige metadata: sendedato, mottaksdato, vedlegg, kategorier og lese-indikatorer. Disse metadataene styres direkte av Outlook, utenfor enhver e-postprotokoll. Når du åpner en PST i Outlook uten tilkobling til en server, hentes datoene som vises direkte fra de interne feltene i PST-filen. Så langt, så bra.

Problemet oppstår når du prøver å overføre innholdet til en postkasse som er lagret på en IMAP-server - enten det er Microsoft 365, Google Workspace eller en vanlig e-postleverandør. Da forlater du PST-verdenen og trer inn i IMAP-verdenen, og reglene endres radikalt.

IMAP APPEND og INTERNALDATE: kjernen i problemet

I IMAP har hver melding som er lagret på serveren to typer datodata:

• Date:-headeren (RFC 2822), som er en del av selve meldingsinnholdet. Dette er datoen avsenderen skrev inn i meldingen.
• INTERNALDATE, en metadata-verdi som styres av IMAP-serveren. Den representerer tidspunktet meldingen ble lagt til på serveren. Det er denne verdien Outlook bruker til å sortere meldinger i visningen "Mottatt dato".

(Hvis du noen gang har prøvd å lese rå e-postheadere, vet du at det ikke akkurat er strandlesning. Men det er her alt skjer.)

Når en e-post ankommer serveren på vanlig måte, setter e-postserveren automatisk INTERNALDATE til det eksakte mottakstidspunktet. Resultatet: datoen som vises i Outlook stemmer faktisk med når du mottok meldingen.

Når Outlook importerer en PST-fil til en IMAP-postkasse, brukes kommandoen IMAP APPEND til å sende hver melding til serveren. IMAP-standarden tillater at du sender en eksplisitt INTERNALDATE ved en APPEND-operasjon. Men det gjør ikke Outlook. Meldingene sendes uten at INTERNALDATE spesifiseres. IMAP-serveren, uten noen instruksjon, faller tilbake til sin standardregel: INTERNALDATE settes til gjeldende tidspunkt, altså importøyeblikket.

Resultatet: 8 000 importerte e-poster, 8 000 e-poster med dagens dato.

Hvorfor Outlook oppfører seg slik

Dette er ikke en forglemmelse fra Microsoft. Det er et implementasjonsvalg som sannsynligvis virket fornuftig den gangen: i det opprinnelige bruksscenarioet for PST-import arkiverer brukeren meldinger lokalt og "importerer" dem til sin aktive postkasse. Den relevante datoen for sortering burde vært den opprinnelige mottaksdatoen... men Microsoft valgte altså å ikke videreføre INTERNALDATE under importoperasjonen.

For å være presis: denne oppførselen gjelder PST-import via Outlooks innebygde veiviser (Fil > Åpne og eksporter > Importer/Eksporter). Andre importmetoder, som visse tredjepartsverktøy eller migreringer via Exchange-administrasjonssenteret, kan oppføre seg annerledes avhengig av deres implementering av IMAP APPEND.

Oppførselen er kjent og dokumentert på Microsofts forum i mange år. Den endret seg ikke med Outlook 2016, ikke med Outlook 2019, og ikke med gjeldende Microsoft 365-versjoner. En bruker som importerer en PST i dag vil oppleve nøyaktig samme problem som i 2015.

Hvordan dette skiller seg fra en vanlig IMAP-migrering

Her blir det interessant, for PST-import gir et lignende resultat som en vanlig IMAP-migrering med ødelagte datoer, men via en annen mekanisme.

Ved en typisk IMAP-migrering, for eksempel med BitTitan MigrationWiz eller imapsync, flyttes e-poster fra en IMAP-kildeserver til en IMAP-målserver. Migreringverktøyet henter meldingene og injiserer dem på nytt via IMAP APPEND. Noen verktøy bevarer INTERNALDATE korrekt, andre gjør det ikke. Men uansett har meldingene allerede fått en Received:-header med migreringsdatoen lagt til underveis, noe som kan forstyrre visningen i Outlook uavhengig av INTERNALDATE.

Med PST-import er mekanismen enklere: ingen Received:-header fra migreringen legges til (PST-filer passerer ikke gjennom en mellomliggende e-postserver), men INTERNALDATE settes rett og slett aldri til korrekt verdi. Det synlige resultatet er identisk, den underliggende årsaken er litt forskjellig.

Dette skillet har en direkte konsekvens for rettingen: fremgangsmåten er ikke helt den samme enten man behandler en IMAP-migrering eller en PST-import. Se også hvorfor INTERNALDATE forårsaker ødelagte datoer for en detaljert forklaring av begge tilfellene.

Hvorfor Outlooks visningsalternativer ikke hjelper

Den vanlige reaksjonen når man oppdager problemet er å grave i Outlook-innstillingene. Og det finnes faktisk et innstillingsvalg som ser lovende ut: muligheten til å sortere e-poster etter "Dato" i stedet for "Mottatt dato".

Sortering etter sendedato er ikke en løsning. Det er et plaster.

Her er grunnen: selv om du endrer sorteringen til å vise kolonnen "Dato" (som tilsvarer Date:-headeren i meldingen, altså den opprinnelige datoen), vedvarer flere problemer:

• Outlook-søket indekserer på INTERNALDATE. Et søk etter "e-poster fra januar 2020" vil ikke returnere dine importerte e-poster fra januar 2020, fordi INTERNALDATE deres sier at de stammer fra importdagen.
• Mappene "I dag", "Denne uken", "Denne måneden" i Outlook-grensesnittet er basert på INTERNALDATE, ikke på Date:-headeren.
• I nettgrensesnitt (Outlook Web App, Gmail) og på mobilklienter er den viste datoen og sorteringsoppførselen nesten alltid avhengig av server-INTERNALDATE.
• Automatiske regler og filtre som er basert på mottaksdato vil ikke fungere korrekt.

Altså: å endre visningen løser det for én bestemt bruker, på én bestemt klient, i én bestemt konfigurasjon. Det retter ikke problemet ved kilden.

OST-resynkronisering hjelper heller ikke

Et annet klassisk forsøk: tøm OST-cachen og tving en fullstendig resynkronisering fra serveren. Tanken er at problemet kanskje ligger i Outlooks lokale cache, ikke på serveren.

Feil spor. OST-filen er en lokal cache som gjenspeiler tilstanden til IMAP-serveren. Hvis INTERNALDATE er feil på serveren, vil den være feil i OST-filen etter resynkronisering. Å slette OST-filen endrer ingenting på dataene som er lagret på Exchange Online- eller Google Workspace-serveren. Det er serveren som er autoriteten.

Den eneste måten å rette datoene på er å rette metadataene direkte på serversiden, melding for melding. Og det er nettopp her det blir komplisert å gjøre manuelt.

Skalaproblem: 1 e-post er trivielt. 15 000 er en helt annen sak

Teknisk sett, om man forstår problemet, kan man tenke seg å skrive et skript som går gjennom postkassen, leser Date:-headeren til hver melding, og retter INTERNALDATE tilsvarende. Å forstå problemet er én ting. Å rette det på 15 000 e-poster uten å miste én eneste, er noe helt annet.

Noen realiteter fra virkeligheten:

• Microsoft Graph API og Gmail har hastighetsbegrensninger (rate limits). Et naivt skript vil utløse 429 Too Many Requests-feil, avbryte kjøringen midt i en retteprosess, og etterlate deg med en delvis rettet postkasse der du ikke vet hvilke e-poster som ble behandlet og hvilke som ikke ble det.
• Noen e-poster i en PST kan ha manglende eller misformede Date:-headere. Et skript uten håndtering av disse grensetilfellene kan korruptere disse meldingene eller hoppe over dem lydløst.
• Signerte e-poster (S/MIME) eller krypterte meldinger (PGP) har ekstra integritetsbegrensninger. Å endre metadataene uten forsiktighet kan ugyldiggjøre den kryptografiske signaturen.
• Multipart/alternative-strukturer med komplekse MIME-grenser reagerer noen ganger uforutsigbart på endringsoperasjoner.
• Ingen rollback-mekanisme. Hvis noe går galt midt i behandlingen, hvordan går man tilbake til utgangspunktet?

Et skript som fungerer på 10 teste-poster vil ikke fungere på en produksjonspostkasse med 50 000 meldinger. For et år siden prøvde en kunde med et PST-arkiv på 40 GB å rette dette med et Python-skript hentet fra Stack Overflow. Resultatet: 3 000 e-poster i duplikat, 200 meldinger med utilgjengelige vedlegg, og to uker med manuelt opprydningsarbeid.

Hva Redate.io gjør i dette konkrete tilfellet

Redate.io analyserer metadataene til hver melding i målpostkassen, identifiserer e-poster med feil datoer (inkludert de som stammer fra en PST-import), og anvender en rettelse via den proprietære korreksjonsmotoren. Den flertrinns analysepipelinen sammenligner header-kjeden i hver melding, ekstraherer den opprinnelige datoen med RFC-samsvar-validering, og gjennomfører en målrettet metadatakorreksjonen uten å endre meldingsinnholdet.

Hver rettet e-post verifiseres individuelt. Originalene bevares i en synlig sikkerhetskopimappe i 30 dager før eventuelle endelige endringer. Rettingen fungerer på de tre hovedplattformene: Microsoft 365 (via Azure AD), Google Workspace (via domenedelegering) og direkte IMAP for vanlige e-postleverandører.

Det innledende skannet er gratis. Det viser nøyaktig hvor mange e-poster som er berørt og hvordan de feil datoene fordeler seg, før du bestemmer deg for noe som helst.

Se også:

• Rett e-postdatoer etter Microsoft 365-migrering
• Outlook: mottaksdato IMAP vs sendedato etter migrering
• Kan e-postdatoer rettes etter migrering?

PST-importen din har overskrevet alle e-postdatoene? Skann postkassen din gratis på Redate.io for å kartlegge omfanget av problemet før du handler.