Migrácia iCloud do Office 365: nesprávne dátumy emailov

Migrácia, ktorá systematicky kazí dátumy

Práve ste dokončili presun pošty z iCloud do Office 365. Emaily sú na mieste, priečinky sú v poriadku, všetko vyzerá perfektne. V pondelok ráno prichádza prvá sťažnosť: "Všetky moje staré emaily ukazujú dnešný dátum." Potom druhá. Potom desať.

Nie je to ojedinelá chyba. Migrácia z iCloud Mail do Office 365 patrí medzi najlepšie zdokumentované scenáre poškodenia dátumov emailov, a to z presných technických dôvodov, ktoré súvisia so správaním Apple Mail, protokolom IMAP a spôsobom, akým Microsoft 365 spracúva prichádzajúce správy.

Prečo migrácia z iCloud do Office 365 kazí dátumy

Aby sme pochopili problém, treba rozlišovať tri veci, ktoré si mnohí ľudia (vrátane skúsených IT adminov) mýlia: hlavičku Date:, IMAP INTERNALDATE a dátum vytvorenia súboru.

Hlavička Date: (RFC 2822)

Každý email obsahuje hlavičku Date:, ktorá udáva, kedy bola správa odoslaná. Táto hlavička je zabudovaná do tela správy a teoreticky sa nikdy nemení. Je to "pôvodný" dátum v pravom slova zmysle.

IMAP INTERNALDATE

Protokol IMAP (definovaný v RFC 3501) priraďuje každej správe samostatnú metadátovú hodnotu nazvanú INTERNALDATE. Práve túto hodnotu väčšina emailových klientov používa na triedenie a zobrazovanie správ v doručenej pošte, nie hlavičku Date:. Outlook sa obzvlášť silno opiera o INTERNALDATE pri zobrazovaní a triedení.

Problém? Keď nástroj na migráciu kopíruje email z jedného IMAP servera na druhý, mal by ideálne zachovať tento INTERNALDATE. V praxi sa to nie vždy deje.

Zvláštne správanie Apple Mail

Apple Mail pri synchronizácii správ z iCloud niekedy používa dátum vytvorenia súboru na strane servera ako referenciu pre INTERNALDATE. Nie je to chyba v pravom slova zmysle, ale interpretácia špecifikácie IMAP, ktorá sa líši od toho, čo robia iné klienty. (Ak ste niekedy skúšali debugovať problém s INTERNALDATE čítaním surových IMAP RFC, viete, že špecifikácia ponecháva v tomto bode dosť veľký priestor na interpretáciu.)

Výsledok: keď exportujete alebo migrujete z iCloud cez Apple Mail, INTERNALDATES správ môžu byť nesprávne ešte predtým, než sa dostanú do Office 365.

Tri metódy migrácie z iCloud a ich úskalia

Priama IMAP migrácia

Najčastejšia metóda spočíva v nakonfigurovaní iCloud ako IMAP zdroja a Office 365 ako cieľa, potom sa použije migračný nástroj (imapsync, MigrationWiz alebo vlastné riešenie). Nástroj sa pripojí k obom serverom a skopíruje správy.

Problém je tu dvojaký. Jednak Apple IMAP servery majú obmedzenia prenosovej rýchlosti, ktoré núte nástroje robiť prestávky a vytvárajú časové okná, kde sa spojenia zatvárajú a znova otvárajú, čo môže generovať parazitné INTERNALDATES. Okrem toho každá správa skopírovaná cez IMAP APPEND do Exchange Online dostane predvolene dátum vloženia zodpovedajúci momentu migrácie, pokiaľ nástroj explicitne nepredá pôvodný INTERNALDATE v príkaze na vloženie.

Niektoré nástroje to robia správne. Iné nie vždy. A na schránke so 40 000 správami aj 2 % chybovosť predstavuje 800 emailov s nesprávnym dátumom.

Pre migrácie cez imapsync pozrite aj: oprava dátumov migrácie imapsync v Microsoft 365.

Export .mbox alebo .eml a následný import

Niektorí používatelia exportujú emaily z iCloud cez Apple Mail vo formáte .mbox a potom sa ich pokúšajú importovať do Outlooku. Je to remeselná metóda, ktorá prináša premenlivé výsledky.

Formát .mbox kóduje emaily ako sekvenciu textových správ. Dátumy sú prítomné v jednotlivých hlavičkách Date:, ale oddeľovací riadok medzi správami ("From ") obsahuje dátum, ktorý niektoré importéry môžu interpretovať ako dátum vytvorenia. Outlook pri importe .mbox konvertovaného na .pst niekedy používa práve tento oddeľovací dátum namiesto hlavičky Date: samotnej správy.

Presunutie myšou cez Outlook

Tu je metóda, ktorá spôsobuje najviac škôd. Používateľ nakonfiguruje oba účty v Outlooku (iCloud aj Office 365) a potom presúva správy medzi priečinkami metódou drag & drop. Vyzerá to jednoducho. Je to katastrofa pre dátumy.

Keď Outlook presúva správu metódou drag & drop medzi dvoma IMAP účtami, v skutočnosti vytvorí nový súbor .EML, vloží ho do cieľového účtu a vymaže originál. Tento nový súbor zdedí dátum vytvorenia Windows súboru, teda presný okamih presunutia myšou. Pôvodná hlavička Date: je stále prítomná v tele správy, ale INTERNALDATE zaznamenaný na Exchange Online serveri zodpovedá dátumu tejto manipulácie. Outlook potom zobrazuje tento dátum migrácie pre všetky presunuté správy.

Vlastne, toto správanie sa líši podľa verzie Outlooku. Od jesenskej aktualizácie Outlooku z roku 2023 sa situácia mierne zlepšila pre niektoré scenáre, ale drag & drop medzi účtami zostáva zdokumentovaným zdrojom poškodenia dátumov.

Čo Office 365 a Outlook nakoniec zobrazujú

Exchange Online ukladá emaily s ich INTERNALDATE. Outlook Desktop číta tento INTERNALDATE na zobrazenie dátumu v stĺpci "Prijaté" a na triedenie doručenej pošty. Ak bol INTERNALDATE prepísaný počas migrácie, Outlook zobrazí dátum migrácie, a bodka.

Outlook Web App (OWA) robí to isté. Neexistuje žiadne "alternatívne zobrazenie", ktoré by ukazovalo pôvodný dátum z hlavičky Date:. Čo vidíte v stĺpci dátumu, to je INTERNALDATE.

Pôvodná hlavička Date: je stále tam, nedotknutá, čitateľná ak zobrazíte surové hlavičky správy. Ale žiadne bežné zobrazenie ju neukazuje. To je centrálna frustrácia tohto problému: správna informácia existuje, je len nedostupná bez technickej opravy.

Čo podpora Microsoftu nevyrieši

Ak otvoríte ticket u Microsoft Support pre tento problém, pravdepodobne dostanete: potvrdenie, že zobrazené dátumy zodpovedajú uloženým INTERNALDATES, návrh skontrolovať nastavenia triedenia v Outlooku a prípadne odkaz na migračný nástroj, ktorý ste použili.

Nie je to zlá vôľa. Microsoft jednoducho nemá natívny nástroj na spätné opravenie INTERNALDATES tisícok správ, ktoré sú už v Exchange Online. Oprava vyžaduje prístup k správam individuálne, analýzu ich hlavičiek a rekonštrukciu metadát dátumov, čo presahuje rámec štandardnej podpory.

Podpora iCloud zasa tvrdí, že správy boli exportované správne a problém je na strane cieľa. Obe podpory si hádžu loptu, a používateľ zostáva s 12 000 emailmi datovanými dňom migrácie.

Problém rozsahu

Pochopiť, prečo sú dátumy poškodené, je jedna vec. Opraviť ich manuálne na produkčnej schránke je niečo iné.

Niektorí IT admini sa pokúšajú opravu skriptovať. Základná myšlienka nie je ťažká na pochopenie, ale vykonanie na skutočných objemoch prináša problémy, s ktorými si domáce skripty nevedia dobre poradiť:

• Emaily podpísané S/MIME alebo šifrované pomocou PGP nemôžu byť upravené bez zneplatnenia kryptografického podpisu
• Správy so zložitými štruktúrami multipart/alternative (HTML + prostý text + vnorené prílohy) sú pri manipulácii krehké
• Hlavičky kódované v non-ASCII (RFC 2047, najmä pre japonské, arabské alebo cyrilikou písané znaky) môžu byť poškodené nástrojmi, ktoré tieto kódovania nespracúvajú správne
• Kvóty Microsoft Graph API a limity prenosovej rýchlosti Exchange Online (chyba 429 Too Many Requests) zastavujú skripty, ktoré nie sú navrhnuté na správu exponenciálneho backoffu
• Skript, ktorý správne beží na 500 testovacích emailoch, sa zastaví o 3 ráno pri 8 000. správe skutočnej schránky, bez mechanizmu obnovy

A smrteľná otázka: ako overíte, že každý opravený email je po oprave neporušený? Že príloha je stále tam? Že vlákno diskusie nie je rozbitné? Domáci skript túto kontrolu spravidla nerobí.

Ako Redate.io spracúva migrácie z iCloud do Office 365

Redate.io sa pripája priamo k Office 365 cez oprávnenia Microsoft 365 (Azure AD), bez potreby prístupu k serverom iCloud. Emaily sú už v Exchange Online v momente, keď Redate zasahuje.

Korekčný engine Redate analyzuje reťazec hlavičiek každej správy, aby identifikoval pôvodný dátum, pričom rozlišuje hlavičky Received: pridané počas migrácie od legitímnych metadát dátumov. Táto analýza zahŕňa porovnávanie vzorov so signatúrami známych migračných nástrojov, čo umožňuje identifikovať parazitné hlavičky aj vtedy, keď nie sú hneď zrejmé.

Každý opravený email je po spracovaní individuálne overený. Originály sú po dobu 30 dní uchovávané v viditeľnom záložnom priečinku, čo žiadny domáci skript predvolene nerobí. Úvodný sken je bezplatný a umožňuje presne kvantifikovať počet postihnutých emailov pred rozhodnutím o oprave.

Redate tiež podporuje migrácie z Google Workspace do Office 365 a opravy po migrácii cPanel. Pozrite napríklad: dátumy emailov po migrácii do Microsoft 365 alebo nesprávne dátumy po migrácii na Exchange Online.

Najprv skenovať, potom opravovať

Odporúčaný východiskový bod pre každú migráciu z iCloud do Office 365, ktorá spôsobila nesprávne dátumy: spustiť bezplatný sken Redate.io na postihnutých schránkach. Sken presne identifikuje, koľko emailov má podozrivý INTERNALDATE a v ktorých priečinkoch sa nachádzajú.

Trvá to 12 až 45 minút v závislosti od objemu a poskytne jasný obraz rozsahu problému pred akýmkoľvek zásahom. Pre MSP spravujúcich viacero schránok naraz po migrácii tento hromadný sken zabraňuje opravovaniu schránok, ktoré opravu nepotrebujú.

Ak sú dátumy vašich emailov nesprávne po migrácii z iCloud, začnite bezplatným skenom na Redate.io a zmerajte rozsah problému na vašich Office 365 schránkach.