CloudM Migrate: jak naprawić daty e-maili

Problem z datami CloudM Migrate, o którym nikt nie ostrzega

CloudM Migrate zakończył pracę. Panel pokazuje 100% ukończenia, wszyscy użytkownicy przeniesieni, zero błędów. Zgłoszenie projektu zostaje zamknięte, a uwaga przechodzi do kolejnego klienta.

Tydzień później dzwoni dyrektor IT. "Dlaczego każdy e-mail w mojej skrzynce pokazuje 2 kwietnia?"

Nie niektóre e-maile. Wszystkie. Pięć lat korespondencji z klientami, dokumenty prawne, akta kadrowe, zamówienia zakupu z 2020 roku, wszystko pokazuje datę, w której CloudM przeprowadził migrację. Wiadomości są na miejscu, treść jest nienaruszona, załączniki w porządku. Ale daty są błędne w każdej jednej z nich.

To nie jest błąd CloudM. Dokumentacja wsparcia CloudM otwarcie to przyznaje. Problem leży na styku sposobu, w jaki narzędzia migracyjne przenoszą wiadomości, i sposobu, w jaki serwery docelowe obsługują metadane przychodzącej poczty. Ale ta wiedza nie pomoże klientowi, którego skrzynka odbiorcza właśnie stała się niemożliwa do sortowania.

Jak CloudM faktycznie przenosi wiadomości e-mail

CloudM Migrate łączy się z platformą źródłową i docelową przez ich API. Dla Google Workspace oznacza to konto usługi z delegacją na poziomie domeny (konfigurowane w Google Admin Console w sekcji Security > API Controls). Dla Microsoft 365 używa Exchange Web Services lub Microsoft Graph API, w zależności od ścieżki migracji.

Gdy CloudM czyta wiadomość ze źródła, pobiera pełną zawartość RFC 2822, włącznie ze wszystkimi oryginalnymi nagłówkami i treścią wiadomości. Oryginalny nagłówek Date: (ten, który serwer pocztowy nadawcy umieścił przy pierwszym wysłaniu) przychodzi nienaruszony. Wszystkie oryginalne nagłówki Received:, śledzące ścieżkę dostarczenia wiadomości, również.

Problem pojawia się w momencie zapisu kopii. Serwer docelowy zachowuje datę, którą otrzymuje: Microsoft 365 i Gmail zachowują oryginalną datę, jeśli kopia ją przenosi. Gdy tego nie robi, kopia otrzymuje jako datę moment wstawienia. A w Google Workspace każda wiadomość zapisana przez Gmail API dostaje też nowy nagłówek Received: opatrzony datą momentu wstawienia.

Tak wyglądają nagłówki jednego z tych e-maili, zachowane po migracji CloudM do Microsoft 365:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Oryginalny nagłówek Date: z 2019 roku jest wciąż na miejscu, tak jak oryginalny łańcuch Received:. Ale w Microsoft 365 data, którą Outlook pokazuje jako datę odebrania, to własny zapis skrzynki pocztowej o tym, kiedy dotarł każdy e-mail: jeśli CloudM nie przekazał oryginalnej daty, ten zapis mówi 2 kwietnia 2026.

Ustawienie "Strip Received Headers" w CloudM

CloudM oferuje ustawienie mające rozwiązać ten problem. W Advanced Settings platformy docelowej, w sekcji Message Options, znajduje się przełącznik "Strip Received Headers". Po włączeniu CloudM usuwa nagłówki Received przed wstawieniem wiadomości i zastępuje je jednym nagłówkiem odpowiadającym nagłówkowi Date: e-maila.

Brzmi jakby rozwiązywało wszystko, prawda? Nie do końca.

Po pierwsze, trzeba o tym wiedzieć przed uruchomieniem migracji. Większość administratorów odkrywa problem z datami po zakończeniu migracji. W tym momencie wiadomości już leżą w skrzynce docelowej z błędnymi datami. Ponowne uruchomienie CloudM z włączonym ustawieniem tworzy tylko duplikaty, nie naprawia tego, co już tam jest.

Po drugie, to ustawienie ma poważne ograniczenie, gdy platformą docelową jest Google Workspace. Dokumentacja Google to potwierdza: Gmail zawsze dodaje nagłówek Received: do wiadomości wstawianych przez API, opatrując go znacznikiem czasu wstawienia. To ograniczenie na poziomie platformy, którego CloudM nie może obejść. Nawet z włączonym "Strip Received Headers" Google Workspace dodaje własny nagłówek Received: z datą migracji.

Dla środowisk Microsoft 365 to ustawienie ma mniejsze znaczenie: Microsoft 365 zachowuje datę, którą otrzymuje, więc o wyświetlanej dacie decyduje to, czy CloudM przekazuje oryginalną datę każdego e-maila.

Które migracje CloudM psują daty (a które nie)

Nie każda migracja CloudM generuje błędne daty. Wynik zależy od kombinacji źródło-cel oraz konkretnej ścieżki API, którą wykorzystuje CloudM:

• Google Workspace do Microsoft 365: daty się psują. CloudM czyta przez Gmail API i zapisuje do Exchange, a każdy e-mail otrzymuje datę kopii.
• Microsoft 365 do Google Workspace: daty się psują. Nawet z włączonym Strip Received Headers API Google dodaje nagłówek Received: opatrzony datą wstawienia. Dokumentacja wsparcia CloudM nazywa to "ścisłym ograniczeniem platformy".
• Google Workspace do Google Workspace: daty się psują. Zmiany domeny, konsolidacje tenantów, fuzje po przejęciach: każda wiadomość zapisana przez Gmail API dostaje nagłówek Received: opatrzony datą migracji.
• Lokalny Exchange do Microsoft 365: wszystko zależy od daty przekazanej przez CloudM, niezależnie czy kopia przechodzi przez IMAP czy EWS.
• Ogólne źródło IMAP do dowolnego celu: ta sama zasada: gdy CloudM łączy się z ogólnym serwerem IMAP jako źródłem, kopia pokazuje datę migracji zawsze, gdy oryginalna data nie zostanie przekazana do celu.

Trudna część? Panel migracji CloudM niczego z tego nie sygnalizuje. Pasek postępu się wypełnia, kolumna statusu mówi "Completed", liczby elementów się zgadzają. Z perspektywy CloudM migracja się powiodła. I technicznie tak było. Wiadomości zostały przeniesione. Daty po prostu nie przetrwały podróży.

CloudM Managed i Self-Service: ten sam problem z datami

CloudM oferuje dwa modele wdrożenia. Wersja SaaS (hostowany CloudM Migrate) działa w całości w infrastrukturze CloudM. Wersja self-hosted pozwala wdrożyć podstawowe i pomocnicze serwery migracji we własnej sieci, Google Cloud, Azure lub AWS.

Niektórzy MSP zakładają, że opcja self-hosted daje większą kontrolę nad obsługą dat, ponieważ serwerami migracji zarządza się bezpośrednio. To nieprawda. O dacie decyduje to, co silnik migracji przekazuje wraz z każdą wiadomością, a ten silnik jest ten sam niezależnie od tego, gdzie działa. Niezależnie od tego, czy farma migracji działa w chmurze CloudM, czy na własnej maszynie Azure VM, wynik dla dat jest taki sam.

CloudM oferuje też w pełni zarządzaną usługę "Serviced Migration", w której ich zespół prowadzi projekt od początku do końca. Ten sam wynik dla dat. Inżynieria jest identyczna, różnią się tylko ręce na klawiaturze. Czy zdarzyło się płacić za usługę premium i mimo to otrzymać to samo ograniczenie co w darmowym planie? Właśnie tak to wygląda.

Komplikacja z nieprawidłowym nagłówkiem Date

Istnieje jeszcze jedno zachowanie specyficzne dla CloudM, które pogarsza sytuację. Gdy CloudM napotyka źródłowy e-mail z nagłówkiem Date:, który nie jest zgodny z RFC 822 (błędna strefa czasowa, brakujący dzień tygodnia, niestandardowy format), modyfikuje nagłówek, aby zapewnić możliwość migracji wiadomości.

Oznacza to, że niektóre e-maile tracą nawet oryginalne odniesienie do daty. Zmodyfikowany nagłówek Date: może w ogóle nie odpowiadać rzeczywistej dacie wysłania. Dokumentacja wsparcia CloudM wspomina o tym jako znanym zachowaniu w sekcji "Possible Changes to Migrated Items", ale nie precyzuje, jaka staje się zmodyfikowana data.

Dla skrzynki pocztowej z 12 000 wiadomościami zgromadzonymi przez osiem lat mogą się znaleźć setki e-maili z lekko niestandardowymi nagłówkami Date (szczególnie wiadomości ze starszych serwerów pocztowych, systemów automatycznych lub od międzynarodowych nadawców z osobliwościami formatowania strefy czasowej). Po modyfikacji CloudM, a do tego kopii, która nie przenosi oryginalnej daty, te wiadomości kończą z datami niemającymi nic wspólnego z rzeczywistością.

Dlaczego ręczne poprawki nie skalują się po CloudM

Czy można to naprawić samodzielnie? Technicznie oryginalny nagłówek Date: jest wciąż osadzony w większości wiadomości (z wyjątkiem tych, które CloudM zmodyfikował dla zgodności z RFC). Niektórzy administratorzy próbowali pisać skrypty do poprawiania dat po migracji CloudM.

Rzeczywistość takiego podejścia jest inna. Trzeba połączyć się z potencjalnie tysiącami skrzynek pocztowych, z których każda zawiera tysiące wiadomości. Dla każdego e-maila trzeba przeanalizować cały łańcuch nagłówków, zidentyfikować, które nagłówki Received: dodał CloudM lub serwer docelowy, obsłużyć przypadki brzegowe (wiadomości podpisane S/MIME, gdzie modyfikacja nagłówka łamie podpis, zawartość zaszyfrowaną PGP, wieloczęściowe struktury MIME z zagnieżdżonymi granicami, zakodowane wg RFC 2047 nagłówki non-ASCII od japońskich lub koreańskich nadawców), i zrobić to wszystko bez utraty jednego załącznika czy zerwania wątków e-mailowych.

Skrypt, który działa na 50 testowych e-mailach z czystej skrzynki, nie przetrwa zderzenia ze środowiskiem produkcyjnym liczącym 40 000 wiadomości z dekady. Co się stanie, gdy trafi na e-mail o wadze 47 MB z sześcioma zagnieżdżonymi załącznikami? A co z limitami API (250 jednostek limitu Google na użytkownika na sekundę, throttling Microsoftu na poziomie około 10 000 żądań na 10 minut)? Jaki jest plan wycofania, gdy coś pójdzie nie tak na wiadomości numer 8347?

A prawdziwe pytanie, którego większość administratorów nie zadaje, aż jest już za późno: jak zweryfikować, że każda poprawiona wiadomość jest naprawdę nienaruszona?

Naprawa dat migracji CloudM za pomocą Redate.io

Redate.io łączy się bezpośrednio z dotkniętymi skrzynkami pocztowymi (Google Workspace, Microsoft 365 lub IMAP) i skanuje w poszukiwaniu e-maili, których wyświetlana data nie zgadza się z ich oryginalną datą. Skanowanie jest bezpłatne i zajmuje kilka minut na skrzynkę, pokazując dokładną liczbę dotkniętych wiadomości przed jakimkolwiek zobowiązaniem.

Korekta wykorzystuje silnik analizy łańcucha nagłówków opracowany przez Redate i nie musi wiedzieć, jakie narzędzie przeprowadziło migrację. Redate.io wykonuje celowaną korektę metadanych bez zmiany treści wiadomości, zachowując załączniki, wątki, etykiety, foldery i podpisy cyfrowe. Każda poprawiona wiadomość przechodzi indywidualną weryfikację, sprawdzającą integralność wiadomości w porównaniu z oryginałem, zanim proces przejdzie dalej.

Oryginalne e-maile są przechowywane w widocznym folderze kopii zapasowej Redate.io - Originals, aż do samodzielnego usunięcia. Jeśli cokolwiek wymaga wycofania, oryginały znajdują się prosto w skrzynce pocztowej, a nie ukryte w jakimś zewnętrznym archiwum.

Dla MSP, którzy używali CloudM w środowiskach klientów, Redate.io obsługuje korekty wielu skrzynek na dużą skalę, z tą samą weryfikacją każdej wiadomości, niezależnie od tego, czy naprawiana jest 1 skrzynka czy 500. Problem z datami pozostawiony przez CloudM nie musi stać się trwałym elementem środowiska pocztowego klienta.

Przewodniki dla poszczególnych platform dotyczące migracji CloudM

Proces korekty dostosowuje się do platformy docelowej. Redate.io automatycznie obsługuje specyfikę każdej platformy, ale szczegóły dotyczące własnej konfiguracji można znaleźć tutaj:

• Napraw daty migracji CloudM w Gmail
• Napraw daty migracji CloudM w Outlook
• Napraw daty migracji CloudM w Google Workspace
• Napraw daty migracji CloudM w Microsoft 365

Aby dokładniej zrozumieć, dlaczego to się dzieje we wszystkich narzędziach migracyjnych, nie tylko w CloudM, zobacz dlaczego e-maile pokazują błędne daty po migracji.

Migracja przez CloudM zostawiła błędne daty na każdym e-mailu? Uruchom bezpłatne skanowanie, aby zobaczyć dokładnie, ile wiadomości jest dotkniętych i ile kosztuje ich naprawa.