Импорт 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 устанавливается в текущее время, то есть в момент импорта.

Результат: 8 000 импортированных писем - 8 000 писем с сегодняшней датой.

Почему 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» не вернёт импортированные письма за январь 2020-го - их INTERNALDATE говорит, что они получены в день импорта.
• Папки «Сегодня», «На этой неделе», «В этом месяце» в интерфейсе Outlook основаны на INTERNALDATE, а не на заголовке Date:.
• В веб-интерфейсах (Outlook Web App, Gmail) и на мобильных клиентах отображаемая дата и поведение сортировки почти всегда зависят от серверного INTERNALDATE.
• Правила и автоматические фильтры, применённые к дате получения, будут работать некорректно.

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

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

Ещё одна классическая попытка: очистить кэш OST и принудительно выполнить полную пересинхронизацию с сервером. Логика такая: может быть, проблема в локальном кэше Outlook, а не в сервере.

Ложный след. Файл OST - это локальный кэш, который отражает состояние IMAP-сервера. Если INTERNALDATE неверен на сервере, после пересинхронизации он будет неверен и в OST. Удаление OST не меняет данные, хранящиеся на Exchange Online или Google Workspace. Авторитетным источником является сервер.

Единственный способ исправить даты - скорректировать метаданные непосредственно на стороне сервера, сообщение за сообщением. И вот здесь ручное исправление становится по-настоящему сложным.

Проблема масштаба: одно письмо - пустяк. 15 000 - совсем другая история

Технически, понимая проблему, можно представить себе скрипт, который обходит ящик, читает заголовок Date: каждого сообщения и исправляет INTERNALDATE. Понять проблему - это одно. Исправить 15 000 писем, не потеряв ни одного, - совсем другое.

Несколько реалий из практики:

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

Скрипт, который работает на 10 тестовых письмах, не будет работать на рабочем ящике с 50 000 сообщений. В прошлом году клиент с PST-архивом в 40 ГБ попытался исправить это с помощью Python-скрипта, найденного на Stack Overflow. Итог: 3 000 дублирующихся писем, 200 сообщений с недоступными вложениями и две недели ручной уборки.

Что делает Redate.io в этом конкретном случае

Redate.io анализирует метаданные каждого сообщения в целевом ящике, выявляет письма с некорректными датами (включая импортированные из PST) и применяет исправление через проприетарный движок коррекции. Многоступенчатый pipeline анализирует цепочку заголовков каждого сообщения, извлекает оригинальную дату с проверкой соответствия RFC и выполняет точечную коррекцию метаданных без изменения содержимого письма.

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

Первоначальное сканирование бесплатно. Оно позволяет увидеть точное количество затронутых писем и распределение некорректных дат - до того, как принимать какие-либо решения.

Смотрите также:

• Исправить даты писем после миграции Microsoft 365
• Outlook: дата получения IMAP против даты отправки
• Можно ли исправить даты писем после миграции?

Импорт PST перезаписал все даты в Ваших письмах? Бесплатно просканируйте свой ящик на Redate.io, чтобы оценить масштаб проблемы прежде чем действовать.