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 händer när migreringsverktyget inte skickar med varje mejls ursprungliga datum. 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 en IMAP-migrering kan förstöra 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 behåller det datum det får: när verktyget skickar varje meddelandes ursprungliga INTERNALDATE med APPEND-kommandot behåller kopian det. Vissa migreringsverktyg gör det. Andra gör det inte, eller gör det felaktigt, varpå Exchange Online tilldelar infogningsögonblicket, det vill säga migreringsdatumet, 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: när Zoho Migration Wizard verkligen skickar med det ursprungliga datumet behåller Exchange Online det, och Outlook visar rätt datum. De mejl som visar migreringsdatumet är de vars datum inte skickades med.

Admins som använder generiska IMAP-verktyg som imapsync för att lämna Zoho kan stöta på samma problem: imapsync kopierar det datum källservern har lagrat för varje meddelande, så ett fel datum hos källan blir ett fel datum hos målet. (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 loggar in med ditt eget Microsoft-konto, och öppnar bara den e-postlådan med den åtkomst som inloggningen ger. Ingen portal, ingen app att registrera. 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 en egenutvecklad motor som inte behöver veta vilket verktyg som utförde migreringen (Zoho Migration Wizard, imapsync eller något annat). Varje korrigerat mejl verifieras individuellt: innehållsintegritet, bevarade bilagor, RFC-efterlevnad. Redate.io tar aldrig bort originalen. De ligger kvar i en synlig mapp i din egen e-postlåda tills du själv raderar dem.

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: kopian får det datum verktyget skickar, 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 varifrån de felaktiga datumen egentligen kommer.

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.