Какво е CloudM и защо причинява проблеми с датите?
CloudM Migrate (преди Cloud Migrator) е водеща платформа за миграция, специализирана в преходи към Google Workspace. IT администраторите използват CloudM за преместване на пощенски кутии от Microsoft Exchange, Office 365, Lotus Notes, Zimbra и други платформи към Google Workspace. CloudM обработва и миграции в обратната посока и между различни облачни имейл платформи. Самият Google е препоръчвал CloudM като партньор за миграция, което го прави един от най-доверените инструменти в екосистемата на Google Workspace.
Тогава защо четете тази статия? Защото въпреки надеждността на CloudM за трансфер на данни, инструментът произвежда същия разочароващ проблем с датите, който засяга практически всеки инструмент за имейл миграция. След миграция с CloudM всеки имейл в целевата пощенска кутия показва датата на миграцията вместо оригиналната дата на получаване. Хиляди имейли, всички с един и същи печат. Години хронологичен ред, унищожени с един пакет за миграция.
Как CloudM добавя хедъри по време на миграция
Хедърът "Received" от миграцията
Когато CloudM мигрира имейл от изходната платформа към дестинацията, той обработва всяко съобщение през своя конвейер за миграция и го вмъква в целевата пощенска кутия. По време на това вмъкване целевият пощенски сървър добавя "Received" хедър към съобщението. Този хедър записва времевия печат на момента, в който имейлът е вмъкнат в новия сървър, което е датата на миграцията, а не оригиналната дата на доставка.
Свързаният с CloudM "Received" хедър попада в началото на веригата хедъри на имейла. Тъй като пощенски клиенти като Outlook, Apple Mail и Thunderbird определят датата на получаване, като четат най-горния "Received" хедър, всеки мигриран имейл показва времевия печат на миграцията вместо оригиналната дата. Това е същността на проблема.
Идентифициране на CloudM хедъра
За да потвърдите, че проблемът с датата е причинен от CloudM, прегледайте суровите хедъри на засегнат имейл. В Gmail отворете имейла, кликнете на трите точки и изберете "Покажи оригинала". Потърсете "Received" хедърите близо до началото на съобщението. Хедърът от миграцията на CloudM обикновено съдържа препратки към инфраструктурата за обработка на CloudM или общ запис localhost с времеви печат, съвпадащ с датата на миграцията.
Ключовият индикатор е "Received" хедър, чийто времеви печат съвпада с известната дата на миграция, но не съвпада с оригиналната дата на доставка. Ако най-горният "Received" хедър показва април 2024, но "Date" хедърът на имейла показва януари 2021, хедърът от миграцията е причината.
Чести сценарии на CloudM миграция, причиняващи проблеми с датите
Exchange към Google Workspace
Най-честият път на CloudM миграция е от Microsoft Exchange (on-premises или Exchange Online) към Google Workspace. Организациите, преминаващи от Microsoft към Google, използват CloudM за трансфер на пощенски кутии, календари и контакти. Всеки имейл, мигриран по този път, получава "Received" хедъра от миграцията, причинявайки проблеми с показваната дата във всеки IMAP клиент, свързан към Google Workspace кутията.
Office 365 към Google Workspace
Миграциите от Office 365 (Microsoft 365) към Google Workspace следват същия модел. CloudM извлича имейлите чрез Microsoft Graph API или Exchange Web Services и ги вмъква в Google Workspace чрез Gmail API или IMAP. Стъпката на вмъкване добавя хедъра от миграцията и проблемът с датата се появява веднага след завършване на миграцията.
Google Workspace към Google Workspace
Дори миграциите между тенанти на Google Workspace (обичайни при сливания, придобивания или смяна на домейн) могат да предизвикат проблема с датата. CloudM експортира от една Google Workspace организация и импортира в друга, а целевият сървър добавя "Received" хедър по време на процеса на импорт.
Защо проблемът с датата е важен за потребителите на Google Workspace
Потребителите на Google Workspace са особено засегнати, защото много от тях достъпват имейла си чрез множество клиенти. Уеб интерфейсът на Gmail често показва правилната дата (тъй като чете "Date" хедъра), но Outlook, Apple Mail и Thunderbird, свързани към същия акаунт чрез IMAP, показват датата на миграцията. Това създава объркване, когато един и същ имейл се появява с различни дати в различните клиенти.
За организациите, мигрирали към Google Workspace за подобряване на продуктивността, показването на грешна дата на всеки имейл подкопава целия смисъл на миграцията. Потребителите губят доверие в новата платформа, тикетите към бюрото за помощ се натрупват и IT администраторите са изправени пред проблем, който не са предвидили и не могат лесно да разрешат. За да разберете по-добре този проблем, вижте защо имейлите показват грешна дата след IMAP миграция.
Опити за корекция, които не успяват
Сортиране по дата "Изпратено"
Най-честото заобиколно решение е да се каже на потребителите да сортират по дата "Изпратено" вместо по дата "Получено". Това променя реда на показване, но не коригира основните данни. Резултатите от търсенето все още показват грешни времеви печати. Автоматизираните работни процеси и инструментите за съответствие, зависещи от датата на получаване, продължават да не функционират. А потребителите трябва да помнят да променят тази настройка на всяко устройство и във всяка папка. Колко шанс има това да се спази в организация от 200 души?
Свързване с поддръжката на CloudM
Екипът за поддръжка на CloudM не предлага корекция на дати след миграция. Проблемът с датите е последствие от начина, по който IMAP протоколът обработва вмъкването на съобщения, а не бъг в софтуера на CloudM. CloudM не може ретроактивно да премахне "Received" хедърите, добавени по време на миграцията. Инструментът е извършил миграцията правилно - хедърите са очакваният резултат от процеса на вмъкване.
Използване на Google Apps Script
Някои администратори опитват да коригират датите с Google Apps Script. Звучи хитро. Но Google Apps Script не дава достъп до суровите имейл хедъри на нивото, необходимо за премахване на "Received" хедърите. Ендпойнтът modify на Gmail API може да промени етикети и метаданни, но не може да модифицира суровото RFC 2822 съдържание на съобщението. Всъщност пълната корекция изисква работа на много по-дълбоко ниво от това, което Apps Script излага.
Коригиране на CloudM миграционни дати с Redate.io
Как Redate.io обработва CloudM хедърите
Собственият коригиращ двигател на Redate.io анализира пълната верига хедъри на всеки имейл в пощенската кутия. За миграции с CloudM, Redate.io прилага съпоставяне на сигнатури срещу стотици профили на известни инструменти за миграция, включително специфични за CloudM модели, за да идентифицира точно кои "Received" хедъри са добавени по време на миграцията срещу тези, които са легитимни части от оригиналната верига на доставка.
Но идентифицирането на правилния хедър е само началото. Конвейерът за корекция обработва и специалните случаи, които биха объркали обикновен скрипт: S/MIME подписани съобщения, PGP криптирано съдържание, multipart MIME структури с вложени граници, не-ASCII кодирани хедъри и повредени MIME граници от самия процес на миграция. Това е много повече от търсене-замяна на текст в хедъри.
Какво получавате след корекцията
След като Redate.io обработи пощенската кутия, всеки коригиран имейл показва оригиналната си дата на получаване във всички пощенски клиенти - Outlook, Apple Mail, Thunderbird или уеб интерфейса на Gmail. Хронологичният ред е възстановен във всяка папка. Всяка корекция преминава през проверка на целостта преди финализиране, а оригиналите се съхраняват във видима папка "Redate.io - Originals" за 30 дни.
Администраторско делегиране в Google Workspace
За организации с Google Workspace, Redate.io поддържа делегиране на ниво домейн чрез Service Account. IT администраторът се свързва само веднъж и Redate.io може да обработи всички пощенски кутии на организацията без необходимост от индивидуални пароли на потребителите. Това е същият модел на делегиране, който CloudM е използвал за миграцията, което го прави познат за администраторите, вече извършили CloudM миграцията.
Ръководства за корекция на CloudM по платформи
Redate.io предоставя подробни ръководства за всяка комбинация от платформа и клиент, засегната от CloudM миграции:
- Коригиране на CloudM миграционни дати в Gmail
- Коригиране на CloudM миграционни дати в Outlook
- Коригиране на CloudM миграционни дати в Google Workspace
Често задавани въпроси
CloudM има ли опция за предотвратяване на проблеми с датите?
CloudM се опитва да запази INTERNALDATE по време на миграцията. Въпреки това "Received" хедърът, добавен по време на вмъкването, взема превес над INTERNALDATE в повечето пощенски клиенти. Не съществува конфигурация на CloudM, която да попречи на добавянето на този хедър - това е изискване на IMAP протокола.
Redate.io може ли да коригира дати за цяла Google Workspace организация?
Да. Чрез делегиране на ниво домейн Redate.io може да анализира и коригира всяка пощенска кутия в Google Workspace организация от една администраторска връзка. Администраторът избира кои кутии да обработи и Redate.io се грижи за всичко останало.
Корекцията постоянна ли е?
Да. След като Redate.io коригира датата на имейл, корекцията е постоянна. Коригираният имейл показва правилната дата във всички пощенски клиенти занапред. Не е необходим абонамент или текуща поддръжка.
CloudM миграцията остави всеки имейл с грешна дата? Стартирайте безплатен анализ с Redate.io, за да видите точно колко имейла са засегнати и прегледайте корекцията преди покупка.