Грешни дати след миграция от Zoho към Microsoft 365

Какво се е случило с пощенските ви кутии

Приключихте с миграцията на домейна от Zoho Mail към Microsoft 365. Exchange Online е конфигуриран, пощенските кутии са провизионирани, MX записите са актуализирани. И тогава, в понеделник сутринта, един потребител отваря Outlook и вижда, че всички имейли от 2021 г. показват днешна дата. Друг забелязва, че съобщенията от миналата година стоят най-отгоре в Входящата поща, като сякаш са пристигнали преди минути. Тикетите започват да се трупат.

Това не е грешка в Outlook. Не е и специфичен проблем на Zoho. Това се случва, когато инструментът за миграция не предаде оригиналната дата на всеки имейл. Да разберете точно защо се случва е първата стъпка към правилното му отстраняване.

Техническата причина: INTERNALDATE и Received хедъри

Имейлът, съхранен на IMAP сървър, се състои от две отделни неща: суровото съдържание на съобщението (RFC 2822 хедъри, тяло, прикачени файлове) и метаданните за съхранение, управлявани от IMAP сървъра, сред които е INTERNALDATE. Именно тази метаданна използват имейл клиентите, за да показват и сортират съобщенията.

Хедърът Date: в суровото съобщение (RFC 2822) представя датата, на която съобщението е съставено или изпратено от подателя. INTERNALDATE, от своя страна, е датата, на която IMAP сървърът е получил или съхранил съобщението. Нормално, на здрав сървър, двете стойности са близки. След миграция историята е съвсем различна.

Как една IMAP миграция може да развали датите

Когато инструмент за миграция (Zoho Migration Wizard, imapsync, BitTitan или друг) прехвърля съобщение от Zoho Mail към Exchange Online, го прави чрез IMAP протокола. Инструментът се свързва с Zoho, изтегля съобщението и го вмъква в Exchange Online. Точно тук нещата тръгват по грешен път.

Exchange Online запазва датата, която му е подадена: когато инструментът предаде оригиналния INTERNALDATE на всяко съобщение чрез командата APPEND, копието го запазва. Някои инструменти за миграция правят това. Други не го правят, или го правят неправилно, при което Exchange Online присвоява момента на вмъкването, тоест датата на миграцията, като INTERNALDATE.

Резултатът: независимо дали имейлът е изпратен през 2019 или 2022 г., неговият INTERNALDATE сочи към седмицата на миграцията. Outlook чете тази стойност с приоритет. Сортирането се срива.

Специфичното поведение на Zoho Migration Wizard

Zoho предлага собствен инструмент за напускане на платформата: Zoho Migration Wizard. Той е удобен за прости миграции, но в администраторски форуми е документирано едно поведение: инструментът не винаги предава правилно оригиналния INTERNALDATE при вмъкване в сървъра на местоназначението.

По-точно казано: когато Zoho Migration Wizard наистина предаде оригиналната дата, Exchange Online я запазва и Outlook показва правилната дата. Имейлите, показващи датата на миграцията, са тези, чиято дата не е била предадена.

Администраторите, използващи IMAP инструменти като imapsync за напускане на Zoho, могат да срещнат същия проблем: imapsync копира датата, която сървърът-източник пази за всяко съобщение, така че грешна дата в източника се превръща в грешна дата в дестинацията. (Ако някога сте четели imapsync лог ред по ред в търсене на грешка в синхронизацията в 2 часа нощем, знаете, че е мощен инструмент, но доста непрощаващ към гранични случаи.)

Защо Outlook показва грешната дата

Outlook не използва само хедъра Date:, за да покаже датата на имейла. В повечето изгледи се използва INTERNALDATE, предоставен от IMAP/Exchange сървъра, особено при сортиране на Входящата поща. Оригиналният хедър Date: присъства в съобщението, непокътнат, но е игнориран в полза на INTERNALDATE.

Ето защо опцията "Сортиране по дата на изпращане" в Outlook всъщност не решава проблема. Показва различна дата, да, но поведението при сортиране остава нестабилно в зависимост от версията на Outlook и режима на изглед (групирани разговори или не). Сортирането по дата на изпращане не е решение. Това е лепенка, която пада при първата актуализация на клиента.

Реалният мащаб на проблема

При миграция от Zoho към Microsoft 365 с среден мащаб лесно се стига до 50 000 до 500 000 засегнати съобщения, в зависимост от давността на пощенските кутии и размера на организацията. Всеки прехвърлен имейл по време на миграционния прозорец носи едно и също развалено датиране, което прави проблема незабавно видим за потребителите при първото отваряне на Outlook.

Папките "Изпратени" са обикновено най-проблематични. Търговски представител, търсещ оферта, изпратена през март 2022 г., се озовава да рови в стотици имейли, всички с датата на миграцията. Оперативното въздействие е реално, не само козметично.

И за разлика от това, което може да се предположи, проблемът не изчезва с времето. INTERNALDATE е зафиксиран в момента на вмъкването. Не се коригира сам. Без активна намеса имейлите ще пазят развалената си дата за неопределено време.

Защо самостоятелното коригиране е по-рисковано, отколкото изглежда

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

Ето няколко гранични случая, с които самодейният скрипт вероятно няма да се справи добре:

• S/MIME подписани имейли, чийто подпис обхваща всички хедъри. Всяка промяна в структурата на съобщението анулира криптографския подпис.
• PGP криптирани съобщения, при които съдържанието е непрозрачно и всяка манипулация на MIME обвивките може да повреди съобщението.
• Не-ASCII хедъри, кодирани по RFC 2047 (имена на податели със специални символи), които се чупят, ако скриптът не управлява правилно кодирането.
• Прикачени файлове, кодирани в base64 с неправилно завършени редове, нестандартни MIME граници или вложени multipart структури.
• Имейли без валиден хедър Date: (съществуват, особено в стари Zoho експорти), при които скриптът трябва да реши какво да прави.

Скрипт, работещ върху 50 тестови имейла, няма да работи върху производствена пощенска кутия от Zoho с години история. И как да проверите, съобщение по съобщение, че всяка корекция е интактна и прикачените файлове не са отрязани? Проверката е поне толкова сложна, колкото самото коригиране.

Има и въпросът с квотите. API на Exchange Online, чрез Microsoft Graph, налага строги ограничения на честотата (известните грешки 429 Too Many Requests). Неограничен batch върху 100 000 съобщения може да предизвика временни блокирания или безшумни грешки, трудни за диагностициране след факта. Без механизъм за възстановяване след инцидент започвате отначало.

Как Redate.io коригира датите след миграция от Zoho

Всеки потребител се вписва със своя Microsoft акаунт, и Redate.io отваря тази пощенска кутия с достъпа, който вписването предоставя. Ако организацията изисква одобрение от администратор, Redate.io подготвя връзка за препращане към него. Началното сканиране е безплатно: Redate.io идентифицира засегнатите пощенски кутии и изчислява обема имейли с грешни дати, като сравнява INTERNALDATE с датите в хедърната верига на съобщението.

Корекцията използва собствен двигател, анализиращ пълната хедърна верига на всяко съобщение, не се нуждае да знае какъв инструмент е извършил миграцията (Zoho Migration Wizard, imapsync или друг), и реконструира метаданните за дата чрез многоетапен процес на валидиране. Всеки коригиран имейл се проверява индивидуално: целостта на съдържанието, запазването на прикачените файлове, RFC съответствие. Оригиналите никога не се изтриват от Redate.io. Те остават във видима папка на вашата пощенска кутия, докато не решите сами да ги изтриете.

Никаква нова миграция. Никакъв престой. Потребителите продължават да работят с Outlook, докато корекцията се изпълнява на заден план.

Ценообразуването е еднократно плащане, базирано на обема, без абонамент. Подробностите са достъпни директно на сайта.

Сходни случаи, които трябва да познавате

Ако управлявате няколко миграции паралелно, или сте MSP и администрирате клиенти, напускащи Zoho, имайте предвид, че същият проблем се среща при миграции от други платформи към Exchange Online. Механизмът е идентичен: копието получава датата, която инструментът предаде, независимо от източника.

За миграции от Google Workspace, от Exchange on-premises или чрез инструменти като BitTitan MigrationWiz или CloudM, статията Грешни дати след миграция към Exchange Online дава общ преглед на всички сценарии, завършващи в тази среда.

Ако миграцията включва споделени пощенски кутии или Exchange ресурси (зали, оборудване), проблемът е същият и същите инструменти за корекция се прилагат. Страницата Коригиране на датите от миграция Exchange IMAP в Outlook описва стъпките за свързване с вашия тенант.

За екипи, използващи imapsync специално за напускане на Zoho, статията imapsync: датите не се запазиха документира опциите за конфигурация и откъде наистина идват грешните дати.

Датите от миграцията от Zoho все още се показват грешно в Outlook? Сканирайте пощенските си кутии безплатно в Redate.io, за да измерите точния мащаб на проблема, преди да решите как да действате.