Коригиране на имейл дати след миграция към Google Workspace

Проблемът с датите след миграция към Google Workspace

Организациите, мигриращи към Google Workspace, често правят неприятно откритие: всички имейли във всички пощенски кутии показват грешна дата. Вместо оригиналната дата на изпращане или получаване, всяко съобщение показва датата, на която е извършена миграцията. Независимо дали организацията е мигрирала от Microsoft Exchange, Office 365, Zimbra, Lotus Notes или друг IMAP сървър. Хиляди имейли, всички с един и същи печат.

И това не е специфично за конкретен инструмент за миграция. Проблемът се наблюдава при BitTitan MigrationWiz, CloudM Migrate, GSMMO, imapsync и всички други инструменти, вмъкващи имейли в Google Workspace чрез IMAP или Gmail API. Причината е свързана с фундаментален механизъм на обработката на съобщенията от пощенските сървъри.

За специфично ръководство за инструмента GSMMO (Google Workspace Migration for Microsoft Outlook) вижте посветената статия за GSMMO.

Чести пътища за миграция към Google Workspace

От Microsoft Exchange (on-premises)

Организациите, оперирещи Exchange сървъри на място (2010, 2013, 2016 или 2019), мигрират към Google Workspace за намаляване на инфраструктурните разходи и приемане на облачен модел. Тези миграции обикновено използват CloudM, BitTitan MigrationWiz или GSMMO. Инструментът за миграция се свързва с Exchange, изтегля всеки имейл и го зарежда в Google Workspace кутията на потребителя. Всеки зареден имейл получава нов "Received" хедър с времевия печат на миграцията.

От Microsoft 365 (Office 365)

Миграциите от Microsoft 365 към Google Workspace са чести, когато организациите сменят екосистемата. BitTitan MigrationWiz и CloudM са най-популярните инструменти за този тип миграция. Процесът извлича имейлите от Exchange Online и ги вмъква в Google Workspace. Същият проблем с "Received" хедъра се прилага: всеки мигриран имейл показва датата на миграцията.

От други IMAP сървъри

Миграциите от Zimbra, Zoho, cPanel хостинг, Dovecot, Courier и други IMAP сървъри към Google Workspace използват инструменти като imapsync, CloudM или персонализирани скриптове. Дестинацията (Google Workspace) добавя "Received" хедър при операцията за вмъкване, независимо от изходната платформа. Дори миграциите от друг Google Workspace тенант произвеждат същия проблем.

Защо датите се развалят в Google Workspace

Уеб интерфейсът на Gmail срещу IMAP клиентите

Google Workspace представя особена ситуация. Уеб интерфейсът на Gmail обикновено използва "Date" хедъра на имейла за показване на датата на съобщението, което означава, че имейлите често се появяват с правилната дата, когато се преглеждат чрез уеб интерфейса. От друга страна, когато същата кутия се достъпва чрез IMAP клиент (Outlook, Apple Mail, Thunderbird), клиентът чете най-скорошния "Received" хедър и показва датата на миграцията.

Тази разлика създава значително объркване. Администратор, тестващ миграцията в уеб интерфейса на Gmail, вижда правилни дати и заключава, че миграцията е успешна. Но когато потребителите свържат Outlook към Google Workspace акаунта си, те съобщават, че всеки имейл има грешна дата. Проблемът наистина съществува на сървъра (хедърите съдържат времевия печат на миграцията), но става видим само в определени клиенти. Колко администратори са закрили миграционен проект, мислейки, че всичко е наред, за да бъдат затрупани с тикети следващия понеделник?

Факторът IMAP INTERNALDATE

Google Workspace съхранява INTERNALDATE за всеки имейл, зададена по време на процеса на вмъкване. Някои инструменти за миграция задават правилно тази стойност на оригиналната дата, други я оставят на датата на миграцията. Но дори когато INTERNALDATE е правилна, IMAP клиентите, които дават приоритет на "Received" хедърите (като Outlook), все пак показват грешна дата. Пълната корекция изисква както премахване на миграционния "Received" хедър, така и проверка, че INTERNALDATE е правилно зададена. За подробно техническо обяснение вижте защо имейлите показват грешни дати след IMAP миграция.

Административни опции на Google Workspace (които не работят)

Административната конзола на Google

Административната конзола на Google предлага обширни контроли за управление на Google Workspace, но не включва функционалност за коригиране на имейл дати след миграция. Няма инструмент за масова редакция на хедъри. Няма помощна програма за корекция на дати. Няма начин за модификация на INTERNALDATE на съществуващи имейли чрез административния интерфейс.

Google Apps Script

Google Apps Script може да автоматизира много Gmail операции, но не може да модифицира суровите хедъри на имейлите. Услугите GmailApp и Gmail API, изложени чрез Apps Script, позволяват четене на съобщения, смяна на етикети и промяна на метаданни, но не поддържат замяна на суровото RFC 2822 съдържание на съобщението. Корекцията изисква работа на много по-дълбоко ниво от това, което Apps Script излага.

Услуга за миграция на данни на Google

Услугата за миграция на данни на Google (достъпна в административната конзола) е проектирана за мигриране на имейли към Google Workspace, а не за коригиране на хедъри след миграция. Стартирането на втора миграция с този инструмент би добавило допълнителен "Received" хедър, влошавайки проблема.

Коригиране на Google Workspace дати с Redate.io

Как работи администраторското делегиране

Redate.io използва функционалността за делегиране на ниво домейн на Google Workspace за достъп до пощенските кутии. Администраторът създава Service Account в Google Cloud Console, предоставя му необходимите Gmail API обхвати и активира делегирането на ниво домейн. Това позволява на Redate.io да обработи всяка пощенска кутия на организацията без необходимост от индивидуални потребителски данни.

Конфигурирането на делегирането отнема около 10 минути и следва същия процес като другите инструменти за миграция и управление на Google Workspace. След конфигуриране администраторът може да анализира и коригира произволен брой кутии от таблото на Redate.io.

Начало

Създайте Service Account. В Google Cloud Console създайте нов проект (или използвайте съществуващ), активирайте Gmail API и създайте Service Account с активирано делегиране на ниво домейн.

Предоставете API обхвати. В административната конзола на Google Workspace навигирайте до Сигурност, после Контроли на API, после Делегиране на ниво домейн. Добавете клиентския ID на Service Account и предоставете изискваните от Redate.io Gmail API обхвати.

Свържете в Redate.io. Влезте в Redate.io, изберете "Google Workspace" като платформа и качете JSON ключовия файл на Service Account. Redate.io валидира връзката и изброява наличните кутии.

Анализирайте кутиите. Изберете кутиите за анализ (или анализирайте всички). Безплатният анализ идентифицира броя имейли с неправилни дати във всяка кутия. Не се изисква плащане за анализа.

Коригирайте. Прегледайте резултатите от анализа, изберете план и стартирайте корекцията. Собственият коригиращ двигател на Redate.io обработва всяка кутия, подавайки всеки имейл през многоетапен процес на анализ, който обработва проблеми с кодирането, multipart структури на съобщенията, цифрови подписи и десетки специални случаи, които персонализиран скрипт би повредил. Прогресът е видим в реално време. Оригиналните съобщения се съхраняват в етикет "Redate.io - Originals" за 30 дни.

След корекцията

След приключване на корекцията от Redate.io имейлите показват правилната дата във всички клиенти: Gmail уеб, Outlook, Apple Mail, Thunderbird и всяко друго приложение, свързано чрез IMAP. Корекцията е постоянна. Не е необходима текуща поддръжка или абонамент. Потребителите могат да сортират по дата, да търсят по диапазон от дати и да използват инструменти за съответствие с увереност в точността на времевите печати. Кутията функционира както е трябвало от първия ден.

Специфични ръководства по инструменти за Google Workspace

За подробни инструкции, базирани на конкретния използван инструмент за миграция, вижте тези ръководства:

Миграция към Google Workspace и всички имейли показват грешна дата? Стартирайте безплатен анализ с Redate.io, за да видите колко имейла са засегнати във всички кутии и възстановете правилните дати.