Migrace iCloud do Office 365: chybná data e-mailů

Scénář migrace, který systematicky ničí data

Právě jste dokončili přesun poštovní schránky z iCloud do Office 365. E-maily jsou tam, složky jsou na místě, všechno vypadá perfektně. V pondělí ráno přijde první stížnost: "Všechny moje staré e-maily zobrazují dnešní datum." Pak druhá. Pak deset.

Tohle není ojedinělá chyba. Migrace z iCloud Mail do Office 365 je jeden z nejlépe zdokumentovaných scénářů, při kterých se kazí data e-mailů, a to z přesně definovaných technických důvodů. Jde o kombinaci chování Apple Mail, protokolu IMAP a způsobu, jakým Microsoft 365 zpracovává příchozí zprávy.

Proč migrace z iCloud do Office 365 kazí data

Abychom pochopili problém, je třeba rozlišit tři věci, které si mnoho lidí (včetně zkušených IT administrátorů) plete: hlavičku Date:, IMAP INTERNALDATE a datum vytvoření souboru.

Hlavička Date: (RFC 2822)

Každý e-mail obsahuje hlavičku Date:, která říká, kdy byla zpráva odeslána. Tato hlavička je součástí surového těla zprávy a teoreticky se nikdy nemění. Je to "původní" datum ve striktním slova smyslu.

IMAP INTERNALDATE

Protokol IMAP (definovaný v RFC 3501) přiřazuje každé zprávě samostatnou metadatovou hodnotu zvanou INTERNALDATE. Právě tuto hodnotu většina e-mailových klientů používá k řazení a zobrazování zpráv ve schránce, ne hlavičku Date:. Outlook se na INTERNALDATE spoléhá obzvlášť silně, a to jak při zobrazování, tak při řazení.

Problém? Když nástroj pro migraci kopíruje e-mail z jednoho IMAP serveru na jiný, měl by ideálně zachovat INTERNALDATE. V praxi to tak vždy nefunguje.

Specifické chování Apple Mail

Apple Mail při synchronizaci zpráv z iCloud někdy používá jako referenci pro INTERNALDATE datum vytvoření souboru na straně serveru. Není to chyba v pravém slova smyslu, spíš interpretace specifikace IMAP, která se liší od toho, co dělají jiné klienty. (Mimochodem, pokud jste někdy zkoušeli ladit problém s INTERNALDATE čtením surových IMAP RFC, víte, že specifikace ponechává v tomto bodě poměrně velký prostor pro interpretaci.)

Výsledek: když exportujete nebo migrujete z iCloud přes Apple Mail, mohou být INTERNALDATE zpráv nesprávné ještě před příchodem do Office 365.

Tři metody migrace z iCloud a jejich úskalí

Přímá migrace přes IMAP

Nejběžnější metoda spočívá v nastavení iCloud jako zdroje IMAP a Office 365 jako cíle, načež se použije migrační nástroj (imapsync, MigrationWiz nebo vlastní řešení). Nástroj se připojí k oběma serverům a zkopíruje zprávy.

Problém je zde dvojí. Za prvé, IMAP servery Apple mají omezení datového toku, která nutí nástroje dělat pauzy. Vznikají tak časová okna, kdy se spojení zavírají a znovu otevírají, což může generovat parazitní INTERNALDATE hodnoty. Za druhé, každá zpráva zkopírovaná do Exchange Online dostane standardně datum příjmu odpovídající okamžiku migrace, pokud nástroj explicitně nepředá původní INTERNALDATE v příkazu pro vložení zprávy.

Některé nástroje to dělají správně. Jiné ne vždy. A na schránce se 40 000 zprávami představuje i 2% míra chyb 800 e-mailů se špatným datem.

Pro migrace přes imapsync viz také: oprava dat migrace imapsync v Microsoft 365.

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

Někteří uživatelé exportují e-maily z iCloud přes Apple Mail ve formátu .mbox a pak je zkouší importovat do Outlooku. Je to ruční metoda, která přináší proměnlivé výsledky.

Formát .mbox kóduje e-maily jako sekvenci textových zpráv. Data jsou sice přítomna v jednotlivých hlavičkách Date:, ale oddělovací řádek mezi zprávami ("From ") obsahuje datum, které někteří importéři mohou interpretovat jako datum vytvoření. Outlook při importu .mbox souboru převedeného do .pst někdy použije toto datum oddělovače místo hlavičky Date: samotné zprávy.

Přetažení myší v Outlooku

Tady je metoda, která napáchá nejvíce škod. Uživatel nastaví v Outlooku oba účty (iCloud i Office 365) a pak přetahuje zprávy ze složky do složky. Zdá se to jednoduché. Pro data je to katastrofa.

Když Outlook přesouvá zprávu přetažením mezi dvěma IMAP účty, ve skutečnosti vytvoří nový soubor .EML, vloží ho do cílového účtu a odstraní originál. Tento nový soubor zdědí datum vytvoření souboru Windows, tedy přesný okamžik přetažení. Původní hlavička Date: je stále přítomna v těle zprávy, ale INTERNALDATE uložený na serveru Exchange Online odpovídá datu manipulace. Outlook pak zobrazuje datum migrace u všech přesunutých zpráv.

Přesněji řečeno, toto chování se liší podle verze Outlooku. Od aktualizace Outlooku na podzim 2023 se situace pro některé scénáře mírně zlepšila, ale přetahování mezi účty zůstává zdokumentovaným zdrojem korupce dat.

Co Office 365 a Outlook nakonec zobrazují

Exchange Online ukládá e-maily s jejich INTERNALDATE. Outlook Desktop čte INTERNALDATE pro zobrazení data ve sloupci "Přijato" a pro řazení schránky. Pokud byl INTERNALDATE přepsán během migrace, Outlook zobrazí datum migrace. Bez výjimky.

Outlook Web App (OWA) se chová stejně. Neexistuje žádné "alternativní zobrazení", které by ukazovalo původní datum z hlavičky Date:. To, co vidíte ve sloupci s datem, je INTERNALDATE.

Původní hlavička Date: je stále tam, nedotčená, čitelná, pokud zobrazíte surové hlavičky zprávy. Ale žádné běžné zobrazení ji neukazuje. To je jádro frustrace tohoto problému: správná informace existuje, je jen nedostupná bez technické opravy.

Co podpora Microsoftu nevyřeší

Pokud otevřete tiketu u Microsoft Support kvůli tomuto problému, dostanete pravděpodobně toto: potvrzení, že zobrazená data odpovídají uloženým INTERNALDATE hodnotám, návrh zkontrolovat nastavení řazení v Outlooku, a případně odkaz na migrační nástroj, který jste použili.

Není to zlá vůle. Microsoft jednoduše nemá nativní nástroj pro zpětnou opravu INTERNALDATE u tisíců zpráv, které už jsou v Exchange Online. Oprava vyžaduje přístup k jednotlivým zprávám, analýzu jejich hlaviček a rekonstrukci metadat data, což je mimo rámec standardní podpory.

Podpora iCloud na druhé straně zastává názor, že zprávy byly exportovány správně a problém je na straně cíle. Obě podpory si přehazují zodpovědnost a uživatel zůstane s 12 000 e-maily datovanými dnem migrace.

Problém rozsahu

Pochopit, proč jsou data poškozena, je jedna věc. Ručně je opravit na produkční schránce je věc druhá.

Někteří IT administrátoři se pokoušejí opravu naprogramovat. Základní myšlenka není složitá k pochopení, ale provedení na reálných objemech přináší problémy, se kterými si domácí skripty neporadí:

• E-maily podepsané S/MIME nebo šifrované PGP nelze upravit bez zneplatnění kryptografického podpisu
• Zprávy s komplexními strukturami multipart/alternative (HTML + prostý text + vnořené přílohy) jsou při manipulaci křehké
• Hlavičky kódované v non-ASCII (RFC 2047, zejména japonské, arabské nebo cyrilické znaky) mohou být poškozeny nástroji, které tato kódování nezvládají správně
• API kvóty Microsoft Graph a limity datového toku Exchange Online (chyba 429 Too Many Requests) zastavují skripty, které nejsou navrženy pro správu exponenciálního backoff
• Skript, který funguje správně na 500 testovacích e-mailech, se zastaví ve 3 hodiny ráno na 8 000. zprávě skutečné schránky, bez mechanismu obnovení

A zásadní otázka: jak ověřit, že každý opravený e-mail je po opravě nedotčený? Že příloha je stále tam? Že vlákno konverzace není rozbité? Domácí skript toto ověření obvykle nedělá.

Jak Redate.io zpracovává migrace z iCloud do Office 365

Redate.io se připojuje přímo k Office 365 prostřednictvím oprávnění Microsoft 365 (Azure AD), bez nutnosti přístupu k serverům iCloud. E-maily jsou v Exchange Online již v okamžiku, kdy Redate zasáhne.

Korekční engine Redate analyzuje řetězec hlaviček každé zprávy, aby identifikoval původní datum, přičemž rozlišuje hlavičky Received: přidané během migrace od legitimních datových metadat. Tato analýza zahrnuje porovnávání vzorů oproti signaturám stovek známých migračních nástrojů, což umožňuje identifikovat parazitní hlavičky i tehdy, když nejsou na první pohled zřejmé.

Každý opravený e-mail je po zpracování individuálně ověřen. Originály jsou uchovány v přehledné záložní složce po dobu 30 dní, což žádný domácí skript ve výchozím nastavení nedělá. Úvodní sken je bezplatný a umožňuje přesně kvantifikovat počet dotčených e-mailů ještě před rozhodnutím o opravě.

Redate podporuje také migrace z Google Workspace do Office 365 a opravy po migraci cPanel. Viz například: oprava dat e-mailů po migraci Microsoft 365 nebo špatná data e-mailů po migraci do Exchange Online.

Nejdřív skenovat, pak opravovat

Doporučený výchozí bod pro každou migraci z iCloud do Office 365, která způsobila chybná data: spustit bezplatný sken Redate.io na dotčených schránkách. Sken přesně identifikuje, kolik e-mailů má podezřelý INTERNALDATE a ve kterých složkách se nacházejí.

Zabere to mezi 12 a 45 minutami podle objemu a poskytne jasný obraz rozsahu problému před jakýmkoliv zásahem. Pro MSP, kteří spravují více schránek najednou po migraci, tento hromadný sken zabrání opravování schránek, které to nepotřebují.

Pokud jsou data Vašich e-mailů nesprávná po migraci z iCloud, začněte bezplatným skenem na Redate.io a změřte rozsah problému ve svých schránkách Office 365.