PST-import in Outlook: waarom alle datums op vandaag staan

Het symptoom: alle e-mails dateren van vandaag

U hebt net een PST-import uitgevoerd in Outlook. De voortgangsbalk bereikte 100%, alles leek vlot te verlopen. U opent uw inbox... en elk geïmporteerd bericht toont de datum van vandaag. Een e-mail uit 2019, een ander uit 2021, een archief van vijf jaar: ze dragen allemaal dezelfde datum. Die van de dag van de import.

Dit is geen weergavefout. Het heeft niets te maken met tijdzones. Het is een gedrag dat perfect gedocumenteerd is en voortvloeit uit de manier waarop IMAP omgaat met datummetadata. Maar het is een ramp voor iedereen die oude e-mails op datum moet terugvinden.

Lokaal PST-bestand en IMAP: twee heel verschillende werelden

Om te begrijpen waarom datums kapotgaan, moet u eerst weten wat een PST-bestand is vanuit het oogpunt van datumbeheer.

Een PST-bestand (Personal Storage Table) is een eigen Microsoft-formaat. Het slaat e-mails op met hun volledige metadata: verzenddatum, ontvangstdatum, bijlagen, categorieën en leesmarkeringen. Deze metadata worden rechtstreeks door Outlook beheerd, buiten elk e-mailprotocol om. Wanneer u een PST in Outlook opent zonder serververbinding, komen de weergegeven datums direct uit de interne velden van het PST-bestand. Tot zover geen problemen.

De problemen beginnen wanneer u die inhoud wilt overzetten naar een mailbox die op een IMAP-server staat, of dat nu Microsoft 365 is, Google Workspace of een gewone hostingprovider. Dan verlaat u de PST-wereld en stapt u de IMAP-wereld in, en daar gelden heel andere regels.

IMAP APPEND en de INTERNALDATE: de kern van het probleem

In IMAP heeft elk bericht op de server twee soorten datumgegevens:

• De Date:-header (RFC 2822), die onderdeel is van de berichtinhoud zelf. Dit is de datum die de afzender in het bericht heeft opgenomen.
• De INTERNALDATE, een metadata-waarde die door de IMAP-server wordt beheerd. Ze geeft het moment aan waarop het bericht op de server is geplaatst. Dit is de waarde die Outlook gebruikt om berichten te sorteren in de weergave "Ontvangstdatum".

(Als u ooit de ruwe headers van een e-mail hebt proberen te lezen, weet u dat het niet bepaald lichte zomervakantielectuur is. Maar dit is precies waar alles beslist wordt.)

Wanneer een e-mail op de normale manier binnenkomt, stelt de mailserver de INTERNALDATE automatisch in op het exacte moment van ontvangst. Het resultaat: de datum die Outlook toont, klopt met wanneer u het bericht hebt ontvangen.

Wanneer Outlook een PST-bestand importeert naar een IMAP-mailbox, gebruikt het het commando IMAP APPEND om elk bericht naar de server te sturen. De IMAP-standaard laat toe om een expliciete INTERNALDATE mee te geven bij een APPEND. Maar Outlook doet dat niet. Het verstuurt de berichten zonder een INTERNALDATE op te geven. De IMAP-server past dan zijn standaardregel toe: de INTERNALDATE wordt ingesteld op het huidige tijdstip, dus het moment van de import.

Resultaat: 8.000 geïmporteerde e-mails, 8.000 e-mails met de datum van vandaag.

Waarom Outlook zich zo gedraagt

Dit is geen vergissing van Microsoft. Het is een implementatiekeuze die destijds waarschijnlijk logisch leek: in het oorspronkelijke gebruiksscenario van PST-import archiveerde de gebruiker berichten lokaal en "importeerde" ze in zijn huidige mailbox. De relevante datum voor sortering zou de originele ontvangstdatum moeten zijn... maar Microsoft heeft ervoor gekozen de INTERNALDATE niet door te geven bij de importoperatie.

Om precies te zijn: dit gedrag geldt voor de PST-import via de ingebouwde wizard van Outlook (Bestand > Openen en exporteren > Importeren/Exporteren). Andere importmethoden, zoals bepaalde tools van derden of migraties via het Exchange-beheercentrum, kunnen zich anders gedragen afhankelijk van hun implementatie van IMAP APPEND.

Dit gedrag is al jaren bekend en gedocumenteerd op de Microsoft-forums. Het is niet veranderd met Outlook 2016, niet met Outlook 2019, en ook niet met de huidige Microsoft 365-versies. Wie vandaag een PST importeert, stuit op exact hetzelfde probleem als in 2015.

Hoe dit verschilt van een gewone IMAP-migratie

Hier wordt het interessant, want een PST-import levert een vergelijkbaar resultaat op als een klassieke IMAP-migratie met kapotte datums, maar via een ander mechanisme.

Bij een typische IMAP-migratie, bijvoorbeeld met BitTitan MigrationWiz of imapsync, verplaatsen e-mails zich van een bron-IMAP-server naar een doel-IMAP-server. De migratietool haalt de berichten op en plaatst ze opnieuw via IMAP APPEND. Sommige tools bewaren de INTERNALDATE correct, andere niet. Maar in alle gevallen hebben de berichten al een Received:-header met de migratiedatum die onderweg is toegevoegd, wat de weergave in Outlook kan verstoren los van de INTERNALDATE.

Bij een PST-import is het mechanisme eenvoudiger: er wordt geen migratie-Received:-header toegevoegd (PST-bestanden passeren geen tussenliggende mailserver), maar de INTERNALDATE wordt simpelweg nooit op de juiste waarde ingesteld. Het zichtbare resultaat is identiek, de onderliggende oorzaak verschilt licht.

Dit onderscheid heeft een directe invloed op de correctie: de aanpak is niet helemaal dezelfde voor een IMAP-migratie als voor een PST-import. Zie ook waarom de INTERNALDATE datums doet kapotgaan voor een gedetailleerde uitleg van beide gevallen.

Waarom de weergave-opties van Outlook niets oplossen

De meest voor de hand liggende reactie wanneer u het probleem ontdekt, is graven in de Outlook-instellingen. En er is inderdaad een instelling die veelbelovend lijkt: de mogelijkheid om e-mails te sorteren op "Datum" in plaats van op "Ontvangstdatum".

Sorteren op verzenddatum is geen oplossing. Het is een pleister.

Dit is waarom: zelfs als u de sortering aanpast naar de kolom "Datum" (die overeenkomt met de Date:-header van het bericht, dus de originele datum), blijven er meerdere problemen bestaan:

• De Outlook-zoekindex is gebaseerd op de INTERNALDATE. Een zoekopdracht naar "e-mails van januari 2020" geeft uw geïmporteerde berichten uit januari 2020 niet terug, omdat hun INTERNALDATE aangeeft dat ze dateren van de dag van de import.
• De mappen "Vandaag", "Deze week" en "Deze maand" in Outlook zijn gebaseerd op de INTERNALDATE, niet op de Date:-header.
• In webinterfaces (Outlook Web App, Gmail) en mobiele clients is de weergegeven datum en het sorteergedrag vrijwel altijd gebaseerd op de server-INTERNALDATE.
• Automatische regels en filters op ontvangstdatum werken dan niet correct.

Kortom: de weergave aanpassen lost het probleem op voor één specifieke gebruiker, op één specifieke client, in één specifieke configuratie. Het herstelt de fout niet aan de bron.

Ook OST opnieuw synchroniseren helpt niet

Een andere klassieke poging: de OST-cache leegmaken en een volledige hersynchronisatie vanaf de server forceren. Het idee is dat het probleem misschien in de lokale cache van Outlook zit, niet op de server.

Verkeerd spoor. Het OST-bestand is een lokale cache die de toestand van de IMAP-server weerspiegelt. Als de INTERNALDATE fout staat op de server, staat hij na hersynchronisatie ook fout in de OST. De OST verwijderen verandert niets aan de gegevens die op Exchange Online of Google Workspace zijn opgeslagen. De server is de enige bron van waarheid.

De enige manier om datums te herstellen, is de metadata rechtstreeks op de server corrigeren, bericht voor bericht. En precies daar wordt het ingewikkeld om handmatig aan te pakken.

Het schaalprobleem: 1 e-mail is triviaal. 15.000 is een ander verhaal

Wie het probleem technisch begrijpt, zou kunnen denken aan een script dat de mailbox doorloopt, de Date:-header van elk bericht leest, en de INTERNALDATE overeenkomstig corrigeert. Het probleem begrijpen is één ding. Het corrigeren voor 15.000 e-mails zonder er één te verliezen, is iets heel anders.

Enkele praktijkfeiten:

• De Microsoft Graph API en Gmail API leggen rate limits op. Een onbezonnen script triggert 429 Too Many Requests-fouten, onderbreekt halverwege een correctieronde en laat u achter met een gedeeltelijk gecorrigeerde mailbox, zonder dat u weet welke berichten al zijn verwerkt en welke niet.
• Sommige e-mails in een PST kunnen misvormde of ontbrekende Date:-headers hebben. Een script zonder afhandeling van deze randgevallen beschadigt die berichten of slaat ze stilzwijgend over.
• Ondertekende e-mails (S/MIME) of versleutelde berichten (PGP) hebben extra integriteitsvereisten. Hun metadata aanpassen zonder voorzorgsmaatregelen kan de cryptografische handtekening ongeldig maken.
• Multipart/alternative-structuren met complexe MIME-grenzen reageren soms onvoorspelbaar op wijzigingsoperaties.
• Geen rollback-mechanisme. Als er iets misgaat halverwege de verwerking, hoe keert u dan terug naar de begintoestand?

Een script dat werkt op 10 teste-mails, werkt niet op een productiemailbox van 50.000 berichten. Vorig jaar probeerde een klant met een PST-archief van 40 GB dit op te lossen met een Python-script van Stack Overflow. Resultaat: 3.000 e-mails in dubbel, 200 berichten met ontoegankelijke bijlagen, en twee weken handmatig opruimwerk.

Wat Redate.io doet in dit specifieke geval

Redate.io analyseert de metadata van elk bericht in de doelmailbox, identificeert de e-mails met onjuiste datums (inclusief die afkomstig van een PST-import), en past een correctie toe via zijn eigen correctie-engine. De multi-stage analysepipeline vergelijkt de headerketen van elk bericht, extraheert de originele datum met RFC-conformiteitsvalidatie, en voert een gerichte correctie uit van de metadata zonder de berichtinhoud aan te tasten.

Elk gecorrigeerd bericht wordt individueel geverifieerd. De originelen worden 30 dagen bewaard in een zichtbare back-upmap vóór elke definitieve wijziging. De correctie werkt op de drie belangrijkste platformen: Microsoft 365 (via Azure AD), Google Workspace (via domeinbrede delegatie) en directe IMAP voor gewone hostingproviders.

De eerste scan is gratis. Die toont precies hoeveel e-mails zijn getroffen en wat de verdeling van de onjuiste datums is, zodat u een weloverwogen beslissing kunt nemen.

Zie ook:

• E-maildatums herstellen na Microsoft 365-migratie
• Outlook: ontvangstdatum IMAP-migratie vs verzenddatum
• Kunnen e-maildatums worden hersteld na migratie?

Heeft uw PST-import alle e-maildatums overschreven? Scan uw mailbox gratis op Redate.io om de omvang van het probleem te meten voordat u actie onderneemt.