CloudM Migrate: atgarda felaktiga e-postdatum

CloudM Migrates datumproblem som ingen varnar for

CloudM Migrate ar klart. Instrumentpanelen visar 100 % slutfort, alla anvandare migrerade, noll fel. Du stanger projektarendet och gar vidare till nasta kund.

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

Inte nagra e-postmeddelanden. Alla. Fem ars kundkorrespondens, juridiska dokument, HR-handlingar, inkopsordrar fran 2020, allt med datumet da CloudM korde migreringen. Meddelandena finns dar, innehallet ar intakt, bifogade filer ar ok. Men datumen ar fel pa varenda ett.

Det ar inte en CloudM-bugg. CloudMs egen supportdokumentation erkanner det oppet. Problemet ligger i skarnigspunkten mellan hur migreringsverktyg overfar meddelanden och hur destinationens e-postservrar hanterar inkommande e-postmetadata. Men den kunskapen hjalper inte din kund vars inkorg blivit omojlig att sortera kronologiskt.

Hur CloudM faktiskt overfar e-postmeddelanden

CloudM Migrate ansluter till kall- och destinationsplattformar via deras API:er. For Google Workspace innebar det ett tjanstekonto med domanomfattande delegering (konfigurerat i Google Admin Console under Sakerhet > API-kontroller). For Microsoft 365 anvander CloudM antingen Exchange Web Services eller Microsoft Graph API, beroende pa migreringsvagen.

Nar CloudM laser ett meddelande fran kallan far det det fullstandiga RFC 2822-innehallet, inklusive alla originalheaders och meddelandetexten. Det ursprungliga Date:-headret (det som avsandarens e-postserver stamplade nar e-posten forst skickades) foljer med intakt. Det samma galler alla ursprungliga Received:-headers som sparar meddelandets leveransvag.

Problemet uppstar vid destinationen. Nar CloudM skriver det meddelandet i mailboxen stampar destinationsservern det som en ny leverans. Den satter ett nytt Received:-header med aktuellt datum och tid, och satter INTERNALDATE (tidsstampeln som IMAP anvander for sortering) till tidpunkten for insattning.

Sa har ser headerkedjan ut efter en CloudM-migrering till Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

2019-headret finns kvar. Det ursprungliga Date:-headret sager fortfarande 23 september 2019. Men Outlook laser det oversta Received:-headret for att bestamma visningsordningen, och det sager 2 april 2026.

CloudMs "Strip Received Headers"-installning

CloudM erbjuder en installning for att hantera detta. I destinationsplattformens avancerade installningar under Message Options finns en "Strip Received Headers"-vaxel. Nar den ar aktiverad tar CloudM bort Received-headers innan meddelandet sattss in och ersatter dem med ett enda header som matchar e-postens Date:-header.

Later som det loser allt, eller hur? Inte riktigt.

For det forsta maste du kanna till installningen innan du kor migreringen. De flesta administratorer upptacker datumproblemet efter att migreringen ar klar. Da sitter meddelandena redan pa destinationen med felaktiga datum. Att kora CloudM igen med installningen aktiverad skapar bara dubbletter, det atgardar inte det som redan finns dar.

For det andra har denna installning en hard begransning nar Google Workspace ar destinationen. Googles egen dokumentation bekraftar det: Gmail skriver alltid om Received:-headers pa meddelanden som satts in via API, med tidsstampeln for insattningen. Det ar en begransning pa plattformsniva som CloudM inte kan komma runt. Aven med "Strip Received Headers" aktiverat lagger Google Workspace till sitt eget Received:-header med migreringsdatumet.

For Microsoft 365-destinationer fungerar installningen battre i teorin, men M365-transportpipelinen har sitt eget beteende. Exchange Online kan anda satta INTERNALDATE baserat pa sin egen leveransbearbetning, beroende pa hur meddelandet kommer in i systemet.

Vilka CloudM-migreringar forstaor datum (och vilka gor det inte)

Inte varje CloudM-migrering producerar felaktiga datum. Resultatet beror pa kall-destinationskombinationen och den specifika API-vagen som CloudM anvander:

• Google Workspace till Microsoft 365: Datum gar sonder. CloudM laser via Gmail API och skriver till Exchange. M365-transportlagret stampar nya Received-headers.
• Microsoft 365 till Google Workspace: Datum gar sonder. Aven med Strip Received Headers skriver Googles API om Received-headret med insattningsdatumet. CloudMs supportdokumentation kallar detta en "strikt plattformsbegransning".
• Google Workspace till Google Workspace: Datum gar sonder. Domanbyte, tenantkonsolideringar, forvarvssammanslagningar, destinationens Google-tenant stampar alltid migreringsdatumet pa inkommande meddelanden.
• Lokal Exchange till Microsoft 365: Gar vanligtvis sonder via IMAP-vagen. Om CloudM anvander EWS pa bada sidor ar datumbevarande mer palitligt men inte garanterat.
• IMAP-kalla (generisk) till valfri destination: Datum gar sonder. Nar CloudM ansluter till en generisk IMAP-server som kalla, lagger destinationen anda till sina egna leveransheaders.

Den knivskarpa detaljen? CloudMs migreringsinstrumentpanel signalerar inget av detta. Fortskrittsfaltet fylls, statuskolumnen sager "Completed", objektrakningen stammer. Fran CloudMs perspektiv var migreringen lyckad. Och tekniskt sett var den det. Meddelandena overfords. Datumen overlevde bara inte resan.

CloudM Managed vs. Self-Service: samma datumproblem

CloudM erbjuder tva distributionsmodeller. SaaS-versionen (CloudM Migrate hostad) kors helt i CloudMs infrastruktur. Den sjalvhostade versionen later dig deploya primara och sekundara migreringsservrar pa ditt eget natverk, Google Cloud, Azure eller AWS.

Vissa MSP:er antar att den sjalvhostade varianten ger mer kontroll over datumhantering eftersom du hanterar migreringsservrarna direkt. Det gor den inte. Datumproblemet uppstar pa destinationsservern, inte pa CloudMs bearbetningsnoder. Oavsett om din migreringsfarm kors i CloudMs moln eller pa din egen Azure-VM stampar destinationsservern fortfarande migreringsdatumet pa varje meddelande den tar emot.

CloudM erbjuder ocksa en helt hanterad "Serviced Migration" dar deras team skoter projektet fran borjan till slut. Samma resultat for datum. Tekniken ar identisk, faktiskt ar det bara andra hander pa tangentbordet. Har du nagonsin betalat for en premiumtjanst och anda fatt samma begransning som gratisnivaen? Det ar exakt sa det kanns.

Komplikationen med ogiltiga Date-headers

Det finns ytterligare ett CloudM-specifikt beteende som forsammad saken. Nar CloudM stoter pa en kall-e-post med ett Date:-header som inte foljer RFC 822 (felformaterad tidszon, saknad veckodag, icke-standardformat), andrar CloudM headret sa att meddelandet kan migreras.

Det innebar att vissa e-postmeddelanden forlorar till och med sin ursprungliga datumreferens. Det andrade Date:-headret kanske inte alls matchar det riktiga skickdatumet. CloudMs supportdokumentation namner detta beteende under "Possible Changes to Migrated Items" men specificerar inte vad det andrade datumet blir.

For en brevlada med 12 000 meddelanden ackumulerade over atta ar kan det finnas hundratals e-postmeddelanden med latt icke-standard Date-headers (sarskilt meddelanden fran aldre e-postservrar, automatiserade system eller internationella avsandare med tidszonsformateringssaregenheter). Efter CloudMs andring plus destinationsserverns Received-header-omskrivning hamnar dessa meddelanden med datum som inte har nagon likhet med verkligheten.

Varfor manuella korrigeringar inte skalar efter CloudM

Skulle du kunna fixa det sjalv? Tekniskt sett ar det ursprungliga Date:-headret fortfarande inbaddat i de flesta meddelanden (forutom dem CloudM andrade for RFC-overensstammelse). Vissa administratorer har forsakt skriva skript for att korrigera datum efter en CloudM-migrering.

Har ar verkligheten med den metoden. Du maste ansluta till potentiellt tusentals brevlador, var och en med tusentals meddelanden. For varje e-post maste du parsa den fullstandiga headerkedjan, identifiera vilka Received:-headers CloudM eller destinationsservern lade till, hantera kantfallen (S/MIME-signerade meddelanden dar headerandring bryter signaturen, PGP-krypterat innehall, multipart MIME-strukturer med nastlade granser, RFC 2047-kodade icke-ASCII-headers fran japanska eller koreanska avsandare), och gora allt detta utan att forlora en enda bifogad fil eller bryta e-posttradningen.

Ett skript som fungerar pa 50 teste-postmeddelanden fran en ren brevlada overlever inte kontakten med en produktionsmiljo pa 40 000 meddelanden over ett decennium. Vad hander nar du traffar ett 47 MB e-postmeddelande med sex nastlade bilagor? Och API-hastighetsgranserna (250 kvotenheter per anvandare per sekund hos Google, Microsofts begransning pa cirka 10 000 forfragninar per 10 minuter)? Vad ar din rollbackplan nar nagot gar fel pa meddelande nummer 8 347?

Och den riktiga fragan som de flesta administratorer inte staller forran det ar for sent: hur verifierar du att varje korrigerat meddelande faktiskt ar intakt?

Atgarda CloudM-migreringsdatum med Redate.io

Redate.io ansluter direkt till de paverkade brevladorna (Google Workspace, Microsoft 365 eller IMAP) och skannar efter e-postmeddelanden som bar CloudMs migreringsdatumssignatur. Skanningen ar gratis och tar nagra minuter per brevlada, och visar det exakta antalet paverkade meddelanden innan nagot atagande gors.

Korrigeringen anvander en proprietar headerkedjeanalysmotor som identifierar CloudM-specifika migreringsmonster over Received-headerkedjan. Redate.io utfor riktad metadatakorrigering utan att andra meddelandeinnehallet, och bevarar bilagor, tradning, etiketter, mappar och digitala signaturer. Varje korrigerat meddelande gar igenom individuell verifiering, dar meddelandets integritet kontrolleras mot originalet innan processen fortsatter.

Ursprungliga e-postmeddelanden bevaras i en synlig sakerhetskopieringsmapp Redate.io - Originals i 30 dagar. Om nagot behover aterallas finns originalerna dar i brevladan, inte begravda i nagot externt arkiv.

For MSP:er som anvant CloudM pa kundmiljoer hanterar Redate.io korrigeringar over flera brevlador i stor skala, med samma verifiering per meddelande oavsett om du atgardar 1 brevlada eller 500. Datumproblemet som CloudM lamnade efter sig behover inte bli ett permanent inslag i din kunds e-postmiljo.

Plattformsspecifika guider for CloudM-migreringar

Korrigeringsprocessen anpassar sig till destinationsplattformen. Redate.io hanterar varje plattforms sarskilda krav automatiskt, men for detaljer om din konfiguration:

• Atgarda CloudM-migreringsdatum i Gmail
• Atgarda CloudM-migreringsdatum i Outlook
• Atgarda CloudM-migreringsdatum i Google Workspace
• Atgarda CloudM-migreringsdatum i Microsoft 365

For en djupare forklaring av varfor detta hander med alla migreringsverktyg (inte bara CloudM), las varfor e-postmeddelanden visar felaktiga datum efter migrering.

Migrerat med CloudM och fast med felaktiga datum pa varje e-post? Kor en gratis skanning for att se exakt hur manga meddelanden som ar paverkade och vad det kostar att atgarda dem.