Exchange IMAP: dlaczego daty e-maili się psują

Importy IMAP w Exchange a daty e-maili

Exchange Online przypisuje każdej wiadomości w skrzynce datę, i to ta data jest wyświetlana i używana do sortowania w Outlooku. Dla e-maila, który przychodzi z internetu, jest to moment dostarczenia. Dla e-maila skopiowanego przez migrację, jest to data, jaką migracja przypisała kopii: oryginalna, gdy migracja ją przekazuje, dzień importu, gdy tego nie robi.

To właśnie stąd pochodzą błędne daty w importach IMAP w Exchange. Exchange Online nie nadpisuje daty, którą otrzymuje. Ale gdy import nie przenosi oryginalnej daty każdego e-maila, kopia 7-letniej wiadomości otrzymuje datę importu, jakby właśnie została dostarczona.

Efekt? Po zaimportowaniu 4000 e-maili ze starego serwera IMAP do Exchange Online, e-maile wyświetlają datę importu zamiast własnej. E-maile z 2018, 2020, 2023 roku, datowane na dzisiaj. Użytkownicy otwierają Outlooka w poniedziałek rano i widzą ścianę identycznie datowanych wiadomości.

Jak działa kreator migracji w Exchange Admin Center

Exchange Admin Center (EAC) zawiera wbudowany kreator migracji dla importów IMAP. To interfejs graficzny, po który sięga większość administratorów Exchange jako pierwszy: należy przejść do Odbiorców, następnie Migracji, utworzyć nową partię, wybrać "Migruj do Exchange Online", wskazać IMAP jako źródło, wczytać plik CSV z mapowaniami skrzynek i uruchomić partię.

W tle kreator migracji EAC tworzy New-MigrationBatch z typem punktu końcowego ustawionym na IMAP. Exchange łączy się ze źródłowym serwerem IMAP, odczytuje każdą wiadomość i zapisuje ją w docelowej skrzynce Exchange Online. Na papierze wygląda to prosto.

Ale tu administratorzy napotykają problem. Microsoft nie dokumentuje, jak migracja ustawia datę każdej skopiowanej wiadomości, a administratorzy zgłaszają, że e-maile wychodzą z datą synchronizacji zamiast datą odebrania. Outlook, OWA i każdy inny klient połączony z tą skrzynką następnie używa tej daty do wyświetlania i sortowania.

Oryginalny nagłówek Date: z 2019 roku? Wciąż tam jest, ukryty w nagłówkach wiadomości. Ale Exchange nie używa go do porządku sortowania w skrzynce odbiorczej.

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest i ten sam problem

Administratorzy, którzy woleją linię komend, często sięgają po New-MailboxImportRequest do importowania plików PST, lub po New-MigrationBatch z punktami końcowymi IMAP do migracji między serwerami. Oczekiwanie jest takie, że PowerShell daje większą kontrolę. I tak jest, w niektórych kwestiach. Nie w przypadku dat.

New-MailboxImportRequest importuje pliki PST do skrzynek Exchange Online. Plik PST zawiera oryginalne znaczniki czasu każdej wiadomości. Ale polecenie PowerShell nie ma parametru, który kontrolowałby, jaką datę otrzyma każda zaimportowana wiadomość. Nie ma flagi -PreserveDates (a administratorzy naprawdę jej szukali).

New-MigrationBatch -SourceEndpoint z punktem końcowym IMAP działa podobnie do kreatora EAC, tylko bez interfejsu graficznego. To samo połączenie IMAP, ten sam wynik dla dat. Polecenie oferuje parametry filtrowania według zakresu dat (-StartAfter, -CompleteAfter) oraz wykluczania folderów, ale nic, co kontrolowałoby, jak Exchange obsługuje znacznik czasu przychodzącej wiadomości.

Precyzyjniej: dotyczy to głównie daty wyświetlanej i porządku sortowania. Treść wiadomości, w tym oryginalny nagłówek Date, przychodzi nienaruszona. Błędna jest tylko data przypisana kopii, i to ona stoi za wszystkim, co widzi użytkownik.

Bezpośredni import IMAP a narzędzia trzecie

Czy ma znaczenie, czy używa się natywnego importu IMAP Exchange, czy narzędzia trzeciego, takiego jak BitTitan MigrationWiz czy CloudM? Krótka odpowiedź: problem z datami występuje w obu przypadkach, ale z nieco innych powodów.

Przy natywnym imporcie IMAP Exchange (kreator EAC lub PowerShell) sam Exchange łączy się ze źródłowym serwerem IMAP i pobiera wiadomości. Sposób, w jaki ustawia datę każdej kopii, zależy od Microsoftu i nie jest dokumentowany.

Przy narzędziach trzecich narzędzie migracyjne działa jako pośrednik. Odczytuje ze źródła, potencjalnie przekształca wiadomość i zapisuje ją do Exchange Online. Gdy narzędzie zapisuje przez IMAP, Exchange Online zachowuje datę, którą narzędzie przekazuje: jeśli narzędzie wysyła oryginalną datę każdego e-maila, kopia ją zachowuje; jeśli nie, kopia otrzymuje datę migracji. Niektóre narzędzia dodają też własny nagłówek Received: podczas przekazywania.

Praktyczna różnica? Nagłówki pozostawione przez różne narzędzia nie są takie same, więc naprawa nie może opierać się na jednym ustalonym wzorcu. Problem u podstaw jest identyczny: wyświetlana data nie jest oryginalną datą e-maila.

Dlaczego reguły transportu Exchange Online pogarszają sytuację

To coś, co zaskakuje nawet doświadczonych administratorów Exchange. Exchange Online ma reguły transportu (obecnie nazywane "regułami przepływu poczty" w centrum administracyjnym), które mogą się uruchamiać na importowanych wiadomościach. Jeśli organizacja ma reguły, które oznaczają nagłówki, dodają zastrzeżenia lub modyfikują wiadomości na podstawie warunków, te reguły mogą przetwarzać także importowane e-maile.

To znaczy, że e-mail z 2020 roku może otrzymać dodaną stopkę z zastrzeżeniem, albo nagłówek X oznaczony przez regułę zgodności, która nie istniała, gdy oryginalny e-mail został wysłany. Zmiana daty jest najbardziej widocznym symptomem, ale reguły transportu mogą powodować dodatkowe, nieoczekiwane modyfikacje.

Czy reguły transportu można wyłączyć podczas importu? Tak, tymczasowo. Ale większość administratorów nie myśli o tym, ponieważ nie oczekuje, że pipeline transportowy będzie w ogóle przetwarzał migrowane wiadomości. Kiedy zdają sobie sprawę z tego, co się stało, partia importu jest już zakończona, a szkoda dokonana.

Co błędne daty znaczą dla środowisk Exchange

Środowiska Exchange są zwykle środowiskami biznesowymi. Kancelarie prawne, instytucje finansowe, organizacje ochrony zdrowia, agencje rządowe. To nie są osobiste konta Gmail, gdzie błędna data jest lekko irytująca. To skrzynki, w których znaczniki czasu e-maili mają znaczenie prawne i regulacyjne.

Zatrzymanie procesowe (litigation hold) w Exchange zachowuje e-maile na podstawie zakresów dat. Jeśli każdy zaimportowany e-mail wyświetla datę importu zamiast oryginalnej daty, zatrzymanie obejmuje niewłaściwy zestaw wiadomości. Wyszukiwanie eDiscovery dla "wszystkich komunikacji między styczniem a marcem 2022" nie zwraca żadnych wyników, ponieważ te e-maile teraz wyświetlają kwiecień 2026.

Polityki retencji mają ten sam problem. Organizacja z 3-letnią polityką retencji może przypadkowo usunąć e-maile, które wydają się być z 2026 roku (i dlatego są "nowe"), gdy w rzeczywistości są z 2019 roku i powinny być zachowane. Albo odwrotnie: e-maile, które powinny zostać usunięte na podstawie polityki retencji, pozostają, ponieważ ich widoczna data jest niedawna.

Jeden scenariusz z końca 2025 roku: MSP zmigrował około 200 skrzynek z hostowanego dostawcy Exchange do Microsoft 365, używając kreatora migracji EAC. Trzy tygodnie później specjalista do spraw zgodności klienta zgłosił, że kwartalne raporty archiwizacji e-maili pokazywały każdą zarchiwizowaną wiadomość z tą samą datą. Całe archiwum e-maili, sięgające 5 lat wstecz, wyglądało tak, jakby przyszło jednego wtorku w listopadzie.

Naprawa dat importu IMAP w Exchange

Oryginalny nagłówek Date: przechodzi przez import nienaruszony. Import nie modyfikuje oryginalnych nagłówków RFC 2822 wewnątrz wiadomości. Ta oryginalna data jest punktem odniesienia dla naprawy.

Redate.io łączy się ze skrzynką Exchange Online (każda osoba loguje się własnym kontem Microsoft), skanuje wiadomości pod kątem anomalii dat spowodowanych importem IMAP i stosuje własny mechanizm korekcji opracowany przez Redate.io, który przeprowadza walidację zgodności z RFC, zachowanie struktury wiadomości oraz ukierunkowaną rekonstrukcję metadanych. Redate nie musi wiedzieć, jakie narzędzie wykonało import: znajduje e-maile, których wyświetlana data nie zgadza się z ich oryginalną datą.

Każda poprawiona wiadomość jest weryfikowana indywidualnie: integralność treści, sumy kontrolne załączników, umiejscowienie w folderze i wątkowanie konwersacji. Oryginały pozostają w widocznym folderze kopii zapasowej we własnej skrzynce pocztowej, aż zostaną usunięte samodzielnie. Jeśli coś wygląda nie tak, cofnięcie zmian jest oddalone o jedno kliknięcie.

Czemu nie naprawić tego skryptem PowerShell? Ponieważ zrozumienie problemu z nagłówkiem Received to łatwa część. Poprawienie 8000 e-maili w 50 skrzynkach bez naruszenia wiadomości podpisanych S/MIME, złamania zagnieżdżonych struktur MIME, zniekształcenia nagłówków RFC 2047 zawierających znaki inne niż ASCII, czy utraty przypisań do folderów, to trudna część. Jak zweryfikować, że każda pojedyncza poprawiona wiadomość w środowisku produkcyjnym jest nienaruszona, że żaden załącznik nie zginął, że żaden wątek konwersacji nie został przerwany? Skrypt, który działa na testowej skrzynce z 30 wiadomościami, załamie się na rzeczywistych przypadkach granicznych. A ten kontrakt z załącznikiem 42 MB i trzema obrazami wstawionymi w strukturze multipart/mixed wewnątrz otoczki multipart/alternative? Powodzenia.

Przewodniki dla konkretnych platform

Naprawa dat działa na poziomie skrzynki Exchange Online, ale użytkownicy uzyskują dostęp do e-maili przez różne klienty. Każdy z nich wyświetla daty inaczej:

• Napraw daty importu IMAP Exchange w Outlooku
• Napraw daty importu IMAP Exchange w OWA (Outlook w wersji internetowej)

Warto poszerzyć kontekst na temat problemów z datami w Microsoft 365 przy różnych narzędziach migracyjnych? Zobacz kompletny przewodnik naprawy dat e-maili po migracji Microsoft 365.

Import IMAP Exchange zostawił skrzynki z błędnymi datami? Zacznij od bezpłatnego skanowania, aby zobaczyć, ile e-maili jest dotkniętych i ile będzie kosztować naprawa, bez konieczności podawania karty kredytowej.