iCloud į Office 365 migracija: klaidingos el. laiškų datos

Migracijos scenarijus, kuris sistemingai gadina datas

Ką tik baigėte perkelti savo iCloud pašto dėžutę į Office 365. El. laiškai yra vietoje, aplankai sutvarkyti, viskas atrodo puikiai. Pirmadienio rytą ateina pirmasis skundas: "Visi mano seni laiškai rodo šiandienos datą." Paskui antras. Paskui dešimt.

Tai ne vienišas klaidas. Migracija iš iCloud Mail į Office 365 yra vienas iš labiausiai dokumentuotų el. laiškų datų sugadinimo scenarijų, dėl labai konkrečių techninių priežasčių, susijusių su Apple Mail elgsena, IMAP protokolu ir tuo, kaip Microsoft 365 apdoroja gaunamus pranešimus.

Kodėl iCloud migracija į Office 365 gadina datas

Norint suprasti problemą, reikia atskirti tris dalykus, kuriuos daugelis žmonių (įskaitant patyrusius IT administratorius) painioja: Date: antraštę, IMAP INTERNALDATE ir failo sukūrimo datą.

Date: antraštė (RFC 2822)

Kiekviename el. laiške yra Date: antraštė, nurodanti, kada pranešimas buvo išsiųstas. Ši antraštė įterpta į žalio pranešimo kūną ir, teoriškai, niekada nesikeičia. Tai "originali" data griežtąja to žodžio prasme.

IMAP INTERNALDATE

IMAP protokolas (apibrėžtas RFC 3501) kiekvienam pranešimui priskiria atskirą metaduomenų lauką, vadinamą INTERNALDATE. Būtent šią reikšmę dauguma el. pašto klientų naudoja pranešimams rikiuoti ir rodyti gautuosiuose, o ne Date: antraštę. Outlook, ypač, labai stipriai remiasi INTERNALDATE rodydamas ir rikiuodamas laiškus.

Problema? Kai migracijos įrankis kopijuoja el. laišką iš vieno IMAP serverio į kitą, idealiu atveju jis turėtų išsaugoti šį INTERNALDATE. Praktiškai taip nutinka ne visada.

Ypatinga Apple Mail elgsena

Apple Mail, sinchronizuodamas pranešimus iš iCloud, kartais naudoja serverio pusės failo sukūrimo datą kaip INTERNALDATE reikšmę. Tai ne klaida griežtąja prasme, o IMAP specifikacijos interpretacija, kuri skiriasi nuo to, kaip elgiasi kiti klientai. (Beje, jei jums teko derinti INTERNALDATE problemą skaitant žalius IMAP RFC, žinote, kad specifikacija palieka gana plačią interpretacijos laisvę šiuo klausimu.)

Rezultatas: eksportuojant ar migruojant iš iCloud per Apple Mail, pranešimų INTERNALDATE reikšmės gali jau būti neteisingos dar prieš patenkant į Office 365.

Trys iCloud migracijos metodai ir jų spąstai

Tiesioginė IMAP migracija

Dažniausias metodas: sukonfigūruoti iCloud kaip IMAP šaltinį, Office 365 kaip paskirties vietą, ir naudoti migracijos įrankį (imapsync, MigrationWiz ar kitą). Įrankis jungiasi prie abiejų serverių ir kopijuoja pranešimus.

Čia problema dvejopa. Pirma, Apple IMAP serveriai turi greičio apribojimus, kurie verčia įrankius daryti pauzes, sukuriant laiko langus, kai jungtys užsidaro ir atsidaro iš naujo, kas gali generuoti papildomus INTERNALDATE. Antra, kiekvienas pranešimas, nukopijuotas į Exchange Online, pagal numatytąsias nuostatas gauna įdėjimo datą, atitinkančią migracijos momentą, nebent įrankis aiškiai perduoda originalų INTERNALDATE įterpimo komandoje.

Kai kurie įrankiai tai daro teisingai. Kiti, ne sistemingai. O dėžutėje su 40 000 pranešimų net 2 % klaidų lygis reiškia 800 el. laiškų su neteisinga data.

Migracijos per imapsync atveju taip pat žiūrėkite: imapsync datų taisymas Microsoft 365.

.mbox arba .eml eksportas ir vėlesnis importas

Kai kurie vartotojai eksportuoja savo iCloud el. laiškus per Apple Mail .mbox formatu, o paskui bando juos importuoti į Outlook. Tai rankinis metodas, kuris duoda nevienodus rezultatus.

.mbox formatas koduoja el. laiškus kaip teksto pranešimų seką. Datos yra atskirose Date: antraštėse, tačiau pranešimų atskyrimo eilutė ("From ") turi datą, kurią kai kurie importuotojai gali interpretuoti kaip sukūrimo datą. Outlook, importuodamas .mbox konvertuotą į .pst, kartais naudoja šią atskyrimo datą, o ne paties pranešimo Date: antraštę.

Vilkimas ir leidimas per Outlook

Štai metodas, sukeliantis daugiausia žalos. Vartotojas sukonfigūruoja abi paskyras Outlook programoje (iCloud ir Office 365), tada tempia pranešimus iš vieno aplanko į kitą. Atrodo paprasta. Datoms tai katastrofa.

Kai Outlook perkelia pranešimą vilkimu tarp dviejų IMAP paskyrų, iš tikrųjų sukuria naują .EML failą, įterpia jį į paskirties paskyrą ir ištrina originalą. Šis naujas failas paveldi Windows failo sukūrimo datą, tai yra tiksliai vilkimo ir leidimo momentą. Originali Date: antraštė vis dar yra pranešimo kūne, tačiau Exchange Online serveryje užregistruotas INTERNALDATE atitinka manipuliacijos datą. Outlook tada rodo šią migracijos datą visiems perkeltiems pranešimams.

Tiksliau sakant, ši elgsena skiriasi priklausomai nuo Outlook versijos. Nuo 2023 m. rudens Outlook atnaujinimo elgsena kai kuriais scenarijais šiek tiek pagerėjo, tačiau vilkimas ir leidimas tarp paskyrų išlieka dokumentuotu datų sugadinimo šaltiniu.

Ką galiausiai rodo Office 365 ir Outlook

Exchange Online saugo el. laiškus su jų INTERNALDATE. Outlook Desktop skaito šį INTERNALDATE rodydamas datą stulpelyje "Gauta" ir rikiuodamas gautuosius. Jei INTERNALDATE buvo perrašytas migracijos metu, Outlook rodo migracijos datą, ir tiek.

Outlook Web App (OWA) elgiasi taip pat. Nėra jokio "alternatyvaus rodinio", kuris parodytų originalią Date: antraštės datą. Tai, ką matote datos stulpelyje, yra INTERNALDATE.

Originali Date: antraštė vis dar ten, nepažeista, skaitoma, jei rodote žalius pranešimo antraštės duomenis. Tačiau joks įprastas rodinys jos nerodo. Tai ir yra centrinė šios problemos frustracija: teisinga informacija egzistuoja, ji tiesiog nepasiekiama be techninio taisymo.

Ko Microsoft palaikymas neišsprendžia

Jei dėl šios problemos atidarysite bilietą Microsoft palaikyme, greičiausiai gausite: patvirtinimą, kad rodomos datos atitinka saugomas INTERNALDATE reikšmes, siūlymą patikrinti Outlook rikiavimo nuostatas, ir galbūt nukreipimą pas naudoto migracijos įrankio palaikymą.

Tai nėra blogas noras. Microsoft paprasčiausiai neturi natyvaus įrankio retro aktyviai taisyti tūkstančių pranešimų, jau patekusių į Exchange Online, INTERNALDATE reikšmes. Taisymui reikia prieiti prie kiekvieno pranešimo atskirai, išanalizuoti jo antraštes ir rekonstruoti datos metaduomenis, o tai nepatenka į standartinės pagalbos sritį.

iCloud palaikymas, savo ruožtu, laiko, kad pranešimai buvo eksportuoti teisingai ir problema yra paskirties pusėje. Abu palaikymai perduoda kamuolį vienas kitam, o vartotojas lieka su 12 000 el. laiškų, pažymėtų migracijos dienos data.

Masto problema

Suprasti, kodėl datos sugadintos, yra vienas dalykas. Taisyti jas rankiniu būdu gamybinėje dėžutėje yra visiškai kas kita.

Kai kurie IT administratoriai bando sukurti taisymo scenarijų. Pagrindinė idėja konceptualiai nėra sudėtinga, tačiau vykdymas su realiais kiekiais sukelia problemų, kurių namų gamybos scenarijai nesuvaldo gerai:

• S/MIME pasirašytų arba PGP šifruotų el. laiškų negalima keisti nepažeidus kriptografinės parašo
• Pranešimai su sudėtingomis multipart/alternative struktūromis (HTML + paprastas tekstas + įdėtos priedai) yra trapūs manipuliuoti
• Ne-ASCII koduotos antraštės (RFC 2047, ypač japonų, arabų ar kirilicos simboliams) gali būti sugadintos įrankių, neteisingai tvarkančių šiuos kodavimus
• Microsoft Graph API kvotos ir Exchange Online greičio apribojimai (429 Too Many Requests klaida) sustabdo scenarijus, nesukurtus eksponentinio atsitraukimo valdymui
• Scenarijus, veikiantis teisingai su 500 bandomųjų el. laiškų, sustoja 3 val. nakties ties 8 000-uoju pranešimu tikroje dėžutėje, be jokio tęsimo mechanizmo

Ir klausimas, kuris visko nepaveldi: kaip patikrinti, kad kiekvienas pataisytas el. laiškas yra nepažeistas po taisymo? Kad priedas vis dar yra? Kad pokalbio gija nėra sulaužyta? Namų gamybos scenarijus paprastai šio patikrinimo neatlieka.

Kaip Redate.io tvarko iCloud migracijas į Office 365

Redate.io jungiasi tiesiogiai prie Office 365 per Microsoft 365 teises (Azure AD), nereikalaujant prieigos prie iCloud serverių. El. laiškai jau yra Exchange Online, kai Redate.io pradeda veikti.

Redate.io taisymo variklis analizuoja kiekvieno pranešimo antraščių grandinę, kad nustatytų originalią datą, atskirdamas migracijos metu pridėtas Received: antraštes nuo teisėtų datos metaduomenų. Ši analizė apima šablonų atpažinimą pagal žinomų migracijos įrankių signatūras, leidžiantį identifikuoti papildomas antraštes net tada, kai jos nėra iš karto akivaizdžios.

Kiekvienas pataisytas el. laiškas yra tikrinamas atskirai po apdorojimo. Originalai saugomi matomame atsarginės kopijos aplanke 30 dienų, ko joks namų gamybos scenarijus pagal numatytąsias nuostatas nedaro. Pradinis nuskaitymas yra nemokamas ir leidžia tiksliai įvertinti paveiktų el. laiškų skaičių prieš nusprendžiant taisyti.

Redate.io taip pat palaiko migracijas iš Google Workspace į Office 365 ir taisymą po cPanel migracijos. Žiūrėkite, pavyzdžiui: el. pašto datų taisymas po Microsoft 365 migracijos arba neteisingos datos po migracijos į Exchange Online.

Pirmiausia nuskenuoti, paskui taisyti

Rekomenduojamas pradžios taškas bet kokiai iCloud į Office 365 migracijai, kuri davė neteisingas datas: paleisti nemokamą Redate.io nuskaitymą paveiktose dėžutėse. Nuskaitymas tiksliai identifikuoja, kiek el. laiškų turi įtartiną INTERNALDATE ir kuriuose aplankuose jie yra.

Tai užtrunka nuo 12 iki 45 minučių, priklausomai nuo kiekio, ir suteikia aiškų problemos masto vaizdą prieš bet kokią intervenciją. MSP, valdantiems kelias dėžutes po migracijos, šis paketinis nuskaitymas leidžia netaisyti dėžučių, kurioms to nereikia.

Jei jūsų el. laiškų datos yra neteisingos po migracijos iš iCloud, pradėkite nuo nemokamo Redate.io nuskaitymo, kad įvertintumėte problemos mastą savo Office 365 dėžutėse.