Нов Outlook: грешни дати след миграция, истинските причини

Два Outlook, две различни поведения при едни и същи имейли

Ако сте мигрирали пощенски кутии към Microsoft 365 наскоро и някои потребители се оплакват, че всичките им стари имейли показват една и съща дата (тази на миграцията), вероятно сте забелязали нещо странно: потребителите с класическия Outlook понякога виждат правилната дата в прозореца за преглед, докато тези с новия Outlook за Windows виждат системно датата на миграцията. Една и съща кутия. Едни и същи имейли. Различни резултати.

Това не е бъг в строгия смисъл. Това е архитектурно решение, което има преки последствия върху начина, по който датите се показват след IMAP миграция. За да разберете какво се случва, трябва да влезете в детайлите на имейл заглавките и протокола IMAP, което не е точно лека четива, но обяснява защо никаква манипулация от страна на клиента не е достатъчна за решаване на проблема.

IMAP INTERNALDATE: истинският виновник

Когато имейл се съхранява на IMAP сървър, той има два вида дати, които съществуват едновременно и не се смесват.

Първата е заглавката Date:, дефинирана от RFC 2822. Това е датата, записана в самото съобщение - тази, която подателят е поставил в момента на изпращане. Тя е част от тялото на съобщението и никога не се променя, независимо какъв път е извървял имейлът след това.

Втората е INTERNALDATE - метаданни, управлявани от IMAP сървъра, извън съобщението. Това е датата, на която сървърът е записал съобщението. При нормална миграция сериозните инструменти запазват оригиналния INTERNALDATE. Но при лошо конфигурирана миграция, или с инструменти, които не управляват правилно тези метаданни, INTERNALDATE се нулира до датата на самата миграция. Резултатът: всички мигрирани имейли носят еднаква дата на получаване от гледна точка на сървъра.

(Между другото, ако сте чели логовете на imapsync или MigrationWiz, знаете, че съществуват специфични опции за запазване на INTERNALDATE. Тези опции не винаги работят и някои целеви сървъри отказват да ги зачитат.)

Класическият Outlook: как чете датите

Класическият Outlook, тоест COM версиите, инсталирани локално (Outlook 2016, 2019, 2021 и настолният клиент Microsoft 365 Apps), използва малко по-сложен механизъм, за да определи коя дата да показва в списъка с имейли.

За имейлите в папката "Изпратени" той разчита на заглавката Date:. За получените имейли използва приоритетно INTERNALDATE на сървъра, но в определени контексти (особено когато е въвлечен OST кешът или при първото показване в прозореца за преглед) може също да чете веригата от заглавки Received:, за да реконструира приблизителна оригинална дата.

Точно затова се наблюдава това непоследователно поведение: класическият Outlook понякога може да покаже правилната дата в прозореца за преглед, защото чете оригиналната заглавка Date: на съобщението за детайлния преглед, дори ако самият списък с имейли използва повредения INTERNALDATE. Но внимание - това не е надеждно и не поправя нищо. Сортирането остава счупено, търсенето по дата остава грешно.

Новият Outlook: коренно различна архитектура

Новият Outlook за Windows, разгърнат постепенно от края на 2023 г., вече не е COM приложение. По същество това е Progressive Web App (PWA), базирана на същата кодова база като Outlook в уеб (OWA). Тази преработка има дълбоки последствия.

Новият Outlook делегира напълно показването на дати на Microsoft 365 API. Той не чете заглавките Received:, не разравя веригата от заглавки, за да намери оригинална дата, и не прави никакъв опит за реконструкция от страна на клиента. Просто показва това, което сървърът му връща: INTERNALDATE.

Резултатът: ако INTERNALDATE е бил повреден при миграцията, новият Outlook не се колебае. Показва датата на миграцията за всеки засегнат имейл, без изключение, без нюанси. Това е по-последователно и по-предвидимо поведение от класическия Outlook, но прави проблема с миграцията незабавно видим и невъзможен за игнориране.

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

Защо никое решение от страна на клиента не работи

Много администратори опитват решения от страна на клиента, преди да разберат, че проблемът е в сървърните данни. Ето класическите опити и защо се провалят.

Сортиране по "Дата на изпращане" вместо "Дата на получаване"

Сортирането по дата на изпращане в Outlook разчита на заглавката Date: на съобщението, която е непокътната. Така че да, това сортиране може да работи. Но то е пластир, не решение. Търсенето по дата остава счупено. Правилата, базирани на дата, остават неизползваеми. И най-важното: потребителят трябва да преконфигурира ръчно всяка папка, всяка кутия. При 300 кутии това е нереалистично. Сортирането по дата на изпращане не е решение и крайните потребители не разбират защо трябва да сменят навиците си.

Изчистване на кеша на Outlook или пресъздаване на профила

Това не засяга INTERNALDATE от страна на сървъра. След пресъздаване на профила Outlook ресинхронизира имейлите от сървъра и получава абсолютно същите повредени метаданни. Кешът не е проблемът.

Използване на OWA вместо това

OWA и новият Outlook споделят една и съща база данни. Ако INTERNALDATE е повреден на Exchange Online сървъра, OWA показва абсолютно същата грешна дата. Смяната на клиента не променя данните.

Проблемът е на сървъра, в метаданните на всяко съобщение. Никакво действие от страна на клиента не може да коригира данни, съхранени от страна на сървъра.

Капанът на заглавките Received: защо усложняват всичко

Когато инструмент за миграция копира имейл от един сървър на друг чрез IMAP, целевият сървър автоматично добавя заглавка Received: в горната част на веригата, с датата и часа на вмъкването. Това е нормалното поведение на SMTP и IMAP сървъри, съответстващи на RFC стандартите.

Тези заглавки се натрупват в обратен ред на пътя, извървян от имейла. Най-новата е най-горе. Някои имейл клиенти четат първата заглавка Received:, за да оценят датата на получаване, което дава датата на миграцията вместо оригиналната дата.

Уточнение: това поведение не е характерно само за един инструмент. BitTitan MigrationWiz, CloudM, imapsync, GSMMO и дори ръчно IMAP копиране между два Thunderbird клиента - всички дават същия резултат. Оригиналната заглавка Date: остава непокътната в съобщението. Именно това прави корекцията технически възможна. Но INTERNALDATE е отделни метаданни, управлявани от сървъра, и не може да се коригира само чрез манипулиране на заглавките на съобщението от страна на клиента.

За повече подробности относно този механизъм, статията за IMAP INTERNALDATE и счупените дати разяснява как тези метаданни се управляват в зависимост от сървъра.

Кои инструменти за миграция причиняват този проблем в Microsoft 365

Въпросът се появява постоянно: всички ли инструменти за миграция предизвикват този проблем?

Краткият отговор е, че зависи от конфигурацията и целевата платформа. При Exchange Online / Microsoft 365 сървърът е особено строг при управлението на INTERNALDATE. Дори инструменти, които се опитват да го запазят, понякога се провалят, тъй като Graph API и EWS (Exchange Web Services) се държат различно в зависимост от използвания метод на вмъкване.

BitTitan MigrationWiz е един от най-разпространените инструменти за миграции към Microsoft 365, и е също един от тези, чиито проблеми с датите са най-добре документирани. Страницата коригиране на датите от миграция с BitTitan в Microsoft 365 обхваща специфичните конфигурации за следене. CloudM и imapsync имат своите особености, документирани съответно на коригиране на датите от миграция с CloudM в Microsoft 365 и коригиране на датите от миграция с imapsync в Microsoft 365.

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

Защо домашен скрипт е лоша идея тук

Разбирането на проблема понякога създава илюзията, че решението е просто. Не е, не в производствен мащаб.

Промяната на метаданните на имейли, съхранени в Exchange Online, не е тривиална задача. Microsoft Graph API налага строги ограничения на честотата (грешката 429 Too Many Requests при нощен batch се появява бързо). Управлението на имейли, подписани с S/MIME или криптирани с PGP, изисква специално внимание, за да не се обезсилят подписите. Multipart структури с обемисти прикачени файлове добавят ограничения при мрежови времена за изчакване. И най-важното: как да проверите, имейл по имейл, че корекцията е проработила без да промени съдържанието или прикачените файлове?

Скрипт, който работи добре на 50 тестови имейла, няма да се държи по същия начин при кутия с 40 000 съобщения и 8 години история. Вероятността краен случай да счупи нещо нараства с всеки допълнителен хиляда съобщения. И без механизъм за връщане назад, грешка по средата оставя кутията в несъвместимо състояние.

Вижте също: коригиране на дати на имейли след миграция към Microsoft 365 за пълен преглед на наличните опции.

Какво прави Redate.io конкретно

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

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

Новият Outlook след това показва правилните дати, защото сървърните данни са коригирани, а не скрити.

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