Import PST w Outlooku: dlaczego daty emaili się psują

Objaw: wszystkie emaile mają datę dzisiejszą

Import PST w Outlooku dobiegł końca. Pasek postępu doszedł do 100%, wszystko przebiegło bez błędów. A potem otwiera się skrzynka odbiorcza... i każdy zaimportowany email wyświetla dzisiejszą datę. Wiadomość z 2019 roku, inna z 2021, archiwum sprzed pięciu lat: wszystkie noszą tę samą datę. Dzień importu.

To nie jest błąd wyświetlania. To nie problem ze strefą czasową. To zachowanie doskonale udokumentowane, spójne z tym, jak protokół IMAP zarządza metadanymi dat. Ale pozostaje katastrofą dla każdego, kto potrzebuje odnaleźć stare emaile po dacie.

Lokalny PST i IMAP: dwa zupełnie różne światy

Zanim wyjaśnimy, dlaczego daty się psują, warto zrozumieć, czym jest plik PST z perspektywy zarządzania datami.

Plik PST (Personal Storage Table) to zastrzeżony format Microsoft. Przechowuje emaile wraz z pełnymi metadanymi: datą wysyłki, datą odbioru, załącznikami, kategoriami, flagami odczytu. Tymi metadanymi zarządza bezpośrednio Outlook, niezależnie od jakiegokolwiek protokołu pocztowego. Gdy otwiera się PST w Outlooku bez połączenia z serwerem, wyświetlane daty pochodzą wprost z wewnętrznych pól pliku PST. Jak dotąd wszystko gra.

Problem pojawia się w momencie próby przeniesienia tej zawartości do skrzynki pocztowej hostowanej na serwerze IMAP, czy to Microsoft 365, Google Workspace, czy dowolnego standardowego hostingu. Wtedy opuszcza się świat PST i wchodzi w świat IMAP, gdzie reguły są zupełnie inne.

IMAP APPEND i INTERNALDATE: serce problemu

W protokole IMAP każda wiadomość przechowywana na serwerze ma dwa rodzaje danych o dacie:

• Nagłówek Date: (RFC 2822), który jest częścią samej treści wiadomości. To data wpisana w wiadomość przez nadawcę.
• INTERNALDATE, czyli metadana zarządzana przez serwer IMAP. Reprezentuje moment, w którym wiadomość trafiła na serwer. To właśnie tej wartości Outlook używa do sortowania wiadomości w widoku "Data odbioru".

(Swoją drogą, jeśli ktoś próbował kiedyś czytać surowe nagłówki emaila, wie że to niespecjalnie relaksująca lektura. Ale właśnie tam dzieje się wszystko, co ważne.)

Gdy email trafia normalnie na serwer, system pocztowy automatycznie ustawia INTERNALDATE na dokładny moment odbioru. Wynik: data wyświetlana w Outlooku odpowiada rzeczywistemu momentowi otrzymania wiadomości.

Gdy Outlook importuje plik PST do skrzynki IMAP, używa komendy IMAP APPEND, żeby wysłać każdą wiadomość na serwer. Standard IMAP pozwala przekazać jawną wartość INTERNALDATE podczas operacji APPEND. Ale Outlook tego nie robi. Wysyła wiadomości bez podawania INTERNALDATE. Serwer IMAP, nie otrzymując żadnej instrukcji, stosuje domyślną regułę: INTERNALDATE jest ustawiany na aktualny czas, czyli moment importu.

Wynik: 8000 zaimportowanych emaili, 8000 emaili z dzisiejszą datą.

Dlaczego Outlook zachowuje się w ten sposób

To nie jest przeoczenie Microsoftu. To świadoma decyzja implementacyjna, która prawdopodobnie wydawała się rozsądna w swoim czasie: w pierwotnym przypadku użycia importu PST użytkownik archiwizował wiadomości lokalnie i "importował" je do bieżącej skrzynki. Właściwą datą do sortowania byłaby wtedy oryginalna data odbioru... ale Microsoft zdecydował się nie propagować INTERNALDATE podczas operacji importu.

Żeby być precyzyjnym: to zachowanie dotyczy importu PST przez natywnego asystenta Outlooka (Plik > Otwórz i eksportuj > Importuj/Eksportuj). Inne metody importu, jak niektóre narzędzia innych firm lub migracje przez Exchange Admin Center, mogą zachowywać się inaczej, zależnie od ich implementacji IMAP APPEND.

To zachowanie jest znane i udokumentowane na forach Microsoft od lat. Nie zmieniło się w Outlooku 2016, ani w 2019, ani w obecnych wersjach Microsoft 365. Użytkownik importujący PST dzisiaj napotka dokładnie ten sam problem co w 2015 roku.

Czym to różni się od klasycznej migracji IMAP

Tu robi się ciekawie, bo import PST daje wynik podobny do klasycznej migracji IMAP z uszkodzonymi datami, ale przez inny mechanizm.

W typowej migracji IMAP, na przykład z użyciem BitTitan MigrationWiz lub imapsync, emaile przechodzą z serwera źródłowego IMAP na docelowy. Narzędzie migracyjne pobiera wiadomości i wstrzykuje je z powrotem przez IMAP APPEND. Niektóre narzędzia poprawnie zachowują INTERNALDATE, inne nie. Ale w każdym przypadku wiadomości mają już dołączony nagłówek Received: z datą migracji, co może zakłócać wyświetlanie w Outlooku niezależnie od INTERNALDATE.

Przy imporcie PST mechanizm jest prostszy: nie ma nagłówka Received: z datą migracji (pliki PST nie przechodzą przez pośredni serwer pocztowy), ale INTERNALDATE po prostu nigdy nie jest ustawiany na prawidłową wartość. Widoczny efekt jest identyczny, przyczyna leżąca u podstaw jest nieco inna.

To rozróżnienie ma bezpośredni wpływ na korektę: podejście nie jest dokładnie takie samo w przypadku migracji IMAP jak i importu PST. Warto też przeczytać, dlaczego INTERNALDATE powoduje uszkodzenie dat, gdzie oba przypadki są szczegółowo wyjaśnione.

Dlaczego opcje widoku Outlooka nic nie naprawiają

Typowa reakcja po odkryciu problemu to grzebanie w ustawieniach Outlooka. I rzeczywiście jest tam opcja, która wygląda obiecująco: możliwość sortowania emaili według "Data" zamiast "Data odbioru".

Sortowanie według daty wysyłki nie jest rozwiązaniem. To plaster na ranę.

Dlaczego? Nawet jeśli zmieni się sortowanie na kolumnę "Data" (odpowiadającą nagłówkowi Date: wiadomości, czyli dacie oryginalnej), kilka problemów pozostaje:

• Wyszukiwarka Outlooka indeksuje według INTERNALDATE. Wyszukiwanie "emaili ze stycznia 2020" nie zwróci zaimportowanych wiadomości ze stycznia 2020, bo ich INTERNALDATE mówi, że pochodzą z dnia importu.
• Foldery "Dzisiaj", "Ten tydzień", "Ten miesiąc" w interfejsie Outlooka opierają się na INTERNALDATE, nie na nagłówku Date:.
• W interfejsach webowych (Outlook Web App, Gmail) i na klientach mobilnych wyświetlana data i zachowanie sortowania prawie zawsze zależą od INTERNALDATE serwera.
• Reguły i filtry automatyczne stosowane do daty odbioru nie będą działać poprawnie.

Mówiąc krótko, zmiana widoku rozwiązuje problem wyświetlania dla konkretnego użytkownika, na konkretnym kliencie, w konkretnej konfiguracji. Nie naprawia problemu u źródła.

Resynchronizacja OST też nic nie da

Inny klasyczny pomysł: wyczyszczenie cache OST i wymuszenie pełnej resynchronizacji z serwera. Logika jest taka, że problem może tkwić w lokalnym cache Outlooka, a nie na serwerze.

Zły trop. Plik OST to lokalny cache odzwierciedlający stan serwera IMAP. Jeśli INTERNALDATE jest błędny na serwerze, będzie błędny w OST po resynchronizacji. Usunięcie OST nie zmienia żadnych danych przechowywanych na serwerze Exchange Online ani Google Workspace. Serwer jest jedynym źródłem prawdy.

Jedynym sposobem na korektę dat jest poprawienie metadanych bezpośrednio po stronie serwera, wiadomość po wiadomości. I właśnie tu zaczyna się robić skomplikowanie przy próbie ręcznego działania.

Problem skali: 1 email to drobiazg. 15 000 to zupełnie inna historia

Technicznie, jeśli ktoś rozumie problem, mógłby pomyśleć o napisaniu skryptu, który przejrzy skrzynkę, odczyta nagłówek Date: każdej wiadomości i odpowiednio poprawi INTERNALDATE. Rozumienie problemu to jedno. Poprawienie 15 000 emaili bez zgubienia ani jednego to zupełnie co innego.

Kilka realiów z praktyki:

• Microsoft Graph API i Gmail API narzucają limity żądań (rate limits). Naiwny skrypt wywoła błędy 429 Too Many Requests, przerwie działanie w połowie korekty i zostawi skrzynkę częściowo poprawioną, bez jasności, które wiadomości zostały przetworzone, a które nie.
• Niektóre emaile w PST mogą mieć zniekształcone lub brakujące nagłówki Date:. Skrypt bez obsługi takich przypadków brzegowych może uszkodzić te wiadomości lub cicho je pominąć.
• Emaile podpisane (S/MIME) lub zaszyfrowane (PGP) mają dodatkowe ograniczenia integralności. Modyfikacja ich metadanych bez zachowania ostrożności może unieważnić podpis kryptograficzny.
• Struktury multipart/alternative ze złożonymi granicami MIME czasem reagują nieprzewidywalnie na operacje modyfikacji.
• Brak mechanizmu cofania zmian. Jeśli coś pójdzie nie tak w połowie przetwarzania, jak wrócić do stanu wyjściowego?

Skrypt działający na 10 testowych emailach nie zadziała na produkcyjnej skrzynce z 50 000 wiadomości. W zeszłym roku klient z archiwum PST o rozmiarze 40 GB spróbował naprawić to skryptem Pythona znalezionym na Stack Overflow. Wynik: 3000 zduplikowanych emaili, 200 wiadomości z niedostępnymi załącznikami i dwa tygodnie ręcznego sprzątania.

Co robi Redate.io w tym konkretnym przypadku

Redate.io analizuje metadane każdej wiadomości w docelowej skrzynce, identyfikuje emaile z niepoprawnymi datami (w tym te pochodzące z importu PST) i stosuje korektę przez swój autorski silnik korekcji. Wieloetapowy potok analizy porównuje łańcuch nagłówków każdej wiadomości, wyodrębnia oryginalną datę z walidacją zgodności RFC i przeprowadza ukierunkowaną korektę metadanych bez ingerowania w treść wiadomości.

Każdy poprawiony email jest weryfikowany indywidualnie. Oryginały są przechowywane w widocznym folderze zapasowym przez 30 dni przed jakąkolwiek ostateczną modyfikacją. Korekta działa na trzech głównych platformach: Microsoft 365 (przez Azure AD), Google Workspace (przez delegację domeny) i bezpośrednie IMAP dla standardowych hostingów.

Skan wstępny jest bezpłatny. Pozwala dokładnie zobaczyć, ile emaili jest dotkniętych problemem i jaki jest rozkład błędnych dat, zanim podejmie się jakąkolwiek decyzję.

Zobacz też:

• Naprawa dat emaili po migracji Microsoft 365
• Outlook: data IMAP po migracji vs data wysyłki
• Czy można naprawić daty emaili po migracji?

Import PST nadpisał wszystkie daty Twoich emaili? Przeskanuj skrzynkę bezpłatnie w Redate.io i sprawdź skalę problemu, zanim zaczniesz działać.