Hosting współdzielony do Microsoft 365: ukryty problem z datami

Problem, o którym nikt nie uprzedził

Migracja skrzynek pocztowych z OVH, Infomaniak, Ionos lub o2switch do Microsoft 365 zakończona. Narzędzie migracji w EAC (Exchange Admin Center) pracowało przez całą noc, wszystko na zielono, skrzynki zapełnione. Poniedziałkowy poranek, pierwszy ticket: "Wszystkie stare emaile mają dzisiejszą datę." Potem drugi. Potem dziesięć.

To nie jest błąd Microsoft 365. To nie jest też przypadek. To mechaniczny efekt migracji IMAP, a w przypadku hostingu współdzielonego problem bywa dwa razy poważniejszy niż przy klasycznej migracji. Oto dlaczego.

Jak IMAP zarządza datami (i gdzie się to psuje)

Każdy email przechowywany na serwerze IMAP ma dwa odrębne typy datowania. Z jednej strony nagłówek Date: (zdefiniowany przez RFC 2822), obecny w treści samej wiadomości, wskazujący kiedy wiadomość została wysłana lub odebrana. Z drugiej strony INTERNALDATE, metadana na poziomie serwera, która określa kiedy wiadomość trafiła do skrzynki. To właśnie tej wartości klienty pocztowe takie jak Outlook używają domyślnie do sortowania i wyświetlania emaili.

(Swoją drogą, jeśli próbowało się kiedyś czytać surowe nagłówki wiadomości w EAC, to wiadomo, że to nie jest lektura na plażę. Spokojnie dwadzieścia, trzydzieści linii nagłówków zanim dotrze się do treści.)

Gdy narzędzie migracji IMAP przenosi wiadomość z jednej skrzynki do drugiej, musi odtworzyć tę wartość INTERNALDATE na docelowym serwerze. Niektóre narzędzia robią to poprawnie. Wiele nie robi, albo robi z ograniczeniami. A serwer docelowy, ze swojej strony, zachowuje to, co otrzymuje: gdy kopia niesie swoją oryginalną datę, Exchange Online tę datę zachowuje. Gdy więc daty wychodzą błędne, winne jest narzędzie, nie Microsoft 365.

Efekt: każdy zmigrowany email sprawia wrażenie, że został "odebrany" w dniu migracji. Bez względu na to, czy pochodzi z 2019 roku.

Scenariusz dwuetapowy: dlaczego hosting współdzielony pogarsza wszystko

Tu zaczyna się właściwy problem w przypadku migracji z hostingów współdzielonych takich jak OVH, Infomaniak, Gandi, Ionos lub o2switch.

Tacy dostawcy korzystają zazwyczaj ze współdzielonych serwerów Postfix, Dovecot lub cPanel ze standardową konfiguracją IMAP. Wiele małych i średnich firm gromadziło tam emaile przez lata, niekiedy od 2010 lub 2012 roku. Gdy decydują się przejść na Microsoft 365, migracja często przebiega w dwóch etapach.

Etap 1: pierwsze uszkodzenie (jeszcze przed Microsoft 365)

W wielu przypadkach emaile już przeszły przez co najmniej jedną wcześniejszą migrację. Firma zmieniła dostawcę hostingu raz lub dwa na przestrzeni lat: z Gandi na OVH w 2018 roku, potem z OVH na Infomaniak w 2022 roku, na przykład. Każde takie przeniesienie przez IMAP mogło zresetować oryginalny INTERNALDATE na dzień przeniesienia (gdy narzędzie nie przekazało oryginalnej daty), a niektóre narzędzia dodatkowo dołączają własne nagłówki migracji, datowane tym dniem.

Gdy emaile trafiają do Microsoft 365, niosą ze sobą już pewne blizny. Oryginalny nagłówek Date: jest nienaruszony (stanowi część treści wiadomości, nikt go nie dotyka), ale metadane daty zostały już raz zakłócone.

Etap 2: drugie uszkodzenie przy przejściu do Exchange Online

Narzędzie migracji IMAP w EAC, lub narzędzie zewnętrzne jak BitTitan MigrationWiz skonfigurowane w trybie IMAP, przyjmuje wtedy te już błędne e-maile. Jeśli to narzędzie również nie przekazuje oryginalnej daty każdego e-maila, Exchange Online zapisuje wiadomość pod dniem transferu, i to właśnie tę "datę odbioru" pokazuje później Outlook.

Email wysłany w marcu 2017 roku może więc mieć dwie warstwy błędnych dat: nagłówki migracji pozostałe po przeniesieniu w 2022 roku, i datę odbioru z migracji do Microsoft 365 w 2024 roku. Outlook wyświetla 2024. Użytkownik widzi 2024. To błąd na dwóch poziomach.

Właściwie, żeby być precyzyjnym: Outlook wyznacza datę wyświetlania na podstawie kombinacji INTERNALDATE zapisanego przez Exchange Online i obecnych nagłówków. Ale gdy narzędzie migracji nie przekazuje oryginalnych dat, przeniesienie do Exchange Online dodaje nową warstwę błędów na poprzedniej.

Narzędzia migracji i dostawcy hostingu: ryzykowne kombinacje

Kilka kombinacji pojawia się bardzo często w migracjach z hostingów współdzielonych:

• OVH / Infomaniak / Ionos + narzędzie IMAP z EAC: natywne narzędzie Microsoft jest wygodne, ale znane z tego, że nie zachowuje poprawnie dat przy dużych migracjach IMAP.
• cPanel (o2switch, LWS, itp.) + BitTitan MigrationWiz w trybie IMAP: MigrationWiz w trybie IMAP dodaje własne nagłówki migracji. Efekty są udokumentowane, między innymi na stronie naprawy dat BitTitan w Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync to potężne narzędzie, ale obsługa INTERNALDATE zależy od konfiguracji. Bez odpowiedniej opcji daty nie są zachowywane. Patrz też imapsync: daty nie zachowane.
• Każda ręczna migracja przez przeciąganie w Outlooku: jeśli ktoś kopiował całe foldery metodą drag-and-drop między dwoma kontami skonfigurowanymi w Outlooku, INTERNALDATE każdego emaila zostaje nadpisany datą kopiowania. Bez wyjątku.

Wspólny mianownik: wszystkie te metody prowadzą do Exchange Online z emailami, których wyświetlana data w Outlooku nie odpowiada żadnej rzeczywistości.

Dlaczego samodzielne poprawki na dużą skalę to zły pomysł

Zrozumienie problemu to jedno. Poprawienie 8000 emaili rozrzuconych w 40 skrzynkach Exchange Online, na kontach o złożonej strukturze folderów, z wiadomościami podpisanymi S/MIME, dużymi załącznikami i zagnieżdżonymi wątkami, to zupełnie inna sprawa.

Skrypt PowerShell, który pozornie działa na dziesięciu testowych emailach, może cicho zawieść na wiadomości numer 4237 z powodu błędnej granicy MIME lub nagłówka zakodowanego zgodnie z RFC 2047 (ten format =?UTF-8?B?...?= dla znaków spoza ASCII w nazwach nadawców). Bez mechanizmu indywidualnej weryfikacji tego nie widać. Po prostu jeden email znika.

Konkretne ryzyka przy samodzielnym podejściu do tego typu migracji:

• Podwójne wiadomości, gdy logika wstawiania zawiedzie w połowie drogi
• Brakujące załączniki, gdy struktura multipart zostanie błędnie odtworzona
• Zepsute wątki w Outlooku (konwersacje opierają się na nagłówkach References: i In-Reply-To:, które mogą ulec zmianie)
• Błędy 429 (Too Many Requests) z Microsoft Graph API o 3 w nocy, przerywające przetwarzanie bez możliwości cofnięcia zmian
• Brak prostego sposobu weryfikacji, czy wszystkie 8000 poprawek zostało zastosowanych prawidłowo

A w specyficznym przypadku migracji z hostingów współdzielonych dochodzi jeszcze jedna trudność: emaile mają kilka warstw pasożytniczych nagłówków Received:, nie tylko jeden. Prosty skrypt, który usuwa "ostatni Received:", nie wystarczy. Trzeba przeanalizować całą łańcuch, żeby zidentyfikować który nagłówek odpowiada której migracji, i który faktycznie reprezentuje oryginalną datę odbioru.

Co Redate.io robi inaczej

Użytkownik loguje się na własne konto Microsoft, a Redate.io otwiera tę skrzynkę z uprawnieniami, jakie to logowanie przyznaje. Wstępne skanowanie jest bezpłatne: Redate.io identyfikuje wszystkie emaile, których wyświetlana data nie odpowiada dacie rzeczywistej, i przedstawia precyzyjne szacunki dla każdej skrzynki.

Korekta opiera się na autorskim silniku, który analizuje pełny łańcuch nagłówków każdej wiadomości, niezależnie od użytego narzędzia migracji i rekonstruuje metadane daty poprawnie, nawet gdy nakłada się na siebie kilka warstw uszkodzeń. Każdy poprawiony email jest weryfikowany indywidualnie. Oryginały pozostają w widocznym folderze kopii zapasowej we własnej skrzynce, dopóki użytkownik sam ich nie usunie.

W przypadku migracji z hostingów współdzielonych wieloetapowy potok analizy Redate.io obsługuje wprost scenariusze podwójnego uszkodzenia: nie ogranicza się do sprawdzenia ostatniego nagłówka Received:, lecz cofa się przez pełną historię, żeby odnaleźć rzeczywistą datę odbioru. Przeczytaj też ogólny poradnik dotyczący naprawy dat po migracji Microsoft 365 oraz techniczne wyjaśnienie uszkodzeń IMAP INTERNALDATE.

Przed migracją i po niej: dwa momenty na działanie

Dwie sytuacje, dwa podejścia.

Migracja jeszcze przed Tobą. Dobra wiadomość: można ograniczyć straty. Niektóre narzędzia migracyjne (MigrationWiz w trybie Exchange, CloudM z odpowiednimi opcjami) lepiej zachowują daty niż inne. Ale nawet w najlepszym przypadku migracja z hostingu współdzielonego bez czystej historii prawdopodobnie zostawi ślady. Warto zaplanować przejście przez Redate.io po migracji, jeszcze zanim skrzynki zostaną oddane użytkownikom.

Migracja już za Tobą i tickety nadchodzą. Redate.io poprawia istniejące skrzynki w Microsoft 365, niezależnie od tego, jak dawno przeprowadzono migrację. Skanowanie da dokładny obraz stanu każdej skrzynki przed jakąkolwiek interwencją. Warto też przejrzeć checklistę migracji email, żeby uniknąć podobnych problemów w przyszłości.

Migracja z OVH, Infomaniak, Ionos lub o2switch do Microsoft 365 już za Tobą, a daty są błędne? Utwórz konto Redate.io, żeby bezpłatnie zeskanować skrzynki i zobaczyć dokładny zakres problemu przed podjęciem jakichkolwiek decyzji.