Migracija iCloud na Office 365: pogrešni datumi emailova

Migracija koja sistematski kvari datume

Upravo ste završili prenos mejlova sa iCloud naloga na Office 365. Emailovi su tu, fascikle su postavljene, sve izgleda savršeno. U ponedeljak ujutru stiže prva žalba: "Svi moji stari emailovi prikazuju današnji datum." Onda druga. Onda deset.

Ovo nije izolovana greška. Migracija sa iCloud Mail-a na Office 365 jedan je od najdokumentovanijih scenarija kvarenja datuma emailova, iz tehničkih razloga koji se tiču i ponašanja Apple Mail-a, i IMAP protokola, i načina na koji Microsoft 365 obrađuje dolazne poruke.

Zašto iCloud na Office 365 kvari datume

Da bismo razumeli problem, moramo razlikovati tri stvari koje mnogi ljudi, uključujući i iskusne IT administratore, mešaju: zaglavlje Date:, IMAP INTERNALDATE, i datum kreiranja fajla.

Zaglavlje Date: (RFC 2822)

Svaki email sadrži zaglavlje Date: koje pokazuje kada je poruka poslata. To zaglavlje je deo sirovog tela poruke i, u teoriji, nikad se ne menja. To je "originalni" datum u pravom smislu te reči.

IMAP INTERNALDATE

IMAP protokol (definisan u RFC 3501) dodeljuje svakoj poruci poseban metapodatak koji se zove INTERNALDATE. Upravo tu vrednost većina email klijenata koristi za sortiranje i prikaz poruka u prijemnom sandučetu, a ne zaglavlje Date:. Outlook posebno jako oslanja na INTERNALDATE za prikaz i sortiranje.

Problem? Kada alat za migraciju kopira email sa jednog IMAP servera na drugi, idealno bi trebalo da sačuva taj INTERNALDATE. U praksi, to se ne dešava uvek.

Posebno ponašanje Apple Mail-a

Apple Mail, kada sinhronizuje poruke sa iCloud-a, ponekad koristi datum kreiranja fajla na strani servera kao referencu za INTERNALDATE. To nije bag u pravom smislu, već interpretacija IMAP specifikacije koja se razlikuje od onoga što rade drugi klijenti. (Uzgred, ako ste ikad pokušali da debagujete problem sa INTERNALDATE čitajući sirove IMAP RFC-ove, znate da specifikacija ostavlja dosta prostora za interpretaciju po ovom pitanju.)

Rezultat: kada eksportujete ili migrirate sa iCloud-a putem Apple Mail-a, INTERNALDATES poruka već mogu biti pogrešni pre nego što uopšte stignu u Office 365.

Tri metode migracije sa iCloud-a i njihove zamke

Direktna IMAP migracija

Najčešća metoda je konfigurisanje iCloud-a kao izvora i Office 365 kao odredišta putem IMAP-a, a zatim korišćenje alata za migraciju (imapsync, MigrationWiz ili neki drugi). Alat se konektuje na oba servera i kopira poruke.

Problem je dvostruk. Prvo, Apple-ovi IMAP serveri imaju ograničenja propusnosti koja primoravaju alate da prave pauze, stvarajući vremenske prozore u kojima se konekcije zatvaraju i ponovo otvaraju, što može generisati parazitske INTERNALDATE vrednosti. Drugo, svaka poruka kopirana putem IMAP APPEND prema Exchange Online-u po podrazumevanim postavkama dobija datum prijema koji odgovara trenutku migracije, osim ako alat eksplicitno ne prosledi originalni INTERNALDATE u komandi umetanja.

Neki alati to rade ispravno. Drugi, ne uvek. A na sandučetu od 40.000 poruka, čak i stopa greške od 2% znači 800 emailova sa pogrešnim datumom.

Za migracije putem imapsync, pogledajte i: ispravka datuma imapsync migracije u Microsoft 365.

Eksport u .mbox ili .eml formatu pa import

Neki korisnici eksportuju emailove sa iCloud-a putem Apple Mail-a u .mbox formatu, pa ih pokušavaju importovati u Outlook. To je zanatska metoda koja daje promenljive rezultate.

Format .mbox enkodira emailove kao sekvencu tekstualnih poruka. Datumi su prisutni u individualnim zaglavljima Date:, ali linija razdvajanja između poruka ("From ") sadrži datum koji neki importeri mogu interpretirati kao datum kreiranja. Outlook, kada importuje .mbox konvertovan u .pst, ponekad koristi taj datum razdvajanja umesto zaglavlja Date: same poruke.

Prevlačenje i ispuštanje u Outlooku

Evo metode koja pravi najviše štete. Korisnik konfiguriše oba naloga u Outlooku (iCloud i Office 365), pa prevlači poruke iz jedne fascikle u drugu. Deluje jednostavno. Za datume je katastrofa.

Kada Outlook premešta poruku prevlačenjem između dva IMAP naloga, zapravo kreira novi .EML fajl, ubacuje ga u odredišni nalog i briše original. Taj novi fajl nasleđuje datum kreiranja Windows fajla, tj. tačan trenutak prevlačenja. Originalno zaglavlje Date: i dalje je prisutno u telu poruke, ali INTERNALDATE zabeležen na Exchange Online serveru odgovara datumu te operacije. Outlook zatim prikazuje taj datum migracije za sve premeštene poruke.

Da budemo precizni, ovo ponašanje varira u zavisnosti od verzije Outlook-a. Od ažuriranja Outlook-a u jesen 2023. godine, ponašanje se neznatno poboljšalo u nekim scenarijima, ali prevlačenje između naloga ostaje dokumentovani uzrok kvarenja datuma.

Šta Office 365 i Outlook zapravo prikazuju

Exchange Online čuva emailove sa njihovim INTERNALDATE vrednostima. Outlook Desktop čita taj INTERNALDATE da bi prikazao datum u koloni "Primljeno" i sortirao prijemno sanduče. Ako je INTERNALDATE prebrisan tokom migracije, Outlook prikazuje datum migracije, i to je to.

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

Originalno zaglavlje Date: je i dalje tu, netaknuto, čitljivo ako prikažete sirova zaglavlja poruke. Ali nijedan normalan prikaz ga ne pokazuje. To je centralna frustracija ovog problema: tačna informacija postoji, samo je nedostupna bez tehničke ispravke.

Šta Microsoft podrška ne rešava

Ako otvorite tiket kod Microsoft Support-a zbog ovog problema, verovatno ćete dobiti: potvrdu da prikazani datumi odgovaraju uskladištenim INTERNALDATE vrednostima, predlog da proverite podešavanja sortiranja u Outlook-u, i eventualno upućivanje na alat za migraciju koji ste koristili.

To nije loša volja. Microsoft jednostavno nema izvorni alat za retroaktivnu ispravku INTERNALDATE vrednosti hiljada poruka koje su već unete u Exchange Online. Ispravka zahteva individualni pristup svakoj poruci, analizu njenih zaglavlja i rekonstrukciju metapodataka o datumu, što je van okvira standardne podrške.

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

Problem obima

Razumeti zašto su datumi pokvareni jedna je stvar. Ručno ih ispraviti na sandučetu u produkciji sasvim je druga.

Neki IT administratori pokušavaju da skriptuju ispravku. Osnovna ideja nije komplikovana za konceptualizovanje, ali izvršavanje na realnim volumenima postavlja probleme koje domaći skriptovi ne rešavaju dobro:

• S/MIME potpisani ili PGP šifrovani emailovi ne mogu biti modifikovani bez poništavanja kriptografskog potpisa
• Poruke sa složenim multipart/alternative strukturama (HTML + plain text + ugnežđeni prilozi) osetljive su na manipulaciju
• Zaglavlja enkodovana u non-ASCII formatu (RFC 2047, naročito za japanska, arapska ili ćirilična slova) mogu biti oštećena alatima koji ne rukuju ispravno tim enkodiranjima
• API kvote Microsoft Graph-a i ograničenja propusnosti Exchange Online-a (greška 429 Too Many Requests) zaustavljaju skriptove koji nisu dizajnirani za upravljanje eksponencijalnim backoff-om
• Skript koji radi ispravno na 500 test emailova staje u 3 ujutru na 8.000. poruci pravog sandučeta, bez mehanizma za nastavak

I pitanje koje sve ubija: kako proveriti da je svaki korigovani email netaknut posle ispravke? Da prilog i dalje postoji? Da nit razgovora nije pokvarena? Domaći skript to generalno ne proverava.

Kako Redate.io rešava migracije sa iCloud-a na Office 365

Redate.io se konektuje direktno na Office 365 putem Microsoft 365 dozvola (Azure AD), bez potrebe za pristupom iCloud serverima. Emailovi su već u Exchange Online-u u trenutku kada Redate interveniše.

Redate-ov korekcioni engine analizira lanac zaglavlja svake poruke kako bi identifikovao originalni datum, razlikujući Received: zaglavlja dodata tokom migracije od legitimnih metapodataka o datumu. Ta analiza uključuje podudaranje obrazaca sa potpisima poznatih alata za migraciju, što omogućava prepoznavanje parazitskih zaglavlja čak i kada nisu odmah očigledna.

Svaki korigovani email se individualno proverava posle obrade. Originali se čuvaju u vidljivoj backup fascikli 30 dana, što nijedan domaći skript ne radi po podrazumevanim postavkama. Početno skeniranje je besplatno i omogućava precizno kvantifikovanje broja pogođenih emailova pre donošenja odluke o ispravci.

Redate podržava i migracije sa Google Workspace-a na Office 365 i ispravke posle cPanel migracija. Pogledajte na primer: ispravka datuma posle migracije na Microsoft 365 ili pogrešni datumi emailova posle migracije na Exchange Online.

Prvo skeniranje, pa ispravka

Preporučeni polazni korak za svaku migraciju sa iCloud-a na Office 365 koja je dala pogrešne datume: pokrenuti besplatno skeniranje Redate.io na pogođenim sandučetima. Skeniranje precizno identifikuje koliko emailova ima sumnjiv INTERNALDATE i u kojim fasciklama se nalaze.

To traje između 12 i 45 minuta u zavisnosti od volumena, i daje jasnu sliku obima problema pre bilo kakve intervencije. Za MSP-ove koji upravljaju više sandučeta istovremeno posle migracije, ovo grupno skeniranje sprečava korigovanje sandučeta koja to ne zahtevaju.

Ako su datumi Vaših emailova pogrešni posle migracije sa iCloud-a, počnite sa besplatnim skeniranjem na Redate.io da biste izmerili obim problema na Vašim Office 365 sandučetima.