Nieuw Outlook: verkeerde datums na migratie, echte oorzaken

Twee Outlook-versies, twee reacties op dezelfde e-mails

Als u onlangs mailboxen naar Microsoft 365 hebt gemigreerd en sommige gebruikers klagen dat alle oude e-mails dezelfde datum tonen (die van de migratie), heeft u misschien iets merkwaardigs opgemerkt: gebruikers op klassiek Outlook zien soms de juiste datum in het leesvenster, terwijl gebruikers op het nieuwe Outlook voor Windows consequent de migratiedatum zien. Dezelfde mailbox. Dezelfde e-mails. Ander resultaat.

Dit is geen bug in de strikte zin. Het is een architectuurkeuze die directe gevolgen heeft voor de manier waarop datums na een IMAP-migratie worden weergegeven. Om te begrijpen wat er speelt, moet u de details van e-mailheaders en het IMAP-protocol kennen. Dat is niet bepaald lichte kost, maar het verklaart waarom geen enkele aanpassing aan de clientzijde volstaat om het probleem op te lossen.

De IMAP INTERNALDATE: de echte schuldige

Wanneer een e-mail op een IMAP-server wordt opgeslagen, zijn er twee soorten datums die naast elkaar bestaan en niet door elkaar mogen worden gehaald.

De eerste is de Date:-header, gedefinieerd door RFC 2822. Dit is de datum die in het bericht zelf is opgeschreven, de datum die de afzender heeft ingesteld op het moment van verzenden. Ze maakt deel uit van de berichtinhoud en verandert nooit, ongeacht welke weg het e-mailbericht daarna aflegt.

De tweede is de INTERNALDATE, een metadataveld dat door de IMAP-server wordt beheerd en buiten het bericht zelf staat. Het is de datum waarop de server het bericht heeft opgeslagen. Bij een correct uitgevoerde migratie bewaren serieuze tools de originele INTERNALDATE. Maar bij een slecht geconfigureerde migratie, of met tools die dit metadataveld niet correct verwerken, wordt de INTERNALDATE teruggezet naar de datum van de migratie. Het gevolg: alle gemigreerde e-mails krijgen vanuit het oogpunt van de server dezelfde ontvangstdatum.

(Als u ooit de logs van imapsync of MigrationWiz hebt doorgelezen, weet u dat er specifieke opties bestaan om de INTERNALDATE te proberen bewaren. Die opties werken niet altijd, en sommige doelservers weigeren ze te respecteren.)

Klassiek Outlook: hoe het datums uitleest

Klassiek Outlook, dat wil zeggen de lokaal geïnstalleerde COM-versies (Outlook 2016, 2019, 2021 en de Microsoft 365 Apps desktopclient), gebruikt een iets complexer mechanisme om te bepalen welke datum in de berichtenlijst wordt getoond.

Voor e-mails in de map Verzonden steunt het op de Date:-header. Voor ontvangen e-mails gebruikt het primair de INTERNALDATE van de server, maar in bepaalde omstandigheden (met name wanneer de OST-cache betrokken is of bij de eerste weergave in het leesvenster) kan het ook de keten van Received:-headers lezen om een benaderde originele datum te reconstrueren.

Dat verklaart het inconsistente gedrag: klassiek Outlook kan soms de juiste datum tonen in het leesvenster, omdat het voor het gedetailleerde voorbeeld de originele Date:-header van het bericht leest, ook al gebruikt de berichtenlijst zelf de beschadigde INTERNALDATE. Maar let op, dit is onbetrouwbaar en lost niets op. Sorteren op datum blijft kapot. Zoekopdrachten op datum geven nog steeds verkeerde resultaten.

Het nieuwe Outlook: een fundamenteel andere architectuur

Het nieuwe Outlook voor Windows, dat geleidelijk is uitgerold vanaf eind 2023, is geen COM-applicatie meer. Het is in wezen een Progressive Web App (PWA) die op dezelfde codebasis draait als Outlook op het web (OWA). Die volledige heropbouw heeft ingrijpende gevolgen.

Het nieuwe Outlook delegeert de weergave van datums volledig aan de Microsoft 365 API. Het leest geen Received:-headers, graaft niet in de headerketen op zoek naar een originele datum, en doet geen enkele poging tot reconstructie aan de clientzijde. Het toont simpelweg wat de server teruggeeft: de INTERNALDATE.

Resultaat: als de INTERNALDATE beschadigd is geraakt tijdens de migratie, aarzelt het nieuwe Outlook geen moment. Het toont voor elk getroffen bericht de migratiedatum, zonder uitzondering. Dit gedrag is consistenter en voorspelbaarder dan dat van klassiek Outlook, maar het maakt het migratieprobleem onmiddellijk zichtbaar en onmogelijk te negeren.

Een beheerder die op vrijdagavond 300 mailboxen migreert, ontdekt maandagochtend dat alle gebruikers op het nieuwe Outlook hun volledige archief gedateerd zien op afgelopen weekend. De tickets stapelen zich snel op.

Waarom tijdelijke oplossingen aan de clientzijde niet werken

Veel beheerders proberen oplossingen aan de clientzijde voordat ze begrijpen dat het probleem in de serverdata zit. Dit zijn de klassieke pogingen, en waarom ze mislukken.

Sorteren op "Verzenddatum" in plaats van "Ontvangstdatum"

Sorteren op verzenddatum in Outlook steunt op de Date:-header van het bericht, die intact is. Dus ja, dit kan werken. Maar het is een pleister, geen oplossing. Zoekopdrachten op datum blijven kapot. Regels op basis van datum blijven onbruikbaar. En bovenal: de gebruiker moet handmatig elke map en elke mailbox opnieuw configureren. Bij 300 mailboxen is dat niet realistisch. Sorteren op verzenddatum lost niets op, en eindgebruikers begrijpen niet waarom ze hun gewoonten moeten aanpassen.

De Outlook-cache leegmaken of het profiel opnieuw aanmaken

Dit heeft geen effect op de INTERNALDATE aan de serverzijde. Na het opnieuw aanmaken van het profiel synchroniseert Outlook de e-mails opnieuw vanaf de server en haalt exact dezelfde beschadigde metagegevens op. De cache is niet het probleem.

OWA gebruiken in plaats van de desktopclient

OWA en het nieuwe Outlook delen dezelfde database. Als de INTERNALDATE beschadigd is op de Exchange Online-server, toont OWA exact dezelfde verkeerde datum. Van client wisselen verandert de data niet.

Het probleem zit op de server, in de metagegevens van elk afzonderlijk bericht. Geen enkele actie aan de clientzijde kan data corrigeren die aan de serverzijde zijn opgeslagen.

De val van Received-headers: waarom ze alles ingewikkelder maken

Wanneer een migratietool een e-mail via IMAP van de ene server naar de andere kopieert, voegt de doelserver automatisch een Received:-header toe bovenaan de keten, met de datum en het tijdstip van het invoegen. Dit is het normale gedrag van RFC-conforme SMTP- en IMAP-servers.

Deze headers stapelen zich op in omgekeerde volgorde van het afgelegde pad. De recentste staat bovenaan. Sommige e-mailclients lezen de eerste Received:-header om de ontvangstdatum te schatten, wat de migratiedatum oplevert in plaats van de originele datum.

Ter verduidelijking: dit gedrag is niet specifiek voor één tool. BitTitan MigrationWiz, CloudM, imapsync, GSMMO en zelfs een handmatige IMAP-kopie tussen twee Thunderbird-clients produceren allemaal hetzelfde resultaat. De originele Date:-header blijft intact in het bericht. Dat is precies wat een correctie technisch mogelijk maakt. Maar de INTERNALDATE is een afzonderlijk metadataveld dat door de server wordt beheerd en kan niet worden gecorrigeerd door simpelweg de berichtheaders aan de clientzijde aan te passen.

Voor meer achtergrond over dit mechanisme legt het artikel over IMAP INTERNALDATE en kapotte datums uit hoe dit metadataveld per server wordt beheerd.

Welke migratietools dit probleem veroorzaken op Microsoft 365

De vraag komt regelmatig terug: veroorzaken alle migratietools dit probleem?

Het korte antwoord is dat het afhangt van de configuratie en het doelplatform. Op Exchange Online / Microsoft 365 is de server bijzonder streng in het beheer van de INTERNALDATE. Zelfs tools die proberen deze te bewaren, mislukken soms, omdat de Graph API en EWS (Exchange Web Services) zich anders gedragen afhankelijk van het gebruikte invoegpad.

BitTitan MigrationWiz is een van de meest gebruikte tools voor migraties naar Microsoft 365, en ook een van de tools waarvan de datumproblemen het best zijn gedocumenteerd. De specifieke pagina BitTitan-migratiedatums in Microsoft 365 herstellen behandelt de configuraties waar u op moet letten. CloudM en imapsync hebben hun eigen eigenaardigheden, respectievelijk gedocumenteerd op CloudM-migratiedatums in Microsoft 365 herstellen en imapsync-migratiedatums in Microsoft 365 herstellen.

Wat al deze tools gemeen hebben: de originele Date:-header overleeft de migratie. Dat is de basis waarop een correctie mogelijk is.

Waarom een zelfgemaakt script hier een slecht idee is

Het probleem begrijpen geeft soms de illusie dat de oplossing eenvoudig is. Dat is ze niet, niet op productieschaal.

Het aanpassen van metagegevens van e-mails die zijn opgeslagen in Exchange Online is verre van eenvoudig. De Graph API van Microsoft legt strikte snelheidslimieten op (de 429 Too Many Requests-fout tijdens een nachtelijke batch, dat gebeurt sneller dan u denkt). Het verwerken van S/MIME-ondertekende of PGP-versleutelde e-mails vereist bijzondere zorg om digitale handtekeningen niet ongeldig te maken. Multipart-structuren met grote bijlagen voegen beperkingen toe wat betreft netwerktimeouts. En bovenal: hoe verifieert u, bericht voor bericht, dat de correctie goed is verlopen zonder de inhoud of de bijlagen aan te tasten?

Een script dat prima werkt op 50 testmails gedraagt zich heel anders op een mailbox van 40.000 berichten met 8 jaar geschiedenis. De kans dat een randgeval iets kapotmaakt neemt toe met elk extra duizendtal berichten. En zonder terugdraaimechanisme laat een fout halverwege de mailbox in een inconsistente staat achter.

Zie ook: e-maildatums herstellen na Microsoft 365-migratie voor een volledig overzicht van de beschikbare opties.

Wat Redate.io concreet doet

Redate.io opent uw Microsoft 365-mailbox nadat u zich met uw eigen Microsoft-account hebt aangemeld (geen portaal, geen applicatie om te registreren), scant e-mails met onjuiste datums gratis, en past vervolgens een eigen correctie-engine toe op de geïdentificeerde berichten. De meerfasige analysepipeline voert patroonherkenning uit op honderden bekende migratietoolsignaturen, RFC-conformiteitsvalidatie en headerketenanalyse om de juiste datummetagegevens te reconstrueren.

Elk gecorrigeerd bericht wordt individueel geverifieerd. De originele berichten worden door Redate.io nooit verwijderd; ze blijven in een zichtbare back-upmap in uw eigen mailbox totdat u ze zelf verwijdert. Het prijsmodel is een eenmalige betaling per mailbox, zonder abonnement.

Het nieuwe Outlook toont daarna de juiste datums, omdat de serverdata zijn gecorrigeerd, niet gemaskeerd.

Hebt u getroffen mailboxen op het nieuwe Outlook? Start een gratis scan op Redate.io om exact te zien hoeveel e-mails zijn getroffen, voordat u beslist hoe u verdergaat.