Outlook-profiel opnieuw aanmaken: waarom datums veranderen

De standaard oplossing die datums kapotmaakt

Een gebruiker klaagt dat Outlook niet meer synchroniseert. E-mails komen niet binnen, de map Verzonden wordt niet bijgewerkt, het wiel draait maar door. De technicus diagnosticeert een beschadigd profiel, verwijdert het OST-bestand en maakt het Outlook-profiel helemaal opnieuw aan. Resultaat: Outlook maakt opnieuw verbinding, de e-mails verschijnen weer, alles lijkt te werken.

Tot de volgende ochtend, wanneer de gebruiker zijn mailbox opent en realiseert dat 8 jaar aan correspondentie dezelfde datum toont: vandaag.

Dit is precies hetzelfde symptoom als bij een mislukte IMAP-migratie. En om dezelfde redenen.

Wat er technisch gebeurt

Om te begrijpen waarom het opnieuw aanmaken van een profiel dit resultaat geeft, moet je terug naar een onderscheid dat de meeste technici slecht kennen: het verschil tussen de Date:-header van een e-mail en zijn IMAP INTERNALDATE.

Elke e-mail bevat in zijn RFC 2822-headers een veld Date: dat aangeeft wanneer het bericht is verzonden. Dit veld wordt door de e-mailclient van de afzender ingevuld op het moment van verzending, en vervolgens ongewijzigd doorgegeven via alle servers naar uw mailbox. Het verandert nooit. Een e-mail verzonden op 14 maart 2019 om 09:32 heeft altijd dat intacte Date:-veld, ongeacht wat er daarna gebeurt.

De IMAP INTERNALDATE is iets anders. Het is een metadata-veld dat door de mailserver wordt beheerd, los van de inhoud van het bericht. Het geeft aan wanneer het bericht in de mailbox is "geplaatst". Normaal gesproken, wanneer een e-mail via SMTP binnenkomt, slaat de server de ontvangsttijd op als INTERNALDATE. Een e-mail ontvangen op 14 maart 2019 heeft dus een INTERNALDATE die consistent is met de verzenddatum.

Outlook sorteert en toont e-mails standaard op basis van de INTERNALDATE die de IMAP-server doorgeeft, niet op basis van het Date:-veld in het bericht zelf. (Als u ooit de volledige eigenschappen van een e-mail in Outlook hebt geopend om de ruwe headers te bekijken, weet u dat dit zelden gemakkelijke kost is.)

Wat het verwijderen van het OST-bestand veroorzaakt

Wanneer Outlook een IMAP-account gebruikt, onderhoudt het een lokale database: het OST-bestand (Offline Storage Table). Dit bestand is een lokale spiegel van de e-mails die op de server zijn opgeslagen, inclusief hun metadata, leesstatus, categorieën, enzovoort.

Het OST-bestand verwijderen is hetzelfde als die lokale spiegel wissen. Outlook moet dan alles opnieuw downloaden vanaf de IMAP-server.

Het probleem? Wanneer Outlook een bericht opnieuw downloadt via IMAP, gebruikt het de FETCH-opdracht om de inhoud op te halen. Maar het gebruikt niet altijd de opdracht FETCH INTERNALDATE om de originele IMAP-datum op te halen en te bewaren. In bepaalde configuraties en versies van Outlook bouwt de client zijn lokale index op met de datum waarop het bericht opnieuw werd gedownload, in plaats van de INTERNALDATE die op de server is opgeslagen.

En zo krijgen alle e-mails in de mailbox de datum van de dag waarop ze opnieuw werden geladen.

Niet alle versies van Outlook gedragen zich hetzelfde

Eigenlijk treft dit gedrag niet alle versies van Outlook op dezelfde manier, en dat maakt de diagnose er niet eenvoudiger op.

Outlook 2016 en 2019 in IMAP-modus hebben gedocumenteerd onjuist gedrag bij het herbouwen van de index na het verwijderen van de cache. Het nieuwe Outlook (gebaseerd op de webversie, geleidelijk uitgerold vanaf eind 2023) beheert de cache anders en kan wisselende resultaten geven. Outlook via Exchange/Microsoft 365 met een account in Exchange-modus is minder gevoelig voor dit specifieke probleem, omdat het MAPI/Exchange-protocol synchronisatie anders afhandelt dan IMAP.

Maar als uw gebruiker een IMAP-account heeft in klassiek Outlook, en een technicus het OST-bestand heeft verwijderd of het profiel opnieuw heeft aangemaakt: het risico is reeel.

Hoe dit te onderscheiden van een echte migratie

Een IT-beheerder die tickets krijgt met "mijn datums kloppen niet" na het opnieuw aanmaken van een profiel, denkt misschien ten onrechte aan een migratieprobleem. Hier leest u hoe u de twee gevallen onderscheidt.

Het geval van een IMAP-migratie

Bij een IMAP-migratie (BitTitan, CloudM, imapsync, enzovoort) kopieert het migratietool e-mails van de ene server naar de andere. Voor elk gekopieerd bericht maakt het een nieuw item aan op de doelserver via de IMAP APPEND-opdracht. Als het tool de originele INTERNALDATE niet expliciet opgeeft in die opdracht, registreert de doelserver het huidige tijdstip als INTERNALDATE. Sommige tools voegen bovendien een Received:-header toe met de migratiedatum, wat het probleem in bepaalde clients verergert. Het detail van dit mechanisme staat beschreven in het artikel over IMAP INTERNALDATE en kapotte datums.

Het geval van het opnieuw aanmaken van een profiel

Hier staan de e-mails nog altijd op dezelfde server, met dezelfde originele INTERNALDATE-waarden. Er is niets veranderd aan de serverkant. Alleen de lokale cache van Outlook is herbouwd met onjuiste datums. Het zichtbare symptoom is identiek (alle e-mails tonen dezelfde recente datum), maar de oorzaak verschilt.

Ter bevestiging: log in op de mailbox via webmail (Gmail, Outlook.com, of de webmailinterface van uw hosting). Als de datums in de webmail correct zijn, is het probleem puur lokaal in Outlook. Als de datums ook in de webmail onjuist zijn, is het probleem aan de serverkant (migratie of aanpassing van de INTERNALDATE-waarden op de server zelf).

Waarom de originele datums nog te herstellen zijn

Goed nieuws: in beide gevallen (migratie of opnieuw aangemaakt profiel) zijn de originele datums niet verloren.

De RFC 2822 Date:-header is een integraal onderdeel van het bericht. Hij is even onveranderlijk als de berichttekst of de bijlagen. Een e-mail verzonden in 2017 bevat in zijn ruwe tekst iets als:

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

Die regel staat in het bericht op de server. Hij is niet gewijzigd. Wat Outlook (onjuist) toont, is een metadata-veld buiten de inhoud van het bericht.

Dit maakt correctie mogelijk. De engine van Redate.io analyseert de headerketen van elk bericht om de echte originele datum te extraheren, waarna een gerichte correctie van de metadata wordt uitgevoerd zonder de berichtinhoud aan te passen. De INTERNALDATE die Outlook ziet, wordt herbouwd op basis van die authentieke informatie die altijd aanwezig is in het bericht.

De valkuil van de "nette" profielherstel

U heeft zojuist een synchronisatieprobleem opgelost voor een gebruiker. Zijn Outlook werkt weer, nieuwe e-mails komen binnen. U sluit het ticket.

Drie dagen later belt de gebruiker terug: hij zoekt een e-mail van een leverancier van vorig jaar, maar in Outlook staan al zijn e-mails uit 2023 als "gisteren" ontvangen. Hij vindt niets. Automatische archivering heeft misschien recente e-mails als oud geclassificeerd. En zijn manager vraagt een e-mailconversatie uit september 2022 op voor een geschil.

Dit scenario komt regelmatig voor. Niet omdat de technicus zijn werk slecht heeft gedaan, maar omdat dit Outlook-gedrag niet zichtbaar is gedocumenteerd in de standaard probleemoplossingsgidsen.

Schijnoplossingen die niets oplossen

E-mails sorteren op "Verzenddatum" in plaats van "Ontvangstdatum" in Outlook is het eerste wat gebruikers proberen. En het lijkt te werken... tot ze merken dat sorteren op verzenddatum alleen beschikbaar is voor bepaalde mappen, dat het verdwijnt als u van weergave wisselt, en dat andere applicaties (mobiel, webmail, automatische sorteerregels) de onjuiste INTERNALDATE blijven gebruiken.

Sorteren op verzenddatum is geen oplossing. Het is een pleister die het symptoom verhult zonder het echte probleem aan te pakken. Dat wordt uitgebreid uitgelegd in het artikel Sorteren op verzenddatum lost niets op.

Het profiel een tweede keer opnieuw aanmaken? Dat verandert niets als Outlook zijn cache opnieuw opbouwt met de huidige datum.

Exporteren en dan opnieuw importeren als PST? Voorzichtig. Een PST-export vanuit een Outlook met beschadigde datums exporteert ook die beschadigde metadata. Het PST-bestand bevat de verkeerde datums. Het opnieuw importeren van dat bestand corrigeert niets, en kan de situatie zelfs verergeren door duplicaten te maken met inconsistente datums. Dit onderwerp wordt apart behandeld in het artikel over PST-import in Outlook en datums die op vandaag springen.

Wat Redate.io doet in dit specifieke geval

Of het probleem nu komt van een IMAP-migratie of van het opnieuw aanmaken van een Outlook-profiel, het resultaat aan de serverkant is vergelijkbaar: e-mails waarvan de datummetadata niet overeenkomt met hun werkelijke inhoud.

Redate.io maakt rechtstreeks verbinding met de mailbox (Google Workspace, Microsoft 365 of directe IMAP), scant alle berichten om te identificeren welke onjuiste metadata hebben, en past vervolgens een multi-stage analysepipeline toe om elk e-mailbericht afzonderlijk te corrigeren. Elke correctie wordt geverifieerd. De originele berichten worden bewaard in een zichtbare back-upmap totdat u ze zelf verwijdert.

Het proces behandelt de randgevallen die zelfgemaakte scripts stelselmatig missen: S/MIME-ondertekende berichten, e-mails met niet-ASCII-coderingen in de headers (RFC 2047), complexe multipart-structuren, Date:-headers met niet-standaard of onjuist opgemaakte tijdzones. Een script dat correct werkt op 50 testberichten in een ontwikkelingsmailbox kan in productie 2000 berichten onherstelbaar beschadigen. Er is geen native rollback-mechanisme in IMAP zodra een bericht is vervangen zonder voorafgaande back-up.

Voor gevallen die specifiek met Outlook te maken hebben, beschrijft de pagina handmatige IMAP-kopieerdatums in Outlook herstellen de stappen om uw mailbox te koppelen en de analyse te starten.

Het probleem voorkomen bij volgende interventies

Als u technicus of IT-beheerder bent en regelmatig aan Outlook-profielen werkt, zijn er een paar gewoontes die deze situatie voorkomen.

Controleer vóór het verwijderen van een OST-bestand of het opnieuw aanmaken van een profiel de datums in de webmail. Als ze correct zijn, noteer dit dan in uw ticket. Na het opnieuw aanmaken, logt u opnieuw in via de webmail en vergelijkt u de weergegeven datums met die in Outlook. Als er een verschil is, is het probleem direct vastgesteld, voordat de gebruiker er drie dagen later over klaagt.

Voor geplande migraties bevat de checklist e-mailmigratie de verificaties die voor en na moeten worden uitgevoerd om dit soort problemen direct na afloop te detecteren.

U heeft een Outlook-profiel opnieuw aangemaakt en alle datums in uw mailbox zijn nu onjuist? Start een gratis scan op Redate.io om de getroffen e-mails te identificeren en de metadata te corrigeren zonder de inhoud van uw berichten aan te passen.