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 через Gmail API (про це прямо кажуть власні примітки до випуску Google для цього інструмента). Саме тут виникає проблема дат, і варто розуміти цей механізм, бо він пояснює, чому виправлення не таке просте, як "просто повторно імпортувати".

Коли GSMMO завантажує повідомлення через Gmail API, 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-файлу і завантажує листи через Gmail API. Користувачеві потрібен обліковий запис Google Workspace та встановлений у Outlook плагін GSMMO. Це клієнтський інструмент.

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

Ключова відмінність? У GSMMO немає жодної серверної логіки, яка б приймала рішення щодо збереження дат. Кожне повідомлення, яке він завантажує, отримує однакове поводження, чи це свіжий лист, чи архівне повідомлення десятирічної давнини: заголовок Received:, датований днем завантаження. І все.

Чому збереження дат у GSMMO не працює

Якщо ви дивилися на налаштування GSMMO, ви могли помітити, що там насправді немає опції "зберегти дати". Це не недогляд. GSMMO залежить від того, як Gmail обробляє повідомлення, завантажені через його API, і не може це змінити.

Ось технічний ланцюжок подій:

1. GSMMO читає повідомлення з PST-файлу, включно з оригінальними позначками часу
2. GSMMO завантажує дані повідомлення через Gmail API
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: Дати ламаються. Те саме завантаження через Gmail API, як і при імпорті PST.
• Exchange Online (Microsoft 365) у Gmail через GSMMO: Дати ламаються. GSMMO читає з сервера Exchange і завантажує через Gmail API.
• Локальний Exchange у Gmail через GSMMO: Дати ламаються. Той самий механізм.
• Gmail у Gmail (повторний імпорт експорту PST): Дати ламаються. Навіть якщо оригінальні листи мали правильні дати в PST, повторний імпорт ставить на них нову позначку.

Закономірність очевидна. Кожне повідомлення, завантажене через Gmail API, отримує заголовок 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 залишила ваші листи з хибними датами? Запустіть безкоштовне сканування, щоб побачити точну кількість уражених листів і вартість їх виправлення, перш ніж брати на себе будь-які зобов'язання.