Problem - każdy email pokazuje tę samą datę
Po migracji IMAP użytkownicy otwierają skrzynkę pocztową i odkrywają niepokojący widok: każdy email wyświetla dokładnie tę samą datę. Zamiast oryginalnej daty wysłania lub odbioru, wszystkie wiadomości noszą datę przeprowadzenia migracji. Lata korespondencji wyglądają tak, jakby dotarły tego samego dnia.
To koszmar dla administratorów IT. Zgłoszenia napływają lawinowo, użytkownicy nie mogą niczego znaleźć po dacie, a chronologiczna historia skrzynki pocztowej jest w praktyce zniszczona.
Jak to wygląda w Outlooku
W Microsoft Outlook kolumna "Odebrano" wyświetla datę migracji dla każdego emaila. Czy wiadomość została wysłana w 2018 roku, czy w 2023 - Outlook pokazuje tę samą datę, dzień przetworzenia skrzynki przez narzędzie migracyjne. Skrzynka odbiorcza, elementy wysłane, każdy folder jest dotknięty. Użytkownicy polegający na sortowaniu według daty widzą swój przepływ pracy całkowicie zepsuty.
Jak to wygląda w Apple Mail
Apple Mail na macOS i iOS zachowuje się podobnie. Data wyświetlana obok każdej wiadomości odzwierciedla znacznik czasu migracji, a nie datę oryginalną. Ponieważ Apple Mail wykorzystuje metadane serwera IMAP do ustalania dat wyświetlania, ten sam problem daje ten sam widoczny rezultat. Przeglądając skrzynkę odbiorczą, widać jedynie ścianę identycznych dat.
Jak to wygląda w Gmail (interfejs webowy)
Interfejs webowy Gmail prezentuje nieco inną sytuację. Klient webowy Gmaila zazwyczaj używa nagłówka "Date" samego emaila, więc wiadomości mogą pojawiać się z prawidłową datą w Gmailu. Ale INTERNALDATE IMAP pozostaje nieprawidłowy, co oznacza, że każdy klient IMAP łączący się z tym kontem Gmail (Outlook, Thunderbird, Apple Mail) wyświetli datę migracji. W efekcie ta sama skrzynka wygląda poprawnie w jednym kliencie, ale błędnie w innym. Dość mylące.
Dlaczego tak się dzieje - przyczyna techniczna
Przyczyna leży w sposobie, w jaki narzędzia migracji IMAP obsługują nagłówki emaili, oraz w tym, jak klienci poczty elektronicznej określają, którą datę wyświetlić. Zrozumienie tego wymaga krótkiego spojrzenia na protokół IMAP i strukturę nagłówków.
Jak narzędzia migracji IMAP obsługują nagłówki
Kiedy email jest migrowany z jednego serwera na drugi, narzędzie migracji pobiera surową wiadomość z serwera źródłowego i przesyła ją na serwer docelowy za pomocą polecenia IMAP APPEND. W trakcie tego procesu protokół IMAP wymaga od serwera docelowego dodania nagłówka "Received" do wiadomości. Ten nagłówek zawiera znacznik czasu momentu wstawienia wiadomości na nowy serwer, czyli datę migracji.
Nagłówek "Received", który psuje wszystko
Wiadomości email zazwyczaj zawierają kilka nagłówków "Received", z których każdy dodany przez serwer pocztowy obsługujący wiadomość podczas oryginalnego dostarczenia. Klienci tacy jak Outlook określają "datę odbioru" odczytując najnowszy nagłówek "Received", ten na szczycie łańcucha. Kiedy narzędzie migracji dodaje nowy nagłówek "Received" ze znacznikiem czasu migracji, staje się on najnowszym, a klienci poczty wyświetlają tę datę zamiast oryginalnej.
To nie jest błąd narzędzia migracyjnego ani klienta poczty. Oba poprawnie przestrzegają standardów IMAP i email. Problem polega na tym, że te standardy nigdy nie zostały zaprojektowane z myślą o masowej migracji, a interakcja między IMAP APPEND a logiką wyświetlania dat daje ten niepożądany rezultat.
INTERNALDATE vs nagłówek Date
Serwery IMAP przechowują dwie różne wartości dat dla każdej wiadomości. Nagłówek "Date" jest częścią samego emaila - rejestruje, kiedy wiadomość została napisana i wysłana. INTERNALDATE to metadane przechowywane przez serwer IMAP, reprezentujące moment dostarczenia lub wstawienia wiadomości na dany serwer.
Niektóre narzędzia migracji próbują zachować oryginalny INTERNALDATE, ustawiając go podczas polecenia APPEND. Ale nawet gdy INTERNALDATE jest prawidłowo ustawiony, dodany nagłówek "Received" wciąż powoduje problemy w klientach, które priorytetyzują datę "Received" względem INTERNALDATE.
Które narzędzia migracji powodują ten problem?
Tak naprawdę niemal każde narzędzie migracji IMAP może wywołać ten problem. Kwestia jest nieodłączna od protokołu IMAP, a nie specyficzna dla konkretnego narzędzia. Niektóre są jednak częściej kojarzone z problemem ze względu na ich powszechne zastosowanie.
BitTitan MigrationWiz
BitTitan MigrationWiz to jedno z najpopularniejszych komercyjnych narzędzi migracyjnych używanych przez MSP i konsultantów IT. MigrationWiz dodaje nagłówek "Received" zawierający "mx.migrationwiz.com" podczas procesu migracji. Ten nagłówek staje się najnowszym w łańcuchu, powodując wyświetlanie daty migracji w Outlooku i innych klientach IMAP. Zobacz szczegółowe przewodniki dla naprawy dat BitTitan w Outlooku, Microsoft 365, Google Workspace i Exchange Online.
CloudM Migrate
CloudM Migrate (wcześniej Cloud Migrator) jest szeroko stosowany do migracji Google Workspace. Jak inne narzędzia, CloudM dodaje własny nagłówek "Received" podczas wstawiania IMAP. Emaile zmigrowane przez CloudM wyświetlają datę migracji w klientach bazujących na nagłówku "Received". Zobacz przewodniki dla naprawy dat CloudM w Gmailu, Outlooku, Google Workspace i Microsoft 365.
imapsync
imapsync to popularne narzędzie open source wśród administratorów Linux i providerów hostingowych. Choć imapsync próbuje zachować INTERNALDATE, serwer docelowy i tak dodaje nagłówek "Received" podczas operacji APPEND. FAQ imapsync uznaje to ograniczenie, ale nie oferuje wbudowanego rozwiązania do usunięcia dodanego nagłówka po migracji. Zobacz przewodniki dla naprawy dat imapsync w Outlooku, Gmailu, Microsoft 365 i Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) to własne narzędzie Google do migracji z Exchange lub plików PST Outlook do Google Workspace. GSMMO może powodować ten sam problem z datami, szczególnie gdy migracja obejmuje pośredni etap IMAP. Zobacz przewodniki dla naprawy dat GSMMO w Outlooku, Gmailu i Apple Mail.
Exchange Admin Center (natywny import IMAP)
Centrum administracyjne Exchange od Microsoft zawiera natywną funkcję importu IMAP do migracji do Exchange Online (Microsoft 365). To wbudowane narzędzie migracyjne dodaje nagłówki "Received" podczas importu, powodując ten sam problem z wyświetlaniem dat. Zobacz przewodniki dla naprawy dat migracji Exchange IMAP w Outlooku i OWA.
Ręczne kopiowanie IMAP
Nawet ręczne kopiowanie emaili między serwerami IMAP za pomocą klienta takiego jak Thunderbird może spowodować ten problem z datami. Kiedy klient poczty kopiuje wiadomość przez IMAP, serwer docelowy traktuje ją jako nowe wstawienie i dodaje własny nagłówek "Received" z bieżącym znacznikiem czasu. Zobacz przewodniki dla naprawy dat ręcznego kopiowania IMAP w Outlooku, Gmailu, Thunderbirdzie i Apple Mail.
Dlaczego typowe obejścia nie działają
W obliczu tego problemu użytkownicy i administratorzy próbują zazwyczaj kilku podejść, zanim zdadzą sobie sprawę, że żadne z nich naprawdę nie rozwiązuje problemu.
"Sortuj według daty wysłania" - dlaczego to nie wystarcza
Najczęstsza sugestia to przełączenie z sortowania po dacie "odbioru" na datę "wysłania" w kliencie poczty. To zmienia kolejność wyświetlania, ale nie naprawia danych bazowych. Wyniki wyszukiwania wciąż pokazują złą datę. Integracje kalendarza, narzędzia zgodności i zautomatyzowane przepływy pracy zależne od daty odbioru nadal działają nieprawidłowo. A użytkownicy muszą pamiętać o zmianie tego ustawienia na każdym urządzeniu i w każdym folderze.
Ponowna migracja - kosztowna i ryzykowna
Niektórzy administratorzy rozważają ponowne uruchomienie migracji, mając nadzieję na uniknięcie problemu z datami za drugim razem. To podejście jest kosztowne (500 do 5000 EUR w zależności od liczby skrzynek), czasochłonne i ryzykowne. Druga migracja wprowadza ten sam problem z nagłówkiem "Received", podwaja ryzyko utraty danych i wymaga znacznego przestoju. Ponowna migracja nie rozwiązuje problemu dat, chyba że narzędzie migracyjne zostanie gruntownie zmodyfikowane.
Ręczna edycja nagłówków - wymaga dostępu do serwera
Technicznie korekta polega na usunięciu migracyjnego nagłówka "Received" z każdego emaila. Ale robienie tego ręcznie wymaga bezpośredniego dostępu do serwera, znajomości struktury nagłówków email i niestandardowych skryptów. Dla skrzynki z 10000 emaili ręczna edycja jest niepraktyczna i niebezpiecznie podatna na błędy. Emaile podpisane S/MIME, wiadomości zaszyfrowane PGP, struktury multipart z zagnieżdżonymi granicami MIME, problemy z Content-Transfer-Encoding, nagłówki nie-ASCII (RFC 2047), zbyt duże załączniki - każdy z tych przypadków może sprawić, że prosty skrypt nieodwracalnie uszkodzi dane. Jak potwierdzić, że 10000 poprawionych emaili jest w pełni nienaruszone? Nie da się tego zrobić bez systemu weryfikacji zaprojektowanego specjalnie do tego celu.
Prawdziwe rozwiązanie - przywrócenie oryginalnych dat
Właściwe podejście polega na identyfikacji artefaktów migracji w łańcuchu nagłówków każdego emaila i zastosowaniu celowanych korekt przywracających oryginalną kolejność chronologiczną we wszystkich klientach poczty. To nie jest prosta edycja nagłówka. Proces obejmuje walidację zgodności RFC, zachowanie struktury wiadomości i dopasowanie sygnatur migracji z bazy danych profili znanych narzędzi.
Jak Redate.io naprawia ten problem
Redate.io łączy się ze skrzynką pocztową (Google Workspace, Microsoft 365 lub dowolny serwer IMAP) i analizuje każdy email w celu identyfikacji wiadomości dotkniętych nagłówkami migracyjnymi. Analiza jest bezpłatna i pokazuje dokładnie, ile emaili jest dotkniętych, przed jakąkolwiek płatnością.
Dla każdego dotkniętego emaila autorski silnik korekcji Redate.io przepuszcza wiadomość przez wieloetapowy proces analizy. Silnik stosuje dopasowanie sygnatur na setkach profili znanych narzędzi migracyjnych, zbudowanych na podstawie przetwarzania dużych wolumenów rzeczywistych danych email. Obsługuje problemy z kodowaniem, struktury multipart, załączniki inline i dziesiątki szczególnych przypadków, które spowodowałyby uszkodzenie danych przez skrypt DIY (nie jest to rodzaj odkrycia, którego chce się dokonać w poniedziałek rano). Każdy poprawiony email przechodzi weryfikację integralności przed finalizacją. Oryginalna wiadomość jest przenoszona do widocznego folderu "Redate.io - Originals" (nie usuwana) i przechowywana przez 30 dni.
Rezultat? Emaile wyświetlają prawidłowe oryginalne daty we wszystkich klientach. Sortowanie znów działa. Chronologiczna historia skrzynki jest przywrócona.
Najczęściej zadawane pytania
Czy daty można naprawić miesiące po migracji?
Tak. Oryginalny nagłówek "Date" jest zachowany wewnątrz wiadomości email niezależnie od tego, kiedy migracja miała miejsce. Redate.io może naprawić daty emaili tygodnie, miesiące, a nawet lata po migracji. Korekta działa tak długo, jak oryginalne nagłówki emaila pozostają nienaruszone.
Czy naprawa dat usunie moje emaile?
Nie. Redate.io nigdy nie usuwa emaili. Oryginalne wiadomości są przenoszone do widocznego folderu o nazwie "Redate.io - Originals" w skrzynce pocztowej, gdzie pozostają dostępne przez 30 dni. Każdy poprawiony email jest weryfikowany względem oryginału przed finalizacją procesu. Jeśli weryfikacja nie powiedzie się dla jakiejś wiadomości, oryginał pozostaje nietknięty.
Czy to działa ze skrzynkami współdzielonymi?
Tak. Redate.io działa ze skrzynkami współdzielonymi w Google Workspace i Microsoft 365. W przypadku skrzynek współdzielonych wymagany jest dostęp na poziomie administratora do autoryzacji połączenia. Proces jest identyczny jak dla skrzynek indywidualnych: analiza, korekta, weryfikacja.
Gotowy, by przywrócić prawidłowe daty? Uruchom bezpłatną analizę, aby dowiedzieć się, ile emaili jest dotkniętych w każdej skrzynce.