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

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

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

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

Техническата причина: 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, при получаване на всяко съобщение, генерира нов хедър Received:, който добавя в началото на съобщението. Този хедър носи точната дата и час на вмъкването, тоест датата на миграцията. Някои инструменти се опитват да запазят оригиналния INTERNALDATE, като го предават като параметър. Други не го правят, или го правят неправилно, след което Exchange Online автоматично присвоява датата на получаване като INTERNALDATE.

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

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

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

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

Администраторите, използващи IMAP инструменти като imapsync за напускане на Zoho, срещат абсолютно същия проблем, понякога в по-тежка форма, защото конфигурацията по подразбиране на imapsync не е оптимизирана за Exchange Online. (Ако някога сте четели 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

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

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

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

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

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

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

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

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

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

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