GSMMO zepsuło daty e-maili? Jak to naprawić

GSMMO i problem z datami, o którym nikt nie ostrzega

Google Workspace Migration for Microsoft Outlook (GSMMO) to narzędzie desktopowe udostępniane przez Google do migracji plików PST, profili Outlook i lokalnych archiwów e-mail do Gmaila. Jest bezpłatne, oficjalnie wspierane i to jest właśnie ta ścieżka migracji, którą Google poleca przy przenoszeniu małego zespołu lub kilku indywidualnych skrzynek pocztowych z Outlooka do Google Workspace.

Narzędzie działa. E-maile trafiają do Gmaila, struktura folderów mapuje się na etykiety, kontakty przechodzą. Ale wystarczy otworzyć Gmaila później i posortować wiadomości po dacie. Każdy e-mail pokazuje dzisiejszą datę. Ta propozycja wysłana w styczniu 2021 roku? Kwiecień 2026. Faktura od księgowego z marca 2023 roku? Również kwiecień 2026.

GSMMO nie ostrzega, że to się stanie. Dziennik migracji pokazuje sukces dla każdej wiadomości. Dokumentacja Google nie wymienia tego jako znanego ograniczenia. Problem odkrywa się dopiero wtedy, gdy ktoś szuka starego e-maila według zakresu dat i otrzymuje zero wyników.

Jak GSMMO faktycznie przesyła e-maile

GSMMO odczytuje wiadomości z pliku PST (lub bezpośrednio z profilu Outlook) i przesyła je do Gmaila przez Gmail API (tak wynika z własnych notatek wydania tego narzędzia od Google). Właśnie tu powstaje problem z datami i warto zrozumieć ten mechanizm, bo wyjaśnia, dlaczego naprawa nie jest tak prosta jak "po prostu zaimportować jeszcze raz".

Gdy GSMMO przesyła wiadomość przez Gmail API, Gmail dodaje nowy nagłówek Received: datowany na moment przesłania. A gdy oryginalna data nie jest przekazana wraz z wiadomością, INTERNALDATE, czyli znacznik czasu, który Gmail wykorzystuje wewnętrznie do sortowania i wyświetlania, zostaje ustawiony na moment przesłania, a nie na oryginalną datę wysłania.

Tak wygląda łańcuch nagłówków po migracji 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

Ten oryginalny nagłówek Date: z września 2019 roku wciąż tam jest, nienaruszony. GSMMO nie modyfikuje treści wiadomości ani oryginalnych nagłówków. Gmail jednak ignoruje go do celów wyświetlania i używa zamiast tego INTERNALDATE, który teraz wskazuje kwiecień 2026.

GSMMO a narzędzia migracji po stronie administratora

Tu często zaczyna się zamieszanie. Google udostępnia kilka narzędzi migracji i nie wszystkie działają tak samo.

GSMMO (aplikacja desktopowa) działa na komputerze użytkownika. Odczytuje dane z Outlooka lub pliku PST i przesyła e-maile przez Gmail API. Użytkownik potrzebuje konta Google Workspace oraz wtyczki GSMMO zainstalowanej w Outlooku. To narzędzie po stronie klienta.

Google Workspace Migration Service (narzędzie w konsoli administracyjnej) działa po stronie serwera. Administrator konfiguruje je w Google Admin Console, wskazuje serwer Exchange lub inną organizację Google Workspace, a migracja przebiega w infrastrukturze Google. To narzędzie ma w niektórych konfiguracjach nieco lepszą obsługę dat, ponieważ może ustawić INTERNALDATE na podstawie metadanych źródła. Ale "nieco lepsza" nie znaczy "wiarygodna", a wielu administratorów zgłasza ten sam problem z datami również przy tym narzędziu.

Najważniejsza różnica? W przypadku GSMMO nie ma po stronie serwera żadnej logiki podejmującej decyzje o zachowaniu daty. Każda przesłana wiadomość jest traktowana tak samo, niezależnie od tego, czy to świeży e-mail czy zarchiwizowana wiadomość z dziesięciu lat: nagłówek Received: datowany na dzień przesłania. Koniec.

Dlaczego zachowanie dat przez GSMMO nie działa

Sprawdzając ustawienia GSMMO, można zauważyć, że nie istnieje tam opcja "zachowaj daty". To nie przeoczenie. GSMMO zależy od sposobu, w jaki Gmail obsługuje wiadomości przesyłane przez swoje API, i nie może tego nadpisać.

Tak wygląda techniczny łańcuch zdarzeń:

1. GSMMO odczytuje wiadomość z pliku PST, łącznie z jej oryginalnymi znacznikami czasu
2. GSMMO przesyła dane wiadomości przez Gmail API
3. Gmail odbiera przesłane dane i zapisuje wiadomość w skrzynce pocztowej
4. Gmail dodaje nowy nagłówek Received: datowany na moment przesłania (linia gmailapi.google.com w przykładzie powyżej)
5. Gdy oryginalna data nie jest przekazana, Gmail ustawia INTERNALDATE na znacznik czasu przesłania
6. Wiadomość trafia do Gmaila z dzisiejszą datą

Kroki 4 i 5 są decydujące. Gmail dodaje ten nagłówek do każdej wiadomości przesłanej przez swoje API, niezależnie od tego, co wysyła narzędzie, a GSMMO nie ma ustawienia, które przekazałoby lub zachowało oryginalną datę. Efekt jest taki, że wszystkie historyczne e-maile wyglądają, jakby przyszły dzisiaj.

Niektórzy administratorzy próbowali uruchamiać GSMMO z określonymi ustawieniami Google Workspace lub dostosowywać ustawienia profilu GSMMO. Żadne z nich nie wpływa na zachowanie dat. Nagłówek Received: jest dodawany po stronie Google i żadna konfiguracja po stronie klienta tego nie zmienia.

Konkretne scenariusze GSMMO psujące daty

Nie każda migracja GSMMO kończy się chaosem dat, choć większość tak. Oto sytuacje, w których ma to znaczenie:

• Plik PST do Gmaila: Daty się psują. To najczęstszy przypadek użycia GSMMO i najbardziej narażony.
• Profil Outlook do Gmaila: Daty się psują. Ten sam sposób przesyłania przez Gmail API co import PST.
• Exchange Online (Microsoft 365) do Gmaila przez GSMMO: Daty się psują. GSMMO odczytuje dane z serwera Exchange i przesyła je przez Gmail API.
• Exchange lokalny do Gmaila przez GSMMO: Daty się psują. Ten sam mechanizm.
• Gmail do Gmaila (ponowny import eksportu PST): Daty się psują. Nawet jeśli oryginalne e-maile miały prawidłowe daty w pliku PST, ponowny import stempluje je na nowo.

Wzorzec jest jasny. Każda wiadomość przesłana przez Gmail API otrzymuje nagłówek Received: datowany na dzień przesłania. GSMMO zawsze korzysta z tej ścieżki.

Co jest szczególnie frustrujące, raport migracji GSMMO pokazuje wszystko jako zakończone sukcesem. Żadnych ostrzeżeń o datach, żadnych błędów, żadnych flag. Trzeba by ręcznie porównać znaczniki czasu przed i po migracji, żeby to zauważyć, a większość administratorów nie robi tego, dopóki użytkownik się nie zgłosi.

Wpływ wykraczający poza sortowanie

Błędne daty po migracji GSMMO tworzą realne problemy, które wykraczają daleko poza nieporządek w skrzynce.

Wyobraźmy sobie księgowego, który właśnie przeniósł się na Google Workspace. Potrzebuje znaleźć całą korespondencję z klientami z trzeciego kwartału 2024 roku na potrzeby rozliczenia podatkowego. Wyszukuje w Gmailu według zakresu dat: lipiec do września 2024. Zero wyników. Każdy e-mail z tego okresu pokazuje teraz datę migracji, więc filtr dat Gmaila nie może ich znaleźć. Pozostaje przewijanie tysięcy wiadomości albo wyszukiwanie po słowach kluczowych z nadzieją, że pamięta się właściwe terminy.

Dla branż regulowanych to więcej niż niewygoda. Znaczniki czasu e-maili służą jako dowód prawny. Doradca finansowy, który musi udowodnić, że wysłał ujawnienie informacji przed datą transakcji, nie może tego zrobić, gdy e-mail pokazuje kwiecień 2026 roku zamiast lutego 2023. Audyty zgodności z SOX lub HIPAA opierają się na dokładnych znacznikach czasu komunikacji, a błędne daty oznaczają niezaliczone audyty.

A potem jest problem z wątkami. Gmail grupuje konwersacje według daty i tematu. Gdy każda wiadomość w wątku pokazuje tę samą datę, widok konwersacji staje się pomieszany. Odpowiedzi pojawiają się przed oryginalną wiadomością. Cała struktura wątku zapada się w kupę identycznie datowanych e-maili.

Naprawa dat GSMMO za pomocą Redate.io

Dobra wiadomość: oryginalny nagłówek Date: jest wciąż nienaruszony wewnątrz każdego zmigrowanego e-maila. GSMMO nie modyfikuje treści wiadomości. Prawidłowa data tam jest, tylko jest ignorowana przez logikę wyświetlania Gmaila, ponieważ INTERNALDATE i górny nagłówek Received wskazują na datę migracji.

Redate.io łączy się ze skrzynką pocztową Google Workspace, skanuje e-maile dotknięte migracją GSMMO i koryguje metadane dat za pomocą zastrzeżonego mechanizmu analizy łańcucha nagłówków i rekonstrukcji dat. Redate nie musi wiedzieć, jakie narzędzie wykonało migrację: znajduje e-maile, których wyświetlana data nie zgadza się z ich oryginalną datą, i koryguje je bez zmiany treści wiadomości, załączników czy struktury wątków.

Każdy poprawiony e-mail przechodzi indywidualną weryfikację: integralność wiadomości, zachowanie załączników, mapowanie etykiet i spójność wątku. Oryginały pozostają w widocznym folderze kopii zapasowej Redate.io - Originals we własnej skrzynce pocztowej, dopóki nie zostaną samodzielnie usunięte.

Czy można to naprawić samodzielnie za pomocą skryptu? Zrozumienie problemu to jedna rzecz. Poprawienie 12 000 e-maili bez zniszczenia podpisów S/MIME, popsucia zagnieżdżonych części MIME czy zniekształcenia nagłówków kodowanych według RFC 2047 w produkcyjnej skrzynce pocztowej to zupełnie inna sprawa. Jak obsłużyć e-mail z załącznikiem 38 MB i nieprawidłową granicą MIME, który GSMMO zaimportowało, ale ledwo utrzymało w całości? Jak zweryfikować, że każda pojedyncza wiadomość przeszła bez zniszczeń? Skrypt, który działa na 20 testowych wiadomościach w laboratorium, nie przetrwa realnej skrzynki pocztowej z ośmioletnią korespondencją.

Przewodniki dla konkretnych platform GSMMO

Skoro GSMMO migruje konkretnie do Google Workspace, naprawa odbywa się na poziomie Gmaila. Ale dotknięte e-maile są widoczne w każdym kliencie połączonym z tym kontem Gmail:

• Napraw daty migracji GSMMO w Gmailu
• Napraw daty migracji GSMMO w Outlooku (połączonym z Google Workspace)
• Napraw daty migracji GSMMO w Apple Mail

Migracja odbyła się już miesiące temu? Oryginalny nagłówek Date nie ulega degradacji z czasem. Redate.io może naprawić e-maile dotknięte GSMMO niezależnie od tego, czy migracja odbyła się tydzień temu, czy trzy lata temu.

Migracja GSMMO zostawiła e-maile z błędnymi datami? Darmowe skanowanie pokazuje dokładną liczbę dotkniętych e-maili oraz koszt naprawy, zanim zapadnie jakakolwiek decyzja.