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. Tā ir sagaidāma, bet slikti dokumentēta, jebkuras IMAP migrācijas uz Exchange Online uzvedība, 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 bojā 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, saņemot katru ziņojumu, ģenerē jaunu galveni Received: un pievieno to ziņojuma sākumā. Šī galvene satur precīzu ievietošanas datumu un laiku, tas ir, migrācijas datumu. Daži migrācijas rīki mēģina saglabāt sākotnējo INTERNALDATE, nododot to kā parametru APPEND komandai. Citi to nedara vai dara nepareizi, un tādā gadījumā Exchange Online automātiski piešķir saņemšanas 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, problēma galvenokārt skar migrācijas uz serveriem, kas sistemātiski pievieno galveni Received: katram ienākošajam ziņojumam, kas ir tieši Exchange Online uzvedība. Pat ja Zoho Migration Wizard nodod sākotnējo datumu, izmantojot APPEND parametru, Exchange Online ģenerētā galvene Received: nonāk pirmajā vietā galveņu ķēdē, un Outlook to izmanto, lai noteiktu, "kad e-pasts ieradās".

Administratori, kas izmanto IMAP rīkus, piemēram, imapsync, lai atstātu Zoho, saskaras ar tieši tādu pašu problēmu, dažreiz vēl sliktāku, jo imapsync noklusējuma konfigurācija nav optimizēta Exchange Online. (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, izmantojot Microsoft Graph, 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 jūsu Microsoft 365 nomniekam, izmantojot standarta Azure AD atļaujas, bez globāla administratora piekļuves. 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 patentētu korekcijas dzinēju, kas analizē katras ziņojuma pilno galveņu ķēdi, identificē Zoho migrācijas rīku specifiskos parakstus (gan Zoho Migration Wizard, gan imapsync, kas konfigurēts Zoho migrācijai), 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. Oriģināli tiek saglabāti pieejamā dublēšanas mapē 30 dienas.

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: Exchange ģenerētā galvene Received: pārraksta INTERNALDATE 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 ceļveži 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, kāpēc tās nav pietiekamas, lai izvairītos no problēmas Exchange Online gadījumā.

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.