iCloud naar Office 365-migratie: verkeerde e-maildatums

Een migratiescenario dat datums stelselmatig breekt

U heeft net uw iCloud-mailbox overgezet naar Office 365. De e-mails staan er, de mappen zijn aangemaakt, alles ziet er goed uit. Maandagochtend komt de eerste klacht binnen: "Al mijn oude e-mails tonen de datum van vandaag." Dan een tweede. Dan tien.

Dit is geen incident. Migratie van iCloud Mail naar Office 365 is een van de meest gedocumenteerde scenario's voor corruptie van e-maildatums, om technische redenen die te maken hebben met het gedrag van Apple Mail, het IMAP-protocol en de manier waarop Microsoft 365 binnenkomende berichten verwerkt.

Waarom iCloud naar Office 365 datums breekt

Om het probleem te begrijpen, moet u drie dingen onderscheiden die veel mensen (ook ervaren IT-admins) door elkaar halen: de Date:-header, de IMAP INTERNALDATE, en de aanmaakdatum van het bestand.

De Date:-header (RFC 2822)

Elke e-mail bevat een Date:-header die aangeeft wanneer het bericht is verzonden. Deze header is ingebed in de ruwe berichttekst en verandert in principe nooit. Dit is de "originele" datum in de strikte zin.

De IMAP INTERNALDATE

Het IMAP-protocol (gedefinieerd in RFC 3501) koppelt aan elk bericht een aparte metadata-waarde die INTERNALDATE heet. Die waarde gebruiken de meeste e-mailclients om berichten te sorteren en weer te geven in de inbox, niet de Date:-header. Outlook in het bijzonder vertrouwt sterk op de INTERNALDATE voor weergave en sortering.

Het probleem? Als een migratietool een e-mail van de ene IMAP-server naar de andere kopieert, zou die idealiter de INTERNALDATE moeten behouden. In de praktijk is dat niet altijd wat er gebeurt.

Het bijzondere gedrag van Apple Mail

Apple Mail gebruikt bij het synchroniseren van berichten vanuit iCloud soms de aanmaakdatum van het bestand aan de serverkant als referentie voor de INTERNALDATE. Dat is geen bug in de strikte zin, maar een interpretatie van de IMAP-specificatie die afwijkt van wat andere clients doen. (Als u ooit geprobeerd heeft een INTERNALDATE-probleem te debuggen door de ruwe IMAP-RFC's te lezen, weet u dat de specificatie op dit punt behoorlijk wat interpretatieruimte laat.)

Gevolg: als u exporteert of migreert vanuit iCloud via Apple Mail, kunnen de INTERNALDATES van de berichten al onjuist zijn voordat ze überhaupt in Office 365 aankomen.

De drie iCloud-migratiemethoden en hun valkuilen

Directe IMAP-migratie

De meest gebruikte methode is iCloud configureren als IMAP-bron en Office 365 als bestemming, en vervolgens een migratietool gebruiken (imapsync, MigrationWiz of een eigen tool). De tool verbindt zich met beide servers en kopieert de berichten.

Het probleem hier is tweeledig. Allereerst hebben Apple's IMAP-servers snelheidsbeperkingen die tools dwingen pauzes in te lassen, waardoor verbindingen sluiten en heropen, wat parasitaire INTERNALDATES kan veroorzaken. Daarnaast ontvangt elk bericht dat via IMAP APPEND naar Exchange Online wordt gekopieerd standaard een aanleverdatum die overeenkomt met het moment van de migratie, tenzij de tool de originele INTERNALDATE expliciet meegeeft in de invoegopdracht.

Sommige tools doen dat correct. Andere, niet consequent. En bij een mailbox van 40.000 berichten vertegenwoordigt zelfs een foutpercentage van 2% al 800 e-mails met de verkeerde datum.

Voor migraties via imapsync, zie ook: imapsync-migratiedatums in Microsoft 365 herstellen.

.mbox- of .eml-export en vervolgens importeren

Sommige gebruikers exporteren hun iCloud-e-mails via Apple Mail in .mbox-formaat en proberen ze vervolgens in Outlook te importeren. Dit is een ambachtelijke methode die wisselende resultaten oplevert.

Het .mbox-formaat slaat e-mails op als een reeks tekstberichten. De datums staan in de afzonderlijke Date:-headers, maar de scheidingslijn tussen berichten ("From ") bevat een datum die door sommige importprogramma's als aanmaakdatum wordt geïnterpreteerd. Outlook gebruikt bij het importeren van een naar .pst geconverteerd .mbox-bestand soms die scheidingsdatum in plaats van de Date:-header van het bericht zelf.

Slepen en neerzetten via Outlook

Dit is de methode die de meeste schade aanricht. Een gebruiker configureert beide accounts in Outlook (iCloud en Office 365) en sleept berichten van de ene map naar de andere. Dat lijkt eenvoudig. Het is een ramp voor de datums.

Wanneer Outlook een bericht via slepen en neerzetten verplaatst tussen twee IMAP-accounts, maakt het in werkelijkheid een nieuw .EML-bestand aan, voegt dat in bij het doelaccount en verwijdert het origineel. Dit nieuwe bestand erft de aanmaakdatum van het Windows-bestand, dat wil zeggen het exacte moment van het slepen. De originele Date:-header is nog steeds aanwezig in de berichttekst, maar de INTERNALDATE die op de Exchange Online-server is opgeslagen, komt overeen met de datum van de handeling. Outlook toont vervolgens die migratiedatum voor alle verplaatste berichten.

Eerlijk gezegd varieert dit gedrag per Outlook-versie. Sinds de Outlook-update van najaar 2023 is het gedrag voor bepaalde scenario's licht verbeterd, maar slepen en neerzetten tussen accounts blijft een gedocumenteerde bron van datumcorruptie.

Wat Office 365 en Outlook uiteindelijk tonen

Exchange Online slaat e-mails op met hun INTERNALDATE. Outlook Desktop leest die INTERNALDATE om de datum weer te geven in de kolom "Ontvangen" en om de inbox te sorteren. Als de INTERNALDATE tijdens de migratie is overschreven, toont Outlook de migratiedatum. Punt.

Outlook Web App (OWA) doet hetzelfde. Er is geen "alternatieve weergave" die de originele datum uit de Date:-header zou tonen. Wat u ziet in de datumkolom, is de INTERNALDATE.

De originele Date:-header is er nog steeds, intact, leesbaar als u de ruwe headers van een bericht weergeeft. Maar geen normale weergave toont die header. Dat is de kern van de frustratie: de juiste informatie bestaat wel, maar is gewoon ontoegankelijk zonder technische correctie.

Wat Microsoft-ondersteuning niet oplost

Als u bij Microsoft Support een ticket opent voor dit probleem, krijgt u waarschijnlijk dit: een bevestiging dat de weergegeven datums overeenkomen met de opgeslagen INTERNALDATES, een suggestie om de sorteerinstellingen in Outlook te controleren, en mogelijk een doorverwijzing naar de migratietool die u heeft gebruikt.

Dat is geen onwil. Microsoft heeft simpelweg geen native tool om de INTERNALDATES van duizenden berichten die al in Exchange Online zijn opgenomen, achteraf te corrigeren. Correctie vereist toegang tot elk bericht afzonderlijk, analyse van de headers en reconstructie van de datummetadata, wat buiten het bereik van standaard ondersteuning valt.

iCloud-ondersteuning beschouwt de berichten als correct geëxporteerd en stelt dat het probleem aan de kant van de bestemming ligt. Beide partijen verwijzen naar elkaar, en de gebruiker blijft achter met 12.000 e-mails gedateerd op de dag van de migratie.

Het schaalproblem

Begrijpen waarom datums kapot zijn, is één ding. Ze handmatig corrigeren op een productiemailbox is een ander verhaal.

Sommige IT-admins proberen de correctie te scripten. Het basisidee is niet moeilijk te conceptualiseren, maar de uitvoering op echte volumes brengt problemen met zich mee die zelfgeschreven scripts niet goed aankunnen:

• S/MIME-ondertekende of PGP-versleutelde e-mails kunnen niet worden gewijzigd zonder de cryptografische handtekening ongeldig te maken
• Berichten met complexe multipart/alternative-structuren (HTML + platte tekst + geneste bijlagen) zijn kwetsbaar om te bewerken
• In non-ASCII gecodeerde headers (RFC 2047, met name voor Japanse, Arabische of Cyrillische tekens) kunnen beschadigd raken door tools die deze codering niet correct afhandelen
• Microsoft Graph API-quota's en Exchange Online-snelheidsbeperkingen (fout 429 Too Many Requests) stoppen scripts die niet zijn ontworpen voor exponentiële backoff-afhandeling
• Een script dat correct werkt op 500 teste-mails, stopt om 3 uur 's nachts bij het 8.000ste bericht van een echte mailbox, zonder herstelmechanisme

En de vraag die alles bepaalt: hoe verifieert u dat elke gecorrigeerde e-mail intact is na de correctie? Dat de bijlage er nog is? Dat de berichtthread niet kapot is? Een zelfgeschreven script doet die verificatie doorgaans niet.

Hoe Redate.io migraties van iCloud naar Office 365 afhandelt

Redate.io verbindt zich rechtstreeks met Office 365 via Microsoft 365-machtigingen (Azure AD), zonder toegang tot iCloud-servers te vereisen. De e-mails zijn al in Exchange Online op het moment dat Redate aan de slag gaat.

De correctie-engine van Redate analyseert de headerketen van elk bericht om de originele datum te identificeren, waarbij Received:-headers die tijdens de migratie zijn toegevoegd worden onderscheiden van legitieme datummetadata. Deze analyse omvat patroonherkenning op basis van handtekeningen van bekende migratietools, waardoor parasitaire headers worden geïdentificeerd zelfs als ze niet onmiddellijk zichtbaar zijn.

Elke gecorrigeerde e-mail wordt na verwerking individueel geverifieerd. De originelen worden gedurende 30 dagen bewaard in een zichtbare back-upmap, wat geen enkel zelfgeschreven script standaard doet. De initiële scan is gratis en laat precies zien hoeveel e-mails zijn getroffen voordat u beslist te corrigeren.

Redate ondersteunt ook migraties van Google Workspace naar Office 365 en correcties na cPanel-migraties. Zie bijvoorbeeld: e-maildatums herstellen na Microsoft 365-migratie of verkeerde e-maildatums na migratie naar Exchange Online.

Eerst scannen, dan corrigeren

Het aanbevolen startpunt voor elke iCloud-naar-Office-365-migratie die onjuiste datums heeft opgeleverd: de gratis scan van Redate.io uitvoeren op de getroffen mailboxen. De scan identificeert precies hoeveel e-mails een verdachte INTERNALDATE hebben en in welke mappen ze zich bevinden.

Dat duurt tussen de 12 en 45 minuten afhankelijk van het volume, en geeft een duidelijk beeld van de omvang van het probleem voor er ook maar iets wordt gewijzigd. Voor MSP's die na een migratie meerdere mailboxen tegelijk beheren, voorkomt deze batchscan dat mailboxen worden gecorrigeerd die dat helemaal niet nodig hebben.

Als de datums van uw e-mails onjuist zijn na een migratie vanuit iCloud, start dan met de gratis scan op Redate.io om de omvang van het probleem in uw Office 365-mailboxen in kaart te brengen.