Przejście z POP na IMAP: stare maile datowane na dziś

Klasyczny scenariusz poniedziałkowego poranka

Właśnie przełączyłeś konto email z POP3 na IMAP. Konfiguracja była prosta, dostawca hostingu przeprowadził cię krok po kroku, wszystko poszło gładko. Do czasu, gdy ponownie otworzyłeś skrzynkę odbiorczą. Emaile z 2019 roku, z 2021, archiwum z zeszłego roku... wszystkie wyświetlają tę samą datę: dzisiaj. Czasem nawet tę samą godzinę, z dokładnością do kilku sekund.

To nie jest błąd klienta pocztowego. To nie problem ze strefą czasową. To oczekiwane zachowanie protokołu IMAP, które dotyczy każdego, kto przesyła lokalnie przechowywane emaile na serwer tą metodą.

POP3 a IMAP: zasadnicza różnica w sposobie przechowywania

Żeby zrozumieć, dlaczego problem w ogóle występuje, trzeba najpierw pojąć, jak działa POP3 i czym różni się radykalnie od IMAP.

W przypadku POP3 serwer pełni rolę wyłącznie tymczasowej skrzynki pocztowej. Klient pocztowy (Outlook, Thunderbird, Apple Mail) łączy się, pobiera wiadomości, a następnie usuwa je z serwera (lub pozostawia, zależnie od konfiguracji). Emaile żyją potem wyłącznie lokalnie: w pliku .pst dla Outlooka, w lokalnym profilu Thunderbirda, w bazie danych na dysku twardym.

Z IMAP jest odwrotnie: wiadomości przechowywane są na serwerze. Klient pocztowy jedynie wyświetla to, co jest składowane zdalnie. Stąd właśnie przezroczysta synchronizacja między wszystkimi urządzeniami.

Problem pojawia się podczas przejścia między tymi dwoma protokołami, kiedy próbujesz przenieść lokalne archiwum POP na serwer IMAP.

IMAP APPEND: polecenie, które zmienia wszystko

Gdy klient pocztowy przesyła lokalną wiadomość na serwer IMAP, używa polecenia IMAP APPEND. Mówi ono serwerowi: „zapisz tę wiadomość w danym folderze".

Serwer odbiera wiadomość, zapisuje ją i przypisuje jej znacznik czasu. Ten znacznik to INTERNALDATE. To centralna metadana IMAP: określa, kiedy wiadomość została umieszczona na serwerze. Domyślnie, jeśli klient nie poda explicite daty w poleceniu APPEND, serwer używa... bieżącego momentu.

Innymi słowy: nieważne, że wiadomość zawiera w nagłówkach datę z 2018 roku. Jeśli nikt nie powie serwerowi „ten email pochodzi z 2018 roku", serwer stwierdzi, że właśnie go dostarczono, i przypisze mu dzisiejszy INTERNALDATE.

(Swoją drogą, jeśli kiedykolwiek przeglądałeś surowe nagłówki emaila, widziałeś linię Date: pośród kilkudziesięciu innych linii Received:. To właśnie pole Date:, zdefiniowane przez RFC 2822, zawiera prawdziwą datę wysyłki. Natomiast INTERNALDATE IMAP to oddzielna metadana przechowywana po stronie serwera, która nie ma nic wspólnego z treścią samej wiadomości.)

Dlaczego różni się to od migracji IMAP-do-IMAP

W klasycznej migracji z jednego serwera IMAP na drugi (przy użyciu BitTitana, CloudM, imapsync itp.) problem jest nieco inny. Narzędzie migracyjne kopiuje wiadomości między serwerami i w tym przypadku może (teoretycznie) przekazać oryginalny INTERNALDATE do serwera docelowego za pośrednictwem polecenia APPEND. Problem polega tam na tym, że niektóre narzędzia dodają nagłówek Received: z datą migracji, co zaburza wyświetlanie w klientach takich jak Outlook.

W twoim przypadku punkt startowy to dane czysto lokalne. Nie ma źródłowego INTERNALDATE do skopiowania. Plik .pst czy profil Thunderbirda przechowuje wiadomości we własnym, zastrzeżonym formacie, z własnymi wewnętrznymi metadanymi. Gdy klient pocztowy odczytuje te wiadomości, by przesłać je na serwer IMAP, rekonstruuje polecenie APPEND na podstawie treści wiadomości. I przez większość czasu nie przekazuje żadnej explicytnej daty.

Rezultat: serwer IMAP odbiera setki lub tysiące wiadomości w ciągu kilku minut i przypisuje im wszystkim ten sam przedział czasowy: teraz.

To właśnie dlatego problem natychmiast rozprzestrzenia się na wszystkie urządzenia. Telefon, tablet, drugi komputer, wszystkie łączą się z tym samym serwerem IMAP i widzą dokładnie to samo. Korekcja po stronie klienta jest niemożliwa.

Który klient pokazuje co i dlaczego

Nie wszystkie klienty pocztowe reagują tak samo. To punkt, który wielu administratorów IT odkrywa po fakcie.

Outlook (w nowszych wersjach, szczególnie po aktualizacjach z lat 2023-2024) używa INTERNALDATE z serwera dla kolumny „Odebrano". Wyświetla więc datę przesłania na serwer, a nie oryginalną datę wysyłki. Więcej na temat tego specyficznego zachowania Outlooka znajdziesz w artykule: Outlook: data IMAP po migracji vs data wysyłki.

Gmail / Google Workspace i Thunderbird zachowują się nieco inaczej. Gmail na przykład może czasem używać pola Date: z nagłówka wiadomości do wyświetlania, co sprawia wrażenie, że wszystko jest w porządku... dopóki nie spróbujesz posortować wiadomości według daty i nie odkryjesz, że kolejność jest zupełnie chaotyczna.

Apple Mail zazwyczaj wyświetla datę wyciągniętą z nagłówka Date:, ale sortowanie i wyszukiwanie w tle korzystają z INTERNALDATE. W efekcie emaile mogą „wyglądać" na poprawnie datowane, ale funkcja sortowania przestaje działać prawidłowo. Szczegóły dotyczące zachowania Apple Mail opisuje artykuł: Apple Mail: zła data po migracji.

Dobra wiadomość: oryginalna data jest nienaruszona

Nagłówek Date: każdego emaila, ten zawierający prawdziwą datę wysyłki (lub odbioru), nie został naruszony. Nadal tam jest, w treści wiadomości. To właśnie on jest widoczny po otwarciu emaila i sprawdzeniu szczegółów.

To, co serwer IMAP „zepsuł", to wyłącznie INTERNALDATE, zewnętrzna metadana wiadomości. Sama wiadomość jest nienaruszona.

To właśnie umożliwia korekcję. I wyjaśnia też, dlaczego problem może przez jakiś czas pozostawać niezauważony: emaile wyglądają poprawnie, gdy otwierasz je jeden po drugim. Dopiero patrząc na listę skrzynki odbiorczej posortowaną według daty problem staje się widoczny. Emaile z 2019 roku pojawiają się na górze, jakby właśnie nadeszły. Wszystkie z tą samą datą.

Problem skali: 3000 emaili to nie to samo co 3

Może pojawia się myśl: „Wystarczy usunąć i zaimportować ponownie, tym razem poprawnie." Na 5 czy 10 testowych emailach - tak, zadziała. Na skrzynce z 8000 wiadomości, zagnieżdżonymi folderami, dużymi załącznikami, emailami podpisanymi S/MIME i wątkami sięgającymi 2015 roku... to zupełnie inna historia.

Skrypt napisany własnoręcznie, który działa na partii testowej 50 emaili, może z łatwością tworzyć duplikaty, gubić załączniki lub niszczyć wątki konwersacji na skrzynce produkcyjnej. Obsługa limitów API, timeoutów sieciowych, wiadomości o niestandardowych strukturach MIME... tyle przypadków brzegowych, z którymi niesprecyzowane narzędzie sobie nie poradzi.

A jeśli coś pójdzie nie tak w połowie drogi? Bez mechanizmu tworzenia kopii zapasowych i przywracania stanu dane zostaną utracone bezpowrotnie.

Ten problem jest dobrze znany administratorom zarządzającym migracjami na dużą skalę. Rozumieć, dlaczego daty są zepsute, to jedno. Poprawnie naprawić 15 000 emaili, zachowując każdą strukturę wiadomości - to coś zupełnie innego. Więcej na temat różnych podejść i ich ograniczeń znajdziesz w artykule Czy można naprawić daty emaili po migracji?

Jak Redate.io radzi sobie z tym konkretnym przypadkiem

Redate.io powstało dokładnie z myślą o tego typu sytuacjach. Jego silnik analityczny identyfikuje emaile, których INTERNALDATE nie odpowiada dacie zawartej w nagłówkach wiadomości, niezależnie od tego, czy chodzi o migrację POP na IMAP, migrację między serwerami IMAP, czy ręczne przesłanie lokalnych archiwów.

Wieloetapowy potok analizy sprawdza łańcuch nagłówków każdej wiadomości, weryfikuje zgodność z RFC i rekonstruuje metadane daty bez zmiany treści wiadomości: ani tekstu, ani załączników, ani struktury MIME, ani ewentualnych podpisów cyfrowych. Każdy poprawiony email jest weryfikowany indywidualnie przed zatwierdzeniem.

Oryginały przechowywane są w widocznym folderze kopii zapasowej przez 30 dni. Jeśli coś nie wyjdzie po twojej myśli, możesz przywrócić pierwotny stan.

Wstępne skanowanie jest bezpłatne: Redate analizuje skrzynkę, identyfikuje problemowe emaile i podaje dokładną ich liczbę zanim podejmiesz jakąkolwiek decyzję. Zero zobowiązań w ciemno.

Redate.io łączy się bezpośrednio ze skrzynkami przez Google Workspace (delegacja domeny), Microsoft 365 (Azure AD) lub bezpośrednio przez IMAP. Żadnej lokalnej instalacji. Żadnych plików .pst do ręcznej obsługi.

Administratorom zarządzającym wieloma skrzynkami pocztowymi polecamy uzupełniającą lekturę: MSP: naprawa dat emaili klientów. A w sprawie specyfiki korekcji w Thunderbirdzie, który ma własne zachowanie przy przejściu POP/IMAP, warto zajrzeć do artykułu Thunderbird: błędna data po migracji.

Jeśli migracja jeszcze przed tobą: jak zapobiec problemowi

Jeśli nie przeniosłeś jeszcze lokalnych archiwów na serwer IMAP albo planujesz kolejne migracje kont POP w organizacji, warto mieć w głowie kilka kwestii.

• Sprawdź, czy klient pocztowy obsługuje jawne przekazanie daty w poleceniu APPEND. Thunderbird na przykład zachowywał się różnie w tej kwestii w zależności od wersji.
• Najpierw przeprowadź test na koncie walidacyjnym z 50-100 reprezentatywnymi wiadomościami: stare emaile, z załącznikami, emaile podpisane. Sprawdź daty wyświetlane w różnych klientach.
• Zaplanuj korekcję zanim użytkownicy końcowi zaczną pracować na zmigrowanej skrzynce. Poprawianie dat na aktywnej skrzynce jest bardziej skomplikowane niż na świeżo zmigrowanej.
• Udokumentuj liczbę emaili przed migracją i po niej. To jedyny sposób na wykrycie cichych strat.

Pełna checklista punktów do sprawdzenia przed migracją i po niej dostępna jest w artykule Checklista migracji email: jak uniknąć błędów dat.

Stare emaile wyświetlają dzisiejszą datę po przejściu z POP na IMAP? Uruchom bezpłatne skanowanie na Redate.io, by ocenić skalę problemu i naprawić metadane dat bez ingerencji w treść wiadomości.