Trzy daty wewnątrz każdego emaila
Każdy email przechowywany na serwerze IMAP nosi co najmniej trzy odrębne wartości dat. Zrozumienie jak te daty działają i jak klienty poczty wybierają, którą wyświetlić, jest kluczem do zrozumienia, dlaczego migracja psuje daty. Ten artykuł to pogłębiona analiza techniczna systemu dat IMAP, przeznaczona dla administratorów IT i każdego, kto chce zrozumieć przyczynę problemów z datami po migracji.
1. Nagłówek "Date" RFC 2822
Nagłówek "Date" jest zdefiniowany w RFC 2822 (format wiadomości internetowych). Jest ustawiany przez klienta poczty nadawcy w momencie komponowania i wysyłania wiadomości. Ten nagłówek jest częścią samego ciała wiadomości - podróżuje z wiadomością i nigdy nie jest modyfikowany przez serwery pocztowe na drodze dostarczenia. Typowy nagłówek Date wygląda tak:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Nagłówek Date reprezentuje "datę wysłania" wiadomości. To najbardziej wiarygodna data, ponieważ jest ustawiana raz i nigdy zmieniana. Jednak odzwierciedla zegar nadawcy, który może być źle skonfigurowany. W rzadkich przypadkach nagłówek Date może być całkowicie nieobecny (szczególnie w zautomatyzowanych powiadomieniach systemowych lub źle sformatowanych wiadomościach).
2. IMAP INTERNALDATE
INTERNALDATE jest zdefiniowany w RFC 3501 (protokół IMAP4rev1). To wartość metadanych po stronie serwera reprezentująca datę i godzinę dostarczenia wiadomości na serwer. W przeciwieństwie do nagłówka Date, INTERNALDATE nie jest częścią samego emaila. Jest przechowywany oddzielnie przez serwer IMAP jako metadane.
Kiedy email jest dostarczany normalnie (bez migracji), serwer IMAP ustawia INTERNALDATE na bieżący czas w momencie dostarczenia. Ta wartość ściśle odpowiada nagłówkowi Date, zazwyczaj z różnicą kilku sekund lub minut. Klienty poczty często używają INTERNALDATE jako "daty odbioru", ponieważ odzwierciedla moment faktycznego odbioru wiadomości przez serwer.
I tu robi się ciekawie. Kiedy wiadomość jest wstawiana poleceniem IMAP APPEND (z którego korzystają narzędzia migracji), polecenie APPEND pozwala klientowi jawnie określić INTERNALDATE. Dobrze zaprojektowane narzędzia migracyjne wykorzystują tę funkcję do zachowania oryginalnego INTERNALDATE z serwera źródłowego. Ale nawet gdy INTERNALDATE jest prawidłowo ustawiony, problem z nagłówkiem "Received" (opisany poniżej) może i tak nadpisać wyświetlaną datę w wielu klientach.
3. Łańcuch nagłówków "Received"
Za każdym razem, gdy email przechodzi przez serwer pocztowy, ten serwer dodaje nagłówek "Received" na początku wiadomości. To tworzy łańcuch nagłówków Received rejestrujący podróż emaila od nadawcy do odbiorcy. Najnowszy (na szczycie) pokazuje ostatni serwer, który przetworzył wiadomość, a najstarszy (na dole) pokazuje pierwszy.
Normalny email może mieć 3 do 6 nagłówków Received, dokumentujących podróż od serwera wychodzącego nadawcy przez przekaźniki do serwera przychodzącego odbiorcy. Każdy nagłówek Received zawiera znacznik czasu. Oto uproszczony przykład:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Jak klienty poczty wybierają, którą datę wyświetlić
Outlook (Desktop, Web, Mobile)
Microsoft Outlook używa kombinacji INTERNALDATE i najnowszego nagłówka "Received" do ustalenia wyświetlanej daty "Odbioru" w skrzynce. W praktyce Outlook ma tendencję do priorytetyzowania znacznika czasu z najnowszego nagłówka Received dla kolumny "Odebrano". Kolumna "Wysłano" używa nagłówka Date. Ponieważ Outlook domyślnie sortuje po kolumnie "Odebrano", to znacznik czasu nagłówka Received widzą użytkownicy w pierwszej kolejności.
Apple Mail
Apple Mail na macOS i iOS używa głównie IMAP INTERNALDATE do wyświetlania daty. Jeśli INTERNALDATE został prawidłowo zachowany podczas migracji, Apple Mail może wyświetlać prawidłową datę, ale tylko jeśli INTERNALDATE został jawnie ustawiony podczas operacji APPEND. Jeśli narzędzie migracyjne nie ustawiło INTERNALDATE, serwer domyślnie używa czasu wstawiania (daty migracji). Szczegóły wpływu na użytkowników Apple Mail znajdziesz w artykule Apple Mail: błędna data po migracji.
Thunderbird
Mozilla Thunderbird oferuje największą elastyczność. Może wyświetlać zarówno "Datę" (z nagłówka Date) jak i "Odebrano" (z nagłówków Received). Domyślnie Thunderbird wyświetla wartość nagłówka Date, co oznacza, że daty mogą wydawać się prawidłowe w Thunderbirdzie nawet gdy są błędne w Outlooku. Kolumna "Odebrano" w Thunderbirdzie zawsze wyświetla datę migracji. Zobacz Thunderbird: błędna data po migracji po więcej szczegółów.
Interfejs webowy Gmail
Klient webowy Gmaila używa nagłówka Date dla głównego wyświetlania daty. To oznacza, że Gmail web często pokazuje prawidłowe daty nawet po migracji. Ale IMAP INTERNALDATE na serwerze Gmail jest i tak nieprawidłowy, co wpływa na każdego klienta IMAP łączącego się z tym kontem Gmail. Różnica między Gmail web a Outlookiem czy Apple Mail jest częstym źródłem zamieszania i jednym, które kosztuje administratorów dużo czasu na rozwiązywanie problemów.
Dlaczego IMAP APPEND psuje daty
Co się dzieje podczas migracji
Kiedy narzędzie migracyjne przenosi email z Serwera A na Serwer B, łączy się z Serwerem A przez IMAP i pobiera surową wiadomość, następnie łączy się z Serwerem B i używa polecenia APPEND do jej wstawienia. Podczas tego wstawiania Serwer B traktuje wiadomość przychodzącą i dodaje nowy nagłówek Received z bieżącym znacznikiem czasu: datą migracji. To standardowe zachowanie IMAP zdefiniowane w protokole. Serwer traktuje każde APPEND jako nowe dostarczenie wiadomości.
Rezultat: skażony łańcuch nagłówków
Po migracji nagłówki Received emaila wyglądają tak:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Nagłówek Received narzędzia migracyjnego jest teraz najwyższym wpisem. Każdy klient poczty używający najnowszego nagłówka Received do ustalenia daty wyświetlania (Outlook, w szczególności) wyświetli "11 kwietnia 2025" zamiast "15 stycznia 2024". Oryginalny nagłówek Date i oryginalne nagłówki Received wciąż są nienaruszone pod spodem, ale nie są już w pozycji, którą klienty poczty priorytetyzują.
Nawet dobra obsługa INTERNALDATE tego nie zapobiega
Niektóre narzędzia migracyjne prawidłowo ustawiają INTERNALDATE podczas APPEND. Na przykład imapsync jawnie zachowuje INTERNALDATE serwera źródłowego. Ale nagłówek Received jest dodawany przez serwer docelowy, nie przez narzędzie migracyjne. Narzędzie migracyjne nie ma żadnej kontroli nad tym zachowaniem. Nawet przy idealnym zachowaniu INTERNALDATE, najwyższy nagłówek Received wciąż zawiera datę migracji, a klienty takie jak Outlook i tak wyświetlają złą datę.
No właśnie, co można z tym konkretnie zrobić?
Które narzędzia migracji dodają nagłówki Received
Wszystkie narzędzia migracji IMAP powodują ten problem, ponieważ nagłówek Received jest dodawany przez serwer docelowy, nie przez samo narzędzie. Zawartość dodanego nagłówka różni się w zależności od narzędzia i serwera.
BitTitan MigrationWiz dodaje nagłówek Received zawierający "mx.migrationwiz.com". CloudM Migrate dodaje nagłówki odwołujące się do "cloudm.io". imapsync wyzwala generyczny nagłówek Received serwera docelowego. GSMMO dodaje nagłówki z odwołaniami do "gmailapi.google.com".
Naprawa: przywrócenie prawidłowych dat
Dobra wiadomość jest taka, że prawidłowa informacja o dacie wciąż istnieje w każdym emailu. Oryginalny nagłówek Date jest nietknięty. Oryginalne nagłówki Received są nietknięte. Problem polega na tym, że zanieczyszczający nagłówek siedzi nad nimi.
Autorski silnik korekcji Redate.io analizuje pełny łańcuch nagłówków każdego dotkniętego emaila, stosując dopasowanie sygnatur na setkach znanych sygnatur narzędzi migracyjnych, aby precyzyjnie zidentyfikować, które nagłówki wymagają korekty. Wieloetapowy pipeline analizy obsługuje przypadki brzegowe, z którymi prostsze podejścia sobie nie radzą: wiadomości podpisane S/MIME, treści zaszyfrowane PGP, struktury multipart/alternative, problemy z Content-Transfer-Encoding, nagłówki nie-ASCII (RFC 2047), zbyt duże załączniki i uszkodzone granice MIME.
Po korekcie każdy email przechodzi proces weryfikacji integralności potwierdzający, że struktura, treść i załączniki wiadomości są zachowane identycznie. Oryginały są przechowywane w widocznym folderze kopii zapasowej przez 30 dni.
Czy da się napisać skrypt, by samodzielnie spróbować tej korekty? Technicznie tak. Ale różnica między "działa na 95% emaili" a "działa na 100% emaili bez uszkodzenia ani jednego" to miesiące rozwoju. A kiedy mowa o całej skrzynce pocztowej kogoś, 5% współczynnik niepowodzenia oznacza setki wiadomości cicho uszkodzonych bez możliwości weryfikacji, co poszło nie tak.
Chcesz wiedzieć, ile emaili w skrzynce ma błędne daty? Uruchom bezpłatną analizę z Redate.io, aby uzyskać natychmiastowy wynik dotkniętych emaili, bez wymaganej płatności.