Verkeerde e-maildatums na migratie naar Exchange Online

Het klassieke maandagochtendscenario

U heeft de IMAP-migratie naar Exchange Online net afgerond. De batch is zonder fouten uitgevoerd in het Exchange-beheercentrum, de postvakken zijn gesynchroniseerd, gebruikers kunnen inloggen. Vrijdagavond sluit u uw laptop met het gevoel dat het werk klaar is.

Maandagochtend stromen de tickets binnen. "Alle e-mails zijn gedateerd op vrijdag." "Mijn postvak in is onbruikbaar." "Er ontbreken oude e-mails." Er ontbreekt eigenlijk niets: de berichten zijn er gewoon, maar Outlook toont ze allemaal met de migratiedatum in plaats van de originele verzenddatum. Een e-mail uit 2019 lijkt van afgelopen vrijdag. Het gevolg: het hele postvak lijkt alleen recente berichten te bevatten.

Dit is een van de meest frustrerende problemen bij IMAP-migraties naar Exchange Online, en Microsoft documenteert het vrijwel nooit goed.

Waarom de EAC-migratie datums kapotmaakt

Wanneer u het Exchange-beheercentrum (EAC) gebruikt om een IMAP-migratie te configureren vanuit een lokale server (Dovecot, Courier, Cyrus, UW-IMAP, maakt niet uit), maakt Exchange Online verbinding met uw bronserver via IMAP, haalt de berichten op en injecteert ze via zijn eigen interne transportpipeline in de doelpostvakken.

Daar ontstaat het probleem.

Elk e-mailbericht dat door de transportpipeline van Exchange gaat, krijgt automatisch een tijdgestempelde Received:-header. Dat is al decennialang standaardgedrag van SMTP- en IMAP-servers: elke server die een bericht aanraakt, voegt zijn eigen tijdstempel toe. Het probleem is dat Outlook (in het bijzonder Outlook voor Windows in recente versies) de meest recente Received:-header als weergavebron gebruikt wanneer andere metadata dubbelzinnig zijn.

De originele Date:-header (die aangeeft wanneer het bericht werkelijk is verzonden, conform RFC 2822) is nog steeds aanwezig in het bericht. Hij is niet verwijderd. Maar hij wordt als het ware overschaduwd door de nieuwe Received:-header die Exchange tijdens de injectie toevoegt.

Tegelijkertijd wordt de IMAP INTERNALDATE (de metadata die IMAP-servers intern gebruiken om berichten te dateren en die het sorteren in de meeste clients aanstuurt) ingesteld op de injectiedatum, niet op de originele datum van het bericht. Exchange Online heeft geen native manier om de INTERNALDATE van de bronserver te bewaren tijdens een batch-migratie via het EAC.

EAC versus externe tools: een belangrijk verschil

Het is goed om twee situaties te onderscheiden. Bij tools als BitTitan MigrationWiz of CloudM Migrate bestaat het probleem ook, maar die tools hebben soms configuratie-opties (gedeeltelijk gedocumenteerd, vaak verstopt in geavanceerde instellingen) die proberen bepaalde datummetadata te bewaren.

De native migratie via het EAC biedt geen enkele optie van dat soort. Microsoft stelt geen parameter beschikbaar om de bewaring van de INTERNALDATE te sturen in de batch-migrationpipeline. Het is een black box: u configureert de batch, u start hem op, en Exchange doet intern wat het wil. En dat is, consequent, de berichten dateren op het moment van injectie.

(Als u ooit de ruwe headers van een via het EAC gemigreerde e-mail heeft bekeken, weet u dat de Received:-header die Exchange toevoegt meteen herkenbaar is: hij bevat verwijzingen naar interne Microsoft-servers zoals *.protection.outlook.com of *.prod.exchangelabs.com, met een tijdstempel dat precies overeenkomt met het migratietijdvenster.)

Waarom de batch opnieuw aanmaken niets oplost

De instinctieve reactie van veel IT-beheerders is: "Als ik de gemigreerde postvakken verwijder en de batch opnieuw start, zijn de datums misschien dit keer wel correct."

Begrijpelijk. Maar het werkt niet.

Het probleem zit niet in de batchconfiguratie. Niet in een vergeten instelling. Het zit in de architectuur van de Exchange-transportpipeline zelf, die bij elke migratie identiek is. Een nieuwe batch geeft precies hetzelfde resultaat: dezelfde Received:-headers met de nieuwe migratiedatum, en dezelfde verkeerde INTERNALDATE-waarden. U bent tijd kwijt en gebruikers zijn voor niets een tweede keer gestoord.

Sommige beheerders proberen ook de sorteerinstellingen in Outlook aan te passen ("sorteren op verzenddatum" in plaats van "ontvangstdatum"). Dat is geen oplossing. Het is een pleister. De Date:-header en de INTERNALDATE blijven verkeerd voor clients die die instelling niet bieden, voor OWA, voor Outlook Mobile, en voor alle externe applicaties die het postvak via IMAP of EWS benaderen.

Wat er werkelijk in de headers gebeurt

Hier is een vereenvoudigd voorbeeld van wat een e-mail bevat na migratie via het EAC. De originele header:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@ouddomein.nl
Subject: Rapport Q1 2019

Na de migratie krijgt het bericht bovenaan de headerketen zoiets als dit:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook ziet deze Received:-header als eerste (hij staat bovenaan het headerblok), interpreteert hem als de meest recente verwerkingsdatum van het bericht, en toont hem als ontvangstdatum. De originele Date:-header uit 2019 is er nog, intact, een paar regels lager. Maar Outlook gebruikt hem niet voor de weergave in de berichtenlijst.

Om precies te zijn: het gedrag verschilt licht per Outlook-versie. Versies van na 2021 (en zeker het nieuwe Outlook voor Windows dat eind 2023 breed is uitgerold) zijn bijzonder gevoelig voor dit probleem, omdat ze meer leunen op Exchange Graph-metadata dan op de ruwe Date:-header. Dat betekent dat migraties die met Outlook 2016 geen zichtbaar probleem gaven, nu wel problemen veroorzaken met het nieuwe Outlook.

Wie er echt last van heeft

De meest voorkomende IMAP-bronservers bij dit type migratie zijn Dovecot (wijdverspreid in Linux/cPanel-omgevingen) en Courier. Beide bieden INTERNALDATE via IMAP aan, maar het EAC bewaart die niet. Bij een migratie van on-premises Exchange naar Exchange Online (hybride of cutover-migratie) gedraagt dit zich anders, omdat Microsoft daar een intern transportprotocol (MAPI/EWS) gebruikt dat metadata beter bewaart. De generieke IMAP-migratie via het EAC is het probleem.

De hardst getroffen gebruikers zijn degenen met postvakken die een lange geschiedenis hebben (5 jaar en meer) en een groot berichtenvolume. Een gebruiker met 300 e-mails is er snel overheen. Een commercieel directeur met 12.000 berichten gesorteerd op datum, waarop hij dagelijks terugvalt om klantgesprekken terug te vinden, zit volledig vast.

Waarom een zelfgemaakt script hier geen goed idee is

IT-beheerders die het technische probleem begrijpen, worden soms verleid om een PowerShell- of Python-script te schrijven om de headers handmatig te corrigeren. Het basisidee lijkt eenvoudig zodra u het mechanisme heeft geïdentificeerd. Maar een correctie in productie is een heel andere zaak.

Eerst de randgevallen. S/MIME-gesigneerde e-mails en PGP-versleutelde berichten hebben een structuur die headerwijzigingen niet verdraagt zonder de handtekening ongeldig te maken. Berichten met multipart/alternative-structuren en slecht gevormde MIME-grenzen (frequent op oude Courier-servers) kunnen worden beschadigd door een script dat het bericht aanpast zonder de structuur correct te reconstrueren. Niet-ASCII-headers gecodeerd volgens RFC 2047 (namen van afzenders met geaccentueerde tekens of Japanse karakters, bijvoorbeeld) zijn een klassieke bron van fouten.

Dan het volume. Een script dat werkt op 50 testberichten in een ontwikkelomgeving gaat niet om met de snelheidsbeperkingen van de Exchange Online-API in productie. De fout 429 Too Many Requests om 2 uur 's nachts tijdens een batch van 8.000 berichten, zonder herstelmechanisme, leidt tot een slapelloze nacht en mogelijk dubbele of verloren berichten.

En vooral: hoe controleert u dat elk gecorrigeerd bericht intact is? Dat geen bijlage is afgekapt, dat geen gespreksdraad is gebroken, dat labels en mappen bewaard zijn? Zonder een individueel validatiemechanisme hoopt u maar dat alles goed is gegaan.

Het corrigeren van datums na migratie lijkt een script van 50 regels, maar vraagt er duizenden om betrouwbaar te zijn in productie.

Wat Redate.io anders doet

Redate.io maakt verbinding met Exchange Online via de Microsoft 365-API's (Azure Active Directory, delegatiemachtigingen op tenantniveau) en scant de betreffende postvakken om e-mails te identificeren waarvan de datummetadata door de migratie zijn beschadigd. Deze scanstap is gratis en geeft een exact beeld van de omvang van het probleem: aantal getroffen berichten, betrokken postvakken, reeks beschadigde datums.

De eigen correctie-engine van Redate.io verwerkt vervolgens elk bericht afzonderlijk via een meerstappenanalyse-pipeline. Die omvat patroonherkenning op handtekeningen van bekende migratietools (inclusief de Exchange Online-transportpipeline), RFC-conformiteitsvalidatie en een controle van de structurele integriteit van elk bericht voor en na correctie. S/MIME-gesigneerde e-mails, complexe MIME-structuren, niet-standaard coderingen: alle worden verwerkt via specifieke verwerkingspaden.

Elk gecorrigeerd bericht wordt afzonderlijk geverifieerd. De originelen worden 30 dagen bewaard in een zichtbare back-upmap. Als er iets niet klopt met een bepaald bericht, wordt het niet gewijzigd: Redate.io meldt de afwijking in plaats van een beschadiging te riskeren.

De prijsstelling is gebaseerd op volume, als eenmalige betaling per postvak. Geen abonnement, geen terugkerende kosten. U lost het probleem eenmalig op, en het is klaar.

Voor Exchange Online-migraties specifiek ondersteunt Redate.io de verbinding via Azure AD-applicatiemachtigingen (zonder dat u voor elk postvak afzonderlijke inloggegevens hoeft aan te maken), wat de verwerking van grote postvloten aanzienlijk eenvoudiger maakt voor een IT-beheerder of MSP.

Als u meerdere klanten beheert die dit type migratie hebben ondergaan, bekijk dan ook de volledige gids over het corrigeren van datums na een Microsoft 365-migratie voor een overzicht van de verschillende gedekte scenario's.

De e-mails zijn er, de originele datums ook. Start een gratis scan op Redate.io om precies te zien hoeveel berichten zijn getroffen in uw Exchange Online-postvakken, voor u beslist wat u doet.