CloudM Migrate: hibás e-mail dátumok javítása

A CloudM Migrate dátumproblémája, amire senki nem figyelmeztet

A CloudM Migrate befejezte a munkát. Az irányítópult 100%-os befejezést mutat, minden felhasználó migrálva, nulla hiba. Lezárja a projekt jegyét és továbblép a következő ügyfélre.

Aztán egy héttel később hív az IT igazgató. "Miért mutat minden e-mail a postaládámban április 2-át?"

Nem néhány e-mail. Mind. Öt évnyi ügyfél-levelezés, jogi dokumentumok, HR nyilvántartások, 2020-as beszerzési rendelések, mind a CloudM migráció futtatásának dátumát mutatja. Az üzenetek megvannak, a tartalom sértetlen, a mellékletek rendben. De a dátumok hibásak mindegyiken.

Ez nem CloudM hiba. A CloudM saját támogatási dokumentációja nyíltan elismeri. A probléma a migrációs eszközök üzenetátviteli módja és a céloldali levelezőszerverek bejövő e-mail metaadat-kezelése közötti metszéspontban rejlik. De ennek ismerete nem segít azon az ügyfélen, akinek a postaládája rendezhetetlenné vált.

Hogyan viszi át a CloudM valójában az e-maileket

A CloudM Migrate a forrás- és célplatformokhoz azok API-jain keresztül csatlakozik. Google Workspace esetén ez egy domain-wide delegation-nel rendelkező szolgáltatásfiókot jelent (a Google Admin Console-ban a Security > API Controls alatt konfigurálva). Microsoft 365 esetén Exchange Web Services-t vagy Microsoft Graph API-t használ, a migrációs útvonaltól függően.

Amikor a CloudM kiolvas egy üzenetet a forrásból, megkapja a teljes RFC 2822 tartalmat, beleértve az összes eredeti fejlécet és az üzenettörzset. Az eredeti Date: fejléc (amelyet a feladó levelezőszervere az e-mail első elküldésekor pecsételt) sértetlenül érkezik. Az üzenet kézbesítési útvonalát nyomon követő összes eredeti Received: fejléc szintén.

A probléma a céloldalon történik. Amikor a CloudM beírja az üzenetet a cél postaládába, a célszerver új kézbesítésként kezeli. Friss Received: fejlécet ad hozzá az aktuális dátummal és idővel, és az INTERNALDATE értéket (az IMAP által rendezésre használt időbélyeget) a beillesztés pillanatára állítja.

Így néz ki a fejlécsor egy CloudM-mel Microsoft 365-be történő migráció után:

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

A 2019-es fejléc ott van. Az eredeti Date: továbbra is 2019. szeptember 23-át mutatja. De az Outlook a legfelső Received: fejlécet olvassa a megjelenítési sorrendhez, és az már 2026. április 2-át mondja.

A CloudM "Strip Received Headers" beállítása

A CloudM kínál egy beállítást erre. A célplatform Advanced Settings részében, a Message Options alatt van egy "Strip Received Headers" kapcsoló. Bekapcsoláskor a CloudM eltávolítja a received fejléceket az üzenet beillesztése előtt, és egyetlen, az e-mail Date: fejlécével egyező fejléccel helyettesíti őket.

Mindent megold, ugye? Nem egészen.

Először is, a migráció futtatása előtt tudni kell róla. A legtöbb rendszergazda a migráció befejezése után fedezi fel a dátumproblémát. Ekkor az üzenetek már hibás dátumokkal ülnek a célhelyen. A CloudM újrafuttatása a bekapcsolt beállítással csak duplikátumokat hoz létre, nem javítja a már ott lévőket.

Másodszor, ennek a beállításnak komoly korlátja van, amikor a cél Google Workspace. A Google saját dokumentációja megerősíti: a Gmail mindig felülírja a Received: fejléceket az API-n keresztül beillesztett üzeneteken, a beillesztési időbélyeggel. Ez platformszintű korlátozás, amelyet a CloudM nem tud felülbírálni. Még a "Strip Received Headers" bekapcsolásával is a Google Workspace hozzáadja a saját Received: fejlécét a migráció dátumával.

Microsoft 365 célok esetén a beállítás elméletben jobban működik, de az M365 szállítási pipeline-nak saját viselkedése van. Az Exchange Online a saját kézbesítési feldolgozása alapján is beállíthatja az INTERNALDATE-et, attól függően, hogyan lép be az üzenet a rendszerbe.

Mely CloudM migrációk rontják el a dátumokat (és melyek nem)

Nem minden CloudM migráció eredményez hibás dátumokat. Az eredmény a forrás-cél kombinációtól és a CloudM által használt API-útvonaltól függ:

• Google Workspace - Microsoft 365: A dátumok elromlanak. A CloudM a Gmail API-n keresztül olvas és az Exchange-be ír. Az M365 szállítási réteg új Received fejléceket pecsétel.
• Microsoft 365 - Google Workspace: A dátumok elromlanak. Még Strip Received Headers mellett is a Google API felülírja a Received fejlécet a beillesztési dátummal. A CloudM támogatási dokumentációja "szigorú platformkorlátozásnak" nevezi.
• Google Workspace - Google Workspace: A dátumok elromlanak. Domain-váltások, tenant-konszolidációk, felvásárlási fúziók, a cél Google tenant mindig a migrációs dátummal pecsételi a bejövő üzeneteket.
• Helyi Exchange - Microsoft 365: IMAP-útvonalon általában elromlik. Ha a CloudM EWS-t használ mindkét oldalon, a dátummegőrzés megbízhatóbb, de nem garantált.
• Általános IMAP forrás - bármely cél: A dátumok elromlanak. Amikor a CloudM általános IMAP-szerverhez csatlakozik forrásként, a cél akkor is hozzáadja a saját kézbesítési fejléceit.

A nehéz rész? A CloudM migrációs irányítópultja semmit sem jelez ezekből. A haladásjelző megtelik, az állapotoszlop "Completed"-et mutat, az elemszámok egyeznek. A CloudM szemszögéből a migráció sikeres volt. Technikailag igen. Az üzenetek átkerültek. A dátumok egyszerűen nem élték túl az utat.

CloudM Managed vs. Self-Service: ugyanaz a dátumprobléma

A CloudM két üzembe helyezési modellt kínál. A SaaS verzió (hosztolt CloudM Migrate) teljes egészében a CloudM infrastruktúrájában fut. A self-hosted verzió lehetővé teszi elsődleges és másodlagos migrációs szerverek telepítését saját hálózaton, Google Cloud-on, Azure-on vagy AWS-en.

Egyes MSP-k feltételezik, hogy a self-hosted opció nagyobb kontrollt ad a dátumkezelés felett, mivel közvetlenül kezelik a migrációs szervereket. Nem ad. A dátumprobléma a célszerveren történik, nem a CloudM feldolgozó csomópontjain. Akár a CloudM felhőjében, akár saját Azure VM-en fut a migrációs farm, a cél levelezőszerver a migráció dátumával pecsételi minden fogadott üzenetet.

A CloudM teljesen menedzselt "Serviced Migration"-t is kínál, ahol csapatuk kezeli a projektet az elejétől a végéig. Ugyanaz az eredmény a dátumok tekintetében. A mérnöki munka azonos, csak a billentyűzeten lévő kezek mások.

Az érvénytelen Date fejléc bonyodalma

Van még egy CloudM-specifikus viselkedés, ami rontja a helyzetet. Amikor a CloudM olyan forrás e-mailt talál, amelynek Date: fejléce nem felel meg az RFC 822-nek (hibás időzóna-formátum, hiányzó hét napja, nem szabványos formátum), módosítja a fejlécet, hogy biztosítsa az üzenet migrálhatóságát.

Ez azt jelenti, hogy egyes e-mailek még az eredeti dátum-hivatkozásukat is elveszítik. A módosított Date: fejléc egyáltalán nem feltétlenül egyezik a valódi küldési dátummal. A CloudM támogatási dokumentációja ismert viselkedésként említi a "Possible Changes to Migrated Items" rész alatt, de nem határozza meg, mivé válik a módosított dátum.

Egy nyolc éven át gyűjtött 12 000 üzenetes postaládában akár több száz e-mail is lehet enyhén nem szabványos Date fejlécekkel. A CloudM módosítása plusz a célszerver Received fejléc felülírása után ezek az üzenetek a valósággal semmi közöset nem mutató dátumokkal végzik.

Miért nem skálázódnak a kézi javítások CloudM után

Meg lehetne javítani saját erőből? Technikailag az eredeti Date: fejléc a legtöbb üzenetben továbbra is beágyazva van (kivéve azokat, amelyeket a CloudM RFC-kompatibilitás érdekében módosított). Egyes rendszergazdák megpróbáltak szkripteket írni a dátumok javítására CloudM migráció után.

Ennek a megközelítésnek a valósága: potenciálisan több ezer postaládához kell csatlakozni, mindegyikben több ezer üzenettel. Minden e-mailnél elemezni kell a teljes fejlécláncot, azonosítani melyik Received: fejléceket adta hozzá a CloudM vagy a célszerver, kezelni kell a szélsőséges eseteket (S/MIME aláírt üzenetek ahol a fejléc módosítás megtöri az aláírást, PGP titkosított tartalom, beágyazott határokkal rendelkező többrészes MIME struktúrák, RFC 2047 kódolású nem-ASCII fejlécek japán vagy koreai feladóktól), és mindezt egyetlen melléklet elvesztése vagy e-mail szálak megszakítása nélkül.

Egy 50 teszt e-mailen működő szkript nem éli túl a találkozást egy évtizedet átfogó 40 000 üzenetes termelési környezettel. Mi történik, amikor egy 47 MB-os, hat beágyazott melléklettel rendelkező e-mailre bukkan? Mi a helyzet az API korlátozásokkal (a Google 250 kvótaegysége felhasználónként másodpercenként, a Microsoft throttling-ja 10 000 kérésnél 10 percenként)? Mi a visszagörgetési terv, ha valami rosszul sül el a 8 347. üzenetnél?

CloudM migrációs dátumok javítása a Redate.io segítségével

A Redate.io közvetlenül csatlakozik az érintett postaládákhoz (Google Workspace, Microsoft 365 vagy IMAP) és megkeresi a CloudM migrációs dátum-aláírását viselő e-maileket. A vizsgálat ingyenes és postaládánként pár percet vesz igénybe, megmutatva az érintett üzenetek pontos számát bármilyen kötelezettségvállalás előtt.

A javítás egy szabadalmazott fejléclánc-elemző motort használ, amely azonosítja a CloudM-specifikus migrációs mintákat a Received fejlécláncban. A Redate.io célzott metaadat-korrekciót végez az üzenettartalom módosítása nélkül, megőrizve a mellékleteket, szálakat, címkéket, mappákat és digitális aláírásokat. Minden javított üzenet egyedi ellenőrzésen megy át, összevetve az eredeti integritásával.

Az eredeti e-mailek egy látható Redate.io - Originals biztonsági mentési mappában maradnak 30 napig. Ha bármit vissza kell görgetni, az eredetik ott vannak a postaládában.

A CloudM-et ügyfélkörnyezetekben használó MSP-k számára a Redate.io kezeli a többszörös postaláda-javításokat, ugyanazzal az üzenetenkénti ellenőrzéssel, akár 1, akár 500 postaládát javítunk.

Platformspecifikus útmutatók CloudM migrációkhoz

A javítási folyamat a célplatformhoz igazodik. A Redate.io automatikusan kezeli az egyes platformok sajátosságait, de a beállítás részleteiért:

• CloudM migrációs dátumok javítása Gmailben
• CloudM migrációs dátumok javítása Outlookben
• CloudM migrációs dátumok javítása Google Workspace-ben
• CloudM migrációs dátumok javítása Microsoft 365-ben

Annak mélyebb magyarázatáért, hogy miért történik ez minden migrációs eszközzel (nem csak a CloudM-mel), lásd miért mutatnak hibás dátumot az e-mailek migráció után.

CloudM-mel migrált és hibás dátumokkal maradt minden e-mailen? Indítson ingyenes vizsgálatot, hogy megtudja, hány üzenet érintett és mennyibe kerül a javítás.