Gedeelde hosting naar Microsoft 365: verborgen datumprobleem

Het probleem dat niemand u heeft verteld

U heeft zojuist de migratie van uw e-mail afgerond van OVH, Infomaniak, Ionos of o2switch naar Microsoft 365. De migratiewizard in het EAC (Exchange Admin Center) heeft de hele nacht gedraaid, alles staat op groen, de mailboxen zijn gevuld. Maandagochtend, het eerste ticket: "Al mijn oude e-mails hebben de datum van vandaag." Dan een tweede. Dan tien.

Dit is geen bug in Microsoft 365. Het is ook geen toeval. Het is het mechanische resultaat van een IMAP-migratie, en bij een gedeelde hostingprovider is het probleem vaak twee keer zo ernstig als bij een gewone migratie. Dit is waarom.

Hoe IMAP omgaat met datums (en waar het misgaat)

Elke e-mail op een IMAP-server heeft twee verschillende soorten datering. Enerzijds de Date:-header (gedefinieerd door RFC 2822), aanwezig in de berichttekst zelf, die aangeeft wanneer het bericht is verzonden of ontvangen. Anderzijds de INTERNALDATE, een metadataveld op serverniveau dat aangeeft wanneer het bericht in de mailbox is geplaatst. Die waarde gebruiken e-mailclients zoals Outlook standaard om e-mails te sorteren en weer te geven.

(Als u ooit de ruwe headers van een e-mail in het EAC heeft geprobeerd te lezen, weet u dat het geen strandlectuur is. Er staan al snel twintig tot dertig regels headers vóór de eigenlijke inhoud.)

Wanneer een IMAP-migratietool een bericht van de ene mailbox naar de andere verplaatst, moet hij die INTERNALDATE opnieuw aanmaken op de bestemming. Sommige tools doen dit correct. Veel niet, of met beperkingen. En de ontvangende server houdt de datum aan die hij binnenkrijgt: draagt een kopie haar originele datum, dan behoudt Exchange Online die datum. Blijken de datums dus verkeerd, dan ligt dat aan de tool, niet aan Microsoft 365.

Resultaat: elke gemigreerde e-mail lijkt te zijn "ontvangen" op de dag van de migratie. Ook als hij van 2019 is.

Het scenario in twee stappen: waarom gedeelde hosting alles erger maakt

Hier wordt de situatie echt problematisch bij migraties vanaf gedeelde hostingproviders zoals OVH, Infomaniak, Gandi, Ionos of o2switch.

Deze providers draaien doorgaans op gedeelde Postfix-, Dovecot- of cPanel-servers met standaard IMAP-configuraties. Veel kleine bedrijven hebben daar jarenlang e-mails verzameld, soms al vanaf 2010 of 2012. Wanneer zij overstappen naar Microsoft 365, verloopt de migratie vaak in twee fasen.

Fase 1: de eerste beschadiging (nog vóór Microsoft 365)

In veel gevallen hebben de e-mails al een eerste migratie ondergaan. Het bedrijf is door de jaren heen één of twee keer van hostingprovider gewisseld: van Gandi naar OVH in 2018, dan van OVH naar Infomaniak in 2022, bijvoorbeeld. Elke IMAP-overdracht kan de originele INTERNALDATE terugzetten naar de dag van de overdracht, als de tool de originele datum niet doorgeeft, en sommige tools voegen ook hun eigen migratieheaders toe, gedateerd op die dag.

Wanneer de e-mails op Microsoft 365 aankomen, dragen ze dus al littekens. De originele Date:-header is intact (die maakt deel uit van de berichttekst en wordt nooit aangeraakt), maar de datummetadata zijn al één keer verstoord.

Fase 2: de tweede beschadiging bij de overgang naar Exchange Online

De IMAP-migratietool van het EAC, of een tool van derden zoals BitTitan MigrationWiz in IMAP-modus, neemt die al beschadigde e-mails op. Als die tool ook de originele datum van elke e-mail niet doorgeeft, plaatst Exchange Online de e-mail onder de dag van de overdracht, en dat is de "ontvangstdatum" die Outlook uiteindelijk toont.

Een e-mail verzonden in maart 2017 kan dus twee lagen verkeerde datums dragen: migratieheaders die zijn achtergebleven van de verhuizing in 2022, en een ontvangstdatum van de migratie naar Microsoft 365 in 2024. Outlook toont 2024. De gebruiker ziet 2024. Dat is op twee niveaus onjuist.

Eigenlijk is het niet helemaal precies om te zeggen dat het altijd de meest recente Received:-header is die wordt gebruikt. Outlook bepaalt de weergavedatum op basis van een combinatie van de INTERNALDATE van de Exchange Online-mailbox en de aanwezige headers. Maar telkens wanneer de migratietool de originele datums niet doorgeeft, voegt de overstap naar Exchange Online een nieuwe laag fouten toe bovenop de bestaande.

Migratietools en hostingproviders: de risicovolle combinaties

Een aantal combinaties komt zeer vaak terug bij migraties vanuit gedeelde hosting:

• OVH / Infomaniak / Ionos + IMAP-tool van het EAC: de native Microsoft-tool is handig maar staat bekend om het niet correct bewaren van datums bij omvangrijke IMAP-migraties.
• cPanel (o2switch, LWS, enz.) + BitTitan MigrationWiz in IMAP-modus: MigrationWiz in IMAP-modus voegt zijn eigen migratieheaders toe. Het resultaat is gedocumenteerd, onder andere op de pagina BitTitan-migratiedatums in Microsoft 365 herstellen.
• Gandi / Mailcow + imapsync: imapsync is een krachtige tool, maar het bewaren van de INTERNALDATE hangt af van de configuratie. Zonder de juiste optie worden datums niet bewaard. Zie ook imapsync: datums niet behouden.
• Elke handmatige migratie via slepen en neerzetten in Outlook: als iemand volledige mappen heeft gekopieerd door te drag-and-droppen tussen twee accounts in Outlook, wordt de INTERNALDATE van elk bericht overschreven met de datum van de kopie. Zonder uitzondering.

De gemeenschappelijke noemer: al deze methoden resulteren in Exchange Online-mailboxen met e-mails waarvan de weergegeven datum in Outlook niets meer met de werkelijkheid te maken heeft.

Waarom "het zelf oplossen" op grote schaal een slecht idee is

Het probleem begrijpen is één ding. 8.000 e-mails herstellen verspreid over 40 Exchange Online-mailboxen, op accounts met complexe mapstructuren, S/MIME-ondertekende berichten, grote bijlagen en geneste discussies, is een heel ander verhaal.

Een PowerShell-script dat bij tien testmailberichten lijkt te werken, kan stilzwijgend falen op bericht nummer 4237 vanwege een beschadigde MIME-grens of een in RFC 2047 gecodeerde header (dat =?UTF-8?B?...?=-formaat voor niet-ASCII-tekens in afzendernamen). Zonder individueel verificatiemechanisme weet u dat niet. U heeft gewoon een verloren bericht.

De concrete risico's van zelf doen bij dit type migratie:

• Dubbele berichten als de invoeglogica halverwege misloopt
• Ontbrekende bijlagen als de multipart-structuur verkeerd wordt opgebouwd
• Gebroken gespreksdraadjes in Outlook (conversaties zijn gebaseerd op References:- en In-Reply-To:-headers die kunnen worden beschadigd)
• 429-fouten (Too Many Requests) van de Microsoft Graph API om 3 uur 's nachts, die de verwerking onderbreken zonder terugdraaifunctie
• Geen eenvoudige manier om te controleren of alle 8.000 correcties correct zijn toegepast

En bij migraties vanuit gedeelde hosting is er nog een extra moeilijkheid: de e-mails dragen meerdere lagen parasitaire Received:-headers, niet slechts één. Een eenvoudig script dat "de laatste Received:" verwijdert, volstaat niet. De volledige headerreeks moet worden geanalyseerd om te bepalen welke header bij welke migratie hoort, en welke de werkelijke originele ontvangstdatum vertegenwoordigt.

Wat Redate.io anders doet

Elke gebruiker meldt zich aan met zijn eigen Microsoft-account, en Redate.io opent alleen die ene mailbox met de toegang die die aanmelding geeft. De eerste scan is gratis: Redate.io identificeert alle e-mails waarvan de weergegeven datum niet overeenkomt met de werkelijke datum, en geeft een nauwkeurige schatting per mailbox.

De correctie maakt gebruik van een eigen correctie-engine die de volledige headerreeks van elk bericht analyseert, ongeacht welke migratietool is gebruikt, en de datummetadata correct reconstrueert, zelfs wanneer meerdere corruptielagen over elkaar heen liggen. Elk gecorrigeerd bericht wordt individueel geverifieerd. Redate.io verwijdert de originelen nooit. Ze blijven in een zichtbare map van uw eigen mailbox tot u ze zelf verwijdert.

Voor migraties vanuit gedeelde hosting behandelt de meerfasige analysepipeline van Redate.io expliciet de scenario's met dubbele beschadiging: in plaats van alleen naar de laatste Received:-header te kijken, analyseert Redate.io de volledige geschiedenis om de werkelijke ontvangstdatum te achterhalen. Zie ook hoe u e-maildatums herstelt na een Microsoft 365-migratie in het algemeen, en de specifieke uitleg over IMAP INTERNALDATE-problemen voor de onderliggende mechaniek.

Voor of na de migratie: twee momenten om in te grijpen

Twee situaties, twee aanpakken.

U heeft nog niet gemigreerd. Goed nieuws: de schade kan worden beperkt. Sommige migratietools (MigrationWiz in Exchange-modus, CloudM met de juiste opties) bewaren datums beter dan andere. Maar zelfs in het beste geval zal een migratie vanuit gedeelde hosting zonder schone historiek waarschijnlijk sporen nalaten. Plan een correctieronde met Redate.io in na de migratie, vóór u de mailboxen aan gebruikers overhandigt.

U heeft al gemigreerd en de tickets stromen binnen. Redate.io herstelt bestaande mailboxen in Microsoft 365, ongeacht hoe lang geleden de migratie heeft plaatsgevonden. De scan geeft u een nauwkeurig beeld van de werkelijke toestand van elke mailbox vóór enige ingreep. Raadpleeg ook de checklist e-mailmigratie om dezelfde problemen in de toekomst te voorkomen.

Gemigreerd vanuit OVH, Infomaniak, Ionos of o2switch naar Microsoft 365 en de datums kloppen niet? Maak een Redate.io-account aan om uw mailboxen gratis te scannen en precies te zien wat de omvang van de schade is voordat u een beslissing neemt.