Перестворення профілю Outlook: чому змінюються дати

Стандартний крок усунення неполадок, який ламає дати

Користувач скаржиться, що Outlook більше не синхронізується. Листи не надходять, папка "Надіслані" не оновлюється, колесо крутиться нескінченно. Технік діагностує пошкоджений профіль, видаляє файл OST, відтворює профіль Outlook з нуля. Результат: Outlook знову підключається, листи з'являються, все, здається, працює.

Аж до наступного ранку, коли користувач відкриває поштову скриньку і розуміє, що 8 років листування відображають одну дату: сьогодні.

Це точно той самий симптом, що й при невдалій IMAP-міграції. І з тих самих причин.

Що відбувається технічно

Щоб зрозуміти, чому перестворення профілю дає такий результат, треба повернутися до розрізнення, яке більшість техніків погано знають: різниця між заголовком Date: листа та його INTERNALDATE IMAP.

Кожен лист містить у заголовках RFC 2822 поле Date:, яке вказує, коли повідомлення було надіслано. Це поле записується поштовим клієнтом відправника в момент відправлення, а потім передається без змін через усі сервери до Вашої скриньки. Воно ніколи не змінюється. Лист, надісланий 14 березня 2019 року о 09:32, завжди матиме це поле Date: незмінним, незалежно від того, що відбуватиметься далі.

INTERNALDATE IMAP - це інша річ. Це метадані, якими керує поштовий сервер, незалежно від вмісту повідомлення. Вони вказують, коли повідомлення було "покладено" до скриньки. За нормальних умов, коли лист надходить через SMTP, сервер записує час отримання як INTERNALDATE. Лист, отриманий 14 березня 2019 року, матиме INTERNALDATE, узгоджений з датою надсилання.

Outlook за замовчуванням сортує та відображає листи за INTERNALDATE, переданим IMAP-сервером, а не за полем Date: самого повідомлення. (До речі, якщо Ви коли-небудь відкривали повні властивості листа в Outlook, щоб побачити необроблені заголовки, то знаєте, що це не найзручніше читання.)

Що запускає видалення файлу OST

Коли Outlook використовує IMAP-обліковий запис, він підтримує локальну базу даних: файл OST (Offline Storage Table). Цей файл є локальним дзеркалом листів, збережених на сервері, з їхніми метаданими, статусами прочитання, категоріями тощо.

Видалення файлу OST рівнозначне видаленню цього локального дзеркала. Outlook повинен завантажити все заново з IMAP-сервера.

Проблема? Коли Outlook перезавантажує повідомлення через IMAP, він використовує команду FETCH для отримання вмісту. Але він не завжди використовує команду FETCH INTERNALDATE для отримання та збереження оригінальної дати IMAP. У деяких конфігураціях та версіях Outlook клієнт відновлює свій локальний індекс, використовуючи дату, коли він перезавантажив повідомлення, а не INTERNALDATE, збережений на сервері.

І тоді всі листи скриньки виявляються датованими днем перезавантаження.

Не всі версії Outlook поводяться однаково

Уточнення: ця поведінка не стосується всіх версій Outlook однаково, і саме тут діагностика стає складною.

Outlook 2016 та 2019 у режимі IMAP мають задокументовану поведінку некоректного відновлення індексу після видалення кешу. Новий Outlook (веб-версія, що поступово розгортається з кінця 2023 року) по-іншому керує кешем і може давати різні результати. Outlook через Exchange/Microsoft 365 з обліковим записом у режимі Exchange менш схильний до цієї конкретної проблеми, оскільки протокол MAPI/Exchange обробляє синхронізацію інакше, ніж IMAP.

Але якщо Ваш користувач налаштував IMAP-обліковий запис у класичному Outlook, і технік видалив файл OST або відтворив профіль: ризик цілком реальний.

Як відрізнити цей випадок від справжньої міграції

ІТ-адміністратор, який отримує тікети "мої дати неправильні" після відтворення профілю, може помилково вирішити, що це проблема міграції. Ось як розрізнити ці два випадки.

Випадок IMAP-міграції

При IMAP-міграції (BitTitan, CloudM, imapsync тощо) інструмент міграції копіює листи з одного сервера на інший. Для кожного скопійованого повідомлення він створює новий запис на сервері призначення через команду IMAP APPEND. Якщо інструмент явно не вказує оригінальний INTERNALDATE у цій команді, сервер призначення записує поточний час як INTERNALDATE. Паралельно деякі інструменти також додають заголовок Received: з датою міграції, що в певних клієнтах погіршує ситуацію. Детальний опис цього механізму можна знайти в статті про IMAP INTERNALDATE і зламані дати.

Випадок відтворення профілю

Тут листи залишаються на тому самому сервері з тими самими оригінальними INTERNALDATE. З боку сервера нічого не змінилося. Лише локальний кеш Outlook був відновлений з некоректними датами. Видимий симптом ідентичний (всі листи відображають однакову нещодавню дату), але причина інша.

Для підтвердження: увійдіть до скриньки через вебпошту (Gmail, Outlook.com або інтерфейс вебпошти Вашого хостингу). Якщо дати у вебпошті правильні, проблема суто локальна в Outlook. Якщо дати також неправильні у вебпошті, проблема на стороні сервера (міграція або зміна INTERNALDATE на самому сервері).

Чому оригінальні дати залишаються відновлюваними

Хороша новина: в обох випадках (міграція або відтворення профілю) оригінальні дати не втрачаються.

Заголовок Date: RFC 2822 є невід'ємною частиною повідомлення. Він такий же незмінний, як і текст листа чи вкладення. Лист, надісланий у 2017 році, містить у своєму необробленому тексті щось на кшталт:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Цей рядок присутній у повідомленні, збереженому на сервері. Він не був змінений. Те, що Outlook відображає (неправильно), є метаданими, зовнішніми щодо вмісту повідомлення.

Саме це робить виправлення можливим. Рушій Redate.io аналізує ланцюжок заголовків кожного повідомлення, щоб витягти реальну оригінальну дату, а потім виконує цільове виправлення метаданих без зміни вмісту повідомлення. INTERNALDATE, видимий для Outlook, відновлюється на основі цієї автентичної інформації, яка завжди присутня в повідомленні.

Пастка "чистого" відтворення

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

Три дні по тому користувач телефонує знову: він шукає лист від постачальника з минулого року, але в Outlook всі його листи за 2023 рік з'являються як отримані "вчора". Він нічого не знаходить. Автоматичне архівування, можливо, класифікувало нещодавні листи як старі. А його керівник запитує листування за вересень 2022 року щодо спору.

Такий сценарій трапляється регулярно. Не тому що технік погано виконав свою роботу, а тому що ця поведінка Outlook не задокументована наочно в стандартних посібниках з усунення неполадок.

Хибні рішення, які нічого не вирішують

Сортування листів за "Датою надсилання" замість "Дати отримання" в Outlook - це перше, що намагаються зробити користувачі. І це, здається, працює... поки вони не розуміють, що сортування за датою надсилання доступне лише для певних папок, що воно зникає при зміні виду, і що інші застосунки (мобільний, вебпошта, правила автоматичного сортування) продовжують використовувати некоректний INTERNALDATE.

Сортування за датою надсилання - це не рішення. Це пластир, який приховує симптом, не торкаючись реальної проблеми. Детальніше про це в статті Сортування за датою відправлення - не рішення.

Відтворити профіль вдруге? Це нічого не змінює, якщо Outlook відновлює кеш з поточною датою.

Експортувати, а потім імпортувати PST? Обережно. Експорт PST з Outlook з неправильними датами експортує неправильні метадані. Файл PST міститиме неправильні дати. Повторний імпорт цього файлу нічого не виправить і навіть може погіршити ситуацію, створивши дублікати з суперечливими датами. Ця тема докладно розглядається в статті про імпорт PST в Outlook і дати, які стають сьогоднішніми.

Що робить Redate.io в цьому конкретному випадку

Чи надходить проблема від IMAP-міграції, чи від відтворення профілю Outlook, результат на стороні сервера схожий: листи, метадані дат яких суперечать їхньому реальному вмісту.

Redate.io підключається безпосередньо до поштової скриньки (Google Workspace, Microsoft 365 або прямий IMAP), сканує всі повідомлення для виявлення тих, у яких метадані неправильні, а потім застосовує багатоетапний аналітичний конвеєр для виправлення кожного листа окремо. Кожне виправлення перевіряється. Оригінальні повідомлення зберігаються у видимій резервній папці вашої скриньки, і Redate.io ніколи їх не видаляє: вони залишаються там, доки ви самі не видалите їх.

Процес обробляє граничні випадки, з якими саморобні скрипти систематично не справляються: підписані S/MIME повідомлення, листи з не-ASCII кодуванням у заголовках (RFC 2047), складні multipart-структури, заголовки Date: з нестандартними або некоректними часовими поясами. Скрипт, який правильно працює на 50 тестових листах у середовищі розробки, може безповоротно пошкодити 2000 повідомлень у продакшені. У IMAP немає нативного відкату після заміни повідомлення без попереднього резервного копіювання.

Для випадків, пов'язаних саме з Outlook, сторінка виправлення виправлення дат IMAP-копіювання в Outlook детально описує кроки для підключення Вашої скриньки та запуску аналізу.

Як запобігти проблемі під час майбутніх втручань

Якщо Ви технік або ІТ-адміністратор і регулярно працюєте з профілями Outlook, кілька простих звичок допоможуть уникнути цієї ситуації.

Перш ніж видаляти файл OST або відтворювати профіль, перевірте відображувані дати у вебпошті. Якщо вони правильні, зафіксуйте це у своєму тікеті. Після відтворення знову зайдіть у вебпошту і порівняйте дати з тими, що відображаються в Outlook. Якщо з'являється розбіжність, проблему буде виявлено одразу, до того як користувач поскаржиться через три дні.

Для запланованих міграцій чекліст міграції пошти перелічує перевірки, які слід виконати до і після, щоб виявити такий тип проблеми одразу після завершення операції.

Ви відтворили профіль Outlook і тепер усі дати у Вашій скриньці неправильні? Запустіть безкоштовне сканування на Redate.io, щоб виявити уражені листи та виправити метадані без зміни вмісту Ваших повідомлень.