Migracija iCloud na Office 365: krivi datumi emailova

Scenarij migracije koji sustavno kvari datume

Upravo ste završili prijenos pošte s iClouda na Office 365. Emailovi su tu, mape su na svom mjestu, sve izgleda savršeno. U ponedjeljak ujutro stiže prva žalba: "Svi moji stari emailovi prikazuju današnji datum." Zatim druga. Zatim deset.

Ovo nije izolirani bug. Migracija s iCloud Maila na Office 365 jedan je od najdokumentiranijih scenarija kvara datuma emailova, iz vrlo preciznih tehničkih razloga koji uključuju ponašanje Apple Maila, IMAP protokol i način na koji Microsoft 365 obrađuje dolazne poruke.

Zašto migracija s iClouda na Office 365 kvari datume

Da bismo razumjeli problem, treba razlikovati tri stvari koje mnogi ljudi (uključujući iskusne IT administratore) miješaju: zaglavlje Date:, IMAP INTERNALDATE i datum stvaranja datoteke.

Zaglavlje Date: (RFC 2822)

Svaki email sadrži zaglavlje Date: koje označava kada je poruka poslana. To zaglavlje ugrađeno je u sirovi sadržaj poruke i, u teoriji, nikada se ne mijenja. To je "originalni" datum u strogom smislu te riječi.

IMAP INTERNALDATE

IMAP protokol (definiran u RFC 3501) svakoj poruci pridružuje zasebnu metapodatkovnu vrijednost zvanu INTERNALDATE. Tu vrijednost većina email klijenata koristi za sortiranje i prikazivanje poruka u pretincu, a ne zaglavlje Date:. Outlook se posebno jako oslanja na INTERNALDATE za prikaz i sortiranje.

Problem? Kada alat za migraciju kopira email s jednog IMAP poslužitelja na drugi, idealno bi trebao sačuvati taj INTERNALDATE. U praksi, to se ne događa uvijek.

Posebno ponašanje Apple Maila

Apple Mail, kada sinkronizira poruke s iClouda, ponekad koristi datum stvaranja datoteke na strani poslužitelja kao referencu za INTERNALDATE. To nije bug u strogom smislu, nego interpretacija IMAP specifikacije koja se razlikuje od onoga što rade drugi klijenti. (Inače, ako ste ikad pokušali otkloniti grešku vezanu uz INTERNALDATE čitajući sirove IMAP RFC-ove, znate da specifikacija ostavlja prilično širok prostor za interpretaciju u tom pogledu.)

Rezultat: kada izvozite ili migrirate s iClouda putem Apple Maila, INTERNALDATE vrijednosti poruka mogu već biti netočne prije nego što stignu u Office 365.

Tri metode migracije s iClouda i njihove zamke

Izravna IMAP migracija

Najčešća metoda uključuje konfiguraciju iClouda kao IMAP izvora i Office 365 kao odredišta, a zatim korištenje alata za migraciju (imapsync, MigrationWiz ili vlastito rješenje). Alat se spaja na oba poslužitelja i kopira poruke.

Problem je dvostruk. Prvo, Appleovi IMAP poslužitelji imaju ograničenja propusnosti koja prisiljavaju alate na pauze, stvarajući vremenske prozore u kojima se veze zatvaraju i ponovno otvaraju, što može generirati parazitske INTERNALDATE vrijednosti. Drugo, svaka poruka kopirana putem IMAP APPEND na Exchange Online po zadanim postavkama dobiva datum pohrane koji odgovara trenutku migracije, osim ako alat eksplicitno ne proslijedi originalni INTERNALDATE u naredbi umetanja.

Neki alati to rade ispravno. Drugi, ne sustavno. A na sandučiću s 40.000 poruka, čak i stopa grešaka od 2 % znači 800 emailova s krivim datumom.

Za migracije putem imapsynca, vidi također: popravak datuma imapsync u Microsoft 365.

Izvoz .mbox ili .eml, zatim uvoz

Neki korisnici izvozе svoje iCloud emailove putem Apple Maila u formatu .mbox, a zatim ih pokušavaju uvesti u Outlook. To je zanatska metoda koja daje promjenjive rezultate.

Format .mbox kodira emailove kao niz tekstualnih poruka. Datumi su prisutni u pojedinim zaglavljima Date:, ali razdjelna linija između poruka ("From ") uključuje datum koji neki uvoznici mogu interpretirati kao datum stvaranja. Outlook, kada uvozi .mbox konvertiran u .pst, ponekad koristi taj razdjelni datum umjesto zaglavlja Date: same poruke.

Povlačenje i ispuštanje putem Outlooka

Evo metode koja uzrokuje najviše štete. Korisnik konfigurira oba računa u Outlooku (iCloud i Office 365), zatim povlači i ispušta poruke iz jedne mape u drugu. Izgleda jednostavno. Za datume je katastrofa.

Kada Outlook premješta poruku povlačenjem i ispuštanjem između dva IMAP računa, zapravo stvara novu .EML datoteku, umeće je u odredišni račun i briše original. Ta nova datoteka nasljeđuje datum stvaranja Windows datoteke, to jest točan trenutak kada je operacija izvršena. Originalno zaglavlje Date: i dalje je prisutno u tijelu poruke, ali INTERNALDATE zabilježen na Exchange Online poslužitelju odgovara datumu manipulacije. Outlook zatim prikazuje taj datum migracije za sve premještene poruke.

Da budemo precizni: ovo ponašanje varira ovisno o verziji Outlooka. Od Outlookovog ažuriranja u jesen 2023., ponašanje se neznatno poboljšalo za neke scenarije, ali povlačenje i ispuštanje između računa ostaje dokumentirani izvor kvara datuma.

Što Office 365 i Outlook na kraju prikazuju

Exchange Online pohranjuje emailove s njihovim INTERNALDATE vrijednostima. Outlook Desktop čita taj INTERNALDATE za prikaz datuma u stupcu "Primljeno" i za sortiranje pretinca. Ako je INTERNALDATE bio prepisan tijekom migracije, Outlook prikazuje datum migracije. Točka.

Outlook Web App (OWA) radi isto. Ne postoji "alternativni prikaz" koji bi pokazivao originalni datum iz zaglavlja Date:. Ono što vidite u stupcu datuma je INTERNALDATE.

Originalno zaglavlje Date: i dalje postoji, netaknuto, čitljivo ako prikažete sirova zaglavlja poruke. Ali nijedan normalni prikaz ne prikazuje ga. To je srž frustracije ovog problema: ispravna informacija postoji, samo je nedostupna bez tehničke korekcije.

Što Microsoftova podrška ne rješava

Ako otvorite tiket kod Microsoftove podrške zbog ovog problema, vjerojatno ćete dobiti: potvrdu da prikazani datumi odgovaraju pohranjenim INTERNALDATE vrijednostima, prijedlog da provjerite postavke sortiranja u Outlooku i eventualno preusmjeravanje na alat za migraciju koji ste koristili.

To nije zlonamjernost. Microsoft jednostavno nema izvorni alat za retroaktivno ispravljanje INTERNALDATE vrijednosti tisuća poruka već unesenih u Exchange Online. Korekcija zahtijeva pristup pojedinim porukama, analizu njihovih zaglavlja i rekonstrukciju metapodataka datuma, što je izvan opsega standardne podrške.

iCloud podrška, s druge strane, smatra da su poruke ispravno izvezene i da je problem na strani odredišta. Obje podrške prebacuju odgovornost jedna na drugu, a korisnik ostaje s 12.000 emailova datiranih danom migracije.

Problem razmjera

Razumjeti zašto su datumi pokvareni jedna je stvar. Ručno ih ispraviti na produkcijskom sandučiću sasvim je druga.

Neki IT administratori pokušavaju skriptirati korekciju. Osnovna ideja nije teška za konceptualizirati, ali izvođenje na stvarnim volumenima postavlja probleme koje kućni skripti ne rješavaju dobro:

• S/MIME potpisani ili PGP šifrirani emailovi ne mogu se mijenjati bez poništavanja kriptografskog potpisa
• Poruke sa složenim multipart/alternative strukturama (HTML + plain text + ugniježđeni privici) osjetljive su na manipulaciju
• Zaglavlja kodirana u non-ASCII formatu (RFC 2047, posebno za japanske, arapske ili ćirilične znakove) mogu biti oštećena alatima koji ne upravljaju ispravno tim kodiranjima
• API kvote Microsoft Grapha i ograničenja propusnosti Exchange Onlinea (greška 429 Too Many Requests) zaustavljaju skripte koje nisu dizajnirane za upravljanje eksponencijalnim backoffom
• Skripta koja ispravno radi na 500 testnih emailova staje u 3 ujutro na 8.000. poruci pravog sandučića, bez mehanizma nastavka

I pitanje koje sve odlučuje: kako provjeriti da je svaki ispravljeni email netaknut nakon korekcije? Da privitak i dalje postoji? Da nit razgovora nije prekinuta? Kućna skripta obično ne vrši tu provjeru.

Kako Redate.io obrađuje migracije s iClouda na Office 365

Redate.io spaja se izravno na Office 365 putem Microsoft 365 dozvola (Azure AD), bez potrebe za pristupom iCloud poslužiteljima. Emailovi su već u Exchange Onlineu u trenutku kada Redate intervenira.

Redateov motor za korekciju analizira lanac zaglavlja svake poruke kako bi identificirao originalni datum, razlikujući zaglavlja Received: dodana tijekom migracije od legitimnih metapodataka datuma. Ta analiza uključuje podudaranje uzoraka na potpisima poznatih alata za migraciju, što omogućuje identifikaciju parazitskih zaglavlja čak i kada nisu odmah očita.

Svaki ispravljeni email verificira se pojedinačno nakon obrade. Originali se čuvaju u vidljivoj mapi sigurnosne kopije 30 dana, što nijedna kućna skripta ne radi po zadanim postavkama. Početno skeniranje je besplatno i omogućuje precizno kvantificiranje broja zahvaćenih emailova prije odluke o korekciji.

Redate podržava i migracije s Google Workspacea na Office 365 te korekcije nakon migracije s cPanela. Pogledajte, primjerice: ispravak datuma emailova nakon Microsoft 365 migracije ili pogrešni datumi emailova nakon migracije na Exchange Online.

Najprije skenirajte, zatim ispravite

Preporučeno polazište za svaku migraciju s iClouda na Office 365 koja je proizvela netočne datume: pokrenite besplatno skeniranje Redate.io na zahvaćenim sandučićima. Skeniranje precizno identificira koliko emailova ima sumnjiv INTERNALDATE i u kojim mapama se nalaze.

Traje između 12 i 45 minuta ovisno o volumenu, i daje jasnu sliku opsega problema prije bilo kakve intervencije. Za MSP-ove koji upravljaju više sandučića odjednom nakon migracije, to skupno skeniranje izbjegava ispravljanje sandučića kojima to nije potrebno.

Ako su datumi Vaših emailova netočni nakon migracije s iClouda, počnite s besplatnim skeniranjem na Redate.io kako biste izmjerili opseg problema na Vašim Office 365 sandučićima.