GSMMO испортил даты писем? Как исправить

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

Google Workspace Migration for Microsoft Outlook (GSMMO) - настольный инструмент, который Google предоставляет для миграции PST-файлов, профилей Outlook и локальных почтовых архивов в Gmail. Он бесплатный, официально поддерживается и является тем путём миграции, который Google рекомендует при переносе небольшой команды или нескольких отдельных почтовых ящиков из Outlook в Google Workspace.

Инструмент работает. Письма попадают в Gmail, структура папок отображается в виде меток, контакты переносятся. Но откройте Gmail после этого и отсортируйте по дате. Каждое письмо показывает сегодняшнюю дату. То предложение, которое вы отправили в январе 2021 года? Апрель 2026. Счёт от вашего бухгалтера за март 2023 года? Тоже апрель 2026.

GSMMO не предупреждает, что это произойдёт. Журнал миграции показывает успех для каждого сообщения. Собственная документация Google не упоминает это как известное ограничение. Вы узнаёте об этом только тогда, когда кто-то ищет старое письмо по диапазону дат и получает ноль результатов.

Как в действительности GSMMO загружает вашу почту

GSMMO считывает сообщения из PST-файла (или напрямую из профиля Outlook) и загружает их в Gmail через API Gmail (это подтверждают собственные примечания к выпуску инструмента от Google). Именно здесь возникает проблема с датами, и стоит разобраться в механике, потому что это объясняет, почему исправление не сводится просто к "повторному импорту".

Когда GSMMO загружает сообщение через API Gmail, Gmail добавляет новый заголовок Received:, датированный моментом загрузки. А если исходная дата не передаётся вместе с сообщением, INTERNALDATE - метка времени, которую Gmail использует внутри для сортировки и отображения, - устанавливается на момент загрузки, а не на дату исходной отправки.

Вот как выглядит цепочка заголовков после миграции GSMMO:

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

Видите тот исходный заголовок Date:, датированный сентябрём 2019 года? Он всё ещё там, нетронутый. GSMMO не изменяет тело сообщения или исходные заголовки. Но Gmail игнорирует его при отображении и использует вместо этого INTERNALDATE, которая теперь указывает на апрель 2026 года.

GSMMO и инструменты миграции на стороне администратора

Именно здесь часто начинается путаница. У Google несколько инструментов миграции, и все они ведут себя по-разному.

GSMMO (настольное приложение) работает на компьютере пользователя. Он считывает данные из Outlook или PST-файла и загружает письма через API Gmail. Пользователю нужна учетная запись Google Workspace и плагин GSMMO, установленный в Outlook. Это клиентский инструмент.

Google Workspace Migration Service (инструмент консоли администратора) работает на стороне сервера. Администратор настраивает его в консоли Google Admin, указывает сервер Exchange или другой домен Google Workspace, и миграция выполняется в инфраструктуре Google. У этого инструмента чуть лучше обработка дат в некоторых конфигурациях, потому что он может устанавливать INTERNALDATE на основе метаданных источника. Но "чуть лучше" не значит "надёжно", и многие администраторы сообщают о такой же проблеме с датами и в этом инструменте.

В чём ключевое отличие? У GSMMO нет серверной логики, принимающей решения о сохранении дат. Каждое загруженное сообщение получает одинаковую обработку, будь это свежее письмо или архивное сообщение десятилетней давности: заголовок Received:, датированный днём загрузки. Точка.

Почему сохранение дат в GSMMO не работает

Если вы заглядывали в настройки GSMMO, то могли заметить, что опции "сохранить даты" там на самом деле нет. Это не недосмотр. GSMMO зависит от того, как Gmail обрабатывает сообщения, загруженные через его API, и не может это изменить.

Вот техническая последовательность событий:

1. GSMMO считывает сообщение из PST-файла, включая его исходные метки времени
2. GSMMO загружает данные сообщения через API Gmail
3. Gmail получает загрузку и сохраняет сообщение в почтовом ящике
4. Gmail добавляет новый заголовок Received:, датированный моментом загрузки (строка gmailapi.google.com в примере выше)
5. Если исходная дата не передаётся, Gmail устанавливает INTERNALDATE на метку времени загрузки
6. Сообщение попадает в Gmail с сегодняшней датой

Шаги 4 и 5 - решающие. Gmail добавляет этот заголовок к каждому сообщению, загруженному через его API, независимо от того, что передаёт инструмент, а у GSMMO нет настройки для передачи или сохранения исходной даты. В результате все ваши старые письма выглядят так, будто пришли сегодня.

Некоторые администраторы пробовали запускать GSMMO с определёнными включёнными настройками Google Workspace или изменять параметры профиля GSMMO. Ничто из этого не влияет на поведение дат. Заголовок Received: добавляется на стороне Google, и никакая настройка на стороне клиента этого не изменит.

Конкретные сценарии GSMMO, ломающие даты

Не каждая миграция GSMMO заканчивается хаосом с датами, хотя большинство заканчиваются именно так. Вот где это важно:

• PST-файл в Gmail: даты ломаются. Это самый распространённый вариант использования GSMMO и самый затронутый.
• Профиль Outlook в Gmail: даты ломаются. Та же загрузка через API Gmail, что и при импорте PST.
• Exchange Online (Microsoft 365) в Gmail через GSMMO: даты ломаются. GSMMO считывает данные с сервера Exchange и загружает их через API Gmail.
• Локальный Exchange в Gmail через GSMMO: даты ломаются. Тот же механизм.
• Gmail в Gmail (повторный импорт экспорта PST): даты ломаются. Даже если исходные письма в PST имели правильные даты, повторный импорт ставит на них новую метку.

Закономерность очевидна. Каждое сообщение, загруженное через API Gmail, получает заголовок Received:, датированный днём загрузки. GSMMO всегда использует этот путь.

Особенно неприятно то, что отчёт о миграции GSMMO показывает всё как успешно выполненное. Никаких предупреждений о датах, никаких ошибок, никаких флагов. Чтобы это заметить, нужно вручную сравнить метки времени до и после миграции, а большинство администраторов делают это только после жалобы пользователя.

Последствия выходят за рамки сортировки

Неправильные даты после миграции GSMMO создают реальные проблемы, выходящие за рамки беспорядка во входящих.

Представьте, что вы бухгалтер, который только что перешёл на Google Workspace. Вам нужно найти всю переписку с клиентами за третий квартал 2024 года для налоговой декларации. Вы ищете в Gmail по диапазону дат: с июля по сентябрь 2024 года. Ноль результатов. Каждое письмо за этот период теперь показывает дату миграции, поэтому фильтр по дате в Gmail не может их найти. Вам остаётся листать тысячи сообщений или искать по ключевым словам, надеясь вспомнить правильные термины.

Для регулируемых отраслей это хуже, чем просто неудобство. Временные метки писем служат юридическим доказательством. Финансовый консультант, которому нужно доказать, что он отправил раскрытие информации до даты сделки, не сможет это сделать, когда письмо показывает апрель 2026 года вместо февраля 2023 года. Аудиты соответствия по SOX или HIPAA опираются на точные временные метки переписки, а неправильные даты означают провал аудита.

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

Исправление дат GSMMO с помощью Redate.io

Хорошая новость: исходный заголовок Date: остаётся нетронутым внутри каждого мигрированного письма. GSMMO не изменяет содержимое сообщения. Правильная дата там есть, просто логика отображения Gmail её игнорирует, потому что INTERNALDATE и верхний заголовок Received указывают на дату миграции.

Redate.io подключается к почтовому ящику Google Workspace, сканирует письма, затронутые миграцией GSMMO, и исправляет метаданные дат с помощью проприетарного механизма анализа цепочки заголовков и восстановления дат. Redate не нужно знать, какой инструмент выполнил миграцию: он находит письма, чья отображаемая дата не совпадает с оригинальной, и исправляет их без изменения содержимого сообщения, вложений или цепочек переписки.

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

Можно ли исправить это самостоятельно с помощью скрипта? Понять проблему - это одно. Исправить 12 000 писем, не сломав подписи S/MIME, не повредив вложенные части MIME и не искалечив закодированные по RFC 2047 заголовки в рабочем почтовом ящике - совсем другое. Как быть с письмом с вложением на 38 МБ и повреждённой границей MIME, которое GSMMO импортировал, но которое едва держится вместе? Как проверить, что каждое отдельное сообщение прошло без повреждений? Скрипт, который работает на 20 тестовых сообщениях в лаборатории, не выдержит реального ящика с восьмилетней перепиской.

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

Поскольку GSMMO мигрирует именно в Google Workspace, исправление происходит на уровне Gmail. Но затронутые письма видны в любом клиенте, подключённом к этой учетной записи Gmail:

• Исправить даты миграции GSMMO в Gmail
• Исправить даты миграции GSMMO в Outlook (подключённом к Google Workspace)
• Исправить даты миграции GSMMO в Apple Mail

Мигрировали несколько месяцев назад? Исходный заголовок Date не портится со временем. Redate.io может исправить письма, затронутые GSMMO, независимо от того, произошла миграция на прошлой неделе или три года назад.

Миграция GSMMO оставила ваши письма с неправильными датами? Запустите бесплатное сканирование, чтобы увидеть точное количество затронутых писем и стоимость их исправления, прежде чем что-либо оплачивать.