Новий 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 повністю делегує відображення дат API Microsoft 365. Він не читає заголовки 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. Навіть інструменти, які намагаються її зберегти, іноді зазнають невдачі, бо API Graph і EWS (Exchange Web Services) поводяться по-різному залежно від використаного методу вставки.

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

Спільне для всіх цих інструментів: оригінальний заголовок Date: переживає міграцію. Це основа, на якій виправлення стає можливим.

Чому саморобний скрипт - погана ідея

Розуміння проблеми іноді створює ілюзію, що рішення просте. Воно не є таким - не в умовах реального виробничого середовища.

Зміна метаданих листів, що зберігаються на Exchange Online, - нетривіальне завдання. API Graph від Microsoft накладає суворі обмеження на кількість запитів (помилка 429 Too Many Requests під час нічного пакетного завдання трапляється швидко). Обробка листів, підписаних S/MIME або зашифрованих PGP, потребує особливої уваги, щоб не анулювати підписи. Багаточастинні структури з великими вкладеннями додають обмеження на тайм-аути мережі. І найголовніше: як перевірити, лист за листом, що виправлення спрацювало без зміни вмісту або вкладень?

Скрипт, який добре працює на 50 тестових листах, поводитиметься інакше на скриньці з 40 000 повідомлень і 8-річною історією. Імовірність того, що граничний випадок щось зламає, зростає з кожною тисячею додаткових повідомлень. А без механізму відкату помилка на півдорозі залишає скриньку в непослідовному стані.

Дивіться також: виправлення дат листів після міграції Microsoft 365 - повний огляд доступних варіантів.

Що конкретно робить Redate.io

Redate.io відкриває поштову скриньку Microsoft 365 через вхід під власним обліковим записом користувача, без порталу Azure і без реєстрації застосунку, безкоштовно сканує листи з некоректними датами, а потім застосовує власний механізм виправлення до виявлених повідомлень. Багатоетапний конвеєр аналізу виконує зіставлення з сотнями сигнатур відомих інструментів міграції, перевірку відповідності RFC і аналіз ланцюжка заголовків для відновлення коректних метаданих дат.

Кожен виправлений лист перевіряється окремо. Redate.io ніколи не видаляє оригінали. Вони залишаються у видимій папці Вашої поштової скриньки, доки Ви не видалите їх самостійно. Модель оплати - одноразовий платіж за поштову скриньку, без підписки.

Новий Outlook тоді показує правильні дати, бо серверні дані виправлені, а не приховані.

У Вас є скриньки, що постраждали на новому Outlook? Запустіть безкоштовне сканування на Redate.io, щоб точно з'ясувати, скільки листів зачеплено, перш ніж вирішувати, що робити далі.