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 mutatják. 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 postafiókja 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 másolat megírásakor történik. A célhely megtartja azt a dátumot, amelyet megkap: a Microsoft 365 és a Gmail megtartja az eredeti dátumot, ha a másolat azt hordozza. Ha nem, a másolat a beillesztés pillanatát kapja dátumként. A Google Workspace-en pedig minden, a Gmail API-n keresztül írt üzenet emellett kap egy friss Received: fejlécet is, amely a beillesztés pillanatával van datálva.

Így néz ki az egyik ilyen e-mail fejléce egy Microsoft 365-be irányuló CloudM migráció után is:

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

A 2019-es eredeti Date: fejléc továbbra is ott van, ahogy az eredeti Received: lánc is. A Microsoft 365-ben azonban a dátum, amelyet az Outlook beérkezettként mutat, a postafiók saját nyilvántartása arról, hogy mikor érkeztek meg az egyes e-mailek: ha a CloudM nem adta tovább az eredeti dátumot, ez a nyilvántartás 2026. április 2-át mond.

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

A CloudM kínál egy beállítást ennek kezelésére. 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.

Úgy hangzik, mintha ez mindent megoldana, igaz? 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 hozzáad egy új Received: fejlécet az API-n keresztül beírt üzenetekhez, 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 ez a beállítás kevésbé fontos: a Microsoft 365 megtartja a kapott dátumot, így a megjelenített dátumot az dönti el, hogy a CloudM továbbadja-e az adott e-mail eredeti dátumát.

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, így minden e-mail a másolat dátumát kapja.
• Microsoft 365 - Google Workspace: A dátumok elromlanak. Még a 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: minden, a Gmail API-n keresztül írt üzenet a migráció dátumával jelölt Received: fejlécet kap.
• Helyi Exchange - Microsoft 365: Minden azon a dátumon múlik, amelyet a CloudM továbbad, attól függetlenül, hogy a másolat IMAP-on vagy EWS-en megy át.
• Általános IMAP forrás - bármely cél: Ugyanaz a szabály: amikor a CloudM egy általános IMAP-szerverhez csatlakozik forrásként, a másolat a migráció dátumát mutatja, ha az eredeti dátum nem kerül át a célhelyre.

A nehéz rész? A CloudM migrációs irányítópultja semmit sem jelez ebbő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 igenis. 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ó (a 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 Cloudon, 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átumot az dönti el, mit ad tovább a migrációs motor minden üzenettel, és ez a motor ugyanaz, bárhol is fut. Akár a CloudM felhőjében, akár a saját Azure VM-jén fut a migrációs farm, az eredmény a dátumok tekintetében ugyanaz.

A CloudM teljesen menedzselt "Serviced Migration"-t is kínál, ahol a 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. Fizetett már prémium szolgáltatásért, és mégis ugyanazzal a korlátozással találkozott, mint az ingyenes csomagban? Ez pontosan ilyen érzés.

Az érvénytelen Date fejléc bonyodalma

Van még egy CloudM-specifikus viselkedés, amely 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 az üzenet migrálható legyen.

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 felgyűlt, 12 000 üzenetes postafióknál akár több száz e-mail is lehet enyhén nem szabványos Date fejlécekkel (különösen a régebbi levelezőszerverekről, automatizált rendszerekből vagy időzóna-formázási sajátosságokkal küldött nemzetközi feladóktól érkező üzenetek). A CloudM módosítása után, plusz egy másolat, amely nem hordozza az eredeti dátumot, ezek az üzenetek a valósággal semmiféle hasonlóságot 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 az RFC-megfelelőség érdekében módosított). Egyes rendszergazdák megpróbáltak szkripteket írni a dátumok javítására egy CloudM migráció után.

Ennek a megközelítésnek a valósága a következő. Potenciálisan több ezer postafiókhoz 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ása 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 az 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 körülbelül 10 000 kérésnél 10 percenként)? Mi a visszagörgetési terv, ha valami rosszul sül el a 8347. üzenetnél?

És a valódi kérdés, amelyet a legtöbb rendszergazda csak akkor tesz fel, amikor már túl késő: hogyan ellenőrzi, hogy minden javított üzenet valóban sértetlen?

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 postafiókokhoz (Google Workspace, Microsoft 365 vagy IMAP), és megkeresi azokat az e-maileket, amelyeknek a megjelenített dátuma nem egyezik az eredeti dátumukkal. Az átvizsgálás ingyenes, és postafiókonként pár percet vesz igénybe, bármilyen kötelezettségvállalás előtt megmutatva az érintett üzenetek pontos számát.

A javítás egy saját fejlesztésű fejléclánc-elemző motort használ, és nem kell tudnia, melyik eszköz végezte a migrációt. A Redate.io célzott metaadat-javítást végez az üzenettartalom módosítása nélkül, megőrizve a mellékleteket, a szálakat, a címkéket, a mappákat és a digitális aláírásokat. Minden javított üzenet egyedi ellenőrzésen megy át, összevetve az eredeti üzenet integritásával, mielőtt a folyamat továbblép.

Az eredeti e-mailek egy látható Redate.io - Originals biztonsági másolat mappában maradnak, amíg Ön maga nem törli. Ha bármit vissza kell állítani, az eredetik ott vannak a postafiókban, nem egy külső archívumban elrejtve.

Azoknak az MSP-knek, akik CloudM-et használtak ügyfélkörnyezetekben, a Redate.io nagy méretekben kezeli a több postafiókot érintő javításokat, ugyanazzal az üzenetenkénti ellenőrzéssel, akár 1, akár 500 postafiókot javít. A CloudM által hátrahagyott dátumprobléma nem kell, hogy az ügyfele levelezési környezetének tartós vonása maradjon.

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 Outlookban
• 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öznél, nem csak a CloudM-nél, 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 átvizsgálást, hogy pontosan megtudja, hány üzenet érintett, és mennyibe kerül a javítás.