Nepareizi e-pastu datumi pēc migrācijas uz Exchange Online

Klasiskais pirmdienas rīta scenārijs

Tikko esat pabeidzis IMAP migrāciju uz Exchange Online. Batch process noslēdzās bez kļūdām Exchange administrācijas centrā, pastkastes ir sinhronizētas, lietotāji var pieslēgties. Piektdienas vakarā aizverat datoru ar sajūtu, ka darbs ir paveikts.

Pirmdienas rītā sākas biļetes. "Visi mani e-pasti ir ar piektdienas datumu." "Mans iesūtnes vēsture ir nelietojams." "Trūkst vecāku e-pastu." Patiesībā nekas netrūkst: e-pasti ir tur, bet Outlook tos visus rāda ar migrācijas datumu, nevis oriģinālo nosūtīšanas datumu. E-pasts no 2019. gada parādās kā datēts pagājušajā piektdienā. Rezultāts: visa pastkaste šķiet saturot tikai jaunus ziņojumus.

Tas ir viens no visvairāk kaitinošajiem IMAP migrācijas uz Exchange Online problēmjautājumiem, un Microsoft to gandrīz sistemātiski nepietiekami dokumentē.

Kāpēc EAC migrācija sabojā datumus

Kad izmantojat Exchange administrācijas centru (EAC), lai konfigurētu IMAP migrāciju no lokālā servera (Dovecot, Courier, Cyrus, UW-IMAP vai cita), Exchange Online pieslēdzas jūsu avota serverim caur IMAP, izgūst ziņojumus un tos injicē mērķa pastkastēs caur savu iekšējo transporta cauruļvadu.

Tieši tur rodas problēma.

Katrs e-pasts, kas iziet caur Exchange transporta cauruļvadu, automātiski saņem ar laika zīmogu versētu Received: galveni. Tas ir standarta SMTP un IMAP serveru uzvedība jau gadu desmitiem: katrs serveris, kas pieskaras ziņojumam, tam pievieno savu laika parakstu. Problēma ir tā, ka Outlook (jo īpaši Outlook for Windows jaunākajās versijās) izmanto jaunāko Received: galveni kā attēlošanas atsauci, kad citi metadati ir neviennozīmīgi.

Oriģinālā Date: galvene (tā, kas norāda, kad e-pasts tiešām tika nosūtīts, RFC 2822 izpratnē, kā paskaidrots šajā rakstā par nepareiziem datumiem pēc migrācijas) joprojām ir ziņojumā. Tā nav dzēsta. Taču to "aizēno" jaunā Received: galvene, ko Exchange pievienoja injicēšanas laikā.

Paralēli IMAP INTERNALDATE (metadati, ko IMAP serveri izmanto ziņojumu iekšējai datēšanai un kas pārvalda kārtošanu vairumā klientu) tiek iestatīts uz injicēšanas datumu, nevis uz e-pasta oriģinālo datumu. Exchange Online nav nekāda vietējā mehānisma, lai saglabātu avota servera INTERNALDATE batch migrācijas laikā caur EAC.

EAC un trešo pušu rīki: svarīga atšķirība

Jāizšķir divas situācijas. Ar tādiem rīkiem kā BitTitan MigrationWiz vai CloudM Migrate problēma arī pastāv, taču šiem rīkiem dažkārt ir konfigurācijas opcijas (daļēji dokumentētas, bieži vien paslēptas papildus iestatījumos), kas mēģina saglabāt dažus datuma metadatus.

Vietējā migrācija caur EAC nepiedāvā nekādas šādas opcijas. Microsoft nepakļauj nevienu parametru INTERNALDATE saglabāšanas kontrolei batch migrācijas cauruļvadā. Tas ir melnais kaste: jūs konfigurējat batch, palaidat to, un Exchange iekšēji dara, ko grib. Un tas, ko tas sistemātiski dara, ir datēt ziņojumus ar to injicēšanas datumu.

(Starp citu, ja esat kādreiz mēģinājis lasīt neapstrādātas migrēta e-pasta galvenes caur EAC, jūs zināt, ka Exchange pievienotais Received: lauks ir uzreiz atpazīstams: tas satur atsauces uz Microsoft iekšējiem serveriem, piemēram, *.protection.outlook.com vai *.prod.exchangelabs.com, ar laika zīmogu, kas precīzi atbilst migrācijas logam.)

Kāpēc batch atkārtota izveide neko neatrisina

Daudzu IT administratoru instinktīvā reakcija uz šo problēmu ir domāt: "Ja dzēsīšu migrētās pastkastes un no jauna palaidīšu batch, varbūt šoreiz datumi būs pareizi."

Tas ir saprotami. Bet tas nedarbojas.

Problēma nav batch konfigurācijā. Tā nav kādā parametrā, ko aizmirstu atzīmēt. Tā ir paša Exchange transporta cauruļvada arhitektūrā, kas ir identiska katrā migrācijā. Batch atkārtota palaišana dos tieši tādu pašu rezultātu: tās pašas Received: galvenes ar jauno migrācijas datumu un tos pašus nepareizos INTERNALDATE. Jūs būsiet zaudējis laiku, un lietotāji tikuši traucēti otro reizi bez rezultāta.

Daži administratori mēģina arī mainīt kārtošanas parametrus Outlook ("kārtot pēc nosūtīšanas datuma" nevis "saņemšanas datuma"). Kārtošana pēc nosūtīšanas datuma nav risinājums. Tas ir plāksteris. Date: galvene un INTERNALDATE joprojām ir nepareizi klientiem, kas nepieļauj šo iestatījumu, kā arī OWA, Outlook Mobile un jebkurai trešo pušu lietotnei, kas piekļūst pastkastei caur IMAP vai EWS.

Kas patiesībā notiek galvenēs

Lūk, vienkāršots piemērs tam, ko satur e-pasts pēc migrācijas caur EAC. Oriģinālā galvene:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@vecaisdomens.lv
Subject: Q1 2019 atskaite

Pēc migrācijas ziņojums ķēdes sākumā saņem kaut ko līdzīgu:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook redz šo Received: galveni pirmā (tā tiek pievienota galveņu bloka augšdaļā), interpretē to kā jaunāko ziņojuma apstrādes datumu un parāda to kā saņemšanas datumu. Oriģinālā Date: galvene no 2019. gada joprojām ir tur, neskarta, dažas rindas zemāk. Taču Outlook to neizmanto attēlošanai ziņojumu sarakstā.

Precizitātes labad: uzvedība nedaudz atšķiras atkarībā no Outlook versijas. Post-2021 versijas (un jo īpaši jaunais Outlook for Windows, kas tiek izvietots kopš 2023. gada beigām) ir īpaši jutīgas pret šo problēmu, jo vairāk paļaujas uz Exchange Graph metadatiem nekā uz neapstrādāto Date: galveni. Tas nozīmē, ka migrācijas, kas ar Outlook 2016 neradīja redzamas problēmas, tagad var radīt problēmas ar jauno Outlook.

Uz ko tas īsti attiecas

Visizplatītākie IMAP avota serveri šāda veida migrācijās ir Dovecot (ļoti izplatīts Linux/cPanel vidēs) un Courier. Abi eksponē INTERNALDATE caur IMAP, ko EAC nesaglabā. Ja migrējat no lokālā Exchange servera uz Exchange Online (hibrīdā vai cutover migrācija), uzvedība ir atšķirīga, jo Microsoft izmanto iekšējo transporta protokolu (MAPI/EWS), kas labāk saglabā metadatus. Tieši ģeneriskā IMAP migrācija caur EAC rada problēmu.

Visvairāk cietušie lietotāji ir tie, kuriem ir pastkastes ar garu vēsturi (5 gadi un vairāk) un lielu ziņojumu apjomu. Lietotājs ar 300 e-pastiem pastkastē ātri tiks galā. Komercdiektors ar 12 000 e-pastiem, kas sakārtoti pēc datuma un no kuriem viņš ikdienā ir atkarīgs, lai atrastu klientu saraksti, ir pilnīgi paralizēts.

Kāpēc pašdarināts skripts šeit ir slikta ideja

Daži IT administratori, kas saprot tehnisko problēmu, ir kārdinājumā rakstīt PowerShell vai Python skriptu, lai manuāli labotu galvenes. Pamatjēdziens var šķist vienkāršs, kad mehānisms ir identificēts. Taču korekcija ražošanā ir pavisam cita lieta.

Pirmkārt, robežgadījumi. S/MIME parakstītiem e-pastiem un PGP šifrētiem ziņojumiem ir struktūra, kas nepieļauj galveņu modificēšanu bez paraksta atzīšanu par nederīgu. Multipart/alternative ziņojumi ar nepareizi veidotām MIME robežām (bieži sastopami uz veciem Courier serveriem) var tikt sabojāti ar skriptu, kas modificē ziņojumu, nepareizi atjaunojot struktūru. RFC 2047 kodētas ne-ASCII galvenes (sūtītāju vārdi ar garumzīmēm vai japāņu rakstzīmēm, piemēram) ir klasiska kļūdu avots.

Otrkārt, apjoms. Skripts, kas darbojas ar 50 testa e-pastiem izstrādes vidē, netiek galā ar Exchange Online API ātruma ierobežojumiem ražošanā. Kļūda 429 Too Many Requests pulksten 2 naktī 8 000 ziņojumu batch laikā bez atkopšanas mehānisma nozīmē bezmiegu un potenciāli dublikātus vai zaudētus ziņojumus.

Un pats galvenais: kā pārbaudīt, vai katrs labotais e-pasts ir neskarts? Ka neviens pielikums nav saīsināts, ka neviens diskusiju pavediens nav salūzis, ka etiķetes un mapes ir saglabātas? Bez individuāla validācijas mehānisma var tikai cerēt, ka viss ir izgājis labi.

Datumu labošana pēc migrācijas ir problēma, kas izskatās pēc 50 rindu skripta, bet prasa tūkstošus rindu, lai darbotos uzticami ražošanā.

Ko Redate.io dara savādāk

Redate.io pieslēdzas Exchange Online caur Microsoft 365 API (Azure Active Directory, deleģēšanas atļaujas tenant līmenī) un skenē attiecīgās pastkastes, lai identificētu e-pastus, kuru datuma metadati tika bojāti migrācijas laikā. Šī skenēšanas darbība ir bezmaksas un sniedz precīzu priekšstatu par problēmas apjomu: ietekmēto ziņojumu skaits, attiecīgās pastkastes, bojāto datumu diapazons.

Redate.io patentētais korekcijas dzinējs pēc tam apstrādā katru e-pastu individuāli caur daudzpakāpju analīzes cauruļvadu, kas ietver modeļu saskaņošanu ar zināmu migrācijas rīku parakstiem (tostarp Exchange Online transporta cauruļvadu), RFC atbilstības validāciju un ziņojuma strukturālas integritātes pārbaudi pirms un pēc korekcijas. S/MIME parakstīti e-pasti, sarežģītas MIME struktūras, nestandarta kodējumi: visi tiek apstrādāti ar specifiskiem apstrādes ceļiem.

Katrs labotais ziņojums tiek pārbaudīts individuāli. Oriģināli tiek saglabāti redzamā rezerves mapē 30 dienas. Ja ar konkrētu ziņojumu kaut kas nav kārtībā, tas netiek modificēts: Redate.io ziņo par anomāliju, nevis riskē ar bojāšanu.

Cenas ir balstītas uz apjomu, ar vienreizēju maksājumu par pastkasti. Nav abonēšanas, nav atkārtotu maksu. Jūs labojat problēmu vienu reizi un tas ir pabeigts.

Tieši Exchange Online migrācijām Redate.io atbalsta pieslēgšanos caur Azure AD lietojumprogrammu atļaujām (bez nepieciešamības izveidot individuālos akreditācijas datus katrai pastkastei), kas ievērojami vienkāršo lielu pastkašu grupu apstrādes koordinēšanu IT administratoram vai MSP.

Ja pārvaldāt vairākus klientus, kas ir piedzīvojuši šāda veida migrāciju, iepazīstieties arī ar pilnīgo ceļvedi par datumu labošanu pēc Microsoft 365 migrācijas, lai iegūtu pārskatu par dažādiem aptvertajiem scenārijiem.

E-pasti ir tur, oriģinālie datumi arī. Palaidiet bezmaksas skenēšanu Redate.io, lai redzētu tieši, cik ziņojumu ir ietekmēti jūsu Exchange Online pastkastēs, pirms izlemjat, ko darīt.