Outlook: data IMAP po migracji vs data wysyłki

Objaw, który zna każdy admin

Właśnie zakończyła się migracja IMAP do Microsoft 365 lub Google Workspace. W poniedziałek rano zaczynają spływać zgłoszenia: "Wszystkie moje emaile mają tę samą datę", "Moja historia wiadomości jest zepsuta", "Nie mogę nic znaleźć w skrzynce". Otwierasz Outlook i widzisz to samo: tysiące wiadomości z datą minionego weekendu. Nie datą wysłania. Datą, kiedy odbyła się migracja.

To nie jest błąd Outlooka. To bezpośrednia konsekwencja działania protokołu IMAP i narzędzi migracyjnych. Żeby zrozumieć dlaczego, trzeba jednak zajrzeć pod maskę.

Trzy daty w jednym emailu

Email jest bardziej złożony, niż wygląda. Nagłówki, treść, załączniki... i kilka różnych znaczników czasu, które współistnieją w jednej wiadomości. (Swoją drogą, jeśli kiedykolwiek próbowałeś czytać surowe nagłówki emaila, wiesz, że to nie jest lektura na plażę.)

Nagłówek Date: (RFC 2822)

To data, którą nadawca umieścił w wiadomości w chwili jej wysłania. Zdefiniowana przez RFC 2822, wygląda tak:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Ten nagłówek jest wmurowany w ciało wiadomości. Nigdy się nie zmienia, chyba że ktoś zmodyfikuje surową treść emaila. To "data wysyłki" w ścisłym znaczeniu.

Nagłówek Received: (dodawany na każdym przeskoku sieciowym)

Każdy serwer, który dotyka wiadomości w tranzycie, dodaje nagłówek Received: na początku emaila, ze swoją własną datą. Email przechodzący przez trzy serwery zbiera trzy takie nagłówki. Najnowszy jest zawsze pierwszy. Wygląda to mniej więcej tak:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

W efekcie: gdy narzędzie migracyjne takie jak BitTitan MigrationWiz, CloudM, imapsync lub GSMMO przenosi email z serwera źródłowego na docelowy, zachowuje się jak kolejny "przeskok sieciowy". Wstrzykuje nowy nagłówek Received: na sam szczyt stosu, z datą i godziną migracji.

INTERNALDATE w IMAP

To trzecia data i ta, która sprawia problemy. INTERNALDATE to metadana przechowywana po stronie serwera IMAP, niezależna od treści wiadomości. Reprezentuje datę, kiedy email został dostarczony (lub wstawiony) do skrzynki pocztowej. Gdy narzędzie migracyjne wstawia email przez polecenie IMAP APPEND, to ono decyduje, jaką wartość otrzyma INTERNALDATE. W wielu przypadkach narzędzia używają daty z chwili migracji, nie daty oryginalnej.

I właśnie tu wszystko się sypie.

Dlaczego Outlook wyświetla datę migracji

Outlook używa INTERNALDATE do wyświetlania kolumny "Odebrano". To jego domyślne zachowanie, zgodne ze specyfikacją IMAP: INTERNALDATE ma reprezentować datę otrzymania wiadomości w skrzynce. W normalnym przepływie (gdy prawdziwy email przychodzi), INTERNALDATE jest zbliżona do daty w nagłówku Date:. Obie są spójne.

Po nieudanej migracji INTERNALDATE wszystkich zaimportowanych wiadomości wskazuje na noc z 14 na 15 czerwca 2024 roku (lub jakąkolwiek inną datę migracji). Outlook odczytuje tę wartość, wyświetla ją w kolumnie "Odebrano" i efekt jest katastrofalny: 45 000 emaili wygląda, jakby zostały odebrane tego samego wieczoru.

Żeby być precyzyjnym: pierwszy nagłówek Received: (najnowszy w stosie) również wpływa na wyświetlanie w niektórych konfiguracjach. Ale INTERNALDATE pozostaje głównym wyznacznikiem dla kolumny "Odebrano" w Outlooku pracującym w trybie synchronizacji IMAP.

Obejście "Dodaj kolumnę Wysłano" w Outlooku

Pierwszą rzeczą, którą robi większość adminów IT po odkryciu problemu, jest szukanie obejścia po stronie klienta. I takie obejście rzeczywiście istnieje.

W Outlooku można zmodyfikować układ kolumn folderu, zastępując (lub uzupełniając) kolumnę "Odebrano" kolumną "Data" albo "Wysłano". Kolumna "Data" odczytuje bezpośrednio nagłówek Date: wiadomości, nie INTERNALDATE. Ponieważ nagłówek Date: nie został naruszony przez migrację, oryginalne daty powracają.

Jak to zrobić w Outlooku (wersja desktopowa, Microsoft 365): kliknij prawym przyciskiem na nagłówku kolumny na liście wiadomości, wybierz "Ustawienia widoku", następnie zmodyfikuj kolumny, usuwając "Odebrano" i dodając "Data". Można to wdrożyć przez GPO na większą skalę.

Na papierze rozwiązuje to wizualny problem. W praktyce to plaster na ranę tętniczą.

Konkretne ograniczenia tego obejścia

Klienty mobilne i webowe

Outlook na iOS, Androidzie i Outlook Web App (OWA) nie mają tych samych opcji personalizacji. Zmiana widoku wdrożona na stacjach Windows nie jest przenoszona dalej. Użytkownicy sprawdzający pocztę na telefonie nadal widzą datę migracji. W firmie średniej wielkości to prawdopodobnie połowa użytkowników.

Wyszukiwanie

Wyszukiwarka Outlooka używa indeksu Windows Search (lub indeksu Exchange/Microsoft 365 po stronie serwera). Ten indeks jest budowany na podstawie INTERNALDATE, nie nagłówka Date:. Jeśli użytkownik szuka "emaili ze stycznia 2022", wyszukiwarka zwraca wiadomości, których INTERNALDATE przypada na styczeń 2022. Nie te, których nagłówek Date: wskazuje na styczeń 2022. Efekt: stare emaile przestają pojawiać się w filtrach dat. Zmiana kolumny wyświetlania nic tu nie zmienia.

Reguły wiadomości

Reguły Outlooka ("jeśli email został odebrany przed...", "jeśli email został odebrany po...") również używają INTERNALDATE. Reguła sortowania lub archiwizacji oparta na zakresach dat przestanie działać poprawnie po migracji, jeśli INTERNALDATE nie zostało poprawione.

Zgodność z przepisami i eDiscovery

To prawdopodobnie najpoważniejszy punkt. Narzędzia do zachowania zgodności, archiwizacji prawnej i eDiscovery (np. Microsoft Purview) używają INTERNALDATE jako referencji daty przy zapytaniach prawnych. Jeśli firma podlega obowiązkom retencji danych lub musi odpowiadać na żądania discovery, skorumpowane wartości INTERNALDATE mogą stwarzać realne problemy prawne. Audyt wymagający "wszystkich emaili między tą a tą datą" po prostu nie zwróci właściwych wyników. W Polsce dotyczy to obowiązków wynikających m.in. z RODO oraz przepisów o przechowywaniu dokumentacji elektronicznej.

Narzędzia zewnętrzne

CRM-y, systemy ticketingowe, archiwizatory... wszystko, co łączy się z serwerem pocztowym przez IMAP lub API Microsoft 365/Google Workspace, odczytuje INTERNALDATE. Zmiana widoku Outlooka nie naprawia niczego w tych systemach.

Jedyne prawdziwe rozwiązanie: korekta na poziomie serwera

Sortowanie po dacie wysyłki w Outlooku to nie jest rozwiązanie. To plaster. Prawdziwa korekta musi nastąpić na poziomie metadanych serwera, nie widoku klienta.

W praktyce oznacza to korygowanie INTERNALDATE każdego emaila tak, żeby odpowiadała oryginalnej dacie z nagłówka Date:. Oryginalny nagłówek Date: jest zawsze obecny w wiadomości (nie został usunięty przez migrację), co sprawia, że korekta jest w ogóle możliwa. To tam znajdują się prawdziwe informacje o dacie.

W Google Workspace API Gmail udostępnia parametr internalDate, który pozwala bezpośrednio działać na tej metadanej. W Microsoft 365 mechanizm jest inny, ale oczekiwany efekt jest ten sam. Na standardowym serwerze IMAP norma przewiduje możliwość określenia daty przy wstawianiu wiadomości.

W praktyce jednak wykonanie tej operacji na dziesiątkach tysięcy emaili w środowisku produkcyjnym, bez utraty danych, bez duplikatów, bez zepsucia wątków wiadomości ani etykiet, z obsługą przypadków brzegowych (wiadomości podpisane S/MIME, złożone struktury MIME, kodowania non-ASCII według RFC 2047, duże załączniki)... to zupełnie inna historia. Skrypt działający na 50 testowych emailach nie przetrwa konfrontacji ze skrzynką zawierającą 40 000 wiadomości. Obsługa błędów 429 (przekroczony limit API), timeoutów sieciowych o 2 w nocy, wiadomości z częściowo uszkodzoną strukturą MIME już po migracji... to wszystko wymaga poważnej inżynierii.

Właśnie to robi Redate.io. Zastrzeżony silnik korekcyjny analizuje łańcuch nagłówków każdego emaila, identyfikuje wiarygodną oryginalną datę i stosuje ukierunkowaną korektę metadanych bez ingerencji w treść wiadomości. Każdy poprawiony email jest weryfikowany indywidualnie. Oryginały są przechowywane w folderze kopii zapasowej przez 30 dni, co umożliwia rollback w dowolnym momencie. Tego żaden domowy skrypt nie oferuje.

Identyfikacja narzędzia migracyjnego odpowiedzialnego za problem

Problem objawia się tak samo niezależnie od źródła migracji, ale szczegóły różnią się w zależności od użytego narzędzia. BitTitan MigrationWiz, CloudM, imapsync i GSMMO mają własne sygnatury w nagłówkach Received:, które wstrzykują. Potok analizy Redate.io utrzymuje bazę dopasowań obejmującą setki znanych sygnatur narzędzi migracyjnych, pozwalając odróżnić nagłówek migracyjny od reszty legalnego łańcucha tranzytowego.

Jeśli nie wiadomo, jakie narzędzie zostało użyte do migracji (zdarza się, szczególnie gdy przejmuje się środowisko po innym MSP), bezpłatny skan Redate.io identyfikuje skrzynki, których dotyczy problem, i podaje szacunkową liczbę wiadomości do korekty przed jakimkolwiek zobowiązaniem.

W przypadku konkretnych scenariuszy dostępne są szczegółowe przewodniki: naprawa dat imapsync w Outlooku, naprawa dat BitTitan w Outlooku oraz naprawa dat CloudM w Outlooku.

Co zrobić teraz

Jeśli czytasz ten artykuł po migracji, dobra wiadomość jest taka, że oryginalny nagłówek Date: jest nienaruszony w każdej wiadomości. Prawdziwe informacje o dacie są tam, obecne w każdym emailu. Problem tkwi w metadanych, nie w treści. A metadane można naprawić.

Więcej na temat mechaniki problemu znajdziesz w artykule IMAP INTERNALDATE: dlaczego daty się psują, a jeśli szukasz szerszego przeglądu scenariuszy, zajrzyj do przewodnika po błędnych datach w Outlooku po migracji.

Gotowy, żeby naprawić daty w skrzynkach pocztowych? Uruchom bezpłatny skan na Redate.io, aby zidentyfikować wiadomości z problemem i oszacować skalę korekty przed podjęciem jakichkolwiek działań.