Migracja GWS do GWS: uszkodzone daty emaili

Scenariusz, którego nikt się nie spodziewa

Migracja z jednego tenanta Google Workspace do drugiego właśnie dobiegła końca. Przejęcie firmy, zmiana domeny, połączenie dwóch jednostek, które od lat funkcjonowały na oddzielnych kontach G Suite. Operacja przebiegła sprawnie, skrzynki są na miejscu, użytkownicy się logują. W poniedziałek rano pierwszy ticket: "Wszystkie moje emaile mają tę samą datę." Potem drugi. Potem dziesięć.

Pierwsza myśl: to na pewno problem z IMAP, źle skonfigurowane narzędzie, coś egzotycznego. Nie migracja Google do Google. A jednak, to dokładnie tutaj się to dzieje.

Ten scenariusz jest prawdopodobnie najsłabiej udokumentowanym przypadkiem w branży. Większość administratorów IT, którzy się z nim spotykają, traci kilka godzin na szukanie przyczyny po stronie klienta pocztowego, po stronie Outlooka, po stronie ustawień konta, zanim zorientuje się, że problem tkwi w nagłówkach samych wiadomości.

Dlaczego migracja Google do Google psuje daty

Żeby zrozumieć, co się dzieje, trzeba wrócić do mechaniki nagłówków email. Każda wiadomość RFC 2822 zawiera oryginalne pole Date:, ustawione przez klienta lub serwer nadawcy w momencie wysyłki. To jest "prawdziwa" data emaila, odpowiadająca temu, kiedy wiadomość została napisana i wysłana.

Istnieje jednak inny mechanizm: INTERNALDATE IMAP. To metadana przechowywana po stronie serwera, wskazująca kiedy wiadomość została umieszczona w skrzynce. I tu zaczyna się problem.

Gdy narzędzie migracyjne przenosi email z jednego tenanta Google Workspace do drugiego, korzysta z protokołu IMAP (nawet jeśli oba serwery należą do Google). Wiadomość jest odczytywana ze źródła, a następnie wstawiana do miejsca docelowego. W momencie tego wstawiania serwer docelowy automatycznie dodaje nagłówek Received: z sygnaturą czasową operacji, czyli datą migracji.

Tymczasem klienty pocztowe takie jak Outlook używają pierwszego Received: z łańcucha do wyświetlania daty wiadomości, niekoniecznie oryginalnego pola Date:. Wynik: wszystkie emaile wyświetlają datę dnia migracji.

Które narzędzia wywołują problem

Praktycznie wszystkie narzędzia używane do migracji między tenantami Google Workspace są dotknięte tym problemem. Bez znaczących wyjątków:

• GSMMO (Google Workspace Migration for Microsoft Outlook): zaprojektowany pierwotnie do migracji z Exchange, ale stosowany w niektórych przepływach GWS do GWS.
• CloudM Migrate: bardzo popularny wśród MSP przy migracjach między tenantami Google, systematycznie dodaje nagłówek Received: migracji. Szczegółowa analiza dostępna w artykule o CloudM i błędnych datach emaili.
• BitTitan MigrationWiz: podobnie, zachowanie jest omówione w artykule poświęconym BitTitanowi.
• imapsync: open source'owe narzędzie do skryptowania migracji IMAP, w tym między dwoma tenantami Google.
• Ręczny eksport/import przez Takeout + reimport IMAP: rzadziej stosowany, ale dający dokładnie ten sam efekt.

Powód jest prosty: wszystkie te narzędzia działają jak standardowe klienty IMAP. Nie mają dostępu do żadnej "natywnej" ścieżki Google, która zachowałaby metadane. Nawet jeśli oba tenanty są u Google, transfer odbywa się przez warstwę IMAP, a ta warstwa nie wie, że rozmawia sama ze sobą.

Mechanika nagłówków Received w szczegółach

(Swoją drogą, jeśli kiedykolwiek próbowali Państwo czytać surowe nagłówki emaila w Gmailu lub Outlooku, wiecie, że nie jest to lektura szczególnie przyjemna. Ale to właśnie tam kryje się cała prawda.)

Email, który podróżował normalną drogą, zawiera łańcuch nagłówków Received: w odwrotnej kolejności względem trasy: serwer, który ostatni dotknął wiadomości, jest na górze. Po migracji nagłówek migracyjny trafia więc na sam szczyt stosu.

Oto jak wygląda to w wiadomości zmigrowanej przez CloudM z jednego tenanta GWS do drugiego:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <uzytkownik@nowa-domena.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Pole Date: mówi: 2019. Pierwszy Received: mówi: październik 2024. Outlook czyta pierwszy Received:. Użytkownik widzi październik 2024 dla emaila z 2019 roku.

Oryginalne pole Date: jest nienaruszone. Nie ruszyło się z miejsca. To dobra wiadomość: dane są tam, czekają tylko na właściwe wykorzystanie.

Outlook i Gmail zachowują się inaczej

To ważne rozróżnienie. Użytkownicy korzystający z emaili przez interfejs webowy Gmaila często widzą poprawne daty, ponieważ Gmail używa priorytetowo pola Date: RFC 2822 do wyświetlania wiadomości. Problem jest mniej widoczny w wersji webowej.

Natomiast użytkownicy, którzy skonfigurują skrzynkę Google Workspace w Outlooku przez IMAP (lub przez synchronizację Exchange ActiveSync), odczuwają pełen efekt błędnych dat. Outlook opiera się na INTERNALDATE IMAP, który odzwierciedla datę pierwszego nagłówka Received: dodanego podczas migracji.

Właściwie, żeby być precyzyjnym: zachowanie Outlooka różni się w zależności od wersji i trybu połączenia. Outlook 2019 i Microsoft 365 (nowsze wersje) używają INTERNALDATE przy połączeniu IMAP. Starsze wersje mogą zachowywać się nieco inaczej. Ale we wszystkich zaobserwowanych przypadkach produkcyjnych migracja GWS do GWS przez IMAP generuje błędne daty w Outlooku.

W efekcie, w organizacjach, które przeszły na nowy tenant i utrzymują użytkowników hybrydowych (część na webowym Gmailu, część na Outlooku), zgłoszenia ticketów są niespójne. Zespoły IT tracą czas na zrozumienie, dlaczego "niektórzy są dotknięci problemem, a inni nie", podczas gdy odpowiedź jest prosta: to klient pocztowy robi różnicę.

Przejęcia, fuzje, zmiany domeny: najczęstsze przypadki

Ten typ migracji nie jest niczym wyjątkowym. Oto scenariusze generujące największą liczbę ticketów:

Przejęcie firmy

Przejęta spółka miała własny tenant Google Workspace (domena @stara-firma.com). Po przejęciu wszystko musi trafić do tenanta firmy-matki (@grupa.com). 250 skrzynek, archiwa, 8 lat historii emaili. BitTitan lub CloudM zostaje zaangażowany do operacji. Wynik: 2,4 miliona emaili z datą weekendu migracji.

Zmiana domeny

Rebrandowana firma przechodzi z @staranazwa.pl na @nowanazwa.pl. Ten sam tenant Google, ale tworzony jest nowy tenant, żeby zacząć od czystej kartki (częsty wybór, żeby uniknąć artefaktów konfiguracyjnych). Migracja skrzynek przez imapsync lub GSMMO. Daty psują się dokładnie w ten sam sposób.

Konsolidacja filii

Grupa z 4 filiami, każda na własnym historycznym tenancie G Suite, decyduje się zebrać wszystko w jednym tenancie. Cztery równoległe migracje, cztery partie emaili z uszkodzonymi datami do naprawienia.

W tych trzech scenariuszach problem jest identyczny i rozwiązanie jest to samo. Checklista migracji email pozwala przewidzieć tego typu problem przed uruchomieniem migracji.

Dlaczego własny skrypt nie jest odpowiedzią

Zrozumieć problem to jedno. Stwierdzić "napiszę skrypt w Pythonie, który wyczyści nagłówki" i uruchomić go na 30 000 produkcyjnych emaili to zupełnie inna historia.

Przypadki brzegowe są nieuniknione. Skrypt działający na 50 testowych wiadomościach w czystym środowisku natknie się nieuchronnie, w produkcyjnej skrzynce realnego rozmiaru, na:

• Wiadomości z podpisami S/MIME lub treścią szyfrowaną PGP, gdzie jakakolwiek modyfikacja struktury wiadomości unieważnia podpis kryptograficzny.
• Emaile ze złożonymi zagnieżdżonymi strukturami MIME (multipart/alternative wewnątrz multipart/mixed z załącznikami o rozmiarze kilkudziesięciu megabajtów).
• Nagłówki zakodowane w RFC 2047 (znaki spoza ASCII), które źle skonfigurowane parsery po cichu zjadają.
• Błędy 429 Too Many Requests z API Google o 2 w nocy, w trakcie wsadowej korekty, które zostawiają proces w nieokreślonym stanie.
• Emaile, w których łańcuch Received: jest niejednoznaczny: kilka kolejnych narzędzi migracyjnych dodało każde swój nagłówek i niełatwo ustalić, który usunąć.

I najważniejsze pytanie: jak weryfikować, email po emailu, że każda poprawiona wiadomość jest nienaruszona i że nic nie zostało utracone ani uszkodzone? Własny skrypt zazwyczaj tej weryfikacji nie przeprowadza. Redate.io robi to automatycznie, zachowując oryginały w widocznym folderze kopii zapasowej przez 30 dni.

Co robi Redate.io przy tego typu migracji

Redate.io łączy się z docelowym tenantem Google Workspace (przez delegację domenową, bez ręcznej konfiguracji skrzynka po skrzynce) i skanuje emaile w celu identyfikacji tych, których metadane daty są niespójne z treścią wiadomości. Faza skanowania jest bezpłatna i daje dokładny obraz skali problemu przed jakąkolwiek korektą.

Autorski silnik korekcji analizuje następnie łańcuch nagłówków każdej wiadomości, stosuje dopasowywanie wzorców na znanych sygnaturach narzędzi migracyjnych (BitTitan, CloudM, imapsync, GSMMO i innych mniej popularnych) oraz przeprowadza celowaną korektę metadanych bez modyfikowania treści wiadomości. Każdy poprawiony email jest weryfikowany indywidualnie. Oryginały są zachowane.

W przypadku migracji między tenantami Google Workspace, pipeline obsługuje sytuacje, w których miały miejsce kolejne przebiegi migracji (na przykład skrzynka zmigrowana pierwszy raz w 2021 roku, a następnie ponownie w 2024), z wieloma warstwami pasożytniczych nagłówków do rozplątania.

Szczegółowe przewodniki po korekcji dla CloudM do Google Workspace oraz BitTitan do Google Workspace opisują kroki połączenia dla tego typu konfiguracji.

Wykrycie problemu zanim użytkownicy zaczną się skarżyć

Najlepszy moment na wykrycie uszkodzonych dat to zaraz po migracji, przed uruchomieniem produkcyjnym. Szybka weryfikacja na kilku pilotażowych skrzynkach przez klienta IMAP, takiego jak Thunderbird, pozwala porównać wyświetlanie dat z tym, czego można by się spodziewać. Jeśli wszystkie zaimportowane emaile wydają się mieć tę samą, świeżą datę, to charakterystyczny znak problemu.

W praktyce jednak odkrycie problemu następuje często kilka tygodni po migracji, gdy użytkownik szuka starego kontraktu i stwierdza, że jego skrzynka Gmaila jest idealnie posortowana... po dacie migracji. Tysiące emaili skumulowanych pod tym samym znacznikiem czasu. Wyszukiwanie po dacie przestało działać. Wątki są w nieładzie. Historia wydaje się zniknąć.

Dla MSP regularnie przeprowadzających migracje między tenantami Google Workspace, włączenie skanu Redate.io do checklisty post-migracyjnej (przed odbiorem przez klienta) pozwala uniknąć tego rodzaju niespodzianek.

Przeprowadzono migrację między dwoma tenantami Google Workspace i daty emaili są nieprawidłowe? Uruchom bezpłatny skan w Redate.io, żeby ocenić skalę problemu przed jakąkolwiek korektą.