Błędne daty emaili po migracji do Exchange Online

Klasyczny scenariusz poniedziałkowego poranka

Migracja IMAP do Exchange Online zakończona. Batch zamknął się bez błędów w centrum administracyjnym Exchange, skrzynki zsynchronizowane, użytkownicy mogą się logować. W piątek wieczór zamykasz komputer z poczuciem dobrze wykonanej roboty.

W poniedziałek rano zaczynają spływać zgłoszenia. „Wszystkie moje emaile mają datę z piątku." „Historia skrzynki odbiorczej jest bezużyteczna." „Brakuje starych wiadomości." W rzeczywistości nic nie brakuje: emaile są na miejscu, ale Outlook wyświetla je wszystkie z datą migracji zamiast oryginalnej daty wysłania. Wiadomość z 2019 roku wygląda, jakby przyszła w miniony piątek. Efekt jest taki, że cała skrzynka sprawia wrażenie, jakby zawierała wyłącznie nowe wiadomości.

To jeden z najbardziej frustrujących problemów przy migracjach IMAP do Exchange Online, a Microsoft niemal konsekwentnie go nie dokumentuje.

Dlaczego migracja przez EAC psuje daty

Gdy używasz centrum administracyjnego Exchange (EAC) do skonfigurowania migracji IMAP z lokalnego serwera (Dovecot, Courier, Cyrus, UW-IMAP, bez różnicy), Exchange Online łączy się ze źródłowym serwerem przez IMAP, pobiera wiadomości i wstrzykuje je do docelowych skrzynek przez własny wewnętrzny pipeline transportowy.

I tu właśnie pojawia się problem.

Każdy email przechodzący przez pipeline transportowy Exchange automatycznie otrzymuje nagłówek Received: ze znacznikiem czasu. To standardowe zachowanie serwerów SMTP i IMAP od dziesięcioleci: każdy serwer, który dotknie wiadomości, dodaje do niej swój podpis czasowy. Problem w tym, że Outlook (szczególnie Outlook dla Windows w nowszych wersjach) używa najnowszego nagłówka Received: jako punktu odniesienia do wyświetlania daty, gdy inne metadane są niejednoznaczne.

Oryginalny nagłówek Date: (ten, który wskazuje, kiedy email naprawdę został wysłany, zgodnie z RFC 2822) wciąż jest w wiadomości. Nie został usunięty. Ale jest „przyćmiony" przez nowy nagłówek Received: dodany przez Exchange podczas wstrzyknięcia.

Równolegle, INTERNALDATE IMAP (metadana, której serwery IMAP używają do wewnętrznego datowania wiadomości i która steruje sortowaniem w większości klientów) jest ustawiana na datę wstrzyknięcia, a nie na oryginalną datę emaila. Exchange Online nie ma żadnego natywnego sposobu na zachowanie INTERNALDATE z serwera źródłowego podczas migracji batchowej przez EAC.

EAC kontra narzędzia zewnętrzne: istotna różnica

Warto odróżnić dwie sytuacje. W przypadku narzędzi takich jak BitTitan MigrationWiz czy CloudM Migrate problem też występuje, ale te narzędzia mają czasem opcje konfiguracyjne (częściowo udokumentowane, często ukryte w zaawansowanych ustawieniach), które próbują zachować część metadanych dotyczących daty.

Natywna migracja przez EAC nie oferuje żadnej takiej opcji. Microsoft nie udostępnia parametru kontrolującego zachowanie INTERNALDATE w pipeline migracji batchowej. To czarna skrzynka: konfigurujesz batch, uruchamiasz go, Exchange robi w środku co chce. A to, co robi konsekwentnie, to datowanie wiadomości zgodnie z datą ich wstrzyknięcia.

(Swoją drogą, jeśli kiedykolwiek próbowałeś czytać surowe nagłówki emaila zmigrowanego przez EAC, wiesz, że nagłówek Received: dodany przez Exchange jest nie do pomylenia z niczym innym: zawiera odniesienia do wewnętrznych serwerów Microsoft, jak *.protection.outlook.com czy *.prod.exchangelabs.com, ze znacznikiem czasu odpowiadającym dokładnie oknu migracji.)

Dlaczego ponowne uruchomienie batcha nic nie da

Instynktowna reakcja wielu administratorów IT na ten problem to: „Jeśli usunę zmigrowane skrzynki i uruchomię batch od zera, może tym razem daty będą prawidłowe."

To zrozumiałe. Ale nie działa.

Problem nie leży w konfiguracji batcha. Nie chodzi o parametr, którego zapomniano zaznaczyć. Chodzi o samą architekturę pipeline'u transportowego Exchange, która jest identyczna przy każdej migracji. Ponowne uruchomienie batcha da dokładnie ten sam efekt: te same nagłówki Received: z nową datą migracji i te same nieprawidłowe INTERNALDATE. Stracisz czas, a użytkownicy będą po raz drugi zbędnie niepokojeni.

Niektórzy administratorzy próbują też zmieniać ustawienia sortowania w Outlooku (sortowanie „po dacie wysłania" zamiast „dacie odebrania"). Sortowanie po dacie wysłania to nie rozwiązanie. To plaster. Nagłówek Date: i INTERNALDATE nadal pozostają nieprawidłowe dla klientów, którzy nie mają takiego ustawienia, dla OWA, Outlooka Mobile i każdej zewnętrznej aplikacji uzyskującej dostęp do skrzynki przez IMAP lub EWS.

Co tak naprawdę dzieje się w nagłówkach

Oto uproszczony przykład tego, co zawiera email po migracji przez EAC. Oryginalny nagłówek:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@staredomena.pl
Subject: Raport Q1 2019

Po migracji wiadomość otrzymuje na początku łańcucha coś takiego:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook widzi ten nagłówek Received: jako pierwszy (jest dodawany na początku bloku nagłówków), interpretuje go jako najpóźniejszą datę przetwarzania wiadomości i wyświetla ją jako datę odebrania. Oryginalny nagłówek Date: z 2019 roku nadal tam jest, nienaruszony, kilka linijek niżej. Ale Outlook nie używa go do wyświetlania na liście wiadomości.

Właściwie: zachowanie różni się nieco w zależności od wersji Outlooka. Wersje po 2021 roku (a szczególnie nowy Outlook dla Windows wdrażany od końca 2023 roku) są na ten problem szczególnie wrażliwe, bo bardziej polegają na metadanych Exchange Graph niż na surowym nagłówku Date:. To oznacza, że migracje, które nie powodowały widocznych problemów w Outlooku 2016, mogą teraz sprawiać kłopoty w nowym Outlooku.

Kogo problem dotyka najbardziej

Najczęstsze serwery IMAP źródłowe w tego typu migracjach to Dovecot (bardzo powszechny w środowiskach Linux/cPanel) i Courier. Oba udostępniają INTERNALDATE przez IMAP, którego EAC nie zachowuje. W przypadku migracji z lokalnego Exchange Server do Exchange Online (migracja hybrydowa lub cutover) sytuacja wygląda inaczej, bo Microsoft używa wewnętrznego protokołu transportowego (MAPI/EWS), który lepiej zachowuje metadane. Problem dotyczy generycznej migracji IMAP przez EAC.

Najbardziej dotknięci są użytkownicy z długą historią skrzynki (5 lat i więcej) oraz dużą liczbą wiadomości. Użytkownik z 300 emailami poradzi sobie szybko. Dyrektor handlowy z 12 000 wiadomości posortowanych według daty, na których polega każdego dnia, żeby odnaleźć korespondencję z klientami, jest w praktyce sparaliżowany.

Dlaczego skrypt pisany na własną rękę to zły pomysł

Niektórzy administratorzy IT, którzy rozumieją techniczne tło problemu, są skuszeni, żeby napisać skrypt PowerShell lub Python do ręcznej korekty nagłówków. Podstawowy mechanizm może wydawać się prosty, gdy już się go zidentyfikuje. Ale rzeczywistość korekty w środowisku produkcyjnym to zupełnie inna historia.

Zacznijmy od przypadków brzegowych. Emaile podpisane S/MIME i wiadomości szyfrowane PGP mają strukturę, która nie toleruje modyfikacji nagłówków bez unieważnienia podpisu. Wiadomości multipart/alternative ze źle sformułowanymi granicami MIME (częste na starych serwerach Courier) mogą zostać uszkodzone przez skrypt modyfikujący wiadomość bez prawidłowej rekonstrukcji struktury. Nagłówki non-ASCII zakodowane zgodnie z RFC 2047 (nazwy nadawców z polskimi literami czy znakami japońskimi) to klasyczne źródło błędów.

Potem jest kwestia wolumenu. Skrypt działający na 50 emailach testowych w środowisku deweloperskim nie radzi sobie z limitami szybkości API Exchange Online w produkcji. Błąd 429 Too Many Requests o 2 w nocy podczas przetwarzania batcha 8000 wiadomości, bez mechanizmu wznawiania, to nieprzespana noc i potencjalnie wiadomości zduplikowane lub utracone.

I przede wszystkim: jak zweryfikować, że każdy poprawiony email jest nienaruszony? Że żaden załącznik nie został obcięty, żaden wątek nie jest zepsuty, że etykiety i foldery zostały zachowane? Bez mechanizmu indywidualnej weryfikacji można tylko mieć nadzieję, że wszystko poszło dobrze.

Naprawa dat po migracji to problem, który wygląda jak 50 linijek kodu, ale wymaga tysięcy, żeby działał niezawodnie w produkcji.

Co Redate.io robi inaczej

Redate.io łączy się z Exchange Online przez API Microsoft 365 (Azure Active Directory, uprawnienia delegowane na poziomie tenanta) i skanuje wskazane skrzynki w poszukiwaniu emaili, których metadane daty zostały uszkodzone podczas migracji. Ten etap skanowania jest bezpłatny i daje dokładny obraz skali problemu: liczba wiadomości do naprawy, których skrzynek dotyczy problem, zakres uszkodzonych dat.

Autorski silnik korekcji Redate.io przetwarza następnie każdy email indywidualnie przez wieloetapowy pipeline analityczny, który obejmuje dopasowywanie wzorców do sygnatur znanych narzędzi migracyjnych (w tym pipeline'u transportowego Exchange Online), walidację zgodności z RFC oraz weryfikację integralności struktury wiadomości przed korektą i po niej. Emaile podpisane S/MIME, złożone struktury MIME, niestandardowe kodowania: wszystkie są obsługiwane przez dedykowane ścieżki przetwarzania.

Każda poprawiona wiadomość jest weryfikowana indywidualnie. Oryginały są przechowywane w widocznym folderze kopii zapasowej przez 30 dni. Jeśli coś jest nie tak z konkretną wiadomością, nie jest modyfikowana: Redate.io zgłasza anomalię zamiast ryzykować uszkodzenie danych.

Cennik oparty jest na wolumenie, jako jednorazowa płatność za skrzynkę. Bez subskrypcji, bez cyklicznych opłat. Naprawiasz problem raz i masz spokój.

W przypadku migracji do Exchange Online Redate.io obsługuje połączenie przez uprawnienia aplikacji Azure AD (bez konieczności tworzenia indywidualnych danych uwierzytelniających dla każdej skrzynki), co znacznie ułatwia zarządzanie dużymi flotami skrzynek dla administratora IT lub MSP.

Jeśli obsługujesz kilku klientów, którzy przeszli przez tego rodzaju migrację, warto też zajrzeć do kompletnego przewodnika po naprawie dat po migracji Microsoft 365, gdzie omówione są różne scenariusze.

Emaile są na miejscu, oryginalne daty też. Uruchom bezpłatny skan na Redate.io i sprawdź dokładnie, ile wiadomości jest dotkniętych problemem w Twoich skrzynkach Exchange Online, zanim zdecydujesz, co dalej.