English
Français
Deutsch
Español
Português
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Türkçe
Ελληνικά
Русский
Polski
Čeština
Українська
Magyar
Română
Български
Hrvatski
Srpski
Slovenčina
Slovenščina
Lietuvių
Latviešu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
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
Тук често започва объркването. Google има няколко инструмента за миграция и те не се държат еднакво.
GSMMO (настолното приложение) се изпълнява на компютъра на потребителя. Той чете от Outlook или от PST файл и качва имейлите през Gmail API. Потребителят се нуждае от акаунт в Google Workspace и от плъгина GSMMO, инсталиран в Outlook. Това е клиентски инструмент.
Google Workspace Migration Service (инструментът в администраторската конзола) е сървърен. Администратор го конфигурира в Google Admin Console, насочва го към сървър на Exchange или към друг наемател на Google Workspace, и миграцията се изпълнява в инфраструктурата на Google. Този инструмент управлява датите малко по-добре в някои конфигурации, защото може да зададе INTERNALDATE въз основа на метаданните от източника. Но "малко по-добре" не означава "надеждно", и много администратори съобщават за същия проблем с датите и при този инструмент.
Каква е ключовата разлика? При GSMMO няма сървърна логика, която да взема решения за запазването на датата. Всяко качено съобщение получава еднакво третиране, независимо дали е нов имейл или архивирано съобщение отпреди 10 години: заглавие Received:, датирано в деня на качването. Точка.
Защо запазването на датите от GSMMO не работи
Ако сте разгледали настройките на GSMMO, вероятно сте забелязали, че всъщност няма опция "запазване на датите". Това не е пропуск. GSMMO разчита на начина, по който Gmail обработва съобщения, качени през своя API, и не може да го промени.
Ето технологичната последователност от събития:
- GSMMO чете съобщението от PST файла, включително оригиналните му времеви клейма
- GSMMO качва данните на съобщението през Gmail API
- Gmail получава качването и съхранява съобщението в пощенската кутия
- Gmail добавя ново заглавие
Received:, датирано в момента на качването (реда сgmailapi.google.comв примера по-горе) - Когато оригиналната дата не е предадена, Gmail задава INTERNALDATE на времето на качването
- Съобщението попада в 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 MB и повредена MIME граница, който GSMMO е внесъл и едвам е задържал заедно? Как проверявате, че всяко отделно съобщение е преминало непокътнато? Скрипт, който работи на 20 тестови съобщения в лаборатория, няма да оцелее в реална пощенска кутия с 8 години кореспонденция.
Ръководства по платформи за GSMMO
Тъй като GSMMO мигрира конкретно към Google Workspace, поправката се извършва на ниво Gmail. Но засегнатите имейли се виждат във всеки клиент, свързан с този акаунт в Gmail:
- Поправка на датите от миграция с GSMMO в Gmail
- Поправка на датите от миграция с GSMMO в Outlook (свързан с Google Workspace)
- Поправка на датите от миграция с GSMMO в Apple Mail
Вече мигрирали преди месеци? Оригиналното заглавие Date не се влошава с времето. Redate.io може да поправи имейли, засегнати от GSMMO, независимо дали миграцията се е случила миналата седмица или преди три години.
Миграцията с GSMMO остави имейлите Ви с грешни дати? Стартирайте безплатен анализ, за да видите точния брой засегнати имейли и цената за поправката им, преди да поемете какъвто и да е ангажимент.