Nepareizi e-pastu datumi pēc Zoho migrācijas uz Microsoft 365

Kas notika ar jūsu pastkasti

Jūs tikko pabeidzāt sava domēna migrāciju no Zoho Mail uz Microsoft 365. Exchange Online infrastruktūra ir iestatīta, pastkastes ir izveidotas, MX ieraksti ir atjaunināti. Un tad, pirmdien no rīta, lietotājs atver Outlook un pamana, ka visi viņa 2021. gada e-pasti rāda šodienas datumu. Cits konstatē, ka pagājušā gada ziņojumi ir sakārtoti iesūtnes augšā, it kā tikko būtu ieradušies. Sāk pienākt pieteikumi.

Tas nav Outlook kļūda. Tas nav arī Zoho specifiska problēma. Tas notiek tad, kad migrācijas rīks nenodod katra e-pasta sākotnējo datumu, un precīza izpratne par to, kāpēc tā notiek, ir pirmais solis, lai to pareizi labotu.

Tehniskais cēlonis: INTERNALDATE un Received galvenes

E-pasts, kas glabājas IMAP serverī, sastāv no divām atsevišķām daļām: ziņojuma neapstrādātā satura (RFC 2822 galvenes, pamatteksts, pielikumi) un servera pārvaldītajiem glabāšanas metadatiem, tostarp INTERNALDATE. Tieši šo metadatu e-pasta klienti izmanto ziņojumu attēlošanai un kārtošanai.

Galvene Date:, kas definēta neapstrādātajā ziņojumā (RFC 2822), norāda datumu, kad ziņojums tika sarakstīts vai nosūtīts sūtītāja pusē. INTERNALDATE savukārt ir datums, kad IMAP serveris ziņojumu saņēma vai saglabāja. Parasti veselīgā serverī šīs divas vērtības ir tuvas. Pēc migrācijas situācija ir pavisam citāda.

Kā IMAP migrācija var bojāt datumus

Kad migrācijas rīks (Zoho Migration Wizard, imapsync, BitTitan vai jebkurš cits) pārsūta ziņojumu no Zoho Mail uz Exchange Online, tas to dara, izmantojot IMAP protokolu. Rīks pieslēdzas Zoho, izgūst ziņojumu un pēc tam to ievieto Exchange Online, izmantojot komandu IMAP APPEND. Un tieši šeit sākas problēmas.

Exchange Online saglabā to datumu, kas tam ir nodots: kad rīks nodod katra ziņojuma sākotnējo INTERNALDATE ar APPEND komandu, kopija to saglabā. Daži migrācijas rīki to dara. Citi to nedara vai dara nepareizi, un tādā gadījumā Exchange Online piešķir ievietošanas brīdi, tas ir, migrācijas datumu, kā INTERNALDATE.

Rezultāts: neatkarīgi no tā, vai e-pasts tika nosūtīts 2019. vai 2022. gadā, tā INTERNALDATE tagad norāda uz migrācijas nedēļu. Outlook šo vērtību lasa ar prioritāti. Kārtošana sabrūk.

Zoho Migration Wizard specifiskā uzvedība

Zoho piedāvā savu migrācijas rīku platformas atstāšanai: Zoho Migration Wizard. Šis rīks ir ērts vienkāršām migrācijām, taču tam ir dokumentēta uzvedība administratoru forumos: tas ne vienmēr pareizi nodod sākotnējo INTERNALDATE ievietošanas laikā mērķa serverī.

Precīzāk sakot: kad Zoho Migration Wizard nodod sākotnējo datumu, Exchange Online to saglabā, un Outlook rāda pareizo datumu. E-pasti, kas rāda migrācijas datumu, ir tie, kuru datums netika nodots.

Administratori, kas izmanto IMAP rīkus, piemēram, imapsync, lai atstātu Zoho, var saskarties ar tādu pašu problēmu: imapsync kopē datumu, ko avota serveris glabā katram ziņojumam, tāpēc nepareizs datums avotā kļūst par nepareizu datumu galamērķī. (Starp citu, ja esat kādreiz pārskatījuši imapsync žurnālu rindiņu pa rindiņai, meklējot sinhronizācijas kļūdu pulksten divos naktī, jūs zināt, ka tas ir jaudīgs rīks, bet ne īpaši piedodošs malu gadījumos.)

Kāpēc Outlook rāda nepareizu datumu

Outlook neizmanto tikai galveni Date:, lai attēlotu e-pasta datumu. Lielākajā daļā skatu tiek izmantots INTERNALDATE, ko nodrošina IMAP/Exchange serveris, īpaši iesūtnes kārtošanai. Sākotnējā galvene Date: ziņojumā joprojām ir klātesoša un neskarta, taču tā tiek ignorēta par labu INTERNALDATE.

Tāpēc opcija "Kārtot pēc nosūtīšanas datuma" Outlook programmā problēmu patiesībā neatrisina. Tā rāda citu datumu, jā, taču kārtošanas uzvedība joprojām ir nestabila atkarībā no Outlook versijas un skata režīma (grupētās sarunas vai nē). Kārtošana pēc nosūtīšanas datuma nav risinājums. Tas ir plāksteris, kas nokrīt pie pirmā klienta atjauninājuma.

Reālais problēmas apmērs

Vidēja lieluma Zoho uz Microsoft 365 migrācijā mēs viegli runājam par 50 000 līdz 500 000 skartajiem ziņojumiem, atkarībā no pastkašu vecuma un organizācijas lieluma. Katrs e-pasts, kas pārsūtīts migrācijas logā, nes vienu un to pašu sabojāto datumu, kas padara problēmu lietotājiem tūlīt redzamu pēc pirmās Outlook atvēršanas.

Sūtīto vienumu mapes bieži vien ir visproblemātiskākās. Pārdevējs, kas meklē piedāvājumu, kurš nosūtīts 2022. gada martā, nonāk situācijā, kur pārlaida simtiem e-pastu, kas visi rāda migrācijas datumu. Operacionālā ietekme ir reāla, ne tikai estētiska.

Un pretēji tam, ko varētu domāt, problēma ar laiku nepazūd. INTERNALDATE tiek fiksēts ievietošanas brīdī. Tas pats par sevi neizlabojas. Bez aktīvas iejaukšanās e-pasti uz visiem laikiem saglabās bojāto datumu.

Kāpēc pašrocīga labošana ir riskantāka, nekā šķiet

Kārdinājums ir saprotams: tā kā sākotnējā galvene Date: joprojām atrodas ziņojumā, pietiek tikai... labot metadatus. Teorijā tas ir loģiski. Praksē, 80 000 e-pastu lielas ražošanas pastkastes gadījumā, tā ir darbība, kas var izvērsties katastrofāli.

Šeit ir daži malu gadījumi, kurus mājas skripts visticamāk nepārvaldīs pareizi:

• S/MIME parakstīti e-pasti, kuru paraksts aptver visas galvenes. Jebkura izmaiņa ziņojuma struktūrā padara kriptogrāfisko parakstu nederīgu.
• PGP šifrēti ziņojumi, kur saturs ir necaurspīdīgs un jebkura MIME apvalku apstrāde var sabojāt ziņojumu.
• RFC 2047 kodētas ne-ASCII galvenes (sūtītāju vārdi ar īpašām rakstzīmēm), kas salūzt, ja skripts nepareizi apstrādā kodējumu.
• Pielikumi, kas kodēti base64 ar nepareizi noslēgtām rindām, nestandarta MIME robežām vai ligzdotām multipart struktūrām.
• E-pasti bez derīgas galvenes Date: (tādi pastāv, īpaši vecos Zoho eksportos), kur skriptam ir jāizlemj, ko darīt.

Skripts, kas darbojas uz 50 testa e-pastiem, nedarbosies uz ražošanas pastkasti, kas eksportēta no Zoho ar gadiem ilgu vēsturi. Un kā pārbaudīt, ziņojums pa ziņojumam, ka katra labojuma rezultāts ir neskarts un pielikumi nav apgriezti? Verifikācija ir vismaz tikpat sarežģīta kā pati labošana.

Ir arī kvotu jautājums. Exchange Online API uzliek stingrus ātruma ierobežojumus (slavenās kļūdas 429 Too Many Requests). Neregulēts pakešu apstrādes process uz 100 000 ziņojumiem var izraisīt pagaidu bloķēšanu vai kluso kļūdu, kuras ir grūti diagnosticēt pēc fakta. Bez atkopšanās mehānisma pēc incidenta jūs sākat no sākuma.

Kā Redate.io labo datumus pēc Zoho migrācijas

Redate.io pieslēdzas, kad lietotājs pierakstās ar savu Microsoft kontu, un atver tikai šo pastkasti ar piekļuvi, ko piešķir pierakstīšanās, bez portāla vai lietotnes registrācijas. Sākotnējā skenēšana ir bezmaksas: Redate.io identificē skartās pastkastes un novērtē e-pastu apjomu ar nepareiziem datumiem, salīdzinot INTERNALDATE ar vērtībām, ko nes ziņojuma galveņu ķēde.

Labošana izmanto Redate.io izstrādātu korekcijas dzinēju, kas analizē katras ziņojuma pilno galveņu ķēdi, nenosaka, kurš rīks veica migrāciju (Zoho Migration Wizard, imapsync vai kāds cits), un rekonstruē datuma metadatus, izmantojot daudzpakāpju validācijas cauruļvadu. Katrs labotais e-pasts tiek pārbaudīts individuāli: satura integritāte, pielikumu saglabāšana, RFC atbilstība. Sākotnējie ziņojumi tiek saglabāti redzamā dublēšanas mapē jūsu pastkastē, līdz jūs tos paši izdzēšat.

Nav atkārtotas migrācijas. Nav dīkstāves. Lietotāji turpina izmantot Outlook, kamēr labošana notiek fonā.

Cena ir vienreizējs maksājums, kas balstīts uz apjomu, bez abonēšanas. Sīkāka informācija ir pieejama tieši vietnē.

Saistītie scenāriji, kas jāzina

Ja jūs pārvaldāt vairākas paralēlas migrācijas vai esat MSP un administrējat klientus, kas atstāj Zoho, ņemiet vērā, ka tā pati problēma rodas migrācijās no citām platformām uz Exchange Online. Mehānisms ir identisks: kopija saglabā to datumu, ko nodod rīks, neatkarīgi no avota.

Google Workspace, lokālā Exchange vai tādu rīku kā BitTitan MigrationWiz vai CloudM gadījumā Redate.io bloga speciālie raksti sīki apraksta katram rīkam specifisko uzvedību. Raksts Nepareizi e-pastu datumi pēc migrācijas uz Exchange Online sniedz pārskatu par visiem scenārijiem, kas nonāk šajā nomniekā.

Ja jūsu migrācija ietver koplietotās pastkastes vai Exchange resursus (telpas, aprīkojums), problēma ir tāda pati, un piemērojas tie paši labošanas rīki. IMAP uz Exchange labošanas pamācības Redate.io vietnē sīki apraksta savienojuma darbības ar jūsu nomnieku.

Komandām, kas konkrēti izmanto imapsync Zoho atstāšanai, raksts imapsync nesaglabāja datumus? dokumentē imapsync konfigurācijas opcijas un to, no kurienes patiesībā rodas nepareizie datumi.

Jūsu Zoho migrācijas datumi joprojām tiek rādīti Outlook programmā? Skenējiet savas pastkastes bezmaksas Redate.io vietnē, lai precīzi izmērītu problēmas apmēru, pirms izlemjat, kā rīkoties.