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. Zamykamy zgłoszenie projektu i przechodzimy do kolejnego klienta.

Tydzień później dzwoni dyrektor IT. "Dlaczego każdy e-mail w moich skrzynkach 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ę uruchomienia migracji CloudM. Wiadomości są na miejscu, treść nienaruszona, załączniki w porządku. Ale daty są błędne w każdym e-mailu.

To nie jest błąd CloudM. Dokumentacja wsparcia CloudM otwarcie to przyznaje. Problem leży na styku sposobu przenoszenia wiadomości przez narzędzia migracyjne i sposobu obsługi metadanych przychodzących wiadomości przez serwery docelowe. Ale ta wiedza nie pomoże klientowi, którego skrzynka odbiorcza stała się nieposortowalna.

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ę po stronie docelowej. Gdy CloudM zapisuje tę wiadomość w skrzynce docelowej, serwer docelowy traktuje ją jak nowe dostarczenie. Dodaje świeży nagłówek Received: z bieżącą datą i godziną, a INTERNALDATE (znacznik czasu używany przez IMAP do sortowania) ustawia na moment wstawienia.

Tak wygląda łańcuch nagłówków po migracji CloudM do Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Nagłówek z 2019 roku jest dokładnie tam. Oryginalny Date: nadal mówi 23 września 2019. Ale Outlook odczytuje najnowszy nagłówek Received: do określenia kolejności wyświetlania, a ten mówi już 2 kwietnia 2026.

Ustawienie "Strip Received Headers" w CloudM

CloudM oferuje ustawienie rozwiązujące ten problem. W Advanced Settings platformy docelowej, w sekcji Message Options, jest przełącznik "Strip Received Headers". Po włączeniu CloudM usuwa nagłówki received przed wstawieniem wiadomości i zastępuje je pojedynczym 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 docelowej skrzynce z błędnymi datami. Ponowne uruchomienie CloudM z włączonym ustawieniem tworzy tylko duplikaty, nie naprawia istniejących wiadomości.

Po drugie, to ustawienie ma poważne ograniczenie gdy celem jest Google Workspace. Dokumentacja Google potwierdza: Gmail zawsze nadpisuje nagłówki Received: w wiadomościach wstawianych przez API, oznaczając je 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 celów Microsoft 365 ustawienie działa lepiej w teorii, ale pipeline transportowy M365 ma własne zachowanie. Exchange Online może ustawić INTERNALDATE na podstawie własnego przetwarzania dostarczenia, w zależności od sposobu wejścia wiadomości do systemu.

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 i konkretnej ścieżki API używanej przez CloudM:

• Google Workspace do Microsoft 365: Daty się psują. CloudM czyta przez Gmail API i zapisuje do Exchange. Warstwa transportowa M365 dodaje nowe nagłówki Received.
• Microsoft 365 do Google Workspace: Daty się psują. Nawet ze Strip Received Headers API Google nadpisuje nagłówek Received 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, docelowy tenant Google zawsze oznacza przychodzące wiadomości datą migracji.
• Lokalny Exchange do Microsoft 365: Zwykle się psuje przez ścieżkę IMAP. Jeśli CloudM używa EWS po obu stronach, zachowanie dat jest bardziej niezawodne, ale nie gwarantowane.
• Ogólne źródło IMAP do dowolnego celu: Daty się psują. Gdy CloudM łączy się ze zwykłym serwerem IMAP jako źródłem, cel i tak dodaje własne nagłówki dostarczenia.

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. Technicznie tak. 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ć primary i secondary 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ż serwery migracji zarządzane są bezpośrednio. Nie daje. Problem z datami powstaje na serwerze docelowym, nie na węzłach przetwarzania CloudM. Niezależnie od tego, czy farma migracji działa w chmurze CloudM, czy na własnej maszynie Azure VM, docelowy serwer pocztowy oznacza datą migracji każdą otrzymaną wiadomość.

CloudM oferuje również w pełni zarządzaną "Serviced Migration", gdzie ich zespół prowadzi projekt od początku do końca. Ten sam wynik dla dat. Inżynieria jest identyczna, tylko ręce na klawiaturze są inne.

Komplikacja z nieprawidłowym nagłówkiem Date

Jest jeszcze jedno zachowanie specyficzne dla CloudM, które pogarsza sytuację. Gdy CloudM napotyka źródłowy e-mail z nagłówkiem Date: niezgodnym 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 oryginalną referencję daty. Zmodyfikowany nagłówek Date: może w ogóle nie odpowiadać rzeczywistej dacie wysłania. Dokumentacja wsparcia CloudM wspomina o tym jako o 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, może być setki e-maili z lekko niestandardowymi nagłówkami Date (szczególnie wiadomości ze starszych serwerów pocztowych, systemów automatycznych lub międzynarodowych nadawców z osobliwościami formatowania strefy czasowej). Po modyfikacji CloudM plus nadpisanie nagłówka Received przez serwer docelowy, te wiadomości kończą z datami niemającymi nic wspólnego z rzeczywistością.

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

Czy można to naprawić samodzielnie? Technicznie oryginalny nagłówek Date: jest nadal 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 naprawy dat po migracji CloudM.

Rzeczywistość tego podejścia: trzeba połączyć się z potencjalnie tysiącami skrzynek pocztowych, każda z tysiącami wiadomości. Dla każdego e-maila trzeba przeanalizować pełny ł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, zaszyfrowana zawartość PGP, wieloczęściowe struktury MIME z zagnieżdżonymi granicami, nagłówki non-ASCII zakodowane RFC 2047 od japońskich lub koreańskich nadawców), i zrobić to wszystko bez utraty jednego załącznika lub złamania wątków e-mailowych.

Skrypt działający na 50 testowych e-mailach nie przetrwa zderzenia ze środowiskiem produkcyjnym 40 000 wiadomości z dekady. Co się stanie gdy napotka e-mail 47 MB z sześcioma zagnieżdżonymi załącznikami? A limity API (250 jednostek kwoty Google na użytkownika na sekundę, throttling Microsoft na poziomie 10 000 żądań na 10 minut)? Jaki plan wycofania gdy coś pójdzie nie tak na wiadomości numer 8 347?

Naprawa dat migracji CloudM z 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 noszących sygnaturę daty migracji CloudM. 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 zastrzeżony silnik analizy łańcucha nagłówków, który identyfikuje wzorce migracyjne specyficzne dla CloudM w łańcuchu nagłówków Received. 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ść w porównaniu z oryginałem.

Oryginalne e-maile są przechowywane w widocznym folderze kopii zapasowej Redate.io - Originals przez 30 dni. Jeśli cokolwiek wymaga cofnięcia, oryginały są tam, w skrzynce pocztowej.

Dla MSP, którzy używali CloudM w środowiskach klientów, Redate.io obsługuje korekty wielu skrzynek na skalę, z tą samą weryfikacją per wiadomość niezależnie czy naprawiamy 1 skrzynkę czy 500.

Przewodniki dla poszczególnych platform po migracjach CloudM

Proces korekty dostosowuje się do platformy docelowej. Redate.io automatycznie obsługuje specyfikę każdej platformy, ale szczegóły dotyczące konfiguracji:

• Naprawa dat migracji CloudM w Gmail
• Naprawa dat migracji CloudM w Outlook
• Naprawa dat migracji CloudM w Google Workspace
• Naprawa dat migracji CloudM w Microsoft 365

Dla głębszego wyjaśnienia dlaczego to się dzieje ze wszystkimi narzędziami migracji (nie tylko CloudM), zobacz dlaczego e-maile pokazują błędne daty po migracji.

Migrowaliście z CloudM i utknęliście z błędnymi datami na każdym e-mailu? Uruchomcie bezpłatne skanowanie, aby zobaczyć ile wiadomości jest dotkniętych i ile kosztuje naprawa.