Nowy Outlook: błędne daty po migracji, prawdziwe przyczyny

Dwa Outlooki, dwa różne zachowania wobec tych samych wiadomości

Jeśli niedawno przeprowadzono migrację skrzynek do Microsoft 365 i część użytkowników skarży się, że wszystkie stare emaile pokazują tę samą datę (datę migracji), można zaobserwować coś dziwnego: użytkownicy korzystający z klasycznego Outlooka widzą niekiedy właściwą datę w oknie podglądu, podczas gdy ci korzystający z nowego Outlooka dla Windows widzą konsekwentnie datę migracji. Ta sama skrzynka. Te same wiadomości. Różne wyniki.

To nie jest błąd w ścisłym sensie. To decyzja architektoniczna, która ma bezpośrednie konsekwencje dla sposobu wyświetlania dat po migracji IMAP. Żeby zrozumieć, co się dzieje, trzeba wejść w szczegóły nagłówków emaili i protokołu IMAP, co nie jest dokładnie lekturą na plażę, ale pozwala zrozumieć, dlaczego żadna manipulacja po stronie klienta nie wystarczy, żeby rozwiązać problem.

INTERNALDATE IMAP: prawdziwy winowajca

Kiedy email jest przechowywany na serwerze IMAP, ma dwa typy dat, które współistnieją i nie są tym samym.

Pierwsza to nagłówek Date:, zdefiniowany przez RFC 2822. To data zapisana w samej wiadomości, którą nadawca umieścił w momencie wysyłania emaila. Jest częścią treści wiadomości i nigdy się nie zmienia, niezależnie od drogi, jaką email później przebędzie.

Druga to INTERNALDATE: metadana zarządzana przez serwer IMAP, zewnętrzna wobec wiadomości. To data, w której serwer zarejestrował wiadomość. Przy normalnej migracji poważne narzędzia zachowują oryginalną INTERNALDATE. Ale przy migracji źle skonfigurowanej, lub z narzędziami, które nie obsługują tej metadanej prawidłowo, INTERNALDATE jest resetowana do daty przeprowadzenia migracji. Efekt: wszystkie zmigrowane emaile mają tę samą datę odbioru w oczach serwera.

(Swoją drogą, jeśli ktoś czytał logi imapsync lub MigrationWiz, wie, że istnieją konkretne opcje do próby zachowania INTERNALDATE. Te opcje nie zawsze działają, a niektóre serwery docelowe odmawiają ich respektowania.)

Klasyczny Outlook: jak odczytuje daty

Klasyczny Outlook, czyli zainstalowane lokalnie wersje COM (Outlook 2016, 2019, 2021 oraz klient desktop Microsoft 365 Apps), używa nieco bardziej złożonego mechanizmu do ustalenia, którą datę wyświetlić na liście wiadomości.

Dla emaili w folderze Wysłane opiera się na nagłówku Date:. Dla odebranych wiadomości używa przede wszystkim INTERNALDATE serwera, ale w pewnych kontekstach (szczególnie gdy zaangażowany jest cache OST albo przy pierwszym wyświetleniu w oknie podglądu) może też odczytywać łańcuch nagłówków Received:, żeby odtworzyć przybliżoną datę pierwotną.

Stąd właśnie to niespójne zachowanie: klasyczny Outlook może niekiedy wyświetlić właściwą datę w oknie podglądu, ponieważ odczytuje oryginalny nagłówek Date: wiadomości do szczegółowego podglądu, nawet jeśli sama lista emaili używa nieprawidłowej INTERNALDATE. Uwaga jednak: to nie jest niezawodne i niczego nie naprawia. Sortowanie pozostaje zepsute, a wyszukiwanie po dacie nadal działa błędnie.

Nowy Outlook: radykalnie inna architektura

Nowy Outlook dla Windows, wdrażany stopniowo od końca 2023 roku, nie jest już aplikacją COM. To w zasadzie Progressive Web App (PWA) oparta na tej samej bazie kodu co Outlook w przeglądarce (OWA). Ta zmiana architektury ma poważne konsekwencje.

Nowy Outlook całkowicie deleguje wyświetlanie dat do API Microsoft 365. Nie odczytuje nagłówków Received:, nie zagłębia się w łańcuch nagłówków w poszukiwaniu pierwotnej daty i nie podejmuje żadnej próby rekonstrukcji po stronie klienta. Wyświetla po prostu to, co serwer mu zwraca: INTERNALDATE.

Rezultat: jeśli INTERNALDATE stała się nieprawidłowa podczas migracji, nowy Outlook nie ma żadnych wahań. Wyświetla datę migracji dla każdej dotkniętej wiadomości, bez wyjątków, bez niuansów. To zachowanie jest bardziej spójne i przewidywalne niż klasycznego Outlooka, ale sprawia, że problem migracji staje się natychmiast widoczny i niemożliwy do zignorowania.

Administrator, który migruje 300 skrzynek w piątek wieczorem, odkryje w poniedziałek rano, że wszyscy użytkownicy nowego Outlooka widzą swoje całe archiwa z datą ubiegłego weekendu. Zgłoszenia przychodzą szybko.

Dlaczego żadne obejście po stronie klienta nie działa

Wielu administratorów próbuje rozwiązań po stronie klienta, zanim zorientuje się, że problem tkwi w danych po stronie serwera. Oto klasyczne próby i powody ich niepowodzenia.

Sortowanie po "Dacie wysyłki" zamiast "Daty odbioru"

Sortowanie po dacie wysyłki w Outlooku opiera się na nagłówku Date: wiadomości, który jest nienaruszony. Więc tak, to sortowanie może działać. Ale to plaster, nie rozwiązanie. Wyszukiwanie po dacie pozostaje zepsute. Reguły oparte na dacie pozostają bezużyteczne. A przede wszystkim: użytkownik musi ręcznie przekonfigurować każdy folder, każdą skrzynkę. Przy 300 skrzynkach to nierealne. Sortowanie po dacie wysyłki to nie rozwiązanie, a końcowi użytkownicy nie rozumieją, dlaczego mają zmieniać swoje przyzwyczajenia.

Czyszczenie cache Outlooka lub odtworzenie profilu

To nie dotyka INTERNALDATE po stronie serwera. Po odtworzeniu profilu Outlook ponownie synchronizuje emaile z serwera i pobiera dokładnie te same nieprawidłowe metadane. Cache nie jest problemem.

Używanie OWA zamiast klienta

OWA i nowy Outlook współdzielą tę samą bazę danych. Jeśli INTERNALDATE jest nieprawidłowa na serwerze Exchange Online, OWA wyświetla dokładnie tę samą błędną datę. Zmiana klienta nie zmienia danych.

Problem leży na serwerze, w metadanych każdej wiadomości. Żadne działanie po stronie klienta nie może naprawić danych przechowywanych po stronie serwera.

Pułapka nagłówków Received: dlaczego komplikują wszystko

Kiedy narzędzie migracji kopiuje email z jednego serwera na drugi przez IMAP, serwer docelowy automatycznie dodaje nagłówek Received: na początku łańcucha, z datą i godziną wstawienia. To normalne zachowanie serwerów SMTP i IMAP zgodnych z RFC.

Te nagłówki gromadzą się w odwrotnej kolejności do drogi pokonanej przez email. Najnowszy jest na górze. Niektóre klienty mailowe odczytują pierwszy nagłówek Received:, żeby oszacować datę odbioru, co daje datę migracji zamiast oryginalnej daty.

Uwaga: to zachowanie nie jest charakterystyczne dla jednego narzędzia. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, a nawet ręczne kopiowanie IMAP między dwoma klientami Thunderbird dają ten sam wynik. Oryginalny nagłówek Date: pozostaje nienaruszony w wiadomości. To właśnie sprawia, że korekta jest technicznie możliwa. Ale INTERNALDATE to odrębna metadana zarządzana przez serwer i nie można jej naprawić, manipulując po prostu nagłówkami wiadomości po stronie klienta.

Więcej na temat tego mechanizmu można znaleźć w artykule o IMAP INTERNALDATE i błędnych datach, który szczegółowo omawia, jak ta metadana jest zarządzana w zależności od serwera.

Które narzędzia migracji powodują ten problem w Microsoft 365

Pytanie wraca często: czy wszystkie narzędzia migracji powodują ten problem?

Krótka odpowiedź: to zależy od konfiguracji i platformy docelowej. Na Exchange Online / Microsoft 365 serwer jest szczególnie rygorystyczny w zarządzaniu INTERNALDATE. Nawet narzędzia, które próbują ją zachować, niekiedy ponoszą porażkę, ponieważ API Graph i EWS (Exchange Web Services) zachowują się inaczej w zależności od użytej ścieżki wstawiania.

BitTitan MigrationWiz to jedno z najczęściej stosowanych narzędzi do migracji do Microsoft 365, a zarazem jedno z tych, których problemy z datami są najlepiej udokumentowane. Strona poświęcona naprawie dat BitTitan w Microsoft 365 omawia konkretne konfiguracje, na które należy zwrócić uwagę. CloudM i imapsync mają swoje własne specyfiki, opisane odpowiednio na naprawie dat CloudM w Microsoft 365 i naprawie dat imapsync w Microsoft 365.

Co jest wspólne dla wszystkich tych narzędzi: oryginalny nagłówek Date: przeżywa migrację. To podstawa, na której możliwa jest korekta.

Dlaczego własny skrypt to tutaj zły pomysł

Rozumienie problemu daje niekiedy złudzenie, że rozwiązanie jest proste. Nie jest, nie w skali środowiska produkcyjnego.

Modyfikowanie metadanych emaili przechowywanych na Exchange Online nie jest trywialne. API Graph Microsoftu narzuca ścisłe limity żądań (błąd 429 Too Many Requests przy nocnym wsadowym przetwarzaniu przydarza się szybko). Obsługa emaili podpisanych S/MIME lub szyfrowanych PGP wymaga szczególnej uwagi, żeby nie unieważnić podpisów. Struktury multipart z dużymi załącznikami dodają ograniczenia dotyczące timeoutów sieciowych. A przede wszystkim: jak weryfikować, email po emailu, że korekta zadziałała bez zmiany treści lub załączników?

Skrypt działający poprawnie na 50 testowych wiadomościach nie zachowa się tak samo na skrzynce z 40 000 emaili i 8-letnim archiwum. Prawdopodobieństwo, że jakiś przypadek brzegowy coś zepsuje, rośnie z każdym kolejnym tysiącem wiadomości. A bez mechanizmu wycofania zmian, błąd w połowie procesu zostawia skrzynkę w niespójnym stanie.

Warto też zajrzeć do artykułu o naprawie dat emaili po migracji Microsoft 365, który przedstawia pełny przegląd dostępnych opcji.

Co konkretnie robi Redate.io

Każdy użytkownik loguje się swoim kontem Microsoft, a Redate.io otwiera tę jedną skrzynkę z dostępem, jaki to logowanie przyznaje. Redate.io skanuje emaile z błędnymi datami bezpłatnie, a następnie stosuje autorski mechanizm korekcji na zidentyfikowanych wiadomościach. Wieloetapowy pipeline analizy realizuje dopasowanie do setek sygnatur znanych narzędzi migracyjnych, walidację zgodności z RFC oraz analizę łańcucha nagłówków w celu odtworzenia właściwych metadanych dat.

Każda poprawiona wiadomość jest weryfikowana indywidualnie. Oryginalne wiadomości są przechowywane w widocznym folderze kopii zapasowej do momentu, aż użytkownik sam je usunie. Model cenowy to jednorazowa opłata za skrzynkę, bez subskrypcji.

Nowy Outlook wyświetla wtedy właściwe daty, ponieważ dane po stronie serwera są poprawione, a nie maskowane.

Skrzynki dotknięte problemem w nowym Outlooku? Uruchom bezpłatny skan w Redate.io, żeby sprawdzić dokładnie, ile emaili jest dotkniętych, zanim zostanie podjęta decyzja o dalszych krokach.