eM Client: błędne daty po imporcie PST lub Thunderbird

Objaw: wszystkie emaile mają tę samą datę

Import PST do eM Client zakończony. Albo migracja z Thunderbirda do nowej skrzynki. Żadnych błędów po drodze, wszystko przebiegło sprawnie. Ale po otwarciu skrzynki odbiorczej coś wyraźnie nie gra: setki, niekiedy tysiące wiadomości nosi tę samą datę, datę dnia importu. Email z 2019 roku wygląda jak odebrany wczoraj. Umowa podpisana trzy lata temu pojawia się tak, jakby właśnie nadeszła.

Pierwsza reakcja? Wina eM Client. Zły parametr, zła kolumna sortowania, błąd wyświetlania... Szuka się w preferencjach. Przełącza się między "Datą otrzymania" a "Datą wysyłki". Nic się nie zmienia. A właściwie coś się zmienia, ale nie rozwiązuje to sedna problemu.

Bo problem nie leży w eM Client. Leży w metadanych serwera.

Prawdziwa przyczyna: INTERNALDATE IMAP nadpisany podczas importu

Żeby zrozumieć, co się dzieje, trzeba zejść o poziom niżej i przyjrzeć się temu, jak protokół IMAP przechowuje wiadomości.

Każda wiadomość na serwerze IMAP ma dwa odrębne typy dat:

• Nagłówek Date: (zdefiniowany przez RFC 2822): to data wpisana przez nadawcę w momencie wysyłki. Jest osadzona w treści wiadomości i teoretycznie nienaruszalna.
• INTERNALDATE: metadana serwera, zewnętrzna względem wiadomości, oznaczająca datę złożenia wiadomości w skrzynce. To właśnie ta wartość jest używana przez klientów pocztowych priorytetowo do sortowania i wyświetlania emaili.

Podczas importu PST lub migracji z Thunderbirda narzędzie importujące (czy to wbudowany moduł eM Client, narzędzie zewnętrzne, czy ręczne kopiowanie IMAP) umieszcza wiadomości na docelowym serwerze IMAP. I jeśli narzędzie nie zachowuje oryginalnego INTERNALDATE w momencie zapisu, serwer automatycznie przypisuje bieżący INTERNALDATE, czyli datę i godzinę importu.

Efekt: 8000 zarchiwizowanych emaili od 2017 roku, wszystkie opatrzone datą „otrzymania" z dnia migracji.

(Swoją drogą, jeśli próbowało się kiedyś czytać surowe nagłówki wiadomości przez opcję Pokaż źródło w eM Client, można było zauważyć, że oryginalny nagłówek Date: jest tam niezmieniony. To wyraźny sygnał, że problem pochodzi z INTERNALDATE serwera, a nie z samej wiadomości.)

Dlaczego zmiana kolumny sortowania nic nie daje

Zamieszanie bierze się z rozróżnienia, które niewielu administratorów zna. W eM Client, podobnie jak w Outlooku czy Thunderbirdzie, istnieją zazwyczaj dwie kolumny daty:

• "Data otrzymania" (lub "Data przybycia"): oparta na INTERNALDATE serwera.
• "Data" lub "Data wysyłki": oparta na nagłówku Date: wiadomości.

Wielu administratorów to odkrywa i uważa, że znalazło rozwiązanie: przełączyć się na "Datę wysyłki", a problem wizualnie znika w eM Client. Ale to nie do końca prawda.

No właśnie, nawet sortując według daty wysyłki w eM Client, problem pozostaje dla wszystkich innych klientów i interfejsów korzystających z tej samej skrzynki. Jeśli użytkownicy sprawdzają pocztę przez OWA, Outlooka na komputerze służbowym, aplikację Gmail na telefonie lub jakikolwiek inny klient skonfigurowany przez IMAP, widzą daty importu. Ustawienie sortowania w eM Client działa wyłącznie w eM Client i nie wpływa na metadane przechowywane po stronie serwera.

Co więcej, w Microsoft 365 i Google Workspace natywny widok webowy sortuje według INTERNALDATE. Nie można tego zmienić z poziomu klienta.

Sortowanie według daty wysyłki to nie rozwiązanie. To plaster, który maskuje prawdziwy problem, zamiast go naprawić.

Specyfika importu PST

Import plików PST zasługuje na osobny akapit. Plik PST (Personal Storage Table) to zastrzeżony format Microsoft przechowujący emaile, kontakty i kalendarze lokalnie. Przy imporcie PST do eM Client możliwe są dwa scenariusze:

• Import lokalny do konta IMAP: eM Client odczytuje PST i przesyła wiadomości na docelowy serwer IMAP. Jeśli data zapisu nie zostanie zachowana, INTERNALDATE jest nadpisywany. To najczęstszy przypadek i właśnie tutaj dochodzi do uszkodzenia dat.
• Import do folderu lokalnego: wiadomości pozostają na maszynie, poza serwerem. INTERNALDATE w tym kontekście nie istnieje, a eM Client może wyświetlać datę Date: z wiadomości. Mniej problemów z datami, ale też mniej praktycznego zastosowania.

W przypadku Thunderbirda sytuacja jest podobna. Czy używa się wbudowanej funkcji importu eM Client (odczytującej profile Thunderbirda), czy kopiuje się foldery mbox przez IMAP, wiadomości są ponownie zapisywane na serwerze bez gwarancji zachowania INTERNALDATE. A serwer, który otrzymuje wiadomość bez wyraźnej instrukcji co do daty INTERNALDATE, zawsze oznacza ją datą odebrania.

Których platform to dotyczy?

Problem jest identyczny niezależnie od platformy docelowej, bo wynika ze standardowego zachowania protokołu IMAP:

• Microsoft 365 / Exchange Online: INTERNALDATE jest nadpisywany przy każdym imporcie, który nie używa polecenia IMAP APPEND z jawnym parametrem daty. Dotyczy to również migracji z Exchange on-premise.
• Google Workspace: identyczne zachowanie. Emaile importowane przez eM Client lub narzędzia zewnętrzne wyświetlają datę importu w Gmailu i w interfejsie administracyjnym.
• Klasyczni hostingodawcy IMAP (OVH, Infomaniak, Ionos, o2switch itp.): brak specjalnego traktowania daty przy odbiorze wiadomości przez APPEND. INTERNALDATE będzie datą złożenia.

Pewien klient zgłosił się do Redate.io po migracji ponad stu skrzynek z Exchange 2013 do Microsoft 365, używając eM Client jako narzędzia przejściowego dla wybranych kont VIP. Skrzynki zmigrowane poprawnie przez MigrationWiz były bez zarzutu, natomiast te przeniesione przez eM Client miały wszystkie daty importu. Zainteresowani użytkownicy nie byli zachwyceni, mówiąc delikatnie.

Dlaczego własny skrypt tu nie wystarczy

Ktoś, kto rozumie protokół IMAP, mógłby pomyśleć o napisaniu skryptu do poprawy wartości INTERNALDATE. Oryginalny nagłówek Date: jest tam, niezmieniony w każdej wiadomości. Wystarczy go odczytać i na tej podstawie odbudować metadane serwera, prawda?

W teorii tak. W praktyce to pole minowe.

Po pierwsze, przypadki brzegowe na skrzynce produkcyjnej szybko się mnożą. Wiadomości podpisane cyfrowo przez S/MIME są szczególnie wrażliwe na jakąkolwiek ingerencję w strukturę. Tak samo wiadomości szyfrowane PGP. Emaile z dużymi załącznikami, niestandardowymi granicami MIME lub rzadkimi kodowaniami Content-Transfer-Encoding mogą ulec cichemu uszkodzeniu, jeśli przetwarzanie nie jest precyzyjne. Skrypt, który działa na 50 testowych wiadomościach, nie zadziała niezawodnie na skrzynce z 20 000 wiadomości i 6-letnim historią.

Po drugie, zarządzanie limitami API. Na Microsoft 365 limity szybkości dla Graph API lub EWS o 3 w nocy podczas wsadowej korekty 8000 wiadomości da się ogarnąć. Ale nie ogarną się same. Niemonitorowany skrypt, który trafi na błąd 429 Too Many Requests przy wiadomości numer 3741, może kontynuować albo nie. Nie wiadomo, które wiadomości zostały przetworzone.

I najważniejsze: jak sprawdzić, że każdy poprawiony email jest nienaruszony po przetworzeniu? Własny skrypt zazwyczaj nie ma mechanizmu weryfikacji każdej wiadomości z osobna. Redate.io robi to automatycznie, dla każdej wiadomości.

Naprawa dat u źródła przez Redate.io

Redate.io atakuje problem tam, gdzie rzeczywiście się znajduje: na poziomie metadanych serwera, a nie na poziomie klienta pocztowego.

Proces zaczyna się od bezpłatnego skanowania. Redate.io łączy się ze skrzynką (Microsoft 365 przez Azure AD, Google Workspace przez delegację domenową, lub bezpośrednio przez IMAP dla klasycznych hostingodawców) i identyfikuje wiadomości, których metadane daty są niespójne z treścią. Wyniki widać przed jakąkolwiek płatnością.

Korekcja używa autorskiego silnika, który analizuje pełny łańcuch nagłówków każdej wiadomości, stosuje dopasowanie wzorców wobec setek znanych sygnatur narzędzi importujących (w tym specyficznych zachowań eM Client, Thunderbirda i importów PST), a następnie precyzyjnie odbudowuje metadane daty bez naruszania treści wiadomości, jej załączników ani struktury MIME.

Każdy poprawiony email jest weryfikowany indywidualnie. Oryginały są przechowywane w widocznym folderze kopii zapasowej przez 30 dni, czego żaden własny skrypt domyślnie nie zrobi.

Taryfikacja jest prosta: jednorazowa płatność za skrzynkę, na podstawie liczby emaili do poprawienia. Bez subskrypcji, bez opłat cyklicznych. Szczegóły na stronie rejestracji.

Przed kolejną migracją: co warto sprawdzić

Jeśli planuje się migrację i chce uniknąć tego problemu z góry, punkt kontrolny jest prosty: czy używane narzędzie jawnie zachowuje INTERNALDATE podczas zapisywania wiadomości na serwerze docelowym?

W przypadku importów PST do Microsoft 365 narzędzia certyfikowane przez Microsoft (jak MigrationWiz w trybach natywnych lub narzędzie migracji Exchange Online) zazwyczaj obsługują to zachowanie. W przypadku ręcznych importów przez eM Client lub Thunderbirda rzadko tak jest. Warto sprawdzić dokumentację narzędzia przed uruchomieniem importu na skrzynkach produkcyjnych.

Dobra checklista migracji email zawsze obejmuje weryfikację dat po migracji na próbce skrzynek. Jeśli temat wymaga głębszego zbadania, artykuł checklista migracji email omawia ten punkt szczegółowo.

Dla administratorów regularnie obsługujących migracje dla klientów artykuł o naprawie dat emaili po stronie MSP oraz ten dotyczący działania INTERNALDATE IMAP dają pełniejszy obraz problemu.

Daty emaili są uszkodzone po imporcie w eM Client? Uruchom bezpłatne skanowanie na Redate.io, żeby zobaczyć skalę problemu przed podjęciem decyzji.