Імпорт PST в Outlook: чому всі дати стають сьогоднішніми

Симптом: всі листи датовані сьогоднішнім днем

Ви щойно завершили імпорт PST в Outlook. Індикатор прогресу досяг 100 %, все пройшло гладко. І раптом ви відкриваєте папку "Вхідні"... і кожен імпортований лист показує сьогоднішню дату. Повідомлення з 2019 року, інше з 2021-го, архів п'ятирічної давності - всі вони мають однакову дату. Дату дня імпорту.

Це не баг відображення. Не проблема часового поясу. Це цілком задокументована поведінка, пов'язана з тим, як IMAP керує метаданими дат. Але для того, хто хоче знайти старі листи за датою, це справжня катастрофа.

Локальний PST і IMAP: два абсолютно різних світи

Перш ніж пояснювати, чому дати ламаються, варто зрозуміти, що таке PST-файл з точки зору управління датами.

PST (Personal Storage Table) - це власний формат Microsoft. Він зберігає листи з повними метаданими: датою відправлення, датою отримання, вкладеннями, категоріями, мітками прочитання. Ці метадані керуються безпосередньо Outlook, поза будь-яким поштовим протоколом. Коли ви переглядаєте PST в Outlook без підключення до сервера, відображувані дати беруться безпосередньо з внутрішніх полів PST-файлу. Поки що все добре.

Проблема виникає, коли ви намагаєтесь перенести цей вміст до поштової скриньки на IMAP-сервері - будь то Microsoft 365, Google Workspace або будь-який звичайний хостинг. Тут ви залишаєте світ PST і потрапляєте у світ IMAP, де правила кардинально змінюються.

IMAP APPEND та INTERNALDATE: серце проблеми

У IMAP кожне повідомлення, збережене на сервері, має два типи даних про дату:

• Заголовок Date: (RFC 2822), який є частиною самого вмісту повідомлення. Це дата, яку відправник вписав у лист.
• INTERNALDATE - метадані, якими керує IMAP-сервер. Вона відображає момент, коли повідомлення було збережено на сервері. Саме це значення Outlook використовує для сортування листів у вигляді "Дата отримання".

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

Коли лист надходить на сервер звичайним чином, поштовий сервер автоматично встановлює INTERNALDATE у момент отримання. Результат: дата, яку показує Outlook, відповідає часу реального надходження повідомлення.

Коли Outlook імпортує PST-файл до IMAP-скриньки, він надсилає кожне повідомлення на сервер командою IMAP APPEND. Стандарт IMAP дозволяє передавати явне значення INTERNALDATE під час APPEND. Але Outlook цього не робить. Він надсилає повідомлення без вказівки INTERNALDATE. Сервер IMAP, не отримавши жодної інструкції, застосовує своє правило за замовчуванням: INTERNALDATE встановлюється рівним поточному часу, тобто моменту імпорту.

Результат: 8000 імпортованих листів, 8000 листів із сьогоднішньою датою.

Чому Outlook поводиться саме так

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

Точніше, ця поведінка стосується імпорту PST через вбудований майстер Outlook (Файл > Відкрити та експортувати > Імпорт/Експорт). Інші методи імпорту - деякі сторонні інструменти або міграції через Exchange Admin Center - можуть поводитись інакше, залежно від їхньої реалізації IMAP APPEND.

Ця поведінка відома і задокументована на форумах Microsoft вже багато років. Вона не змінилася ані в Outlook 2016, ані в Outlook 2019, ані в актуальних версіях Microsoft 365. Користувач, який імпортує PST сьогодні, зіткнеться рівно з тією ж проблемою, що й у 2015 році.

Чим це відрізняється від звичайної IMAP-міграції

Ось тут стає цікаво. Імпорт PST дає результат, схожий на звичайну IMAP-міграцію зі зламаними датами, але механізм інший.

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

При імпорті PST механізм простіший: заголовок Received: від міграції не додається (PST-файли не проходять через проміжний поштовий сервер), але INTERNALDATE просто ніколи не встановлюється в правильне значення. Видимий результат однаковий, а от причина дещо інша.

Ця різниця безпосередньо впливає на підхід до виправлення: метод для IMAP-міграції та для імпорту PST не є цілком ідентичним. Дивіться також чому INTERNALDATE спричиняє хибні дати - там детально розібрано обидва випадки.

Чому налаштування вигляду Outlook нічого не виправляють

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

Сортування за датою відправлення - не рішення. Це пластир.

Ось чому: навіть якщо ви зміните сортування і відображатимете колонку "Дата" (яка відповідає заголовку Date: повідомлення, тобто оригінальній даті), кілька проблем залишаться:

• Пошук Outlook індексує за INTERNALDATE. Пошук "листи за січень 2020" не поверне ваші імпортовані листи за той місяць, бо їхній INTERNALDATE каже, що вони датовані днем імпорту.
• Розділи "Сьогодні", "Цього тижня", "Цього місяця" в інтерфейсі Outlook також базуються на INTERNALDATE, а не на заголовку Date:.
• У веб-інтерфейсах (Outlook Web App, Gmail) і мобільних клієнтах відображувана дата та логіка сортування майже завжди залежать від серверного INTERNALDATE.
• Правила та автоматичні фільтри за датою отримання не працюватимуть коректно.

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

Ресинхронізація OST теж не допоможе

Інша класична спроба: очистити кеш OST і примусово виконати повну ресинхронізацію із сервером. Логіка зрозуміла - а раптом проблема у локальному кеші Outlook, а не на сервері?

Хибний шлях. Файл OST - це локальний кеш, який відображає стан IMAP-сервера. Якщо INTERNALDATE хибний на сервері, він буде хибним і в OST після ресинхронізації. Видалення OST-файлу ніяк не змінює дані, збережені на сервері Exchange Online або Google Workspace. Сервер є джерелом правди.

Єдиний спосіб виправити дати - це виправити метадані безпосередньо на стороні сервера, повідомлення за повідомленням. І саме тут ручне виправлення стає справді складним.

Проблема масштабу: 1 лист - дрібниця. 15 000 - зовсім інша історія

Технічно, розуміючи проблему, можна уявити собі скрипт, який обходить скриньку, зчитує заголовок Date: кожного повідомлення і виправляє INTERNALDATE відповідно. Розуміти проблему - одне. Виправити її на 15 000 листів без утрати жодного - зовсім інше.

Кілька реалій, з якими доведеться зіткнутися:

• Microsoft Graph API та Gmail API мають обмеження запитів (rate limits). Наївний скрипт отримає помилки 429 Too Many Requests, зупиниться посеред виправлення і залишить вас із частково виправленою скринькою - без розуміння, які листи оброблені, а які ні.
• Деякі листи в PST можуть мати відсутні або неправильно сформовані заголовки Date:. Скрипт без обробки таких граничних випадків може пошкодити ці повідомлення або мовчки пропустити їх.
• Підписані (S/MIME) або зашифровані (PGP) листи мають додаткові вимоги до цілісності. Необережна зміна їхніх метаданих може знищити криптографічний підпис.
• Структури multipart/alternative зі складними MIME-межами іноді поводяться непередбачувано при операціях модифікації.
• Жодного механізму відкату. Якщо щось пішло не так у середині обробки - як повернутися до початкового стану?

Скрипт, який чудово працює на 10 тестових листах, не впорається з виробничою скринькою на 50 000 повідомлень. Торік клієнт з PST-архівом розміром 40 ГБ спробував виправити це за допомогою Python-скрипту зі Stack Overflow. Результат: 3000 листів-дублікатів, 200 повідомлень із недоступними вкладеннями і два тижні ручного очищення.

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

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

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

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

Дивіться також:

• Виправлення дат листів після міграції Microsoft 365
• Outlook: дата отримання IMAP vs дата відправлення
• Чи можна виправити дати листів після завершення міграції?

Імпорт PST перезаписав усі дати ваших листів? Скануйте свою скриньку безкоштовно на Redate.io - щоб оцінити масштаб проблеми перед тим, як діяти.