Odtworzenie profilu Outlook: dlaczego daty się zmieniają

Klasyczna naprawa, która psuje daty

Użytkownik zgłasza, że Outlook przestał się synchronizować. Emaile nie przychodzą, folder Wysłane się nie aktualizuje, kółko się kręci w nieskończoność. Technik diagnozuje uszkodzony profil, usuwa plik OST, odtwarza profil Outlook od zera. Efekt: Outlook łączy się ponownie, emaile wracają, wszystko wydaje się działać.

Do następnego ranka, kiedy użytkownik otwiera skrzynkę i odkrywa, że 8 lat korespondencji wyświetla tę samą datę: dzisiaj.

To dokładnie ten sam objaw co po nieudanej migracji IMAP. I z tych samych powodów.

Co się dzieje od strony technicznej

Żeby zrozumieć, dlaczego odtworzenie profilu daje taki efekt, trzeba wrócić do rozróżnienia, które większość techników zna słabo: różnicy między nagłówkiem Date: wiadomości a jej INTERNALDATE IMAP.

Każdy email zawiera w nagłówkach RFC 2822 pole Date:, które wskazuje, kiedy wiadomość została wysłana. To pole jest wpisywane przez klienta poczty nadawcy w chwili wysyłki, a następnie transportowane bez zmian przez wszystkie serwery aż do skrzynki odbiorcy. Nigdy się nie zmienia. Email wysłany 14 marca 2019 o 09:32 zawsze będzie miał ten nagłówek Date: nienaruszony, niezależnie od tego, co się później stanie.

INTERNALDATE IMAP to zupełnie inna sprawa. To metadana zarządzana przez serwer pocztowy, niezależna od treści wiadomości. Wskazuje, kiedy wiadomość została "wrzucona" do skrzynki. W normalnych warunkach, gdy email trafia przez SMTP, serwer rejestruje czas odbioru jako INTERNALDATE. Email odebrany 14 marca 2019 będzie więc miał INTERNALDATE spójny z datą wysyłki.

Outlook domyślnie sortuje i wyświetla emaile według INTERNALDATE przekazywanego przez serwer IMAP, nie według pola Date: samej wiadomości. (Jeśli kiedykolwiek otwierałeś pełne właściwości emaila w Outlooku, żeby zobaczyć surowe nagłówki, wiesz, że to nie jest lektura do porannej kawy.)

Co uruchamia usunięcie pliku OST

Gdy Outlook używa konta IMAP, utrzymuje lokalną bazę danych: plik OST (Offline Storage Table). Ten plik to lokalne odbicie emaili przechowywanych na serwerze, wraz z metadanymi, stanami przeczytania, kategoriami itd.

Usunięcie pliku OST oznacza wymazanie tego lokalnego odbicia. Outlook musi więc pobrać wszystko od nowa z serwera IMAP.

Problem? Gdy Outlook ponownie pobiera wiadomość przez IMAP, używa polecenia FETCH do pobrania treści. Ale nie zawsze używa polecenia FETCH INTERNALDATE, żeby pobrać i zachować oryginalną datę IMAP. W niektórych konfiguracjach i wersjach Outlooka klient odbudowuje lokalny indeks, używając daty pobrania wiadomości zamiast INTERNALDATE przechowywanego na serwerze.

I wtedy wszystkie emaile w skrzynce otrzymują datę dnia przeładowania.

Nie wszystkie wersje Outlooka zachowują się tak samo

Właściwie, to zachowanie nie dotyczy wszystkich wersji Outlooka w identyczny sposób, i tu zaczyna się prawdziwy problem z diagnozowaniem.

Outlook 2016 i 2019 w trybie IMAP mają udokumentowane przypadki niepoprawnej odbudowy indeksu po usunięciu cache'u. Nowy Outlook (oparty na web, wdrażany stopniowo od końca 2023 roku) zarządza cache'em inaczej i może dawać zmienne wyniki. Outlook przez Exchange/Microsoft 365 z kontem skonfigurowanym w trybie Exchange jest mniej narażony na ten konkretny problem, bo protokół MAPI/Exchange obsługuje synchronizację inaczej niż IMAP.

Ale jeśli użytkownik ma konto IMAP skonfigurowane w klasycznym Outlooku i technik usunął plik OST albo odtworzył profil: ryzyko jest realne.

Jak odróżnić ten przypadek od prawdziwej migracji

Administrator IT, który otrzymuje zgłoszenia „moje daty są błędne" po odtworzeniu profilu, może błędnie uznać, że to problem migracyjny. Oto jak rozróżnić oba przypadki.

Przypadek migracji IMAP

Podczas migracji IMAP (BitTitan, CloudM, imapsync itp.) narzędzie migracyjne kopiuje emaile z jednego serwera na drugi. Dla każdej skopiowanej wiadomości tworzy nowy wpis na serwerze docelowym. Jeśli narzędzie nie podaje explicite oryginalnego INTERNALDATE, serwer docelowy rejestruje bieżący czas jako INTERNALDATE. Jednocześnie niektóre narzędzia dodają też nagłówek Received: z datą migracji, co w niektórych klientach pogarsza sytuację. Szczegóły tego mechanizmu opisuje artykuł o IMAP INTERNALDATE i błędnych datach.

Przypadek odtworzenia profilu

Tu emaile nadal są na tym samym serwerze, z tymi samymi oryginalnymi INTERNALDATE. Po stronie serwera nic się nie zmieniło. To wyłącznie lokalny cache Outlooka został odbudowany z błędnymi datami. Widoczny objaw jest identyczny (wszystkie emaile wyświetlają tę samą niedawną datę), ale źródło jest inne.

Żeby potwierdzić: zaloguj się do skrzynki przez webmail (Gmail, Outlook.com lub interfejs webmail hosta). Jeśli daty wyświetlane w webmailu są prawidłowe, problem jest czysto lokalny dla Outlooka. Jeśli daty są też błędne w webmailu, problem leży po stronie serwera (migracja lub modyfikacja INTERNALDATE bezpośrednio na serwerze).

Dlaczego oryginalne daty można odzyskać

Dobra wiadomość: w obu przypadkach (migracja lub odtworzenie profilu) oryginalne daty nie są utracone.

Nagłówek Date: RFC 2822 jest integralną częścią wiadomości. Jest tak samo niezmienny jak treść tekstu czy załączniki. Email wysłany w 2017 roku zawiera w surowym tekście coś takiego:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Ta linia jest obecna w wiadomości przechowywanej na serwerze. Nie została zmieniona. To, co Outlook wyświetla (niepoprawnie), to metadana zewnętrzna wobec treści wiadomości.

To właśnie sprawia, że korekta jest możliwa. Silnik Redate.io analizuje łańcuch nagłówków każdej wiadomości, żeby wyekstrahować rzeczywistą oryginalną datę, a następnie przeprowadza ukierunkowaną korektę metadanych bez naruszania treści wiadomości. INTERNALDATE widoczny przez Outlook jest odbudowywany na podstawie tej autentycznej informacji, zawsze obecnej w wiadomości.

Pułapka "czystego" odtworzenia profilu

Właśnie rozwiązałeś problem z synchronizacją dla użytkownika. Jego Outlook znów działa, nowe emaile przychodzą. Zamykasz zgłoszenie.

Trzy dni później użytkownik dzwoni ponownie: szuka emaila od dostawcy sprzed roku, ale w Outlooku wszystkie wiadomości z 2023 roku wyglądają jak odebrane „wczoraj". Nic nie może znaleźć. Automatyczne archiwizowanie mogło posortować niedawne emaile jako stare. A szef prosi go o wątek mailowy z września 2022 roku na potrzeby sporu.

Ten scenariusz zdarza się regularnie. Nie dlatego, że technik źle wykonał swoją pracę, ale dlatego, że to zachowanie Outlooka nie jest widocznie udokumentowane w standardowych poradnikach rozwiązywania problemów.

Pozorne rozwiązania, które nic nie naprawiają

Sortowanie emaili według "Daty wysłania" zamiast "Daty odebrania" w Outlooku to pierwsza rzecz, którą próbują użytkownicy. I wydaje się działać... dopóki nie zorientują się, że sortowanie po dacie wysyłki jest dostępne tylko dla niektórych folderów, znika po zmianie widoku, a inne aplikacje (mobile, webmail, automatyczne reguły sortowania) nadal używają błędnego INTERNALDATE.

Sortowanie po dacie wysyłki to nie rozwiązanie. To plaster, który ukrywa objaw, nie dotykając rzeczywistego problemu. Wyjaśniamy to szczegółowo w artykule Sortowanie po dacie wysyłki to nie rozwiązanie.

Odtworzyć profil po raz drugi? Nic to nie zmienia, jeśli Outlook ponownie odbuduje cache z bieżącą datą.

Eksportować, a potem zaimportować do PST? Uwaga. Eksport PST z Outlooka z błędnymi datami eksportuje błędne metadane. Plik PST będzie zawierał błędne daty. Reimportowanie go niczego nie naprawi, a może nawet pogorszyć sytuację, tworząc duplikaty z niespójnymi datami. Ten temat jest omówiony osobno w artykule o imporcie PST i datach emaili.

Co robi Redate.io w tym konkretnym przypadku

Niezależnie od tego, czy problem pochodzi z migracji IMAP czy z odtworzenia profilu Outlook, efekt po stronie serwera jest podobny: emaile, których metadane daty są niespójne z ich rzeczywistą treścią.

Redate.io łączy się bezpośrednio ze skrzynką pocztową (Google Workspace, Microsoft 365 lub bezpośrednio IMAP), skanuje wszystkie wiadomości, żeby zidentyfikować te z błędnymi metadanymi, a następnie stosuje wieloetapowy pipeline analizy do korekty każdego emaila z osobna. Każda korekta jest weryfikowana. Oryginalne wiadomości są przechowywane w widocznym folderze backup do momentu, aż użytkownik sam je usunie.

Proces obsługuje przypadki graniczne, na których skrypty domowej roboty regularnie się wykładają: wiadomości podpisane S/MIME, emaile z kodowaniami non-ASCII w nagłówkach (RFC 2047), złożone struktury multipart, nagłówki Date: z niestandardowymi lub zniekształconymi strefami czasowymi. Skrypt, który działa poprawnie na 50 testowych emailach w skrzynce deweloperskiej, może nieodwracalnie uszkodzić 2000 wiadomości w środowisku produkcyjnym. W IMAP nie ma natywnego rollbacku po zastąpieniu wiadomości bez wcześniejszej kopii zapasowej.

Dla przypadków związanych konkretnie z Outlookiem, strona naprawcza Napraw daty ręcznego kopiowania IMAP w Outlook opisuje kroki potrzebne do podłączenia skrzynki i uruchomienia analizy.

Jak zapobiegać problemowi podczas kolejnych interwencji

Jeśli jesteś technikiem lub administratorem IT i regularnie pracujesz z profilami Outlook, kilka nawyków pozwoli uniknąć tej sytuacji.

Przed usunięciem pliku OST lub odtworzeniem profilu sprawdź daty wyświetlane w webmailu. Jeśli są prawidłowe, zanotuj to w zgłoszeniu. Po odtworzeniu zaloguj się ponownie do webmaila i porównaj wyświetlane daty z tymi w Outlooku. Jeśli pojawi się rozbieżność, problem jest zidentyfikowany od razu, zanim użytkownik zgłosi go trzy dni później.

W przypadku planowanych migracji, checklista migracji email zawiera listę weryfikacji do przeprowadzenia przed i po operacji, żeby wykryć ten typ problemu tuż po jej zakończeniu.

Odtworzyłeś profil Outlook i teraz wszystkie daty w skrzynce są błędne? Uruchom bezpłatne skanowanie w Redate.io, żeby zidentyfikować dotknięte emaile i poprawić metadane bez naruszania treści wiadomości.