Objaw: wszystkie stare emaile zgrupowane pod tą samą datą
Otwierasz Outlooka, Gmaila albo Apple Mail pewnego ranka. Coś jest nie tak. Setki, a czasem tysiące starych wiadomości wyświetlają tę samą datę: sprzed kilku dni lub kilku tygodni. Emaile z 2021, z 2019, z 2016 roku wyglądają, jakby zostały odebrane wczoraj. Sortowanie po dacie przestaje mieć sens. Szukasz ważnej wiadomości z zeszłego roku, a ona tonie w bloku tysięcy emaili, które pozornie przybyły tego samego dnia.
Nowe wiadomości mają poprawne daty. Problem dotyczy wyłącznie starszych emaili.
Co tu właściwie się stało?
Pierwsza reakcja: szukanie błędu w oprogramowaniu
Naturalnie, myśl wędruje w stronę usterki. Outlook się zawiesił. Aktualizacja poszła nie tak. Plik uległ uszkodzeniu. I tutaj zaczyna się zwykle prawdziwa gehenna: szukasz „błąd daty Outlook", trafiasz na fora, które mówią o plikach OST, o narzędziu SCANPST.exe, o pełnym odtworzeniu profilu od zera...
Dwie godziny prób. Problem zostaje.
Swoją drogą, SCANPST to narzędzie do naprawy lokalnych plików danych Outlooka (pliki .pst i .ost przechowywane na Twoim komputerze). Potrafi naprawić pewne uszkodzenia pliku, ale nie dotyka danych przechowywanych na serwerze pocztowym. Innymi słowy: nawet po perfekcyjnej naprawie pliku OST daty pozostaną błędne, bo problem nie leży po Twojej stronie.
Problem tkwi w samych emailach, na serwerze.
Co naprawdę się wydarzyło: migracja
W niemal wszystkich przypadkach ten objaw pojawia się po migracji poczty. Firma przeszła ze starego systemu na Google Workspace, Microsoft 365 albo nowy serwer. Ktoś, gdzieś, użył narzędzia do przeniesienia wszystkich emaili z jednego miejsca do drugiego.
Być może nikt Cię o tym nie poinformował. Albo wiedziałeś, ale nie połączyłeś tego faktu z problemem dat. To zupełnie normalne.
Narzędzia migracyjne wykonują potężną pracę: kopiują tysiące wiadomości, całe foldery, załączniki. Mają jednak pewien podstępny efekt uboczny. Kiedy email jest przenoszony z jednego serwera na drugi, narzędzie dodaje do wiadomości małą linię techniczną, zwaną nagłówkiem „Received:", która wskazuje, kiedy wiadomość trafiła na nowy serwer. Czyli: datę migracji.
I tu leży sedno problemu.
Jak klient pocztowy decyduje, którą datę wyświetlić
Email zawiera tak naprawdę kilka różnych dat ukrytych w danych technicznych. Jest data oryginalnego wysłania (ta, którą normalnie widzisz), ale są też nagłówki "Received:", które zapisują każdy etap podróży wiadomości w internecie.
(Jeśli kiedykolwiek kliknąłeś "Pokaż źródło" albo "Wyświetl pełne nagłówki" w e-mailu, prawdopodobnie widziałeś te enigmatyczne linie, wyglądające jak niezrozumiały mur tekstu. To właśnie one.)
W normalnych warunkach klient pocztowy patrzy na najnowszy nagłówek "Received:", aby zdecydować, jaką datę wyświetlić. Ta logika działa doskonale: ostatni nagłówek "Received:" zawsze odpowiada chwili, gdy wiadomość trafiła do Twojej skrzynki, kilka sekund po jej wysłaniu.
Ale po migracji ta logika zawodzi. Narzędzie migracyjne dodało nowy nagłówek "Received:" na samym początku, oznaczony datą przeniesienia. Klient pocztowy odczytuje ten nagłówek jako pierwszy, widzi datę migracji i ją wyświetla. Oryginalna data wysłania wciąż tam jest, nienaruszona, schowana głębiej w danych e-maila. Twój klient po prostu do niej nie dociera, bo zatrzymuje się na pierwszym nagłówku.
Wynik: 8000 e-maili, które wszystkie wydają się dotrzeć tego samego wtorku w listopadzie.
Które narzędzia powodują ten problem?
Najpopularniejsze narzędzia migracyjne działają właśnie tak. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (darmowe narzędzie Google do migracji z Outlooka) i wiele innych. To nie jest tak naprawdę ich wada: to konsekwencja tego, jak technicznie działa protokół pocztowy. Te narzędzia dodają ten nagłówek, bo tego wymaga protokół, gdy wiadomość jest przekazywana z jednego serwera na drugi.
Problem polega na tym, że nikt nie ostrzega użytkowników, że to się stanie.
Jeśli Twoja firma niedawno zmieniła dostawcę poczty, albo dział IT przeprowadził "migrację do chmury", to prawdopodobnie właśnie o to chodzi. Możesz to zweryfikować, patrząc na daty, których to dotyczy: czy skupiają się w mniej więcej tym samym okresie? Jeśli tak, ten okres jest oknem migracji.
Fałszywe tropy, których należy unikać
Kilka rozwiązań, które stale pojawiają się na forach i nie działają:
Naprawa pliku danych za pomocą SCANPST
Jak wspomniano wyżej: SCANPST naprawia lokalne pliki Outlooka (pliki .pst lub .ost znajdujące się na Twoim komputerze). Nie modyfikuje e-maili na serwerze. Po naprawie Twoje e-maile wciąż będą mieć te same błędne daty, ponieważ te daty znajdują się w samych e-mailach, nie w lokalnym pliku.
Ponowne utworzenie profilu Outlooka
Ta sama logika. Ponowne utworzenie profilu Outlooka oznacza rozpoczęcie od nowa lokalnie, a następnie ponowne pobranie wszystkich e-maili z serwera. Te ponownie pobrane e-maile będą mieć dokładnie te same błędne daty co wcześniej. Straciłeś tylko czas na ponowną konfigurację wszystkiego.
Sortowanie według "daty wysłania" zamiast "daty odebrania"
Niektóre fora sugerują zmianę opcji sortowania w Outlooku, przełączenie z daty odebrania na datę wysłania. W niektórych przypadkach może to pomóc... ale nie zawsze. I nie naprawia to niczego dla innych aplikacji, innych urządzeń czy innych osób mających dostęp do Twojej skrzynki. Podstawowa przyczyna wciąż tam jest. Sortowanie według daty wysłania nie jest rozwiązaniem, to plaster.
Ponowna instalacja klienta pocztowego
Nie. E-maile są na serwerze, nie w oprogramowaniu. Ponowna instalacja Outlooka, Gmaila, Apple Mail czy Thunderbirda niczego nie zmienia w danych przechowywanych online.
Dobra wiadomość: prawdziwe daty wciąż tam są
Oto coś ważnego do zrozumienia, i co sprawia, że korekta jest możliwa: oryginalna data wysłania każdego e-maila nie została usunięta. Wciąż znajduje się w e-mailu, w nagłówku zwanym "Date:", który odpowiada dacie wysłania wybranej przez nadawcę. Jest to standard poczty elektronicznej (określony przez specyfikację techniczną zwaną RFC 2822), którego wszystkie narzędzia migracyjne przestrzegają, ponieważ jego modyfikacja byłaby poważnym naruszeniem protokołu.
Innymi słowy, jeśli otrzymałeś e-mail 14 marca 2022 roku, ten e-mail wciąż zawiera tę datę gdzieś w swoich danych. Po prostu nie jest już tą, którą Twój klient pocztowy wyświetla jako pierwszą.
To właśnie sprawia, że korekta jest możliwa. To nie jest utrata danych. To problem z odczytem metadanych: Twój klient pocztowy odczytuje błędną datę, podczas gdy właściwa data wciąż jest obecna. Więcej o mechanice tego zjawiska można przeczytać w tym szczegółowym wyjaśnieniu, czemu e-maile wyświetlają błędne daty po migracji.
Czemu samodzielna korekta jest ryzykowna
Możesz się zastanawiać, czy informatyk mógłby po prostu napisać skrypt, aby to naprawić. Zrozumienie, co się dzieje, to jedno. Poprawne skorygowanie tego w tysiącach e-maili bez utraty ani jednego to zupełnie inna sprawa.
E-mail nie jest prostym plikiem tekstowym. Może zawierać załączniki, podpisy cyfrowe, treść zakodowaną w złożonych formatach. Modyfikacja metadanych takiej wiadomości bez uszkodzenia jej struktury oznacza obsługę dziesiątek przypadków szczególnych: wiadomości podpisane S/MIME, e-maile zaszyfrowane PGP, niestandardowe kodowania, struktury wieloczęściowe... Domowy skrypt, który działa na 20 e-mailach testowych, bardzo prawdopodobnie zawiedzie na produkcyjnej skrzynce liczącej 15000 wiadomości. A jeśli coś pójdzie źle, jak zweryfikować, że żaden e-mail nie został uszkodzony albo utracony? Za pomocą własnego skryptu: nie da się.
Bez mechanizmu kopii zapasowej i weryfikacji każdej wiadomości z osobna, ryzyko szkód pobocznych jest rzeczywiste.
Co robi Redate.io
Redate.io to serwis zbudowany specjalnie dla tego problemu. Łączy się z Twoją skrzynką pocztową (Google Workspace, Microsoft 365 albo serwer IMAP), identyfikuje e-maile, których daty zostały zmienione przez migrację, i poprawia je za pomocą własnego mechanizmu, który wykonuje analizę łańcucha nagłówków i rekonstrukcję metadanych daty dla każdej wiadomości indywidualnie.
Każdy poprawiony e-mail jest weryfikowany indywidualnie. Oryginały są przechowywane w widocznym folderze kopii zapasowej we własnej skrzynce pocztowej, aż sam je usuniesz. Jeśli coś wygląda nie tak, możesz wrócić do poprzedniego stanu.
Początkowe skanowanie jest bezpłatne: Redate.io analizuje Twoją skrzynkę pocztową i pokazuje, ile dokładnie e-maili to dotyczy, zanim podejmiesz jakąkolwiek decyzję. Bez niespodzianek.
Cena to jednorazowa płatność zależna od liczby e-maili do poprawienia. Bez subskrypcji. Płacisz raz, problem jest rozwiązany.
Chcesz zobaczyć pełny zakres problemu przed podjęciem decyzji? Wykonaj bezpłatne skanowanie swojej skrzynki pocztowej na Redate.io i sprawdź w kilka minut, ile e-maili to dotyczy.