Миграция от iCloud към Office 365: грешни дати на имейли

Сценарий на миграция, който системно разваля датите

Току-що сте завършили прехвърлянето на пощата си от iCloud към Office 365. Имейлите са там, папките са наредени, всичко изглежда наред. В понеделник сутринта пристига първата жалба: "Всичките ми стари имейли показват днешната дата." После идва втора. После десет.

Това не е изолиран бъг. Миграцията от iCloud Mail към Office 365 е един от най-добре документираните сценарии на повреда на дати на имейли, по много конкретни технически причини, свързани едновременно с поведението на Apple Mail, протокола IMAP и начина, по който Microsoft 365 обработва входящите съобщения.

Защо миграцията от iCloud към Office 365 разваля датите

За да разберете проблема, трябва да различавате три неща, които много хора (включително опитни IT администратори) бъркат: хедъра Date:, IMAP INTERNALDATE и датата на създаване на файла.

Хедърът Date: (RFC 2822)

Всеки имейл съдържа хедър Date:, който показва кога е изпратено съобщението. Този хедър е вграден в необработеното тяло на съобщението и теоретично никога не се променя. Това е "оригиналната" дата в строгия смисъл на думата.

IMAP INTERNALDATE

Протоколът IMAP (дефиниран в RFC 3501) свързва с всяко съобщение отделна метаданна, наречена INTERNALDATE. Тази стойност е тази, която повечето пощенски клиенти използват за сортиране и показване на съобщенията в пощенската кутия, а не хедъра Date:. Outlook в частност разчита много силно на INTERNALDATE за показване и сортиране.

Проблемът? Когато инструмент за миграция копира имейл от един IMAP сървър към друг, идеално би трябвало да запази INTERNALDATE. На практика това не винаги се случва.

Специфичното поведение на Apple Mail

Apple Mail, при синхронизиране на съобщения от iCloud, понякога използва датата на създаване на файла от страна на сървъра като референция за INTERNALDATE. Това не е бъг в строгия смисъл, а интерпретация на IMAP спецификацията, която се различава от това, което правят другите клиенти. (Между другото, ако сте се опитвали да дебъгвате проблем с INTERNALDATE, четейки необработени IMAP RFC-та, знаете, че спецификацията оставя доста широко поле за интерпретация по този въпрос.)

Резултатът: когато експортирате или мигрирате от iCloud чрез Apple Mail, INTERNALDATE стойностите на съобщенията може вече да са неправилни, преди дори да са стигнали до Office 365.

Трите метода за миграция от iCloud и техните клопки

Директна IMAP миграция

Най-разпространеният метод е да конфигурирате iCloud като IMAP източник и Office 365 като дестинация, след което да използвате инструмент за миграция (imapsync, MigrationWiz или собствен инструмент). Инструментът се свързва с двата сървъра и копира съобщенията.

Проблемът тук е двоен. Първо, IMAP сървърите на Apple имат ограничения на скоростта, които принуждават инструментите да правят паузи, създавайки времеви прозорци, в които връзките се затварят и отварят отново, което може да генерира паразитни INTERNALDATE стойности. После, всяко съобщение, копирано към Exchange Online, получава по подразбиране дата на депозиране, съответстваща на момента на миграцията, освен ако инструментът не предаде изрично оригиналния INTERNALDATE в командата за вмъкване.

Някои инструменти го правят правилно. Други, не систематично. А при пощенска кутия от 40 000 съобщения, дори процент на грешки от 2% представлява 800 имейла с грешна дата.

За миграции чрез imapsync вижте също: коригиране на датите от миграция с imapsync в Microsoft 365.

Експорт на .mbox или .eml и след това импорт

Някои потребители експортират имейлите си от iCloud чрез Apple Mail в .mbox формат, след което се опитват да ги импортират в Outlook. Това е занаятчийски метод, който дава непредсказуеми резултати.

Форматът .mbox кодира имейлите като поредица от текстови съобщения. Датите присъстват в отделните хедъри Date:, но разделителният ред между съобщенията ("From ") включва дата, която може да бъде интерпретирана като дата на създаване от някои инструменти за импорт. Outlook, когато импортира .mbox, конвертиран в .pst, понякога използва тази разделителна дата вместо хедъра Date: на самото съобщение.

Плъзгане и пускане чрез Outlook

Това е методът, който причинява най-много щети. Потребителят конфигурира двата акаунта в Outlook (iCloud и Office 365), след което плъзга и пуска съобщенията от една папка в друга. Изглежда просто. Катастрофа е за датите.

Когато Outlook премества съобщение чрез плъзгане и пускане между два IMAP акаунта, всъщност генерира нов .EML файл, вмъква го в целевия акаунт и изтрива оригинала. Този нов файл наследява датата на създаване на Windows файла, тоест точния момент на плъзгане и пускане. Оригиналният хедър Date: е все още наличен в тялото на съобщението, но INTERNALDATE, записан на сървъра на Exchange Online, съответства на датата на манипулацията. Outlook след това показва тази дата на миграция за всички преместени съобщения.

За да бъдем точни, това поведение варира в зависимост от версията на Outlook. След актуализацията на Outlook от есента на 2023 г. поведението леко се подобри при определени сценарии, но плъзгането и пускането между акаунти остава документиран източник на повреда на дати.

Какво показват в крайна сметка Office 365 и Outlook

Exchange Online съхранява имейлите с техния INTERNALDATE. Outlook Desktop чете INTERNALDATE, за да покаже датата в колоната "Получено" и да сортира пощенската кутия. Ако INTERNALDATE е бил презаписан по време на миграцията, Outlook показва датата на миграцията. Точка.

Outlook Web App (OWA) прави същото. Няма "алтернативен изглед", който да показва оригиналната дата от хедъра Date:. Това, което виждате в колоната с дати, е INTERNALDATE.

Оригиналният хедър Date: е все още там, непокътнат, четим, ако покажете необработените хедъри на съобщение. Но нито един нормален изглед не го показва. Точно тук е основното разочарование от този проблем: правилната информация съществува, просто е недостъпна без техническа корекция.

Това, което поддръжката на Microsoft не решава

Ако отворите тикет при Microsoft Support за този проблем, ето какво вероятно ще получите: потвърждение, че показаните дати съответстват на съхранените INTERNALDATE стойности, предложение да проверите настройките за сортиране в Outlook и евентуално препращане към инструмента за миграция, който сте използвали.

Това не е злоумишленост. Microsoft просто няма нативен инструмент за ретроактивно коригиране на INTERNALDATE стойностите на хиляди съобщения, вече попаднали в Exchange Online. Корекцията изисква достъп до всяко съобщение поотделно, анализ на хедърите му и реконструкция на метаданните за дата, което е извън обхвата на стандартната поддръжка.

Поддръжката на iCloud от своя страна счита, че съобщенията са експортирани правилно и проблемът е от страна на дестинацията. Двете поддръжки си прехвърлят топката, а потребителят остава с 12 000 имейла, датирани от деня на миграцията.

Проблемът с мащаба

Да разберете защо датите са счупени е едно нещо. Да ги поправите ръчно в производствена пощенска кутия е съвсем друго.

Някои IT администратори се опитват да скриптират корекцията. Основната идея не е трудна за концептуализиране, но изпълнението върху реални обеми поставя проблеми, с които домашните скриптове не се справят добре:

• Имейли, подписани с S/MIME или криптирани с PGP, не могат да бъдат модифицирани, без да се анулира криптографският подпис
• Съобщенията със сложни multipart/alternative структури (HTML + обикновен текст + вложени прикачени файлове) са крехки за манипулиране
• Хедъри, кодирани в не-ASCII (RFC 2047, особено за японски, арабски или кирилски символи), могат да бъдат повредени от инструменти, които не обработват правилно тези кодировки
• API квотите на Microsoft Graph и ограниченията на скоростта на Exchange Online (грешка 429 Too Many Requests) спират скриптове, не проектирани за управление на експоненциален backoff
• Скрипт, работещ правилно на 500 тестови имейла, спира в 3 часа сутринта на 8000-ното съобщение на реална пощенска кутия, без механизъм за възобновяване

И въпросът, който убива: как да проверите, че всеки коригиран имейл е непокътнат след корекцията? Че прикаченият файл все още е там? Че нишката на разговора не е счупена? Домашният скрипт обикновено не прави тази проверка.

Как Redate.io обработва миграциите от iCloud към Office 365

Redate.io се свързва директно с Office 365 чрез разрешенията на Microsoft 365 (Azure AD), без да изисква достъп до сървърите на iCloud. Имейлите вече са в Exchange Online в момента, когато Redate се намесва.

Механизмът за корекция на Redate анализира веригата от хедъри на всяко съобщение, за да идентифицира оригиналната дата, като разграничава хедърите Received:, добавени по време на миграцията, от легитимните метаданни за дата. Този анализ включва съпоставяне на шаблони спрямо подписи на известни инструменти за миграция, което позволява идентифициране на паразитни хедъри дори когато не са очевидни на пръв поглед.

Всеки коригиран имейл се верифицира поотделно след обработка. Оригиналите се съхраняват в видима резервна папка в продължение на 30 дни, което нито един домашен скрипт не прави по подразбиране. Началното сканиране е безплатно и позволява да се определи точно колко имейла са засегнати, преди да се вземе решение за корекция.

Redate поддържа също миграции от Google Workspace към Office 365 и корекции след миграция от cPanel. Вижте например: коригиране на имейл дати след миграция към Microsoft 365 или грешни дати след миграция към Exchange Online.

Първо сканирайте, после коригирайте

Препоръчителната отправна точка за всяка миграция от iCloud към Office 365, довела до неправилни дати: стартирайте безплатното сканиране на Redate.io върху засегнатите пощенски кутии. Сканирането идентифицира точно колко имейла имат съмнителен INTERNALDATE и в кои папки се намират.

Отнема между 12 и 45 минути в зависимост от обема и дава ясна картина на мащаба на проблема преди каквато и да е намеса. За MSP-та, управляващи няколко пощенски кутии наведнъж след миграция, това пакетно сканиране избягва коригирането на кутии, които не се нуждаят от него.

Ако датите на имейлите ви са неправилни след миграция от iCloud, започнете с безплатното сканиране на Redate.io, за да измерите обхвата на проблема в пощенските ви кутии в Office 365.