eM Client : даты писем после импорта PST или Thunderbird

Симптом: все письма с одной и той же датой

Вы только что завершили импорт PST в eM Client, или перешли с Thunderbird на новый почтовый ящик. Импорт прошёл без видимых ошибок. Но открыв папку «Входящие», Вы замечаете что-то странное: сотни, а иногда тысячи писем показывают одну и ту же дату - дату импорта. Письмо из 2019 года выглядит так, будто пришло вчера. Контракт, подписанный три года назад, отображается как только что полученный.

Первая реакция - обвинить eM Client. Неправильный параметр, не та колонка сортировки, визуальный баг... Начинаете рыться в настройках. Переключаетесь между «Датой получения» и «Датой отправки». Ничего не меняется. Точнее, кое-что меняется, но суть проблемы остаётся.

Потому что проблема не в eM Client. Она в метаданных на сервере.

Настоящая причина: INTERNALDATE IMAP перезаписывается при импорте

Чтобы разобраться, нужно опуститься на уровень ниже и понять, как протокол IMAP хранит письма.

Каждое сообщение на IMAP-сервере имеет два разных типа дат:

• Заголовок Date: (определён в RFC 2822): дата, которую отправитель вписал в сообщение в момент отправки. Она инкапсулирована в теле письма и теоретически неизменна.
• INTERNALDATE: серверный метаданный параметр, внешний по отношению к сообщению. Он отражает дату, когда сообщение было помещено в ящик. Именно это значение почтовые клиенты используют в первую очередь для сортировки и отображения писем.

При импорте PST или миграции с Thunderbird инструмент импорта (будь то встроенный модуль eM Client, сторонний инструмент или ручное копирование по IMAP) помещает сообщения на целевой IMAP-сервер. И если инструмент явно не сохраняет оригинальный INTERNALDATE в момент загрузки, сервер автоматически присваивает текущий INTERNALDATE - то есть дату и время импорта.

Итог: 8 000 писем, заархивированных с 2017 года, все с отметкой «получено» в момент Вашей миграции.

(Кстати, если Вы когда-нибудь пробовали читать сырые заголовки письма через «Показать источник» в eM Client, то заметили бы, что оригинальный заголовок Date: всегда на месте, нетронутый. Это верный признак того, что проблема в INTERNALDATE на сервере, а не в самом сообщении.)

Почему смена колонки сортировки ничего не даёт

Путаница возникает из-за различия, которое мало кто знает. В eM Client, как и в Outlook или Thunderbird, обычно есть два типа колонок с датой:

• «Дата получения» (или «Дата прихода»): основана на INTERNALDATE сервера.
• «Дата» или «Дата отправки»: основана на заголовке Date: сообщения.

Многие администраторы обнаруживают это и думают, что нашли решение: переключиться на «Дату отправки» - и проблема визуально исчезает в eM Client. Но это не совсем так.

Уточним: даже если сортировать по дате отправки в eM Client, проблема сохраняется для всех остальных клиентов и интерфейсов, которые обращаются к тому же ящику. Если пользователи читают почту через OWA, Outlook в офисе, приложение Gmail на телефоне или любой другой IMAP-клиент, они увидят даты импорта. Параметр сортировки eM Client работает только внутри eM Client и не влияет на метаданные, хранящиеся на сервере.

Более того, в Microsoft 365 и Google Workspace веб-интерфейсы сортируют по INTERNALDATE. Изменить это поведение со стороны клиента невозможно.

Сортировка по дате отправки - не решение. Это пластырь, который скрывает реальную проблему, не устраняя её.

Особый случай: импорт PST

Импорт PST-файлов заслуживает отдельного разговора. PST (Personal Storage Table) - проприетарный формат Microsoft для локального хранения писем, контактов и календарей. При импорте PST в eM Client возможны два сценария:

• Импорт на IMAP-аккаунт: eM Client читает PST и загружает сообщения на целевой IMAP-сервер. Если дата загрузки не сохраняется, INTERNALDATE перезаписывается. Это самый частый случай, и именно здесь даты оказываются повреждены.
• Импорт в локальную папку: сообщения остаются на машине, вне сервера. INTERNALDATE в этом контексте не существует, и eM Client может отображать дату из заголовка Date:. Проблем с датами здесь меньше, но и практической пользы тоже.

С Thunderbird ситуация похожая. Используете ли Вы встроенную функцию импорта eM Client (которая читает профили Thunderbird), или копировали папки mbox через IMAP - сообщения заново помещаются на сервер без гарантии сохранения INTERNALDATE. А сервер, получивший сообщение без явного указания даты для INTERNALDATE, всегда проставит время получения.

Какие платформы затронуты?

Проблема одинакова на любой целевой платформе, потому что это стандартное поведение протокола IMAP:

• Microsoft 365 / Exchange Online: INTERNALDATE перезаписывается при любом импорте, не использующем команду IMAP APPEND с явным параметром даты. То же самое при миграции с локального Exchange.
• Google Workspace: аналогичное поведение. Письма, импортированные через eM Client или сторонние инструменты, показывают дату импорта в Gmail и в административном интерфейсе.
• Классические IMAP-хостинги (OVH, Infomaniak, Ionos, Timeweb и др.): никакой специальной обработки даты при получении сообщения через APPEND. INTERNALDATE будет датой загрузки.

Один клиент обратился к нам после того, как перенёс около сотни ящиков с Exchange 2013 на Microsoft 365, используя eM Client в качестве переходного инструмента для ряда VIP-аккаунтов. Ящики, перенесённые корректно через MigrationWiz, были в порядке, а ящики, прошедшие через eM Client, все получили даты импорта. Пользователям это не понравилось, мягко говоря.

Почему самописный скрипт здесь не поможет

Технически, человек, знакомый с протоколом IMAP, мог бы написать скрипт для исправления INTERNALDATE. Оригинальный заголовок Date: есть в каждом сообщении, нетронутый. Казалось бы, достаточно прочитать его и восстановить серверные метаданные, верно?

В теории - да. На практике - минное поле.

Во-первых, граничные случаи быстро накапливаются в рабочем ящике. Сообщения с цифровой подписью S/MIME особенно чувствительны к любым манипуляциям со структурой. PGP-зашифрованные тоже. Письма с объёмными вложениями, нестандартными MIME-границами или необычными кодировками Content-Transfer-Encoding могут тихо повредиться, если обработка недостаточно аккуратная. Скрипт, работающий на 50 тестовых письмах, ненадёжно поведёт себя на рабочем ящике из 20 000 сообщений с шестилетней историей.

Во-вторых, управление квотами API. На Microsoft 365 лимиты Graph API или EWS в три часа ночи при обработке пакета из 8 000 сообщений - это то, чем надо управлять. Но само по себе оно не управляется. Скрипт без наблюдения, который встретит ошибку 429 Too Many Requests на сообщении номер 3741, может продолжить работу, а может нет. И Вы не всегда узнаете, какие письма были обработаны.

И главное: как проверить, что каждое исправленное письмо цело после обработки? У самописного скрипта, как правило, нет механизма индивидуальной верификации. Redate.io делает это автоматически, для каждого сообщения.

Исправить даты на уровне сервера с Redate.io

Redate.io решает проблему там, где она находится: на уровне серверных метаданных, а не на уровне почтового клиента.

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

Исправление выполняется с помощью проприетарного движка, который анализирует полную цепочку заголовков каждого сообщения, применяет сопоставление шаблонов по сотням известных сигнатур инструментов импорта (включая специфику eM Client, Thunderbird, PST-импортов) и восстанавливает метаданные даты целенаправленно, не затрагивая содержимое письма, вложения или структуру MIME.

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

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

Перед следующей миграцией: что проверить

Если Вы планируете миграцию и хотите избежать этой проблемы заранее, контрольный вопрос простой: явно ли сохраняет INTERNALDATE Ваш инструмент при загрузке сообщений на целевой сервер?

Для импортов PST в Microsoft 365 сертифицированные Microsoft инструменты (например, MigrationWiz в нативных режимах или инструмент миграции Exchange Online) как правило обеспечивают это сохранение. Для ручных импортов через eM Client или Thunderbird - почти никогда. Изучите документацию Вашего инструмента до запуска импорта на рабочих ящиках.

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

Для администраторов, регулярно проводящих миграции для клиентов, полезны статья об исправлении дат для MSP и материал о том, как работает INTERNALDATE IMAP - они дают более полную картину проблемы.

Даты писем повреждены после импорта в eM Client? Запустите бесплатное сканирование на Redate.io - и оцените масштаб проблемы прежде, чем принимать решение.