iCloud uz Office 365 migrācija: nepareizi e-pastu datumi

Migrācijas scenārijs, kas sistemātiski saboj datumus

Tikko pabeidzāt savas iCloud pastkastes pārsūtīšanu uz Office 365. E-pasti ir tur, mapes ir izveidotas, viss izskatās kārtībā. Pirmdienas rītā pienāk pirmā sūdzība: "Visi mani vecākie e-pasti rāda šodienas datumu." Tad vēl viena. Tad desmit.

Tas nav izolēts kļūmes gadījums. Migrācija no iCloud Mail uz Office 365 ir viens no visvairāk dokumentētajiem e-pastu datumu bojājumu scenārijiem, un tam ir ļoti precīzi tehniski iemesli, kas saistīti gan ar Apple Mail uzvedību, gan ar IMAP protokolu, gan ar to, kā Microsoft 365 apstrādā ienākošos ziņojumus.

Kāpēc iCloud uz Office 365 migrācija saboj datumus

Lai saprastu problēmu, jānošķir trīs lietas, kuras daudzi cilvēki (tostarp pieredzējuši IT administratori) bieži jauc: Date: galvene, IMAP INTERNALDATE un faila izveides datums.

Date: galvene (RFC 2822)

Katrs e-pasts satur Date: galveni, kas norāda, kad ziņojums tika nosūtīts. Šī galvene ir iestrādāta ziņojuma neapstrādātajā saturā un teorētiski nekad nemainās. Tas ir "oriģinālais" datums tiešā nozīmē.

IMAP INTERNALDATE

IMAP protokols (definēts RFC 3501) katram ziņojumam piešķir atsevišķu metadatu vērtību, ko sauc par INTERNALDATE. Tieši šo vērtību lielākā daļa e-pasta klientu izmanto, lai kārtotu un rādītu ziņojumus iesūtnē, nevis Date: galveni. Outlook, konkrēti, ļoti lielā mērā paļaujas uz INTERNALDATE parādīšanai un kārtošanai.

Problēma? Kad migrācijas rīks kopē e-pastu no viena IMAP servera uz citu, tam ideālā gadījumā vajadzētu saglabāt šo INTERNALDATE. Praksē tā ne vienmēr notiek.

Apple Mail īpašā uzvedība

Apple Mail, sinhronizējot ziņojumus no iCloud, dažreiz izmanto faila izveides datumu servera pusē kā atsauci INTERNALDATE. Tas nav kļūdains tiesā pilnajā nozīmē, tā ir IMAP specifikācijas interpretācija, kas atšķiras no citu klientu pieejas. (Starp citu, ja jums kādreiz ir nācies atkļūdot INTERNALDATE problēmu, lasot neapstrādātas IMAP RFC, jūs zināt, ka specifikācija šajā punktā atstāj diezgan plašu interpretācijas telpu.)

Rezultāts: eksportējot vai migrējot no iCloud, izmantojot Apple Mail, ziņojumu INTERNALDATE vērtības var jau būt nepareizas, pirms tās nonāk Office 365.

Trīs iCloud migrācijas metodes un to slazdi

Tieša IMAP migrācija

Visizplatītākā metode ir konfigurēt iCloud kā IMAP avotu un Office 365 kā galamērķi, pēc tam izmantot migrācijas rīku (imapsync, MigrationWiz vai pašdarinātu risinājumu). Rīks pieslēdzas abiem serveriem un kopē ziņojumus.

Šeit problēma ir divkārša. Pirmkārt, Apple IMAP serveri ir ar ātruma ierobežojumiem, kas liek rīkiem apstāties, radot laika logus, kuros savienojumi aizveras un atkal atveras, kas var ģenerēt nevēlamus INTERNALDATE. Otrkārt, katrs ziņojums, kas kopēts uz Exchange Online, pēc noklusējuma saņem iesniegšanas datumu, kas atbilst migrācijas brīdim, izņemot gadījumus, kad rīks ievietošanas komandā nepārprotami norāda oriģinālo INTERNALDATE.

Daži rīki to dara pareizi. Citi ne vienmēr. Un 40 000 ziņojumu pastkastē pat 2 % kļūdu likme nozīmē 800 e-pastus ar nepareizu datumu.

Migrācijām, izmantojot imapsync, skatiet arī: imapsync migrācijas datumu labošana Microsoft 365.

.mbox vai .eml eksports un importēšana

Daži lietotāji eksportē savus iCloud e-pastus, izmantojot Apple Mail, .mbox formātā, pēc tam mēģina tos importēt Outlook. Tā ir amatieriskas pieejas metode, kas dod mainīgus rezultātus.

.mbox formāts kodē e-pastus kā teksta ziņojumu secību. Datumi ir norādīti atsevišķu ziņojumu Date: galvenēs, bet atdalītājrindiņa starp ziņojumiem ("From ") ietver datumu, ko daži importētāji var interpretēt kā izveides datumu. Outlook, importējot .mbox, kas konvertēts uz .pst, dažreiz izmanto šo atdalīšanas datumu, nevis paša ziņojuma Date: galveni.

Vilkšana un nomešana, izmantojot Outlook

Šī ir metode, kas nodara visvairāk kaitējuma. Lietotājs konfigurē abus kontus Outlook (iCloud un Office 365), pēc tam velk un nomet ziņojumus no vienas mapes uz otru. Šķiet vienkārši. Bet datumu ziņā tā ir katastrofa.

Kad Outlook pārvieto ziņojumu ar vilkšanu un nomešanu starp diviem IMAP kontiem, tas faktiski ģenerē jaunu .EML failu, ievieto to galamērķa kontā un dzēš oriģinālu. Šis jaunais fails manto Windows faila izveides datumu, tas ir, tieši vilkšanas un nomešanas brīdi. Oriģinālā Date: galvene joprojām ir ziņojuma saturā, taču Exchange Online serverī reģistrētais INTERNALDATE atbilst manipulācijas datumam. Outlook pēc tam rāda šo migrācijas datumu visiem pārvietotajiem ziņojumiem.

Precīzāk sakot, šī uzvedība atšķiras atkarībā no Outlook versijas. Kopš 2023. gada rudens Outlook atjauninājuma daži scenāriji ir nedaudz uzlabojušies, taču vilkšana un nomešana starp kontiem joprojām ir dokumentēts datumu bojājumu avots.

Ko Office 365 un Outlook galu galā rāda

Exchange Online glabā e-pastus ar to INTERNALDATE. Outlook Desktop nolasa šo INTERNALDATE, lai kolonā "Saņemts" parādītu datumu un kārtotu iesūtni. Ja INTERNALDATE tika pārrakstīts migrācijas laikā, Outlook rāda migrācijas datumu, un viss.

Outlook Web App (OWA) rīkojas tāpat. Nav nekādas "alternatīvas skata" iespējas, kas parādītu oriģinālo datumu no Date: galvenes. Datumu kolonnā redzamais ir INTERNALDATE.

Oriģinālā Date: galvene joprojām ir tur, neskarta, lasāma, ja attēlojat ziņojuma neapstrādātās galvenes. Bet neviens parastais attēlojums to nerāda. Tā ir šīs problēmas galvenā neapmierinātība: pareizā informācija pastāv, tā ir vienkārši nepieejama bez tehniskas korekcijas.

Ko Microsoft atbalsts neatrisinās

Ja vērsīsieties pie Microsoft atbalsta ar šo problēmu, visticamāk saņemsiet šādu atbildi: apstiprinājumu, ka rādītie datumi atbilst saglabātajiem INTERNALDATE, ieteikumu pārbaudīt kārtošanas iestatījumus Outlook un, iespējams, novirzīšanu pie migrācijas rīka, ko izmantojāt.

Tā nav ļauna griba. Microsoft vienkārši nav vietēja rīka, lai retroaktīvi labotu tūkstošiem Exchange Online jau uzņemto ziņojumu INTERNALDATE. Korekcija prasa piekļūt ziņojumiem individuāli, analizēt to galvenes un rekonstruēt datumu metadatus, kas ir ārpus standarta atbalsta darbības jomas.

iCloud atbalsts, savukārt, uzskata, ka ziņojumi tika eksportēti pareizi un problēma ir galamērķa pusē. Abi atbalsta dienesti sūta sūdzību vienu otram, un lietotājs paliek ar 12 000 e-pastiem, kas datēti ar migrācijas dienu.

Mēroga problēma

Saprast, kāpēc datumi ir bojāti, ir viena lieta. Labot tos manuāli reālā ražošanas pastkastē ir pavisam cita.

Daži IT administratori mēģina rakstīt skriptus korekcijas automatizācijai. Pamatideja nav sarežģīta konceptuāli, taču izpilde reālos apjomos rada problēmas, ar kurām mājas skripstes netiek galā:

• S/MIME parakstīti vai ar PGP šifrēti e-pasti nevar tikt modificēti, nepārkāpjot kriptogrāfisko parakstu
• Ziņojumi ar sarežģītām multipart/alternative struktūrām (HTML + vienkāršs teksts + ligzdoti pielikumi) ir trausli apstrādē
• Ne-ASCII kodētas galvenes (RFC 2047, jo īpaši japāņu, arābu vai kirilicas rakstzīmēm) var sabojāt rīki, kas šos kodējumus neapstrādā pareizi
• Microsoft Graph API kvotas un Exchange Online ātruma ierobežojumi (kļūda 429 Too Many Requests) aptur skriptus, kas nav paredzēti eksponenciālās atkāpšanās pārvaldībai
• Skripts, kas pareizi darbojas ar 500 testa e-pastiem, apstājas pulksten 3 no rīta pie 8000. ziņojuma reālā pastkastē, bez atsākšanas mehānisma

Un galvenais jautājums: kā pārbaudīt, vai katrs labotais e-pasts pēc korekcijas ir neskarti? Vai pielikums joprojām ir tur? Vai diskusijas pavediens nav salūzis? Mājas skripts parasti šo pārbaudi neveic.

Kā Redate.io apstrādā iCloud migrācijas uz Office 365

Redate.io tieši pieslēdzas Office 365, izmantojot Microsoft 365 (Azure AD) atļaujas, bez nepieciešamības piekļūt iCloud serveriem. E-pasti jau ir Exchange Online brīdī, kad Redate sāk darboties.

Redate korekcijas dzinējs analizē katra ziņojuma galvenes ķēdi, lai identificētu oriģinālo datumu, nošķirot migrācijas laikā pievienotās Received: galvenes no likumīgajiem datumu metadatiem. Šī analīze ietver rakstu atbilstību zināmu migrācijas rīku parakstiem, kas ļauj identificēt nevēlamās galvenes pat tad, kad tās nav uzreiz acīmredzamas.

Katrs labotais e-pasts tiek pārbaudīts individuāli pēc apstrādes. Oriģināli tiek saglabāti redzamā dublēšanas mapē 30 dienas, ko neviens mājas skripts pēc noklusējuma nedara. Sākotnējā skenēšana ir bezmaksas un ļauj precīzi noteikt skarto e-pastu skaitu, pirms pieņem lēmumu par korekciju.

Redate atbalsta arī migrācijas no Google Workspace uz Office 365 un korekcijas pēc cPanel migrācijām. Skatiet, piemēram: e-pastu datumu labošana pēc Microsoft 365 migrācijas vai nepareizi e-pastu datumi pēc migrācijas uz Exchange Online.

Vispirms skenēt, tad labot

Ieteicamais sākumpunkts jebkurai iCloud uz Office 365 migrācijai, kas radījusi nepareizus datumus: palaist Redate.io bezmaksas skenēšanu skartajās pastkastēs. Skenēšana precīzi identificē, cik e-pastu ir ar aizdomīgu INTERNALDATE un kuros mapēs tie atrodas.

Tas aizņem no 12 līdz 45 minūtēm atkarībā no apjoma, un sniedz skaidru priekšstatu par problēmas apmēru pirms jebkādas iejaukšanās. MSP partneriem, kas pārvalda vairākas pastkastes vienlaikus pēc migrācijas, šī pakešu skenēšana ļauj izvairīties no to pastkastes labošanas, kurām tas nav vajadzīgs.

Ja jūsu e-pastu datumi ir nepareizi pēc migrācijas no iCloud, sāciet ar bezmaksas skenēšanu Redate.io, lai novērtētu problēmas apmēru jūsu Office 365 pastkastēs.