Hibás e-mail-dátumok Zoho-ból Microsoft 365-be való migráció után

Mi történt a postafiókjával

Éppen befejezte a domain migrálását a Zoho Mailből a Microsoft 365-be. Az Exchange Online be van állítva, a postafiókok létre vannak hozva, az MX-rekordok frissítve vannak. Aztán hétfő reggel egy felhasználó megnyitja az Outlookot, és azt látja, hogy minden 2021-es e-mailen a mai dátum szerepel. Egy másik felhasználó a tavalyi üzeneteket a Beérkezett üzenetek mappa tetején látja, mintha éppen most érkeztek volna. Elindulnak a hibajegyek.

Ez nem Outlook-hiba. Nem is Zoho-specifikus probléma. Ez akkor történik, amikor a migrációs eszköz nem adja át az egyes e-mailek eredeti dátumát. A pontos ok megértése az első lépés a helyes javításhoz.

A technikai gyökérok: az INTERNALDATE és a Received fejlécek

Az IMAP-szerveren tárolt e-mail két különálló részből áll: a nyers üzenettartalomból (RFC 2822 fejlécek, szövegtörzs, mellékletek) és az IMAP-szerver által kezelt tárolási metaadatokból, amelyek közé az INTERNALDATE is tartozik. A levelezőprogramok valójában ezt a metaadatot használják az üzenetek megjelenítéséhez és rendezéséhez.

A nyers üzenetbe ágyazott Date: fejléc (RFC 2822) azt jelzi, mikor írta vagy küldte az üzenetet a feladó. Az INTERNALDATE azt jelzi, mikor fogadta vagy tárolta az üzenetet az IMAP-szerver. Egy egészséges szerveren ez a két érték közel van egymáshoz. Egy migráció után ez egészen más történet.

Hogyan ronthatja el a dátumokat egy IMAP-migráció

Amikor egy migrációs eszköz (a Zoho Migration Wizard, az imapsync, a BitTitan vagy bármi más) átvisz egy üzenetet a Zoho Mailből az Exchange Online-ba, ezt az IMAP-protokollon keresztül teszi. Az eszköz csatlakozik a Zoho-hoz, letölti az üzenetet, majd beszúrja az Exchange Online-ba. És itt kezdődik a baj.

Az Exchange Online megtartja a kapott dátumot: ha az eszköz az APPEND paranccsal átadja az egyes üzenetek eredeti INTERNALDATE-jét, a másolat megtartja azt. Egyes migrációs eszközök megteszik ezt. Mások nem, vagy hibásan teszik, és ebben az esetben az Exchange Online a beillesztés pillanatát, azaz a migráció dátumát rendeli hozzá INTERNALDATE-ként.

Az eredmény: akár 2019-ben, akár 2022-ben küldték az e-mailt, az INTERNALDATE most a migráció hetére mutat. Az Outlook ezt az értéket olvassa be elsőként. A rendezés összeomlik.

Hogyan viselkedik konkrétan a Zoho Migration Wizard

A Zoho saját migrációs eszközt kínál a platform elhagyásához: a Zoho Migration Wizardot. Egyszerű migrációkhoz praktikus, de az adminisztrátori fórumokon dokumentált egy viselkedése: nem mindig adja át helyesen az eredeti INTERNALDATE-t a célszerverre történő beillesztéskor.

Pontosabban: amikor a Zoho Migration Wizard valóban átadja az eredeti dátumot, az Exchange Online megtartja azt, és az Outlook a helyes dátumot mutatja. Azok az e-mailek jelennek meg a migráció dátumával, amelyeknek a dátumát nem adta át az eszköz.

Azok a rendszergazdák, akik általános IMAP-eszközöket, mint az imapsync, használnak a Zoho elhagyásához, ugyanezzel a problémával találkozhatnak: az imapsync a forrásszerveren tárolt dátumot másolja át az egyes üzenetekhez, így egy forrásoldali hibás dátumból a célon is hibás dátum lesz. (Aki már bogarászott imapsync-naplóban hajnali kettőkor egy szinkronizálási hiba után, tudja, hogy ez egy erős eszköz, amely nem különösebben megbocsátó a szélsőséges esetekkel szemben.)

Miért mutat rossz dátumot az Outlook

Az Outlook nem csak a Date: fejlécre támaszkodik egy e-mail dátumának megjelenítésekor. A legtöbb nézetben az IMAP/Exchange szerver által megadott INTERNALDATE vezérli a postafiókban a rendezést. Az eredeti Date: fejléc továbbra is jelen van az üzenetben, sértetlenül, de az INTERNALDATE javára figyelmen kívül marad.

Ezért nem old meg valójában semmit, ha az Outlookban átkapcsol a "Rendezés küldés dátuma szerint" beállításra. Más értéket mutat, ez igaz, de a rendezési viselkedés instabil marad, az Outlook-verziótól és a nézetmódtól függően (csoportosított beszélgetések, vagy nem). A küldés dátuma szerinti rendezés nem javítás. Ez egy ragtapasz, amely leesik a következő kliensfrissítés után.

A probléma valódi mérete

Egy közepes méretű, Zoho Mailről Microsoft 365-be történő migráció esetén könnyen 50 000 és 500 000 közötti érintett üzenetről van szó, attól függően, hogy milyen régiek a postafiókok és mekkora a szervezet. A migrációs időszak alatt átvitt minden e-mail ugyanazt a hibás dátumot viseli, ami a problémát azonnal láthatóvá teszi a felhasználók számára, amint megnyitják az Outlookot.

Az Elküldött elemek mappák gyakran a legrosszabbak. Egy értékesítő, aki egy 2022 márciusában küldött árajánlatot keres, több száz e-mailen kell átrágnia magát, amelyek mind a migráció dátumát mutatják. A működési hatás valódi, nem csak esztétikai.

És azzal szemben, amit remélne, a probléma nem enyészik el idővel. Az INTERNALDATE a beillesztés pillanatában rögzül. Nem javítja ki magát. Aktív beavatkozás nélkül ezek az e-mailek a végtelenségig megtartják a hibás dátumukat.

Miért kockázatosabb ezt saját kezűleg megjavítani, mint amilyennek látszik

A kísértés érthető: mivel az eredeti Date: fejléc még ott van az üzenetben, csak ki kellene... javítani a metaadatokat. Logikusan ez összeáll. A gyakorlatban, egy 80 000 e-mailt tartalmazó éles postafiókon, ez egy olyan művelet, amely katasztrofálisan félresiklhat.

Néhány szélsőséges eset, amelyet egy házilag írt szkript valószínűleg nem kezel jól:

• S/MIME-mel aláírt e-mailek, ahol az aláírás a teljes fejlécstruktúrát lefedi. Az üzenet bármely módosítása érvényteleníti a kriptográfiai aláírást.
• PGP-vel titkosított üzenetek, ahol a tartalom átláthatatlan, és a MIME-borítékok bármilyen manipulálása megrongálhatja az üzenetet.
• RFC 2047 szerint kódolt, nem ASCII fejlécek (speciális karaktereket tartalmazó feladónevek), amelyek elromlanak, ha a szkript nem kezeli helyesen a kódolást.
• Base64-kódolt mellékletek hibás sortöréssel, nem szabványos MIME-határolókkal vagy egymásba ágyazott multipart-struktúrákkal.
• Érvényes Date: fejléc nélküli e-mailek (ilyenek léteznek, különösen a régebbi Zoho-exportokban), ahol a szkriptnek döntenie kell, mit tegyen.

Egy szkript, amely 50 teszt e-mailen működik, nem fog működni egy éveket felölelő éles Zoho-postafiókon. És hogyan ellenőrzi, üzenetről üzenetre, hogy minden javított e-mail sértetlen, és hogy semmilyen melléklet nem csonkult? Az ellenőrzés legalább annyira összetett, mint a javítás maga.

Ott van a kvótaprobléma is. Az Exchange Online API, a Microsoft Graph-on keresztül, szigorú sebességkorlátokat érvényesít (a klasszikus 429 Too Many Requests hiba). Egy 100 000 üzenet feletti, korlátozás nélküli batch átmeneti blokkolást vagy néma hibákat válthat ki, amelyeket utólag majdnem lehetetlen diagnosztizálni. Megfelelő újrapróbálkozási mechanizmus nélkül elölről kell kezdenie az egészet.

Hogyan javítja ki a Redate.io a dátumokat egy Zoho-migráció után

A Redate.io a saját Microsoft-fiókjával történő bejelentkezés pillanatában csatlakozik a Microsoft 365-postafiókjához, nincs szükség regisztrált Azure-alkalmazásra, és nincs szükség előzetesen beállított rendszergazdai jóváhagyási lépésre. A kezdeti átvizsgálás ingyenes: a Redate.io azonosítja az érintett postafiókokat, és megbecsüli a hibás dátumú e-mailek mennyiségét, összehasonlítva az INTERNALDATE-et az üzenet fejléclánca által hordozott értékekkel.

A javítás egy saját fejlesztésű motort használ, amely elemzi az egyes üzenetek teljes fejlécláncát, nem kell tudnia, melyik eszköz végezte a migrációt (Zoho Migration Wizard, imapsync vagy bármi más), és egy többlépcsős ellenőrzési folyamaton keresztül állítja helyre a dátum-metaadatokat. Minden javított e-mail egyedi ellenőrzésen megy át: a tartalom sértetlensége, a mellékletek megőrzése, az RFC-megfelelőség. Az eredetik az Ön saját postafiókjának egy látható mappájában maradnak, amíg Ön maga nem törli őket.

Nincs újramigrálás. Nincs leállás. A felhasználók tovább dolgozhatnak az Outlookban, amíg a javítás a háttérben zajlik.

A részletek közvetlenül a weboldalon elérhetők.

Kapcsolódó forgatókönyvek, amelyeket érdemes ismerni

Ha egyszerre több migrációt kezel, vagy MSP-ként Zohót elhagyó ügyfeleket kezel, vegye figyelembe, hogy ugyanez a probléma más platformokról az Exchange Online-ba történő migrálás esetén is előfordul. A mechanizmus azonos: a másolat azt a dátumot kapja, amelyet az eszköz átad, függetlenül a forrástól.

A Google Workspace-ből, helyszíni Exchange-ből vagy olyan eszközökön keresztül történő migrációkhoz, mint a BitTitan MigrationWiz vagy a CloudM, a Redate.io blogján külön cikkek foglalkoznak az egyes eszközök konkrét viselkedésével. A Hibás e-mail-dátumok Exchange Online-migráció után cikk teljes áttekintést ad minden olyan forgatókönyvről, amely ehhez a bérlőhöz vezet.

Ha a migráció megosztott postafiókokat vagy Exchange-erőforrásokat (termek, eszközök) is tartalmaz, a probléma ugyanaz, és ugyanazok a javítóeszközök alkalmazhatók. A Redate.io oldalán található Exchange IMAP-migrációs dátumok javítása útmutatók végigvezetik a bérlőhöz való csatlakozás lépésein.

Azoknak a csapatoknak, amelyek konkrétan az imapsyncet használják a Zoho elhagyásához, az imapsync: a dátumok nem őrződtek meg útmutató dokumentálja az imapsync konfigurációs beállításait, és azt, hogy a hibás dátumok valójában honnan erednek.

Még mindig a Zoho-migráció dátumait látja az Outlookban? Vizsgálja át ingyenesen postafiókjait a Redate.io oldalán, hogy pontosan felmérje a probléma méretét, mielőtt eldönti, hogyan lépjen tovább.