Selitev iCloud v Office 365: napačni datumi e-pošte

Selitev, ki sistematično pokvari datume

Pravkar ste zaključili prenos e-pošte iz iCloud v Office 365. Sporočila so tam, mape so na mestu, vse zgleda odlično. V ponedeljek zjutraj prispe prva pritožba: "Vsi moji stari e-poštni sporočili prikazujejo današnji datum." Potem druga. Potem deset.

To ni osamljen hrošč. Selitev iz iCloud Mail v Office 365 je eden izmed najbolje dokumentiranih scenarijev za poškodbo datumov e-pošte, in sicer iz zelo natančnih tehničnih razlogov, ki so povezani z obnašanjem Apple Mail, protokolom IMAP in načinom, kako Microsoft 365 obravnava dohodna sporočila.

Zakaj selitev iCloud v Office 365 pokvari datume

Da bi razumeli težavo, je treba ločiti tri stvari, ki jih mnogi (vključno z izkušenimi IT skrbniki) zamenjujejo: glavo Date:, IMAP INTERNALDATE in datum ustvarjanja datoteke.

Glava Date: (RFC 2822)

Vsako e-poštno sporočilo vsebuje glavo Date:, ki označuje, kdaj je bilo sporočilo poslano. Ta glava je vdelana v surovo telo sporočila in se teoretično nikoli ne spremeni. To je "izvirni" datum v strogem pomenu besede.

IMAP INTERNALDATE

Protokol IMAP (definiran v RFC 3501) vsakemu sporočilu pripiše ločen metapodatek, imenovan INTERNALDATE. To vrednost večina e-poštnih odjemalcev uporablja za razvrščanje in prikaz sporočil v nabiralniku, ne glave Date:. Outlook se pri prikazu in razvrščanju zelo močno opira prav na INTERNALDATE.

Težava? Ko orodje za selitev kopira e-poštno sporočilo z enega strežnika IMAP na drugega, bi moralo idealno ohraniti ta INTERNALDATE. V praksi se to ne zgodi vedno.

Posebno obnašanje Apple Mail

Apple Mail pri sinhronizaciji sporočil iz iCloud včasih kot referenco za INTERNALDATE uporabi datum ustvarjanja datoteke na strežniku. To ni napaka v strogem pomenu besede, temveč interpretacija specifikacije IMAP, ki se razlikuje od tega, kar počnejo drugi odjemalci. (Mimogrede, če ste kdaj poskušali razhroščevati težavo z INTERNALDATE z branjem surovih IMAP RFC, veste, da specifikacija pušča precej široko polje za interpretacijo.)

Rezultat: ko izvozite ali preselite sporočila iz iCloud prek Apple Mail, so INTERNALDATE vrednosti sporočil lahko napačne že preden sploh prispejo v Office 365.

Tri metode selitve iz iCloud in njihove pasti

Neposredna IMAP selitev

Najpogostejša metoda je konfiguracija iCloud kot izvora IMAP in Office 365 kot cilja, nato pa uporaba orodja za selitev (imapsync, MigrationWiz ali kakšno lastniško orodje). Orodje se poveže z obema strežnikoma in kopira sporočila.

Težava je tu dvojna. Najprej: Applovi strežniki IMAP imajo omejitve hitrosti, ki silijo orodja k premoru, kar ustvarja časovna okna, v katerih se povezave zaprejo in znova odprejo, kar lahko povzroči parazitske INTERNALDATE vrednosti. Potem: vsako sporočilo, kopirano prek IMAP APPEND v Exchange Online, privzeto prejme datum vnosa, ki ustreza trenutku selitve, razen če orodje izrecno posreduje izvirni INTERNALDATE v ukazu za vstavljanje.

Nekatera orodja to naredijo pravilno. Druga ne, vsaj ne dosledno. Pri nabiralniku s 40.000 sporočili že 2% stopnja napak pomeni 800 e-poštnih sporočil z napačnim datumom.

Za selitve prek imapsync si oglejte tudi: popravek datumov selitve imapsync v Microsoft 365.

Izvoz .mbox ali .eml in nato uvoz

Nekateri uporabniki izvozijo e-pošto iz iCloud prek Apple Mail v formatu .mbox, nato pa jo poskušajo uvoziti v Outlook. To je ročna metoda, ki daje spremenljive rezultate.

Format .mbox kodira e-pošto kot zaporedje besedilnih sporočil. Datumi so prisotni v posameznih glavah Date:, toda ločilna vrstica med sporočili ("From ") vsebuje datum, ki ga nekateri uvozniki interpretirajo kot datum ustvarjanja. Outlook, ko uvozi .mbox, pretvorjen v .pst, včasih uporabi ta ločilni datum namesto glave Date: samega sporočila.

Povleci in spusti prek Outlooka

To je metoda, ki povzroči največ škode. Uporabnik konfigurira oba računa v Outlooku (iCloud in Office 365), nato pa z vlečenjem in spuščanjem premakne sporočila iz ene mape v drugo. Zdi se preprosto. Za datume je to katastrofa.

Ko Outlook premakne sporočilo z vlečenjem in spuščanjem med dvema računoma IMAP, dejansko ustvari novo datoteko .EML, jo vstavi v ciljni račun in izbriše izvirnik. Ta nova datoteka podeduje datum ustvarjanja datoteke Windows, torej točen trenutek vlečenja in spuščanja. Izvirna glava Date: je še vedno prisotna v telesu sporočila, toda INTERNALDATE, shranjen na strežniku Exchange Online, ustreza datumu manipulacije. Outlook nato za vsa premaknjena sporočila prikaže ta datum selitve.

Natančneje povedano, to obnašanje se razlikuje glede na različico Outlooka. Od posodobitve Outlooka jeseni 2023 se je obnašanje za nekatere scenarije nekoliko izboljšalo, toda vlečenje in spuščanje med računi ostaja dokumentiran vir poškodbe datumov.

Kaj Office 365 in Outlook na koncu prikažeta

Exchange Online shrani e-pošto z njihovim INTERNALDATE. Outlook Desktop bere ta INTERNALDATE za prikaz datuma v stolpcu "Prejeto" in za razvrščanje nabiralnika. Če je bil INTERNALDATE med selitvijo prepisan, Outlook prikaže datum selitve, točka.

Outlook Web App (OWA) ravna enako. Ne obstaja "alternativni pogled", ki bi prikazal izvirni datum iz glave Date:. To, kar vidite v stolpcu z datumom, je INTERNALDATE.

Izvirna glava Date: je še vedno tam, nedotaknjena, berljiva, če prikažete surove glave sporočila. Toda noben normalen prikaz je ne kaže. To je osrednja frustracija te težave: pravilna informacija obstaja, le nedostopna je brez tehničnega popravka.

Česar Microsoftova podpora ne reši

Če odprete zahtevek pri Microsoftovi podpori za to težavo, boste verjetno dobili: potrditev, da prikazani datumi ustrezajo shranjenim INTERNALDATE vrednostim, predlog za preverjanje nastavitev razvrščanja v Outlooku, in morda napotitev na orodje za selitev, ki ste ga uporabili.

To ni slaba volja. Microsoft preprosto nima domačega orodja za retroaktivno popravljanje INTERNALDATE vrednosti tisočev sporočil, ki so že bila uvožena v Exchange Online. Popravek zahteva dostop do vsakega sporočila posebej, analizo njegovih glav in rekonstrukcijo metapodatkov datuma, kar presega obseg standardne podpore.

Podpora iCloud pa meni, da so bila sporočila pravilno izvožena in da je težava na strani cilja. Obe podpori si podajata žogo, uporabnik pa ostane z 12.000 e-poštnimi sporočili, datiranimi z dnem selitve.

Težava obsega

Razumeti, zakaj so datumi pokvarjeni, je ena stvar. Ročno jih popraviti v produkcijskem nabiralniku pa je povsem druga zgodba.

Nekateri IT skrbniki poskušajo popravek skriptirati. Osnovna ideja ni težko konceptualizirati, toda izvedba pri realnih obsegih povzroča težave, s katerimi domači skripti ne znajo ravnati:

• E-poštnih sporočil, podpisanih s S/MIME ali šifriranih s PGP, ni mogoče spremeniti brez razveljavitve kriptografskega podpisa
• Sporočila s kompleksnimi strukturami multipart/alternative (HTML + navadno besedilo + gnezdene priloge) so krhka za obdelavo
• Glave, kodirane v non-ASCII (RFC 2047, zlasti za japonske, arabske ali cirilične znake), lahko orodja, ki teh kodiranj ne obvladajo pravilno, poškodujejo
• Kvote API-ja Microsoft Graph in omejitve hitrosti Exchange Online (napaka 429 Too Many Requests) ustavijo skripte, ki niso zasnovane za upravljanje eksponentnega odloga
• Skript, ki pravilno deluje na 500 testnih e-poštnih sporočilih, se ob 3. uri zjutraj ustavi pri 8000. sporočilu pravega nabiralnika, brez mehanizma za nadaljevanje

In ključno vprašanje: kako preveriti, da je vsako popravljeno e-poštno sporočilo po popravku nedotaknjeno? Da je priloga še vedno tam? Da nit pogovora ni prekinjena? Domači skript tega preverjanja navadno ne izvaja.

Kako Redate.io obravnava selitve iCloud v Office 365

Redate.io se neposredno poveže z Office 365 prek dovoljenj Microsoft 365 (Azure AD), brez potrebe po dostopu do strežnikov iCloud. E-pošta je v trenutku, ko Redate posreduje, že v Exchange Online.

Redatov mehanizem za popravek analizira verigo glav vsakega sporočila za identifikacijo izvirnega datuma, pri čemer loči glave Received:, dodane med selitvijo, od legitimnih metapodatkov datuma. Ta analiza vključuje ujemanje vzorcev na podpisih znanih orodij za selitev, kar omogoča identifikacijo parazitskih glav tudi takrat, ko niso takoj očitne.

Vsako popravljeno e-poštno sporočilo je po obdelavi preverjeno posebej. Izvirniki so 30 dni shranjeni v vidni varnostni kopiji, kar domači skripti privzeto ne počnejo. Začetno skeniranje je brezplačno in omogoča natančno določitev števila prizadetih e-poštnih sporočil, preden se odločite za popravek.

Redate podpira tudi selitve iz Google Workspace v Office 365 in popravke po selitvi Microsoft 365. Oglejte si: popravek datumov po selitvi Microsoft 365 ali napačni datumi e-pošte po selitvi v Exchange Online.

Najprej skenirajte, potem popravite

Priporočeno izhodišče za vsako selitev iCloud v Office 365, ki je povzročila napačne datume: zaženite brezplačno skeniranje Redate.io na prizadetih nabiralnikih. Skeniranje natančno identificira, koliko e-poštnih sporočil ima sumljiv INTERNALDATE in v katerih mapah se nahajajo.

Glede na obseg to traja med 12 in 45 minutami in daje jasno sliko obsega težave pred kakršnim koli posegom. Za MSP-je, ki po selitvi upravljajo več nabiralnikov hkrati, to paketno skeniranje prepreči popravljanje nabiralnikov, ki tega ne potrebujejo.

Če so datumi vaše e-pošte napačni po selitvi iz iCloud, začnite z brezplačnim skeniranjem na Redate.io in izmerrite obseg težave v vaših nabiralnikih Office 365.