Все старые письма с одной датой: что происходит?

Симптом: все старые письма сгруппированы по одной дате

Вы открываете Outlook, Gmail или Apple Mail. Что-то не так. Сотни, а иногда тысячи старых писем отображают одну и ту же дату: несколько дней назад или несколько недель назад. Сообщения из 2021-го, 2019-го, 2016 года выглядят так, будто пришли вчера. Сортировка по дате больше ничего не значит. Вы ищете важное письмо прошлого года, а оно утоплено в блоке из тысяч сообщений, которые словно пришли в один день.

Новые письма отображаются с правильными датами. Проблема касается только старых сообщений.

Что вообще могло случиться?

Первый порыв: обвинить программу

Естественно, думаешь об ошибке. Outlook завис. Обновление пошло не так. Файл повредился. И тут начинается долгий путь: ищешь «баг дата Outlook», попадаешь на форумы про файлы OST, SCANPST.exe, пересоздание профиля с нуля...

Тратишь два часа на всё это. Проблема остаётся.

Кстати, SCANPST - это инструмент восстановления локальных файлов данных Outlook. Он может исправить некоторые повреждения файла, но не трогает данные, хранящиеся на почтовом сервере. То есть даже если Вы идеально восстановите файл OST, даты останутся неправильными, потому что проблема не на Вашей стороне.

Проблема находится в самих письмах, на сервере.

Что на самом деле произошло: миграция

В подавляющем большинстве случаев этот симптом появляется после миграции почты. Ваша компания перешла со старой системы на Google Workspace, Microsoft 365 или новый сервер. Кто-то где-то использовал инструмент для переноса всех писем с одного места на другое.

Вас, возможно, не предупредили. Или предупредили, но Вы не связали это с проблемой дат. Всё это вполне понятно.

Инструменты миграции делают огромную работу: копируют тысячи сообщений, целые папки, вложения. Но у них есть один неочевидный побочный эффект. Когда письмо переносится с одного сервера на другой, инструмент добавляет в него небольшую техническую строку, называемую заголовком «Received:», которая фиксирует, когда сообщение поступило на новый сервер. То есть: дату миграции.

Вот в чём дело.

Как почтовый клиент решает, какую дату показывать

Письмо на самом деле содержит несколько разных дат, скрытых в технических данных. Есть исходная дата отправки (та, которую Вы обычно видите), а также заголовки «Received:», фиксирующие каждый этап пути сообщения по интернету.

(Если Вы когда-нибудь нажимали «Показать источник» или «Посмотреть полные заголовки» у письма, Вы, вероятно, видели эти загадочные строки, похожие на непонятный блок текста. Это именно они.)

В обычной ситуации почтовый клиент смотрит на самый последний заголовок «Received:», чтобы определить дату отображения письма. Эта логика работает отлично: последний «Received:» всегда соответствует моменту, когда сообщение попало в Вашу почту, то есть через несколько секунд после отправки.

Но после миграции эта логика оборачивается против Вас. Инструмент миграции добавил новый заголовок «Received:» в самом начале, с датой переноса. Ваш почтовый клиент читает этот заголовок первым, видит дату миграции и отображает её. Исходная дата отправки по-прежнему там, нетронутая, зарыта глубже в данных письма. Но клиент её не видит, потому что останавливается на первом заголовке.

Результат: 8000 писем, которые словно пришли в один вторник ноября.

Какие инструменты вызывают эту проблему?

Наиболее распространённые инструменты миграции ведут себя именно так. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (бесплатный инструмент Google для миграции из Outlook) и многие другие. Это не совсем их недостаток: это следствие технических особенностей протокола электронной почты. Эти инструменты добавляют заголовок, потому что именно это протокол предписывает делать при передаче сообщения с одного сервера на другой.

Проблема в том, что никто не предупреждает пользователей о том, что это произойдёт.

Если Ваша компания недавно сменила почтовую систему или ИТ-служба выполнила «миграцию в облако», это, скорее всего, и есть источник проблемы. Проверить можно, посмотрев на затронутые даты: все они примерно совпадают по времени? Если да, этот период и есть дата миграции.

Ложные решения, которых стоит избегать

Несколько решений, которые часто встречаются на форумах и не работают:

Восстановление файла данных через SCANPST

Выше уже говорилось: SCANPST восстанавливает локальные файлы Outlook (файлы .pst или .ost, хранящиеся на Вашем компьютере). Он не изменяет письма на сервере. После восстановления письма по-прежнему будут с неправильными датами, потому что эти даты находятся в самих письмах, а не в локальном файле.

Пересоздание профиля Outlook

Та же логика. Пересоздать профиль Outlook - значит начать с чистого листа локально, а затем снова скачать все письма с сервера. Скачанные письма будут иметь точно такие же неправильные даты, что и раньше. Вы просто потратили время на перенастройку.

Сортировка по «дате отправки» вместо «даты получения»

На некоторых форумах предлагают изменить критерий сортировки в Outlook: с даты получения на дату отправки. Это иногда помогает... но не всегда. И это ничего не решает для других программ, других устройств или других людей, имеющих доступ к Вашему почтовому ящику. Глубинная причина никуда не уходит. Сортировка по дате отправки - не решение, это пластырь.

Переустановка почтового клиента

Нет. Письма хранятся на сервере, а не в программе. Переустановка Outlook, Gmail, Apple Mail или Thunderbird не изменит данные, хранящиеся в интернете.

Хорошая новость: настоящие даты никуда не делись

Вот что важно понять, и именно это делает исправление возможным: исходная дата отправки каждого письма не была стёрта. Она по-прежнему там, в письме, в заголовке «Date:», который соответствует дате отправки, выбранной отправителем. Это стандарт электронной почты (определённый техническим документом RFC 2822), который все инструменты миграции соблюдают, потому что его изменение было бы грубым нарушением стандартов.

Иными словами, если Вы получили письмо 14 марта 2022 года, в нём до сих пор где-то хранится эта дата. Просто она больше не та, что Ваш почтовый клиент показывает первой.

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

Почему не стоит пытаться исправить это самостоятельно?

Возможно, Вы думаете: а что, если ИТ-специалист просто напишет скрипт для исправления? Понять, что происходит, - одно. Исправить это аккуратно на тысячах писем, не потеряв ни одного, - совсем другое.

Письмо - это не простой текстовый файл. Оно может содержать вложения, цифровые подписи, контент в сложных форматах кодирования. Изменение метаданных такого сообщения без нарушения его структуры требует обработки десятков частных случаев: письма с электронной подписью (S/MIME), зашифрованные сообщения (PGP), нестандартные кодировки, многосоставные структуры... Самодельный скрипт, который работает на 20 тестовых письмах, скорее всего, не справится с рабочим ящиком из 15 000 сообщений. И если что-то пойдёт не так, как убедиться, что ни одно письмо не пострадало и не потерялось? С самодельным скриптом это невозможно.

Без механизма сохранения и индивидуальной проверки каждого письма риск побочного ущерба вполне реален.

Что делает Redate.io

Redate.io - сервис, созданный именно для этой проблемы. Он подключается к Вашему почтовому ящику (Google Workspace, Microsoft 365 или IMAP-сервер), определяет письма, у которых даты были искажены при миграции, и исправляет их с помощью проприетарного движка, который выполняет многоступенчатый анализ цепочки заголовков и восстанавливает метаданные даты для каждого сообщения.

Каждое исправленное письмо проверяется индивидуально. Оригиналы сохраняются в видимой резервной папке на 30 дней. Если что-то пойдёт не так, можно откатиться.

Первоначальное сканирование бесплатно: Redate.io анализирует Ваш ящик и показывает точное количество затронутых писем до того, как Вы примете какое-либо решение. Никаких сюрпризов.

Тарификация - единовременная оплата, исходя из объёма писем для исправления. Без подписки. Платите один раз, проблема решена.

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