Хостинг на Microsoft 365: скрытая проблема дат

Проблема, о которой никто не предупредил

Вы только что завершили миграцию почты с OVH, Infomaniak, Ionos или o2switch на Microsoft 365. Мастер миграции в EAC (Exchange Admin Center) работал всю ночь, всё зелёное, ящики заполнены. В понедельник утром первый тикет: «У всех старых писем стоит сегодняшняя дата.» Потом второй. Потом десять.

Это не баг Microsoft 365. И не случайность. Это закономерный результат миграции IMAP, а в случае с виртуальным хостингом проблема нередко вдвое серьёзнее, чем при обычной миграции. Вот почему.

Как IMAP работает с датами (и где всё ломается)

У каждого письма, хранящегося на IMAP-сервере, есть два разных типа датирования. С одной стороны, заголовок Date: (определённый RFC 2822), присутствующий в самом теле сообщения и указывающий, когда письмо было отправлено или получено. С другой стороны, INTERNALDATE - метаданные на уровне сервера, показывающие, когда именно это сообщение попало в ящик. Именно это значение почтовые клиенты вроде Outlook используют по умолчанию для сортировки и отображения писем.

(Кстати, если Вы когда-нибудь пытались читать сырые заголовки письма в EAC, Вы знаете, что это не пляжное чтение. Там легко двадцать-тридцать строк заголовков, прежде чем доберёшься до содержимого.)

Когда инструмент миграции IMAP переносит сообщение из одного ящика в другой, он должен воссоздать этот INTERNALDATE на стороне назначения. Некоторые инструменты делают это правильно. Многие - нет, или делают с ограничениями. Принимающий сервер, со своей стороны, сохраняет то, что ему передают: если копия несёт свою оригинальную дату, Exchange Online сохраняет эту дату. Поэтому если даты отображаются неправильно, дело в инструменте миграции, а не в Microsoft 365.

Итог: каждое мигрированное письмо выглядит так, будто его «получили» в день миграции. Неважно, что оно было написано в 2019 году.

Двойная порча: почему виртуальный хостинг всё усугубляет

Вот где ситуация становится по-настоящему скверной для миграций с виртуальных хостингов вроде OVH, Infomaniak, Gandi, Ionos или o2switch.

Эти провайдеры, как правило, используют общие серверы на Postfix, Dovecot или cPanel со стандартными IMAP-конфигурациями. Многие малые предприятия копили там письма годами, иногда с 2010 или 2012 года. Когда они решают перейти на Microsoft 365, миграция нередко происходит в два этапа.

Этап 1: первая порча (ещё до Microsoft 365)

Во многих случаях письма уже пережили одну миграцию. Компания меняла хостинг один-два раза за эти годы: с Gandi на OVH в 2018-м, потом с OVH на Infomaniak в 2022-м, например. Каждый перенос IMAP мог сбросить оригинальный INTERNALDATE на день переноса, если инструмент не передавал оригинальную дату, а некоторые инструменты также добавляют собственные заголовки миграции, датированные этим днём.

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

Этап 2: вторая порча при переходе на Exchange Online

Инструмент миграции IMAP в EAC - или сторонний инструмент вроде BitTitan MigrationWiz в режиме IMAP - принимает письма с уже неправильными датами. Если этот инструмент тоже не передаёт оригинальную дату каждого письма, Exchange Online помечает письмо днём переноса, и именно эту "дату получения" показывает Outlook.

Письмо, отправленное в марте 2017 года, может нести два слоя неправильных дат: заголовки миграции, оставленные переносом 2022 года, и дату получения от миграции на Microsoft 365 в 2024 году. Outlook показывает 2024. Пользователь видит 2024. И это ошибка сразу на двух уровнях.

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

Инструменты миграции и хостинги: опасные комбинации

При миграциях с виртуального хостинга чаще всего встречаются такие комбинации:

• OVH / Infomaniak / Ionos + IMAP-инструмент EAC: штатный инструмент Microsoft удобен, но печально известен тем, что плохо сохраняет даты при объёмных миграциях IMAP.
• cPanel (o2switch, LWS и др.) + BitTitan MigrationWiz в режиме IMAP: MigrationWiz в IMAP-режиме добавляет собственные заголовки миграции. Результат хорошо задокументирован, в том числе на странице исправление дат BitTitan в Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync - мощный инструмент, но его работа с INTERNALDATE зависит от конфигурации. Без нужной опции даты не сохраняются. Подробнее: imapsync: даты не сохранились.
• Любая ручная миграция через перетаскивание в Outlook: если кто-то копировал папки drag-and-drop между двумя аккаунтами в Outlook, INTERNALDATE каждого письма перезаписывается датой копирования. Без исключений.

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

Почему «исправить самому» - плохая идея в больших масштабах

Понять проблему - одно. Исправить 8000 писем в 40 ящиках Exchange Online, на аккаунтах со сложной структурой папок, подписанными S/MIME письмами, объёмными вложениями и вложенными цепочками - совсем другое.

PowerShell-скрипт, который кажется рабочим на десяти тестовых письмах, может молча сломаться на сообщении номер 4237 из-за испорченной MIME-границы или заголовка, закодированного по RFC 2047 (тот формат =?UTF-8?B?...?= для не-ASCII символов в именах отправителей). Без механизма поштучной проверки Вы об этом не узнаете. Просто потеряете письмо.

Конкретные риски DIY-подхода при таком типе миграции:

• Дубликаты сообщений, если логика вставки сбоит на полпути
• Потерянные вложения при неправильном восстановлении multipart-структуры
• Сломанные цепочки в Outlook (треды строятся на заголовках References: и In-Reply-To:, которые могут быть повреждены)
• Ошибки 429 (Too Many Requests) от Microsoft Graph API в три ночи, которые прерывают обработку без возможности отката
• Никакого простого способа убедиться, что все 8000 исправлений применены корректно

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

Что делает Redate.io иначе

Каждый пользователь входит под своей учетной записью Майкрософт, и Redate.io открывает именно этот ящик с тем доступом, который даёт этот вход. Начальное сканирование бесплатно: Redate.io находит все письма, чья отображаемая дата не совпадает с реальной, и даёт точную оценку по каждому ящику.

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

Для миграций с виртуального хостинга многоступенчатый аналитический конвейер Redate.io явно обрабатывает сценарии двойной порчи: он не ограничивается просмотром последнего заголовка Received:, а восстанавливает полную историю, чтобы найти реальную дату получения. Подробнее о том, как в целом исправить даты после миграции на Microsoft 365, а также подробное объяснение механики в статье про IMAP INTERNALDATE.

До или после миграции: два момента для действий

Две ситуации, два подхода.

Вы ещё не мигрировали. Хорошая новость: ущерб можно ограничить. Некоторые инструменты миграции (MigrationWiz в режиме Exchange, CloudM с нужными настройками) лучше сохраняют даты, чем другие. Но даже в лучшем случае миграция с виртуального хостинга без чистой истории, скорее всего, оставит следы. Запланируйте прохождение через Redate.io после миграции, до того как передавать ящики пользователям.

Вы уже мигрировали, и тикеты сыплются. Redate.io исправляет существующие ящики в Microsoft 365 независимо от давности миграции. Сканирование даст точную картину реального состояния каждого ящика ещё до любого вмешательства. Ознакомьтесь также с чеклистом миграции почты, чтобы избежать тех же проблем в будущем.

Вы мигрировали с OVH, Infomaniak, Ionos или o2switch на Microsoft 365 и даты неверные? Создайте аккаунт Redate.io, чтобы бесплатно просканировать свои ящики и точно оценить масштаб проблемы, прежде чем принимать какие-либо решения.