CloudM Migrate: åtgärda felaktiga e-postdatum

CloudM Migrates datumproblem som ingen varnar för

CloudM Migrate är klart. Instrumentpanelen visar 100 % slutfört, alla användare migrerade, noll fel. Du stänger projektärendet och går vidare till nästa kund.

En vecka senare ringer IT-chefen. "Varför visar varje e-post i min inkorg den 2 april?"

Inte några e-postmeddelanden. Alla. Fem års kundkorrespondens, juridiska dokument, HR-handlingar, inköpsordrar från 2020, allt med datumet då CloudM körde migreringen. Meddelandena finns där, innehållet är intakt, bifogade filer är ok. Men datumen är fel på varenda ett.

Det är inte en CloudM-bugg. CloudMs egen supportdokumentation erkänner det öppet. Problemet ligger i skärnigspunkten mellan hur migreringsverktyg överfar meddelanden och hur destinationens e-postservrar hanterar inkommande e-postmetadata. Men den kunskapen hjälper inte din kund vars inkorg blivit omöjlig att sortera kronologiskt.

Hur CloudM faktiskt överfar e-postmeddelanden

CloudM Migrate ansluter till käll- och destinationsplattformar via deras API:er. För Google Workspace innebär det ett tjänstekonto med domänomfattande delegering (konfigurerat i Google Admin Console under Säkerhet > API-kontroller). För Microsoft 365 använder CloudM antingen Exchange Web Services eller Microsoft Graph API, beroende på migreringsvägen.

När CloudM läser ett meddelande från källan får det det fullständiga RFC 2822-innehållet, inklusive alla originalheaders och meddelandetexten. Det ursprungliga Date:-headret (det som avsändarens e-postserver stämplade när e-posten först skickades) följer med intakt. Det samma gäller alla ursprungliga Received:-headers som sparar meddelandets leveransväg.

Problemet uppstår när kopian skrivs. Destinationen behåller det datum den får: Microsoft 365 och Gmail behåller det ursprungliga datumet när kopian bär det. När den inte gör det får kopian tidpunkten för insättning som sitt datum. Och på Google Workspace får varje meddelande som skrivs via Gmail API också ett nytt Received:-header daterat till tidpunkten för insättning.

Så här ser headrarna i ett av dessa e-postmeddelanden fortfarande ut efter en CloudM-migrering till Microsoft 365:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Det ursprungliga Date:-headret från 2019 finns fortfarande kvar, och det gör även den ursprungliga Received:-kedjan. Men i Microsoft 365 är det datum Outlook visar som mottaget mailboxens egen uppgift om när varje e-postmeddelande kom in: om CloudM inte skickade med det ursprungliga datumet säger den uppgiften 2 april 2026.

CloudMs "Strip Received Headers"-inställning

CloudM erbjuder en inställning för att hantera detta. I destinationsplattformens avancerade inställningar under Message Options finns en "Strip Received Headers"-växel. När den är aktiverad tar CloudM bort Received-headers innan meddelandet sättss in och ersätter dem med ett enda header som matchar e-postens Date:-header.

Låter som det löser allt, eller hur? Inte riktigt.

För det första måste du känna till inställningen innan du kör migreringen. De flesta administratörer upptäcker datumproblemet efter att migreringen är klar. Då sitter meddelandena redan på destinationen med felaktiga datum. Att köra CloudM igen med inställningen aktiverad skapar bara dubbletter, det åtgärdar inte det som redan finns där.

För det andra har denna inställning en hård begränsning när Google Workspace är destinationen. Googles egen dokumentation bekräftar det: Gmail skriver alltid om Received:-headers på meddelanden som sätts in via API, med tidsstämpeln för insättningen. Det är en begränsning på plattformsnivå som CloudM inte kan komma runt. Även med "Strip Received Headers" aktiverat lägger Google Workspace till sitt eget Received:-header med migreringsdatumet.

För Microsoft 365-destinationer spelar inställningen mindre roll: Microsoft 365 behåller det datum den får, så det som avgör det visade datumet är om CloudM skickar med varje e-postmeddelandes ursprungliga datum.

Vilka CloudM-migreringar förstaör datum (och vilka gör det inte)

Inte varje CloudM-migrering producerar felaktiga datum. Resultatet beror på käll-destinationskombinationen och den specifika API-vägen som CloudM använder:

• Google Workspace till Microsoft 365: Datum går sönder. CloudM läser via Gmail API och skriver till Exchange, och varje e-postmeddelande får kopians datum.
• Microsoft 365 till Google Workspace: Datum går sönder. Även med Strip Received Headers skriver Googles API om Received-headret med insättningsdatumet. CloudMs supportdokumentation kallar detta en "strikt plattformsbegränsning".
• Google Workspace till Google Workspace: Datum går sönder. Domänbyte, tenantkonsolideringar, förvärvssammanslagningar: varje meddelande som skrivs via Gmail API får ett Received:-header daterat till migreringen.
• Lokal Exchange till Microsoft 365: Allt beror på det datum CloudM skickar med, oavsett om kopian går via IMAP eller EWS.
• IMAP-källa (generisk) till valfri destination: Samma regel gäller: när CloudM ansluter till en generisk IMAP-server som källa visar kopian migreringsdatumet varje gång det ursprungliga datumet inte skickas med till destinationen.

Den knivskarpa detaljen? CloudMs migreringsinstrumentpanel signalerar inget av detta. Fortskrittsfältet fylls, statuskolumnen säger "Completed", objekträkningen stämmer. Från CloudMs perspektiv var migreringen lyckad. Och tekniskt sett var den det. Meddelandena överförds. Datumen överlevde bara inte resan.

CloudM Managed vs. Self-Service: samma datumproblem

CloudM erbjuder två distributionsmodeller. SaaS-versionen (CloudM Migrate hostad) körs helt i CloudMs infrastruktur. Den självhostade versionen låter dig deploya primära och sekundära migreringsservrar på ditt eget nätverk, Google Cloud, Azure eller AWS.

Vissa MSP:er antar att den självhostade varianten ger mer kontroll över datumhantering eftersom du hanterar migreringsservrarna direkt. Det gör den inte. Det som avgör datumet är vad migreringsmotorn skickar med för varje meddelande, och den motorn är densamma oavsett var den körs. Oavsett om din migreringsfarm körs i CloudMs moln eller på din egen Azure-VM blir resultatet för datum detsamma.

CloudM erbjuder också en helt hanterad "Serviced Migration" där deras team sköter projektet från början till slut. Samma resultat för datum. Tekniken är identisk, faktiskt är det bara andra händer på tangentbordet. Har du någonsin betalat för en premiumtjänst och ändå fått samma begränsning som gratisnivån? Det är exakt så det känns.

Komplikationen med ogiltiga Date-headers

Det finns ytterligare ett CloudM-specifikt beteende som försämmad saken. När CloudM stöter på en käll-e-post med ett Date:-header som inte följer RFC 822 (felformaterad tidszon, saknad veckodag, icke-standardformat), ändrar CloudM headret så att meddelandet kan migreras.

Det innebär att vissa e-postmeddelanden förlorar till och med sin ursprungliga datumreferens. Det ändrade Date:-headret kanske inte alls matchar det riktiga skickdatumet. CloudMs supportdokumentation nämner detta beteende under "Possible Changes to Migrated Items" men specificerar inte vad det ändrade datumet blir.

För en brevlåda med 12 000 meddelanden ackumulerade över åtta år kan det finnas hundratals e-postmeddelanden med lätt icke-standard Date-headers (särskilt meddelanden från äldre e-postservrar, automatiserade system eller internationella avsändare med tidszonsformateringssäregenheter). Efter CloudMs ändring, plus en kopia som inte bär med sig det ursprungliga datumet, hamnar dessa meddelanden med datum som inte har någon likhet med verkligheten.

Varför manuella korrigeringar inte skalar efter CloudM

Skulle du kunna fixa det själv? Tekniskt sett är det ursprungliga Date:-headret fortfarande inbäddat i de flesta meddelanden (förutom dem CloudM ändrade för RFC-överensstämmelse). Vissa administratörer har försakt skriva skript för att korrigera datum efter en CloudM-migrering.

Här är verkligheten med den metoden. Du måste ansluta till potentiellt tusentals brevlådor, var och en med tusentals meddelanden. För varje e-post måste du parsa den fullständiga headerkedjan, identifiera vilka Received:-headers CloudM eller destinationsservern lade till, hantera kantfallen (S/MIME-signerade meddelanden där headerändring bryter signaturen, PGP-krypterat innehåll, multipart MIME-strukturer med nästlade gränser, RFC 2047-kodade icke-ASCII-headers från japanska eller koreanska avsändare), och göra allt detta utan att förlora en enda bifogad fil eller bryta e-posttrådningen.

Ett skript som fungerar på 50 teste-postmeddelanden från en ren brevlåda överlever inte kontakten med en produktionsmiljö på 40 000 meddelanden över ett decennium. Vad händer när du träffar ett 47 MB e-postmeddelande med sex nästlade bilagor? Och API-hastighetsgränserna (250 kvotenheter per användare per sekund hos Google, Microsofts begränsning på cirka 10 000 förfrågninar per 10 minuter)? Vad är din rollbackplan när något går fel på meddelande nummer 8 347?

Och den riktiga frågan som de flesta administratörer inte ställer förrän det är för sent: hur verifierar du att varje korrigerat meddelande faktiskt är intakt?

Åtgärda CloudM-migreringsdatum med Redate.io

Redate.io ansluter direkt till de påverkade brevlådorna (Google Workspace, Microsoft 365 eller IMAP) och skannar efter e-postmeddelanden vars visade datum inte stämmer med deras ursprungliga datum. Skanningen är gratis och tar några minuter per brevlåda, och visar det exakta antalet påverkade meddelanden innan något åtagande görs.

Korrigeringen använder en proprietär headerkedjeanalysmotor, och den behöver inte veta vilket verktyg som utförde migreringen. Redate.io utför riktad metadatakorrigering utan att ändra meddelandeinnehållet, och bevarar bilagor, trådning, etiketter, mappar och digitala signaturer. Varje korrigerat meddelande går igenom individuell verifiering, där meddelandets integritet kontrolleras mot originalet innan processen fortsätter.

Ursprungliga e-postmeddelanden bevaras i en synlig säkerhetskopieringsmapp Redate.io - Originals tills du själv tar bort dem. Om något behöver återställas finns originalerna där i brevlådan, inte begravda i något externt arkiv.

För MSP:er som använt CloudM på kundmiljör hanterar Redate.io korrigeringar över flera brevlådor i stor skala, med samma verifiering per meddelande oavsett om du åtgärdar 1 brevlåda eller 500. Datumproblemet som CloudM lämnade efter sig behöver inte bli ett permanent inslag i din kunds e-postmiljö.

Plattformsspecifika guider för CloudM-migreringar

Korrigeringsprocessen anpassar sig till destinationsplattformen. Redate.io hanterar varje plattforms särskilda krav automatiskt, men för detaljer om din konfiguration:

• Åtgärda CloudM-migreringsdatum i Gmail
• Åtgärda CloudM-migreringsdatum i Outlook
• Åtgärda CloudM-migreringsdatum i Google Workspace
• Åtgärda CloudM-migreringsdatum i Microsoft 365

För en djupare förklaring av varför detta händer med alla migreringsverktyg (inte bara CloudM), läs varför e-postmeddelanden visar felaktiga datum efter migrering.

Migrerat med CloudM och fast med felaktiga datum på varje e-post? Kör en gratis skanning för att se exakt hur många meddelanden som är påverkade och vad det kostar att åtgärda dem.