Outlook: ontvangstdatum IMAP-migratie vs verzenddatum

Het symptoom dat iedereen kent

U heeft net een IMAP-migratie naar Microsoft 365 of Google Workspace afgerond. Maandagochtend stromen de tickets binnen: "Al mijn e-mails hebben dezelfde datum", "Mijn geschiedenis is kapot", "Ik vind niets meer terug in mijn mailbox". U opent Outlook, en inderdaad: duizenden e-mails tonen de datum van het afgelopen weekend. Niet de datum waarop ze zijn verzonden. De datum waarop de migratie heeft plaatsgevonden.

Dit is geen Outlook-bug. Het is een direct gevolg van hoe het IMAP-protocol en migratiegereedschappen werken. Maar om te begrijpen waarom, moet u even onder de motorkap kijken.

Drie datums in één e-mail

Een e-mail is complexer dan het lijkt. Headers, berichttekst, bijlagen... en meerdere afzonderlijke tijdstempels die naast elkaar bestaan. (Als u ooit de ruwe headers van een e-mail heeft geprobeerd te lezen, weet u dat het bepaald geen strandlectuur is.)

De Date:-header (RFC 2822)

Dit is de datum die de afzender in het bericht heeft gezet op het moment van verzending. Vastgelegd door RFC 2822, ziet het er zo uit:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Deze header is in de kern van het bericht gebakken. Hij verandert nooit, tenzij iemand de ruwe inhoud van het bericht wijzigt. Dit is de "verzenddatum" in de strikte zin.

De Received:-header (toegevoegd bij elke netwerksprong)

Elke server die een e-mail in doorvoer aanraakt, voegt een Received:-header bovenaan het bericht toe, met zijn eigen datum. Een e-mail die langs drie servers gaat, verzamelt dus drie Received:-headers. De meest recente staat altijd bovenaan. Het ziet er ongeveer zo uit:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Het gevolg: wanneer een migratietool zoals BitTitan MigrationWiz, CloudM, imapsync of GSMMO een e-mail van een bronserver naar een doelserver verplaatst, gedraagt hij zich ook als een "netwerksprong". Hij injecteert een nieuwe Received:-header bovenaan de stapel, met de datum en tijd van de migratie.

De IMAP INTERNALDATE

Dit is de derde datum, en die zorgt voor het probleem. De INTERNALDATE is een metadata die opgeslagen is aan de kant van de IMAP-server, los van de inhoud van het bericht. Het vertegenwoordigt de datum waarop de e-mail is afgeleverd (of ingevoerd) in de mailbox. Wanneer een migratietool een e-mail invoegt via de IMAP APPEND-opdracht, bepaalt hij zelf welke waarde hij aan de INTERNALDATE geeft. En in veel gevallen gebruiken tools de datum van het moment van migratie. Niet de originele datum.

Daar loopt het mis.

Waarom Outlook de migratiedatum toont

Outlook gebruikt de INTERNALDATE om de kolom "Ontvangen" weer te geven. Dat is het standaardgedrag, en het is consistent met de IMAP-specificatie: de INTERNALDATE is bedoeld om de ontvangstdatum in de mailbox te vertegenwoordigen. In een normaal e-mailverkeer (een echte e-mail die binnenkomt) ligt de INTERNALDATE dicht bij de datum in de Date:-header. Beide zijn dan consistent.

Na een mislukte migratie wijst de INTERNALDATE van alle geïmporteerde e-mails naar de nacht van 14 op 15 juni 2024 (of wanneer de migratie ook heeft plaatsgevonden). Outlook leest deze waarde, toont hem in de kolom "Ontvangen", en het resultaat is rampzalig: 45.000 e-mails lijken op dezelfde avond te zijn ontvangen.

Om precies te zijn: de eerste Received:-header (de meest recente in de stapel) beïnvloedt ook de weergave in bepaalde configuraties. Maar de INTERNALDATE blijft de belangrijkste factor voor de kolom "Ontvangen" in Outlook in gesynchroniseerde IMAP-modus.

De oplossing "Kolom Verzonden toevoegen" in Outlook

Het eerste wat de meeste IT-admins doen als ze het probleem ontdekken, is zoeken naar een client-side oplossing. En die bestaat, inderdaad.

In Outlook kunt u de kolomweergave van een map aanpassen om de kolom "Ontvangen" te vervangen (of aan te vullen) met de kolom "Datum" of "Verzonden". De kolom "Datum" leest rechtstreeks de Date:-header van het bericht, niet de INTERNALDATE. Omdat de Date:-header niet is aangeraakt door de migratie, verschijnen de originele datums weer.

Hoe u dit doet in Outlook (desktop, Microsoft 365-versie): klik met de rechtermuisknop op de kolomkop in de berichtenlijst, kies "Weergave-instellingen", en pas de kolommen aan om "Ontvangen" te verwijderen en "Datum" toe te voegen. Dit is uitvoerbaar via GPO voor massale uitrol.

Goed. Op papier lost dit het visuele probleem op. In de praktijk is het een pleister op een slagaderlijke bloeding.

De concrete beperkingen van deze aanpak

Mobiele en webclients

Outlook op iOS, Android en Outlook Web App (OWA) hebben niet dezelfde aanpassingsopties. De weergavewijziging die u op de Windows-machines heeft uitgerold, wordt niet doorgevoerd. Gebruikers die hun e-mail op hun telefoon lezen, blijven de migratiedatum zien. En in een middelgroot bedrijf is dat waarschijnlijk de helft van uw gebruikers.

De zoekfunctie

Outlook Zoeken gebruikt de Windows Search-index (of de Exchange/Microsoft 365-index aan de serverzijde). Die index wordt opgebouwd op basis van de INTERNALDATE, niet de Date:-header. Als een gebruiker zoekt naar "e-mails van januari 2022", geeft de zoekfunctie de e-mails terug waarvan de INTERNALDATE in januari 2022 valt. Niet die waarvan de Date:-header in januari 2022 staat. Het resultaat: oude e-mails verschijnen niet meer bij datumfilters. De kolomweergave aanpassen verandert daar niets aan.

E-mailregels

Outlook-regels ("als de e-mail is ontvangen vóór...", "als de e-mail is ontvangen na...") gebruiken ook de INTERNALDATE. Een sorteer- of archiveringsregel op basis van datumbereiken werkt na migratie niet meer correct als de INTERNALDATE niet is gecorrigeerd.

Compliance en eDiscovery

Dit is misschien het meest serieuze punt. Compliance-tools, juridische archivering en eDiscovery-tools (Microsoft Purview, bijvoorbeeld) gebruiken de INTERNALDATE als datumreferentie voor juridische zoekopdrachten. Als uw organisatie onderhevig is aan AVG-bewaarverplichtingen of moet voldoen aan een discovery-verzoek, kunnen beschadigde INTERNALDATE-waarden echte juridische problemen opleveren. Een audit die vraagt om "alle e-mails tussen die en die datum" geeft dan niet de juiste resultaten terug.

Externe tools

CRM-systemen, ticketingtools, archiveringsoplossingen... alles wat via IMAP of de Microsoft 365/Google Workspace-API's verbinding maakt met uw mailserver, leest de INTERNALDATE. De Outlook-weergave aanpassen corrigeert voor die systemen niets.

De enige echte oplossing: corrigeren op serverniveau

Sorteren op verzenddatum in Outlook is geen oplossing. Het is een noodverband. De echte correctie moet plaatsvinden op het niveau van de servermetadata, niet de clientweergave.

Concreet betekent dit de INTERNALDATE van elke e-mail corrigeren zodat die overeenkomt met de originele datum uit de Date:-header. Die originele Date:-header staat altijd nog in het bericht (hij is niet gewist door de migratie), wat de correctie mogelijk maakt. Daar zit de echte datuminformatie.

Op Google Workspace biedt de Gmail API een parameter internalDate waarmee u rechtstreeks op deze metadata kunt ingrijpen. Op Microsoft 365 is het mechanisme anders, maar het verwachte resultaat is hetzelfde. Op een standaard IMAP-server voorziet de norm dat de datum bij het invoegen van een bericht kan worden opgegeven.

In de praktijk is deze operatie uitvoeren op tienduizenden e-mails in productie, zonder dataverlies, zonder duplicaten, zonder gebroken discussiethreads of labels, met afhandeling van randgevallen (S/MIME-ondertekende berichten, complexe MIME-structuren, niet-ASCII-coderingen conform RFC 2047, grote bijlagen)... een heel ander verhaal. Een script dat werkt op 50 testberichten houdt het niet vol in een mailbox met 40.000 berichten. De afhandeling van 429-fouten (API-quota overschreden), netwerktimeouts om 2 uur 's nachts, berichten waarvan de MIME-structuur na migratie al gedeeltelijk beschadigd is... dat alles vereist serieuze technische inzet.

Precies dat doet Redate.io. De proprietary correctie-engine analyseert de headerketen van elke e-mail, identificeert de betrouwbare originele datum en past een gerichte metadatacorrectie toe zonder de berichtinhoud aan te raken. Elk gecorrigeerd bericht wordt individueel geverifieerd. De originelen worden 30 dagen bewaard in een back-upmap, zodat een rollback op elk moment mogelijk is. Iets wat een zelfgemaakt script nooit biedt.

Het gebruikte migratietool identificeren

Het probleem manifesteert zich op dezelfde manier ongeacht de oorsprong van de migratie, maar de details verschillen per gebruikt tool. BitTitan MigrationWiz, CloudM, imapsync en GSMMO hebben elk hun eigen handtekening in de Received:-headers die ze injecteren. De analysepipeline van Redate.io onderhoudt een database met honderden handtekeningen van bekende migratietools om de migratieheader te onderscheiden van de rest van de legitieme transitketen.

Als u niet weet welk tool voor uw migratie is gebruikt (dat komt voor, zeker als u een omgeving overneemt van een andere MSP), identificeert de gratis scan van Redate.io de getroffen mailboxen en geeft een schatting van het te corrigeren volume, zonder enige verplichting.

Voor specifieke situaties zijn gedetailleerde handleidingen beschikbaar: imapsync-datums herstellen in Outlook, BitTitan-datums herstellen in Outlook, of CloudM-datums herstellen in Outlook.

Wat u nu kunt doen

Als u dit artikel leest na een migratie: het goede nieuws is dat de originele Date:-header intact is in elk van uw e-mails. De echte datuminformatie is er, aanwezig in elk bericht. Het probleem zit in de metadata, niet in de inhoud. En metadata valt te corrigeren.

U kunt ook het artikel IMAP INTERNALDATE: waarom datums kapotgaan raadplegen voor meer achtergrond over de technische oorzaak, of de volledige handleiding over verkeerde datums in Outlook na migratie voor een overzicht van alle scenario's.

Klaar om de datums van uw mailboxen te herstellen? Start een gratis scan op Redate.io om de getroffen e-mails te identificeren en het volume in te schatten voordat er iets wordt gecorrigeerd.