Felaktiga e-postdatum efter Zoho-migrering till Microsoft 365

Vad som hände med din brevlåda

Du har precis avslutat migreringen av din domän från Zoho Mail till Microsoft 365. Exchange Online-infrastrukturen är på plats, brevlådorna är etablerade, MX-posterna är uppdaterade. Sedan, måndag morgon, öppnar en användare Outlook och märker att alla mejl från 2021 visar dagens datum. En annan konstaterar att meddelanden från förra året hamnar längst upp i inkorgen, som om de precis hade kommit in. Tickets börjar trilla in.

Det är inte ett Outlook-fel. Det är inte heller ett problem specifikt för Zoho. Det är det förväntade, men dåligt dokumenterade, beteendet vid alla IMAP-migreringar till Exchange Online. Att förstå exakt varför det händer är första steget för att åtgärda det ordentligt.

Den tekniska orsaken: INTERNALDATE och Received-headers

Ett e-postmeddelande som lagras på en IMAP-server består av två separata delar: meddelandets råinnehåll (RFC 2822-headers, brödtext, bilagor) och lagringsmetadata som hanteras av IMAP-servern, inklusive INTERNALDATE. Det är just den metadata som e-postklienter använder för att visa och sortera meddelanden.

Headern Date: i råmeddelandet (RFC 2822) anger när meddelandet skrevs eller skickades av avsändaren. INTERNALDATE är däremot det datum då IMAP-servern tog emot eller lagrade meddelandet. Normalt, på en frisk server, ligger dessa värden nära varandra. Efter en migrering är det en annan historia.

Hur IMAP-migrering förstör datum

När ett migreringsverktyg (Zoho Migration Wizard, imapsync, BitTitan eller något annat) överför ett meddelande från Zoho Mail till Exchange Online sker det via IMAP-protokollet. Verktyget ansluter till Zoho, hämtar meddelandet och lägger sedan in det i Exchange Online. Och det är här det börjar gå fel.

Exchange Online genererar en ny Received:-header för varje mottaget meddelande och lägger till den längst upp i headerlistan. Den headern bär exakt datum och tid för infogandet, det vill säga migreringsdatumet. Vissa migreringsverktyg försöker bevara det ursprungliga INTERNALDATE genom att skicka det som parameter. Andra gör det inte, eller gör det felaktigt, varpå Exchange Online automatiskt tilldelar mottagningsdatumet som INTERNALDATE.

Resultatet: oavsett om ett mejl skickades 2019 eller 2022 pekar dess INTERNALDATE nu på migreringsveckan. Outlook läser det värdet i första hand. Sorteringen kollapsar.

Zoho Migration Wizards specifika beteende

Zoho erbjuder ett eget migreringsverktyg för att lämna plattformen: Zoho Migration Wizard. Verktyget är praktiskt vid enklare migreringar, men det har ett dokumenterat beteende på adminforum: det överför inte alltid INTERNALDATE korrekt vid infogning i målservern.

För att vara exakt gäller problemet framför allt migreringar till servrar som systematiskt lägger till en Received:-header på varje inkommande meddelande, vilket är precis hur Exchange Online fungerar. Även om Zoho Migration Wizard skickar det ursprungliga datumet via APPEND-parametern hamnar Received:-headern som Exchange Online genererar på första plats i headerkedjan, och Outlook använder den för att avgöra "när mejlet kom in".

Admins som använder generiska IMAP-verktyg som imapsync för att lämna Zoho stöter på exakt samma problem, ibland värre, eftersom imapsyncs standardkonfiguration inte är optimerad för Exchange Online. (Om du någon gång har gått igenom en imapsync-logg rad för rad i jakt på ett synkroniseringsfel klockan 02 på natten vet du att det är ett kraftfullt verktyg men inte direkt nådigt mot kantfall.)

Varför Outlook visar fel datum

Outlook använder inte enbart Date:-headern för att visa ett mejls datum. I de flesta vyer är det INTERNALDATE från IMAP/Exchange-servern som används, särskilt för sortering av inkorgen. Den ursprungliga Date:-headern finns kvar i meddelandet, intakt, men ignoreras till förmån för INTERNALDATE.

Det är därför alternativet "Sortera på sändningsdatum" i Outlook inte löser problemet på riktigt. Det visar ett annat datum, visst, men sorteringsbeteendet förblir instabilt beroende på Outlook-version och visningsläge (grupperade konversationer eller inte). Att sortera på sändningsdatum är inte en lösning. Det är ett plåster som lossnar vid första klientuppdateringen.

Problemets verkliga omfattning

Vid en medelstor Zoho-migrering till Microsoft 365 handlar det lätt om 50 000 till 500 000 påverkade meddelanden, beroende på hur gamla brevlådorna är och organisationens storlek. Varje mejl som överfördes under migreringsfönstret bär samma korrupta datum, vilket gör problemet direkt synligt för användarna redan första gången de öppnar Outlook.

Mappen Skickat är ofta mest problematisk. En säljare som letar efter en offert skickad i mars 2022 får bläddra igenom hundratals mejl som alla visar migreringsdatumet. Den operativa påverkan är verklig, inte bara kosmetisk.

Och trots vad man kanske tror försvinner inte problemet med tiden. INTERNALDATE sätts vid infogningen. Det rättar inte till sig självt. Utan aktiv åtgärd behåller mejlen sina korrupta datum på obestämd tid.

Varför det är svårare än det verkar att fixa själv

Frestelsen är begriplig: eftersom den ursprungliga Date:-headern fortfarande finns i meddelandet borde det väl gå att... korrigera metadatan. På pappret är det logiskt. I praktiken, på en produktionsbrevlåda med 80 000 mejl, är det en operation som kan gå katastrofalt fel.

Här är några kantfall som ett hemmabyggt skript troligtvis inte hanterar bra:

• S/MIME-signerade mejl, där signaturen täcker samtliga headers. Att ändra något i meddelandestrukturen ogiltigförklarar den kryptografiska signaturen.
• PGP-krypterade meddelanden, där innehållet är ogenomskinligt och all hantering av MIME-enveloper kan korruptera meddelandet.
• Icke-ASCII-headers kodade enligt RFC 2047 (avsändarnamn med specialtecken), som bryts sönder om skriptet inte hanterar kodningen korrekt.
• Bilagor kodade i base64 med felaktigt avslutade rader, icke-standardiserade MIME-gränser eller nästlade multipart-strukturer.
• Mejl utan giltig Date:-header (det förekommer, särskilt i gamla Zoho-exporter), där skriptet måste bestämma vad det ska göra.

Ett skript som fungerar på 50 testmejl kommer inte att fungera på en produktionsbrevlåda från Zoho med flera års historik. Och hur verifierar du, meddelande för meddelande, att varje korrigering är intakt och att bilagor inte trunkerades? Verifieringen är minst lika komplex som själva korrigeringen.

Det finns också frågan om kvoter. Exchange Online-APIet via Microsoft Graph har strikta hastighetsbegränsningar (de välkända 429 Too Many Requests-felen). Ett okontrollerat batch-jobb mot 100 000 meddelanden kan utlösa temporära blockeringar eller tysta fel som är svåra att diagnostisera i efterhand. Utan återupptagningsmekanismer börjar du om från början.

Hur Redate.io åtgärdar datum efter Zoho-migrering

Redate.io ansluter till din Microsoft 365-tenant via standard Azure AD-behörigheter, utan global adminåtkomst. Den inledande skanningen är gratis: Redate.io identifierar påverkade brevlådor och uppskattar volymen mejl med felaktiga datum, genom att jämföra INTERNALDATE med värdena i meddelandets headerkedja.

Korrigeringen använder ett proprietärt motorn som analyserar varje meddelandets fullständiga headerkedja, identifierar specifika signaturer från Zoho-migreringsverktyg (oavsett om det är Zoho Migration Wizard eller imapsync konfigurerat för Zoho-utflytt) och rekonstruerar datummetadata via ett flerstegigt valideringspipeline. Varje korrigerat mejl verifieras individuellt: innehållsintegritet, bevarade bilagor, RFC-efterlevnad. Originalen behålls i en tillgänglig säkerhetskopieringsmapp i 30 dagar.

Ingen omigrering. Ingen driftstopp. Användarna fortsätter använda Outlook medan korrigeringen körs i bakgrunden.

Prissättningen är en engångsbetalning baserad på volym, utan abonnemang. Detaljer finns direkt på webbplatsen.

Liknande fall att känna till

Om du hanterar flera migreringar parallellt, eller om du är MSP och administrerar kunder som lämnar Zoho, bör du notera att samma problem uppstår vid migreringar från andra plattformar till Exchange Online. Mekaniken är identisk: Received:-headern som Exchange genererar skriver över INTERNALDATE oavsett källplattform.

För migreringar från Google Workspace, från Exchange on-premises eller via verktyg som BitTitan MigrationWiz eller CloudM finns dedikerade artiklar på Redate.io:s blogg som beskriver beteendet för varje specifikt verktyg. Artikeln om felaktiga e-postdatum efter Exchange Online-migrering ger en överblick över alla scenarion som mynnar ut i detta problem på din tenant.

Om migreringen inkluderar delade brevlådor eller Exchange-resurser (mötesrum, utrustning) är problemet detsamma, och samma korrigeringsverktyg gäller. Guiderna på Redate.io beskriver anslutningsstegen till din tenant i detalj.

För team som specifikt använder imapsync för att lämna Zoho dokumenterar artikeln imapsync: datum inte bevarade konfigurationsalternativen i imapsync och varför de inte räcker för att undvika problemet på Exchange Online.

Visas dina Zoho-migreringsdatum fortfarande fel i Outlook? Skanna dina brevlådor gratis på Redate.io för att mäta problemets exakta omfattning innan du bestämmer hur du ska agera.