Błędne daty emaili po migracji Zoho do Microsoft 365

Co się stało z Twoją skrzynką pocztową

Migracja domeny z Zoho Mail do Microsoft 365 zakończona. Infrastruktura Exchange Online gotowa, skrzynki aprowizowane, rekordy MX zaktualizowane. I wtedy, w poniedziałek rano, użytkownik otwiera Outlook i widzi, że wszystkie jego emaile z 2021 roku pokazują dzisiejszą datę. Inny zauważa, że wiadomości sprzed roku są posortowane na samej górze skrzynki odbiorczej, jakby właśnie dotarły. Zaczyna się fala zgłoszeń.

To nie jest błąd Outlooka. To nie jest też problem specyficzny dla Zoho. Dzieje się tak, kiedy narzędzie migracyjne nie przekazuje oryginalnej daty każdego e-maila. Zrozumienie, dlaczego tak się dzieje, to pierwszy krok do prawidłowej naprawy.

Przyczyna techniczna: INTERNALDATE i nagłówki Received

Email przechowywany na serwerze IMAP składa się z dwóch odrębnych elementów: surowej treści wiadomości (nagłówki RFC 2822, treść, załączniki) oraz metadanych zarządzanych przez serwer IMAP, w tym INTERNALDATE. To właśnie ta metadana jest używana przez klientów pocztowych do wyświetlania i sortowania wiadomości.

Nagłówek Date: zawarty w surowej wiadomości (RFC 2822) reprezentuje datę, kiedy wiadomość została napisana lub wysłana przez nadawcę. INTERNALDATE to z kolei data, kiedy serwer IMAP odebrał lub zapisał wiadomość. Normalnie, na zdrowym serwerze, obie wartości są zbliżone. Po migracji to zupełnie inna historia.

Jak migracja IMAP może zmienić daty

Kiedy narzędzie migracyjne (Zoho Migration Wizard, imapsync, BitTitan lub jakiekolwiek inne) przenosi wiadomość z Zoho Mail do Exchange Online, robi to przez protokół IMAP. Narzędzie łączy się z Zoho, pobiera wiadomość, a następnie wstawia ją do Exchange Online za pomocą polecenia IMAP APPEND. I tu zaczyna się problem.

Exchange Online zachowuje datę, którą otrzymuje: kiedy narzędzie przekazuje oryginalny INTERNALDATE każdej wiadomości za pomocą polecenia APPEND, kopia go zachowuje. Niektóre narzędzia migracyjne robią to poprawnie. Inne tego nie robią, albo robią to niepoprawnie. W takim przypadku Exchange Online przypisuje jako INTERNALDATE moment wstawienia, czyli datę migracji.

Rezultat: niezależnie od tego, czy email został wysłany w 2019, czy w 2022 roku, jego INTERNALDATE wskazuje teraz na tydzień migracji. Outlook czyta tę wartość priorytetowo. Sortowanie się sypie.

Specyficzne zachowanie Zoho Migration Wizard

Zoho oferuje własne narzędzie do opuszczenia swojej platformy: Zoho Migration Wizard. Podobne narzędzia korzystające z IMAP, takie jak imapsync, mogą napotkać ten sam problem: imapsync kopiuje datę, którą serwer źródłowy przechowuje dla każdej wiadomości, więc błędna data u źródła staje się błędną datą w miejscu docelowym. Zoho Migration Wizard jest praktycznym narzędziem przy prostych migracjach, ale ma udokumentowane na forach administratorów zachowanie: kiedy przekazuje oryginalną datę, Exchange Online ją zachowuje i Outlook wyświetla właściwą datę, a e-maile pokazujące datę migracji to te, których data nie została przekazana.

Mówiąc precyzyjniej, problem dotyczy głównie migracji do serwerów, które systematycznie dodają nagłówek Received: do każdej przychodzącej wiadomości, co jest dokładnie tym, co robi Exchange Online. Nawet jeśli Zoho Migration Wizard przekaże oryginalną datę przez parametr APPEND, nagłówek Received: wygenerowany przez Exchange Online trafia na pierwszą pozycję w łańcuchu nagłówków, i to właśnie jego Outlook używa, żeby ustalić „kiedy email dotarł". Mówiąc precyzyjnie: kiedy Zoho Migration Wizard przekazuje oryginalną datę, Exchange Online ją zachowuje, a Outlook wyświetla właściwą datę. E-maile pokazujące datę migracji to te, których data nie została przekazana.

Administratorzy korzystający z ogólnych narzędzi IMAP, takich jak imapsync, aby opuścić Zoho, mogą napotkać ten sam problem: imapsync kopiuje datę, którą serwer źródłowy przechowuje dla każdej wiadomości, więc błędna data u źródła staje się błędną datą w miejscu docelowym. (Kto kiedykolwiek przeglądał log imapsync o drugiej w nocy w poszukiwaniu błędu synchronizacji, wie, że to potężne narzędzie, które nie jest szczególnie wybaczające w przypadkach granicznych.)

Dlaczego Outlook wyświetla błędną datę

Outlook nie opiera się wyłącznie na nagłówku Date:, żeby wyświetlić datę e-maila. W większości widoków to INTERNALDATE dostarczany przez serwer IMAP/Exchange decyduje o sortowaniu w skrzynce odbiorczej. Oryginalny nagłówek Date: wciąż jest obecny w wiadomości, nienaruszony, ale zostaje zignorowany na rzecz INTERNALDATE.

Właśnie dlatego przełączenie na "Sortuj według daty wysłania" w Outlooku w rzeczywistości niczego nie rozwiązuje. Pokazuje inną wartość, to prawda, ale zachowanie sortowania pozostaje niestabilne w zależności od wersji Outlooka i trybu widoku (pogrupowane konwersacje lub nie). Sortowanie według daty wysłania nie jest naprawą. To plaster, który odpada po następnej aktualizacji klienta.

Rzeczywista skala problemu

Przy migracji Zoho do Microsoft 365 średniej wielkości liczba dotyczy łatwo od 50 000 do 500 000 wiadomości, w zależności od tego, jak stare są skrzynki pocztowe i jak duża jest organizacja. Każdy e-mail przeniesiony w okresie migracji nosi tę samą błędną datę, co czyni problem natychmiast widocznym dla użytkowników w momencie, gdy otwierają Outlook.

Foldery Wysłane są często najgorsze. Przedstawiciel handlowy szukający oferty wysłanej w marcu 2022 roku musi przeszukać setki e-maili, wszystkie pokazujące datę migracji. Skutki operacyjne są rzeczywiste, nie tylko kosmetyczne.

I wbrew temu, czego można by się spodziewać, problem nie zanika z czasem. INTERNALDATE jest ustalany w momencie wstawienia. Nie naprawia się sam. Bez aktywnej interwencji te e-maile zachowują błędną datę bezterminowo.

Dlaczego naprawienie tego samodzielnie jest bardziej ryzykowne, niż się wydaje

Pokusa jest zrozumiała: skoro oryginalny nagłówek Date: wciąż jest w wiadomości, wystarczy... naprawić metadane. Logicznie, to się zgadza. W praktyce, na produkcyjnej skrzynce pocztowej z 80 000 e-maili, to operacja, która może pójść katastrofalnie źle.

Oto kilka przypadków granicznych, z którymi domowy skrypt najpewniej sobie nie poradzi:

Skrypt, który działa na 50 testowych e-mailach, nie zadziała na produkcyjnej skrzynce Zoho z latami historii. I jak zweryfikować, wiadomość po wiadomości, że każdy poprawiony e-mail jest nienaruszony i żaden załącznik nie został ucięty? Weryfikacja jest przynajmniej tak złożona jak samo naprawianie.

Jest też problem limitów. API Exchange Online, przez Microsoft Graph, wymusza ścisłe limity częstotliwości (klasyczny błąd 429 Too Many Requests). Nieograniczona partia ponad 100 000 wiadomości może wywołać tymczasowe blokady lub ciche błędy, które są prawie niemożliwe do zdiagnozowania po fakcie. Bez odpowiedniego mechanizmu ponownych prób, trzeba zaczynać od zera.

Jak Redate.io naprawia daty po migracji z Zoho

Redate.io łączy się ze skrzynką pocztową Microsoft 365 w momencie logowania przy użyciu własnego konta Microsoft, bez konieczności rejestrowania aplikacji Azure, bez etapu konfigurowania zgody administratora z góry. Wstępne skanowanie jest bezpłatne: Redate.io identyfikuje skrzynki pocztowe, których to dotyczy, i szacuje liczbę e-maili z nieprawidłowymi datami, porównując INTERNALDATE z wartościami przenoszonymi w łańcuchu nagłówków wiadomości.

Naprawa wykorzystuje mechanizm opracowany przez Redate, który analizuje pełny łańcuch nagłówków każdej wiadomości, nie musi wiedzieć, jakie narzędzie wykonało migrację (Zoho Migration Wizard, imapsync czy jakiekolwiek inne), i odtwarza metadane daty za pomocą wieloetapowego procesu walidacji. Każdy naprawiony e-mail jest weryfikowany indywidualnie: integralność treści, zachowanie załączników, zgodność z RFC. Oryginały pozostają w widocznym folderze własnej skrzynki pocztowej użytkownika, aż do ich samodzielnego usunięcia.

Brak ponownej migracji. Brak przestojów. Użytkownicy dalej pracują w Outlooku, podczas gdy naprawa działa w tle.

Cennik to jednorazowa płatność zależna od liczby wiadomości, bez abonamentu. Szczegóły są dostępne bezpośrednio na stronie.

Powiązane scenariusze, warto je znać

Administrator zarządzający wieloma migracjami jednocześnie, lub dostawca MSP obsługujący klientów opuszczających Zoho, powinien wiedzieć, że ten sam problem występuje przy migracji z innych platform do Exchange Online. Mechanizm jest identyczny: kopia otrzymuje datę, którą przekazuje narzędzie, niezależnie od źródła.

W przypadku migracji z Google Workspace, lokalnego Exchange lub przez narzędzia takie jak BitTitan MigrationWiz czy CloudM, dedykowane artykuły na blogu Redate.io opisują specyficzne zachowanie każdego narzędzia. Artykuł Zepsute daty e-maili po migracji do Exchange Online daje pełny przegląd każdego scenariusza, który dotyka danego tenanta.

Jeśli migracja obejmuje udostępnione skrzynki pocztowe lub zasoby Exchange (sale, sprzęt), problem jest ten sam i te same narzędzia naprawcze mają zastosowanie. Przewodniki naprawy dat migracji Exchange IMAP na stronie Redate.io prowadzą krok po kroku przez etapy połączenia z tenantem.

Dla zespołów korzystających konkretnie z imapsync, aby opuścić Zoho, przewodnik imapsync: daty niezachowane dokumentuje opcje konfiguracji imapsync i skąd naprawdę pochodzą błędne daty.

Nadal widoczne są daty migracji Zoho w Outlooku? Zeskanuj swoje skrzynki pocztowe bezpłatnie na Redate.io, aby zmierzyć rzeczywistą skalę problemu, zanim zdecydujesz, jak działać.