Exchange IMAP: почему даты писем искажаются

Импорт IMAP в Exchange и даты ваших писем

Exchange Online присваивает каждому письму в почтовом ящике дату, и именно по этой дате Outlook отображает и сортирует письма. Для письма, пришедшего из интернета, это момент доставки. Для письма, скопированного миграцией, это та дата, которую миграция дала копии: оригинальная, если миграция передаёт её, и день импорта, если нет.

Именно отсюда возникает искажение дат при импорте IMAP в Exchange. Exchange Online не перезаписывает дату, которую ему передают. Но когда миграция не переносит оригинальную дату каждого письма, копия 7-летнего письма получает дату импорта, как будто оно только что доставлено.

Результат? Вы импортируете 4000 писем со старого IMAP-сервера в Exchange Online, и письма показывают дату импорта вместо своей собственной. Письма из 2018, 2020, 2023 годов датированы сегодняшним днём. Ваши пользователи открывают Outlook утром в понедельник и видят стену писем с одинаковой датой.

Как работает мастер миграции Exchange Admin Center

Exchange Admin Center (EAC) включает встроенный мастер миграции для импорта IMAP. Это графический интерфейс, к которому большинство администраторов Exchange обращаются первым делом: вы переходите в Recipients, затем Migration, создаёте новую партию, выбираете "Migrate to Exchange Online", указываете IMAP как источник, загружаете CSV с сопоставлением почтовых ящиков и запускаете партию.

За кулисами мастер миграции EAC создаёт New-MigrationBatch с типом конечной точки IMAP. Exchange подключается к вашему исходному IMAP-серверу, читает каждое письмо и записывает его в целевой почтовый ящик Exchange Online. На бумаге всё просто.

Но вот с чем сталкиваются администраторы. Microsoft не документирует, как миграция задаёт дату каждого скопированного письма, и администраторы сообщают о письмах, которые получают дату синхронизации вместо даты получения. Outlook, OWA и любой другой клиент, подключённый к этому ящику, затем используют эту дату для отображения и сортировки.

Оригинальный заголовок Date: от 2019 года? Он всё ещё там, спрятан в заголовках письма. Но Exchange не использует его для порядка сортировки в вашем почтовом ящике.

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest и та же проблема

Администраторы, предпочитающие командную строку, часто обращаются к New-MailboxImportRequest для импорта PST-файлов или к New-MigrationBatch с конечными точками IMAP для миграции между серверами. Ожидается, что PowerShell даёт больше контроля. И это так, для некоторых вещей. Но не для дат.

New-MailboxImportRequest импортирует PST-файлы в почтовые ящики Exchange Online. PST-файл содержит оригинальные метки времени для каждого письма. Но у командлета PowerShell нет параметра, который контролирует, какую дату получит каждое импортированное письмо. Флага -PreserveDates не существует (и поверьте, администраторы его искали).

New-MigrationBatch -SourceEndpoint с конечной точкой IMAP работает так же, как мастер EAC, только без графического интерфейса. Такое же подключение IMAP, такой же результат для дат. Командлет предлагает параметры для фильтрации по диапазону дат (-StartAfter, -CompleteAfter) и исключения папок, но ничего, что контролировало бы, как Exchange обрабатывает метку времени входящего письма.

Точнее говоря, это в основном влияет на дату отображения и порядок сортировки. Содержимое письма, включая оригинальный заголовок Date, приходит без изменений. Неправильна только дата, которую получила копия, и именно она стоит за всем, что видит пользователь.

Прямой импорт IMAP в Exchange и сторонние инструменты

Имеет ли значение, используете ли вы встроенный импорт IMAP Exchange или сторонний инструмент вроде BitTitan MigrationWiz или CloudM? Короткий ответ: проблема с датами возникает в обоих случаях, но по немного разным причинам.

При встроенном импорте IMAP Exchange (мастер EAC или PowerShell) Exchange сам подключается к исходному IMAP-серверу и забирает письма. Как он задаёт дату каждой копии, решает Microsoft, и это не документировано.

При использовании сторонних инструментов инструмент миграции выступает посредником. Он считывает письмо из источника, возможно, преобразует его, и записывает в Exchange Online. Когда инструмент пишет через IMAP, Exchange Online сохраняет ту дату, которую передаёт инструмент: если инструмент отправляет оригинальную дату каждого письма, копия её сохраняет; если нет, копия получает дату миграции. Некоторые инструменты также добавляют собственный заголовок Received: при пересылке.

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

Почему правила транспорта Exchange Online усугубляют ситуацию

Вот что заставляет врасплох даже опытных администраторов Exchange. У Exchange Online есть правила транспорта (теперь называемые "правилами потока почты" в центре администрирования), которые могут срабатывать на импортированных письмах. Если в вашей организации есть правила, которые ставят заголовки, добавляют дисклеймеры или изменяют письма по условиям, эти правила могут обрабатывать и импортированные письма.

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

Можно ли отключить правила транспорта во время импорта? Да, временно. Но большинство администраторов не думают об этом, потому что вообще не ожидают, что транспортный конвейер обработает мигрированные письма. К тому моменту, когда они понимают, что произошло, партия импорта уже завершена, и вред уже нанесён.

Что неправильные даты значат для сред Exchange

Среды Exchange обычно являются бизнес-средами. Юридические фирмы, финансовые учреждения, медицинские организации, государственные учреждения. Это не личные аккаунты Gmail, где неправильная дата - лишь небольшая неприятность. Это почтовые ящики, где метки времени писем имеют юридическое и нормативное значение.

Судебное удержание (litigation hold) в Exchange сохраняет письма на основе диапазонов дат. Если каждое импортированное письмо показывает дату импорта вместо оригинальной даты, удержание захватывает неправильный набор писем. Поиск eDiscovery по запросу "все переписки между январём и мартом 2022 года" не возвращает ничего, потому что эти письма теперь показывают апрель 2026 года.

Политики хранения сталкиваются с той же проблемой. Организация с трёхлетней политикой хранения может случайно удалить письма, которые выглядят как письма 2026 года (и, следовательно, "новые"), хотя на самом деле они из 2019 года и должны быть сохранены. Или наоборот: письма, которые должны были быть удалены по политике хранения, остаются, потому что их видимая дата недавняя.

Один случай из конца 2025 года: MSP перенёс около 200 почтовых ящиков от хостинг-провайдера Exchange в Microsoft 365 с помощью мастера миграции EAC. Через три недели сотрудник клиента, отвечающий за соответствие, обнаружил, что квартальные отчёты об архивации писем показывают одну и ту же дату для каждого архивированного письма. Весь архив писем за 5 лет выглядел так, будто прибыл в один вторник в ноябре.

Исправление дат импорта IMAP Exchange

Оригинальный заголовок Date: переживает импорт без изменений. Импорт не изменяет оригинальные заголовки RFC 2822 внутри письма. Эта оригинальная дата - опорная точка для исправления.

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

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

Почему не исправить это скриптом PowerShell? Потому что разобраться в проблеме заголовков - это лёгкая часть. Исправить 8000 писем в 50 почтовых ящиках без повреждения писем с подписью S/MIME, без поломки вложенных структур MIME, без искажения заголовков RFC 2047 с не-ASCII символами и без потери привязки к папкам - вот сложная часть. Как вы проверите, что каждое отдельное исправленное письмо в рабочей среде осталось целым, что ни одно вложение не потеряно, что ни одна цепочка переписки не разорвана? Скрипт, который работает на тестовом ящике с 30 письмами, захлебнётся на реальных пограничных ситуациях. А тот контракт с вложением на 42 МБ и тремя встроенными изображениями внутри структуры multipart/mixed, обёрнутой в multipart/alternative? Удачи.

Руководства по платформам

Исправление дат применяется на уровне почтового ящика Exchange Online, но пользователи получают доступ к почте через разные клиенты. Каждый из них отображает даты по-своему:

• Исправить даты миграции IMAP Exchange в Outlook
• Исправить даты миграции IMAP Exchange в OWA (Outlook в браузере)

Нужен более широкий контекст по проблемам дат Microsoft 365 при использовании разных инструментов миграции? См. полное руководство по исправлению дат писем после миграции Microsoft 365.

Миграция IMAP Exchange оставила ваши почтовые ящики с неправильными датами? Начните с бесплатного сканирования, чтобы увидеть, сколько писем затронуто и сколько будет стоить исправление, без банковской карты.