Проблема: все письма показывают одну и ту же дату
После миграции IMAP пользователи открывают почтовый ящик и обнаруживают пугающую картину: каждое письмо показывает одну и ту же дату. Вместо даты отправки или получения все сообщения помечены датой выполнения миграции. Годы переписки выглядят так, будто пришли в один день.
Для IT-администраторов это настоящий кошмар. Тикеты сыплются потоком, пользователи не могут найти нужное письмо по дате, а хронология почтового ящика, по сути, уничтожена.
Как это выглядит в Outlook
В Microsoft Outlook колонка "Получено" показывает дату миграции для каждого письма. Отправлено ли сообщение в 2018 или в 2023, Outlook отображает одну и ту же дату, когда инструмент миграции обработал почтовый ящик. Входящие, отправленные, каждая папка затронута. Пользователи, привыкшие к сортировке по дате, теряют привычный рабочий процесс.
Как это выглядит в Apple Mail
Apple Mail на macOS и iOS ведёт себя аналогично. Дата рядом с каждым сообщением отражает метку времени миграции, а не исходную дату. Поскольку Apple Mail использует метаданные сервера IMAP для определения отображаемых дат, та же причина даёт тот же видимый результат. Просматривая входящие, Вы видите стену одинаковых дат.
Как это выглядит в Gmail (веб-интерфейс)
Веб-интерфейс Gmail представляет немного другую ситуацию. Веб-клиент Gmail обычно использует заголовок "Date" самого письма, поэтому сообщения могут отображаться с правильной датой в Gmail. Но INTERNALDATE IMAP остаётся неверной, а значит любой IMAP-клиент, подключённый к этому аккаунту Gmail (Outlook, Thunderbird, Apple Mail), покажет дату миграции. Один и тот же ящик выглядит правильно в одном клиенте и неправильно в другом. Довольно сбивает с толку.
Почему так происходит: техническая причина
Корень проблемы в том, как инструменты миграции IMAP обрабатывают заголовки писем и как почтовые клиенты определяют, какую дату показывать. Чтобы разобраться, нужно кратко рассмотреть протокол IMAP и структуру заголовков.
Как инструменты миграции IMAP обрабатывают заголовки
Когда письмо мигрирует с одного сервера на другой, инструмент миграции скачивает исходное сообщение с сервера-источника и загружает его на целевой сервер через команду IMAP APPEND. В процессе протокол IMAP обязывает целевой сервер добавить заголовок "Received" к сообщению. Этот заголовок содержит метку времени момента вставки сообщения в новый сервер, то есть дату миграции.
Заголовок "Received", который ломает всё
Электронные письма обычно содержат несколько заголовков "Received", каждый добавлен почтовым сервером, обработавшим сообщение при первоначальной доставке. Клиенты вроде Outlook определяют "дату получения", читая самый верхний заголовок "Received" в цепочке. Когда инструмент миграции добавляет новый заголовок "Received" с меткой времени миграции, он становится самым верхним, и почтовые клиенты показывают эту дату вместо оригинальной.
Это не баг инструмента миграции и не баг почтового клиента. Оба корректно следуют стандартам IMAP и email. Проблема в том, что эти стандарты не были рассчитаны на массовую миграцию, и взаимодействие IMAP APPEND с логикой отображения дат даёт нежелательный результат.
INTERNALDATE и заголовок Date
Серверы IMAP хранят два разных значения даты для каждого сообщения. Заголовок "Date" является частью самого письма, он фиксирует, когда сообщение было составлено и отправлено. INTERNALDATE, это метаданные, хранимые сервером IMAP, обозначающие момент доставки или вставки сообщения на конкретный сервер.
Некоторые инструменты миграции пытаются сохранить оригинальную INTERNALDATE, задавая её во время команды APPEND. Но даже когда INTERNALDATE задана правильно, добавленный заголовок "Received" всё равно вызывает проблемы в клиентах, которые отдают приоритет дате из "Received" перед INTERNALDATE.
Какие инструменты миграции вызывают эту проблему
Практически все инструменты миграции IMAP могут спровоцировать эту проблему. Дело в самом протоколе IMAP, а не в конкретном инструменте. Некоторые, однако, чаще ассоциируются с проблемой из-за широкого распространения.
BitTitan MigrationWiz
BitTitan MigrationWiz, один из самых популярных коммерческих инструментов миграции, которым пользуются MSP и IT-консультанты. MigrationWiz добавляет заголовок "Received" с "mx.migrationwiz.com" в процессе миграции. Этот заголовок становится самым верхним в цепочке, что приводит к отображению даты миграции в Outlook и других IMAP-клиентах. См. подробные руководства по исправлению дат BitTitan в Outlook, Microsoft 365, Google Workspace и Exchange Online.
CloudM Migrate
CloudM Migrate (ранее Cloud Migrator) широко используется для миграций Google Workspace. Как и другие инструменты, CloudM добавляет собственный заголовок "Received" при вставке через IMAP. Письма, мигрированные с помощью CloudM, показывают дату миграции в клиентах, опирающихся на заголовок "Received". См. руководства по исправлению дат CloudM в Gmail, Outlook, Google Workspace и Microsoft 365.
imapsync
imapsync, популярный инструмент с открытым кодом среди Linux-администраторов и хостинг-провайдеров. Хотя imapsync пытается сохранить INTERNALDATE, целевой сервер всё равно добавляет заголовок "Received" при операции APPEND. FAQ imapsync признаёт это ограничение, но не предлагает встроенного решения для удаления добавленного заголовка после миграции. См. руководства по исправлению дат imapsync в Outlook, Gmail, Microsoft 365 и Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO), собственный инструмент Google для миграции из Exchange или файлов PST Outlook в Google Workspace. GSMMO может вызвать ту же проблему с датами, особенно когда миграция включает промежуточный этап IMAP. См. руководства по исправлению дат GSMMO в Outlook, Gmail и Apple Mail.
Exchange Admin Center (встроенный импорт IMAP)
Центр администрирования Exchange от Microsoft включает встроенную функцию импорта IMAP для миграции в Exchange Online (Microsoft 365). Этот встроенный инструмент миграции добавляет заголовки "Received" при импорте, вызывая ту же проблему отображения дат. См. руководства по исправлению дат импорта IMAP Exchange в Outlook и OWA.
Ручное копирование через IMAP
Даже ручное копирование писем между серверами IMAP через клиент вроде Thunderbird может вызвать эту проблему. Когда почтовый клиент копирует сообщение через IMAP, целевой сервер обрабатывает его как новую вставку и добавляет собственный заголовок "Received" с текущей меткой времени. См. руководства по исправлению дат ручного копирования IMAP в Outlook, Gmail, Thunderbird и Apple Mail.
Почему обходные решения не работают
Столкнувшись с проблемой, пользователи и администраторы обычно пробуют несколько подходов, прежде чем осознают, что ни один из них не решает вопрос по-настоящему.
"Сортируйте по дате отправки", почему этого недостаточно
Самый распространённый совет - переключиться с сортировки по дате "получения" на дату "отправки" в почтовом клиенте. Это действительно меняет порядок отображения, но не исправляет данные. Результаты поиска по-прежнему показывают неправильную дату. Интеграции с календарём, инструменты комплаенса и автоматизированные рабочие процессы, зависящие от даты получения, продолжают сбоить. И пользователям нужно менять этот параметр на каждом устройстве и в каждой папке.
Повторная миграция: дорого и рискованно
Некоторые администраторы рассматривают повторный запуск миграции, надеясь избежать проблемы с датами во второй раз. Такой подход дорог (от 500 до 5000 EUR в зависимости от числа ящиков), затратен по времени и рискован. Повторная миграция привносит тот же заголовок "Received", удваивает риск потери данных и требует значительного простоя. Повторная миграция не решает проблему дат, если инструмент миграции не был принципиально изменён.
Ручное редактирование заголовков: нужен доступ к серверу
Технически исправление подразумевает удаление заголовка "Received", добавленного при миграции, из каждого письма. Но ручное выполнение требует прямого доступа к серверу, знания структуры заголовков и написания скрипта. Для почтового ящика из 10 000 писем ручное редактирование непрактично и чрезвычайно подвержено ошибкам. Подписанные S/MIME письма, зашифрованные PGP сообщения, multipart-структуры с вложенными границами MIME, проблемы Content-Transfer-Encoding, не-ASCII заголовки (RFC 2047), крупные вложения - каждый из этих случаев может привести к необратимому повреждению данных простым скриптом. Как подтвердить, что 10 000 исправленных писем целы? Без специализированной системы верификации - никак.
Настоящее решение: восстановить исходные даты
Правильный подход - выявить артефакты миграции в цепочке заголовков каждого письма и применить точечные корректировки, восстанавливающие исходный хронологический порядок во всех почтовых клиентах. На самом деле это не просто редактирование заголовка. Процесс включает валидацию соответствия RFC, сохранение структуры сообщения и сопоставление с базой данных профилей известных инструментов миграции.
Как Redate.io исправляет эту проблему
Redate.io подключается к почтовому ящику (Google Workspace, Microsoft 365 или любой IMAP-сервер) и анализирует каждое письмо для выявления сообщений, затронутых заголовками миграции. Анализ бесплатный и показывает точное количество затронутых писем до любой оплаты.
Для каждого затронутого письма проприетарный движок коррекции Redate.io пропускает сообщение через многоступенчатый конвейер анализа. Движок сопоставляет сигнатуры сотен профилей известных инструментов миграции, созданных на основе обработки больших объёмов реальных почтовых данных. Он обрабатывает проблемы кодировки, multipart-структуры, inline-вложения и десятки особых случаев, из-за которых самописный скрипт повредил бы данные (не то открытие, которое хочется сделать в понедельник утром). Каждое исправленное письмо проходит проверку целостности до финализации. Оригинал перемещается в видимую папку "Redate.io - Originals" (не удаляется) и хранится 30 дней.
Результат? Письма показывают свои правильные исходные даты во всех клиентах. Сортировка снова работает. Хронология почтового ящика восстановлена.
Часто задаваемые вопросы
Можно ли исправить даты через месяцы после миграции?
Да. Оригинальный заголовок "Date" сохраняется внутри письма независимо от давности миграции. Redate.io может исправить даты через недели, месяцы или даже годы после миграции. Коррекция работает, пока исходные заголовки письма не повреждены.
Исправление удалит мои письма?
Нет. Redate.io никогда не удаляет письма. Оригиналы перемещаются в видимую папку "Redate.io - Originals" внутри почтового ящика, где остаются доступными 30 дней. Каждое исправленное письмо сверяется с оригиналом до финализации. Если верификация не пройдена для какого-либо сообщения, оригинал остаётся нетронутым.
Работает ли это с общими почтовыми ящиками?
Да. Redate.io работает с общими ящиками в Google Workspace и Microsoft 365. Для общих ящиков требуется доступ уровня администратора для авторизации подключения. Процесс идентичен личным ящикам: анализ, коррекция, верификация.
Готовы восстановить правильные даты? Запустите бесплатный анализ, чтобы узнать, сколько писем затронуто в каждом почтовом ящике.