Verkeerde e-maildatums na migratie van Zoho naar Microsoft 365

Wat er is misgegaan in uw mailbox

De migratie van uw domein van Zoho Mail naar Microsoft 365 is afgerond. Exchange Online staat, de mailboxen zijn aangemaakt, de MX-records zijn bijgewerkt. En dan, maandagochtend, opent een gebruiker Outlook en ziet dat al zijn e-mails uit 2021 de datum van vandaag tonen. Een collega merkt dat berichten van vorig jaar bovenaan de inbox staan, alsof ze zojuist zijn binnengekomen. De tickets stromen binnen.

Het is geen Outlook-bug. Het is ook geen Zoho-specifiek probleem. Het is het verwachte, maar slecht gedocumenteerde gedrag van elke IMAP-migratie naar Exchange Online. Begrijpen waarom dit precies gebeurt is de eerste stap om het goed te herstellen.

De technische oorzaak: INTERNALDATE en Received-headers

Een e-mail op een IMAP-server bestaat uit twee afzonderlijke onderdelen: de ruwe berichtinhoud (de RFC 2822-headers, de body, de bijlagen) en de opslagmetadata die de IMAP-server beheert, waaronder de INTERNALDATE. Die laatste waarde gebruiken e-mailclients om berichten weer te geven en te sorteren.

De Date:-header in het ruwe bericht (RFC 2822) geeft aan wanneer het bericht door de afzender is opgesteld of verzonden. De INTERNALDATE is de datum waarop de IMAP-server het bericht heeft ontvangen of opgeslagen. Op een gezonde server liggen die twee waarden dicht bij elkaar. Na een migratie is dat een heel ander verhaal.

Hoe een IMAP-migratie datums beschadigt

Wanneer een migratietool (de Zoho Migration Wizard, imapsync, BitTitan of een andere) een bericht van Zoho Mail naar Exchange Online overzet, gebeurt dat via het IMAP-protocol. Het gereedschap verbindt met Zoho, haalt het bericht op en voegt het in Exchange Online in via een IMAP APPEND-opdracht. En precies daar gaat het mis.

Exchange Online genereert bij binnenkomst van elk bericht een nieuwe Received:-header, die bovenaan het bericht wordt geplaatst. Die header bevat de exacte datum en tijd van de invoeging, dus de migratiedatum. Sommige migratietools proberen de originele INTERNALDATE te bewaren door die als parameter mee te geven aan de APPEND-opdracht. Andere doen dat niet, of doen het onjuist. In dat geval kent Exchange Online automatisch de ontvangstdatum toe als INTERNALDATE.

Resultaat: of het nu gaat om een e-mail uit 2019 of uit 2022, de INTERNALDATE verwijst nu naar de migratieweek. Outlook leest die waarde als eerste. De volgorde in de inbox stort in elkaar.

Het specifieke gedrag van de Zoho Migration Wizard

Zoho biedt een eigen migratietool aan: de Zoho Migration Wizard. Handig voor eenvoudige migraties, maar op beheerdersfora staat gedocumenteerd dat dit gereedschap de originele INTERNALDATE niet altijd correct doorgeeft bij het invoegen in de doelserver.

Om precies te zijn: het probleem treft vooral migraties naar servers die bij elk inkomend bericht systematisch een Received:-header toevoegen, wat exact het gedrag van Exchange Online is. Zelfs als de Zoho Migration Wizard de originele datum via de APPEND-parameter doorgeeft, staat de door Exchange Online gegenereerde Received:-header als eerste in de headerketen, en Outlook gebruikt die om te bepalen "wanneer de e-mail is binnengekomen".

Beheerders die generieke IMAP-tools zoals imapsync gebruiken om Zoho te verlaten, lopen tegen exact hetzelfde probleem aan, soms in ergere mate. De standaardconfiguratie van imapsync is niet geoptimaliseerd voor Exchange Online. (Als u ooit een imapsync-log regel voor regel hebt doorgespit op zoek naar een synchronisatiefout om twee uur 's nachts, weet u: krachtig gereedschap, maar niet bepaald vergevingsgezind bij randgevallen.)

Waarom Outlook de verkeerde datum toont

Outlook gebruikt niet alleen de Date:-header om de datum van een e-mail te tonen. In de meeste weergaven wordt de INTERNALDATE van de IMAP/Exchange-server gebruikt, met name voor het sorteren van de inbox. De originele Date:-header zit wel intact in het bericht, maar wordt genegeerd ten gunste van de INTERNALDATE.

Daarom lost de optie "Sorteren op verzenddatum" in Outlook het probleem niet echt op. Er verschijnt inderdaad een andere datum, maar het sorteergedrag blijft instabiel afhankelijk van de Outlook-versie en de weergavemodus (gegroepeerde gesprekken of niet). Sorteren op verzenddatum is geen oplossing. Het is een pleister die er bij de eerste client-update al af valt.

De werkelijke omvang van het probleem

Bij een gemiddelde migratie van Zoho naar Microsoft 365 gaat het makkelijk om 50.000 tot 500.000 getroffen berichten, afhankelijk van de leeftijd van de mailboxen en de grootte van de organisatie. Elk tijdens de migratieperiode overgezet bericht heeft dezelfde beschadigde datum, waardoor het probleem direct zichtbaar is voor gebruikers zodra ze Outlook voor het eerst openen.

Verzonden items zijn vaak het meest problematisch. Een accountmanager die een offerte uit maart 2022 zoekt, doorzoekt honderden e-mails die allemaal de migratiedatum tonen. De operationele impact is reeel, niet alleen cosmetisch.

En anders dan men zou verwachten, verdwijnt het probleem niet vanzelf. De INTERNALDATE wordt vastgelegd op het moment van invoeging. Hij corrigeert zichzelf niet. Zonder actief ingrijpen behouden e-mails hun beschadigde datum voor onbepaalde tijd.

Waarom zelf corrigeren riskanter is dan het lijkt

De verleiding is begrijpelijk: de originele Date:-header zit nog in het bericht, dus u hoeft alleen maar de metadata te corrigeren. Op papier is dat logisch. In de praktijk, op een productie-mailbox van 80.000 e-mails, kan dit catastrofaal aflopen.

Een paar randgevallen die een zelfgemaakt script waarschijnlijk niet goed afhandelt:

• S/MIME-ondertekende e-mails, waarbij de handtekening de volledige headerstructuur omvat. Elke wijziging in de berichtstructuur maakt de cryptografische handtekening ongeldig.
• PGP-versleutelde berichten, waarbij de inhoud ondoorzichtig is en elke manipulatie van de MIME-enveloppen het bericht kan beschadigen.
• Niet-ASCII-headers gecodeerd volgens RFC 2047 (namen van afzenders met speciale tekens), die breken als het script de codering niet correct afhandelt.
• Bijlagen in base64 met onjuist afgebroken regels, niet-standaard MIME-grenzen of geneste multipart-structuren.
• E-mails zonder geldige Date:-header (dat bestaat, met name in oude Zoho-exports), waarbij het script moet beslissen wat te doen.

Een script dat werkt op 50 teste-mails, werkt niet op een Zoho-productiemailbox met jarenlange geschiedenis. En hoe controleert u, bericht voor bericht, dat elke correctie intact is en dat bijlagen niet zijn afgeknopt? De verificatie is minstens zo complex als de correctie zelf.

Er is ook de kwestie van quota. De Exchange Online API via Microsoft Graph hanteert strikte limieten (de beruchte 429 Too Many Requests-fouten). Een onthrottled batch van 100.000 berichten kan tijdelijke blokkades of stille fouten veroorzaken die achteraf moeilijk te diagnosticeren zijn. Zonder mechanisme om bij fouten verder te gaan, begint u opnieuw van voren af aan.

Hoe Redate.io datums herstelt na een Zoho-migratie

Redate.io verbindt met uw Microsoft 365-tenant via standaard Azure AD-machtigingen, zonder globale beheerderstoegang. De initiële scan is gratis: Redate.io identificeert de getroffen mailboxen en schat het volume e-mails met onjuiste datums, door de INTERNALDATE te vergelijken met de waarden in de headerketen van elk bericht.

De correctie maakt gebruik van een eigen correctie-engine die de volledige headerketen van elk bericht analyseert, de specifieke signaturen van Zoho-migratietools herkent (zowel de Zoho Migration Wizard als imapsync geconfigureerd voor vertrek uit Zoho) en de datummetadata reconstrueert via een validatiepipeline met meerdere stappen. Elk gecorrigeerd bericht wordt afzonderlijk gecontroleerd: integriteit van de inhoud, behoud van bijlagen, RFC-conformiteit. De originelen worden bewaard in een back-upmap die 30 dagen toegankelijk blijft.

Geen hermigratie. Geen downtime. Gebruikers werken gewoon door in Outlook terwijl de correctie op de achtergrond wordt uitgevoerd.

De prijs is een eenmalige betaling op basis van volume, zonder abonnement. De details staan rechtstreeks op de website.

Verwante situaties om te kennen

Als u meerdere migraties tegelijk beheert, of als u MSP bent en klanten begeleidt die Zoho verlaten, weet dan dat hetzelfde probleem optreedt bij migraties vanuit andere platforms naar Exchange Online. De techniek is identiek: de door Exchange gegenereerde Received:-header overschrijft de INTERNALDATE, ongeacht de bron.

Voor migraties vanuit Google Workspace, vanuit on-premises Exchange of via tools zoals BitTitan MigrationWiz of CloudM, beschrijven de artikelen op de blog van Redate.io het specifieke gedrag per tool. Het artikel Verkeerde e-maildatums na migratie naar Exchange Online geeft een overzicht van alle scenario's die op dit tenant uitkomen.

Als uw migratie gedeelde mailboxen of Exchange-resources omvat (vergaderruimten, apparatuur), is het probleem identiek en gelden dezelfde correctietools. De handleidingen voor Exchange IMAP-migratiedatums op de Redate.io-website beschrijven de stappen om verbinding te maken met uw tenant.

Voor teams die imapsync specifiek gebruiken om Zoho te verlaten, documenteert het artikel imapsync: datums niet behouden de configuratieopties van imapsync en waarom die niet volstaan om het probleem op Exchange Online te vermijden.

Worden uw Zoho-migratiedatums nog steeds verkeerd weergegeven in Outlook? Scan uw mailboxen gratis op Redate.io om de exacte omvang van het probleem in kaart te brengen voordat u beslist hoe u actie onderneemt.