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 gebeurt wanneer de migratietool de originele datum van elke e-mail niet doorgeeft. 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 kan beschadigen

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 behoudt de datum die het krijgt: als de tool de originele INTERNALDATE van elk bericht meegeeft met de APPEND-opdracht, behoudt de kopie die datum. Sommige migratietools doen dat. Andere doen dat niet, of doen het onjuist. In dat geval kent Exchange Online het moment van invoeging, dus de migratiedatum, 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: als de Zoho Migration Wizard de originele datum wel doorgeeft, behoudt Exchange Online die en toont Outlook de juiste datum. De e-mails die de migratiedatum tonen, zijn precies die waarvan de datum niet werd doorgegeven.

Beheerders die generieke IMAP-tools zoals imapsync gebruiken om Zoho te verlaten, kunnen tegen hetzelfde probleem aanlopen: imapsync kopieert de datum die de bronserver voor elk bericht heeft, dus een verkeerde datum aan de bron wordt een verkeerde datum op de bestemming. (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

Elke gebruiker meldt zich aan met zijn eigen Microsoft-account, en Redate.io opent enkel die ene mailbox met de toegang die die aanmelding geeft. 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, geen weet hoeft te hebben van welke tool de migratie heeft uitgevoerd (Zoho Migration Wizard, imapsync of een andere) 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 zichtbare back-upmap in uw eigen mailbox, tot u ze zelf verwijdert.

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 kopie krijgt de datum die de tool doorgeeft, 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 waar de verkeerde datums werkelijk vandaan komen.

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.