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

Стандартный способ починки, который ломает даты

Пользователь жалуется: Outlook перестал синхронизироваться. Письма не приходят, папка «Отправленные» не обновляется, колесо крутится бесконечно. Техник диагностирует повреждённый профиль, удаляет файл OST, пересоздаёт профиль Outlook с нуля. Результат: Outlook снова подключается, письма появляются, всё как будто работает.

До следующего утра, когда пользователь открывает почту и обнаруживает, что восемь лет переписки показывают одну и ту же дату: сегодняшнюю.

Это в точности тот же симптом, что и при неудачной миграции 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-сервера.

Проблема в том, что при повторной загрузке сообщения через IMAP Outlook использует команду 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), сканирует все сообщения для выявления тех, чьи метаданные неправильны, затем применяет многоступенчатый конвейер анализа для исправления каждого письма по отдельности. Каждое исправление проверяется. Исходные сообщения остаются в видимой резервной папке почтового ящика, пока вы не удалите их сами.

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

Для случаев, связанных конкретно с Outlook, страница исправления исправление дат ручного копирования IMAP в Outlook описывает шаги для подключения Вашего ящика и запуска анализа.

Предотвращение проблемы при следующих вмешательствах

Если вы техник или ИТ-администратор и регулярно работаете с профилями Outlook, несколько простых привычек помогут избежать этой ситуации.

Перед удалением файла OST или пересозданием профиля проверьте отображаемые даты в вебмейле. Если они правильные, зафиксируйте это в тикете. После пересоздания снова войдите в вебмейл и сравните отображаемые там даты с теми, что показывает Outlook. Если есть расхождение, проблема выявлена сразу, до того как пользователь пожалуется через три дня.

Для запланированных миграций в статье чеклист миграции почты перечислены проверки, которые нужно выполнить до и после, чтобы обнаружить такие проблемы сразу по завершении операции.

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