Migracja iCloud do Office 365: błędne daty emaili

Scenariusz migracji, który systematycznie niszczy daty

Właśnie zakończyłeś przenoszenie skrzynki iCloud do Office 365. Emaile są na miejscu, foldery gotowe, wszystko wygląda idealnie. W poniedziałek rano pojawia się pierwsza skarga: „Wszystkie stare emaile mają dzisiejszą datę." Potem kolejna. Potem dziesięć.

To nie jest odosobniony błąd. Migracja z iCloud Mail do Office 365 to jeden z najlepiej udokumentowanych scenariuszy uszkodzenia dat emaili, z bardzo konkretnych przyczyn technicznych związanych jednocześnie z zachowaniem Apple Mail, protokołem IMAP i sposobem, w jaki Microsoft 365 przetwarza przychodzące wiadomości.

Dlaczego migracja z iCloud do Office 365 psuje daty

Żeby zrozumieć problem, trzeba rozróżnić trzy rzeczy, które wiele osób (w tym doświadczeni administratorzy IT) myli ze sobą: nagłówek Date:, INTERNALDATE w IMAP i datę utworzenia pliku.

Nagłówek Date: (RFC 2822)

Każdy email zawiera nagłówek Date: wskazujący, kiedy wiadomość została wysłana. Ten nagłówek jest wbudowany w surową treść wiadomości i w teorii nigdy się nie zmienia. To „oryginalna" data w ścisłym sensie tego słowa.

INTERNALDATE w IMAP

Protokół IMAP (zdefiniowany w RFC 3501) przypisuje każdej wiadomości odrębne metadane zwane INTERNALDATE. To właśnie tej wartości większość klientów poczty używa do sortowania i wyświetlania wiadomości w skrzynce odbiorczej, a nie nagłówka Date:. Outlook w szczególności opiera się bardzo mocno na INTERNALDATE przy wyświetlaniu i sortowaniu.

Problem? Kiedy narzędzie migracyjne kopiuje email z jednego serwera IMAP na inny, powinno w idealnym przypadku zachować ten INTERNALDATE. W praktyce nie zawsze tak się dzieje.

Szczególne zachowanie Apple Mail

Apple Mail, synchronizując wiadomości z iCloud, używa czasem daty utworzenia pliku po stronie serwera jako punktu odniesienia dla INTERNALDATE. To nie jest błąd w ścisłym sensie, to interpretacja specyfikacji IMAP, która odbiega od tego, co robią inne klienty. (Swoją drogą, jeśli kiedykolwiek próbowałeś debugować problem z INTERNALDATE, czytając surowe RFC IMAP, to wiesz, że specyfikacja pozostawia tu dość dużo miejsca na interpretację.)

Rezultat: kiedy eksportujesz lub migrujesz dane z iCloud przez Apple Mail, INTERNALDATES wiadomości mogą być już nieprawidłowe, zanim jeszcze trafią do Office 365.

Trzy metody migracji z iCloud i ich pułapki

Bezpośrednia migracja IMAP

Najpopularniejsza metoda polega na skonfigurowaniu iCloud jako źródła IMAP i Office 365 jako celu, a następnie użyciu narzędzia migracyjnego (imapsync, MigrationWiz lub własnego rozwiązania). Narzędzie łączy się z oboma serwerami i kopiuje wiadomości.

Problem jest tu dwojaki. Po pierwsze, serwery IMAP Apple mają limity przepustowości, które zmuszają narzędzia do przerw, tworząc okna czasowe, w których połączenia są zamykane i ponownie otwierane, co może generować błędne INTERNALDATES. Po drugie, każda wiadomość skopiowana przez IMAP APPEND do Exchange Online domyślnie otrzymuje datę złożenia odpowiadającą momentowi migracji, chyba że narzędzie jawnie przekaże oryginalny INTERNALDATE w poleceniu wstawiania.

Niektóre narzędzia robią to poprawnie. Inne nie zawsze. A na skrzynce z 40 000 wiadomości nawet 2% błędów to 800 emaili z nieprawidłową datą.

W przypadku migracji przez imapsync warto też sprawdzić: naprawa dat imapsync w Microsoft 365.

Eksport .mbox lub .eml i import

Niektórzy użytkownicy eksportują emaile z iCloud przez Apple Mail w formacie .mbox, a następnie próbują zaimportować je do Outlooka. To rzemieślnicza metoda dająca zmienne wyniki.

Format .mbox koduje emaile jako sekwencję wiadomości tekstowych. Daty są obecne w poszczególnych nagłówkach Date:, ale linia separatora między wiadomościami ("From ") zawiera datę, która przez niektóre importery może być interpretowana jako data utworzenia. Outlook, importując .mbox skonwertowany do .pst, używa czasem tej daty separatora zamiast nagłówka Date: samej wiadomości.

Przeciąganie i upuszczanie w Outlooku

To metoda powodująca największe szkody. Użytkownik konfiguruje oba konta w Outlooku (iCloud i Office 365), a następnie przeciąga wiadomości z jednego folderu do drugiego. Wydaje się proste. To katastrofa dla dat.

Kiedy Outlook przenosi wiadomość przez przeciąganie między dwoma kontami IMAP, w rzeczywistości tworzy nowy plik .EML, wstawia go na konto docelowe i usuwa oryginał. Ten nowy plik dziedziczy datę utworzenia pliku Windows, czyli dokładny moment przeciągnięcia. Oryginalny nagłówek Date: wciąż jest obecny w treści wiadomości, ale INTERNALDATE zapisany na serwerze Exchange Online odpowiada dacie tej operacji. Outlook wyświetla następnie tę datę migracji dla wszystkich przeniesionych wiadomości.

Żeby być precyzyjnym: to zachowanie różni się w zależności od wersji Outlooka. Od aktualizacji z jesieni 2023 roku sytuacja nieznacznie się poprawiła w niektórych scenariuszach, ale przeciąganie między kontami pozostaje udokumentowanym źródłem uszkodzenia dat.

Co Office 365 i Outlook faktycznie wyświetlają

Exchange Online przechowuje emaile wraz z ich INTERNALDATE. Outlook Desktop odczytuje ten INTERNALDATE, aby wyświetlić datę w kolumnie „Odebrano" i posortować skrzynkę odbiorczą. Jeśli INTERNALDATE został nadpisany podczas migracji, Outlook wyświetla datę migracji. Koniec, kropka.

Outlook Web App (OWA) działa tak samo. Nie ma żadnego „alternatywnego widoku", który pokazywałby oryginalną datę z nagłówka Date:. To, co widać w kolumnie daty, to INTERNALDATE.

Oryginalny nagłówek Date: wciąż tam jest, nienaruszony, czytelny, jeśli wyświetlisz surowe nagłówki wiadomości. Ale żaden normalny widok go nie pokazuje. Na tym polega główna frustracja tego problemu: właściwa informacja istnieje, jest po prostu niedostępna bez technicznej korekty.

Czego wsparcie Microsoft nie rozwiąże

Jeśli otworzysz zgłoszenie do Microsoft Support w tej sprawie, prawdopodobnie otrzymasz: potwierdzenie, że wyświetlane daty odpowiadają przechowanym INTERNALDATES, sugestię sprawdzenia ustawień sortowania w Outlooku i ewentualnie odesłanie do narzędzia migracyjnego, którego użyłeś.

To nie jest zła wola. Microsoft po prostu nie ma natywnego narzędzia do wstecznej korekty INTERNALDATES tysięcy wiadomości już przetworzonych przez Exchange Online. Korekta wymaga indywidualnego dostępu do każdej wiadomości, analizy jej nagłówków i odbudowania metadanych daty, co wykracza poza zakres standardowego wsparcia.

Wsparcie iCloud z kolei uzna, że wiadomości zostały poprawnie wyeksportowane i że problem leży po stronie docelowej. Oba wsparcia odsyłają się nawzajem, a użytkownik zostaje z 12 000 emaili datowanych na dzień migracji.

Problem skali

Zrozumieć, dlaczego daty są uszkodzone, to jedno. Ręcznie je poprawić na produkcyjnej skrzynce to zupełnie inna sprawa.

Niektórzy administratorzy IT próbują pisać skrypty do korekty. Podstawowa idea nie jest trudna do zrozumienia, ale wykonanie na rzeczywistych wolumenach rodzi problemy, z którymi domowe skrypty nie radzą sobie dobrze:

• Emaile podpisane S/MIME lub zaszyfrowane PGP nie mogą być modyfikowane bez unieważnienia podpisu kryptograficznego
• Wiadomości o złożonej strukturze multipart/alternative (HTML + tekst zwykły + zagnieżdżone załączniki) są delikatne w obsłudze
• Nagłówki kodowane w non-ASCII (RFC 2047, szczególnie dla znaków japońskich, arabskich czy cyrylicy) mogą zostać uszkodzone przez narzędzia, które nie obsługują prawidłowo tych kodowań
• Limity API Microsoft Graph i ograniczenia przepustowości Exchange Online (błąd 429 Too Many Requests) zatrzymują skrypty nieprzygotowane na obsługę wykładniczego cofania (exponential backoff)
• Skrypt działający poprawnie na 500 testowych emailach zatrzymuje się o 3 w nocy na 8000. wiadomości z prawdziwej skrzynki, bez mechanizmu wznowienia

No właśnie, i jest jeszcze jedno pytanie, które wszystko przekreśla: jak zweryfikować, że każdy poprawiony email jest nienaruszony po korekcie? Że załącznik wciąż jest na miejscu? Że wątek konwersacji nie jest zerwany? Domowy skrypt z reguły tej weryfikacji nie wykonuje.

Jak Redate.io obsługuje migracje z iCloud do Office 365

Redate.io łączy się bezpośrednio z Office 365 przez uprawnienia Microsoft 365 (Azure AD), bez potrzeby dostępu do serwerów iCloud. Emaile są już w Exchange Online w momencie, gdy Redate podejmuje działanie.

Silnik korekcji Redate analizuje łańcuch nagłówków każdej wiadomości, żeby zidentyfikować oryginalną datę, odróżniając nagłówki Received: dodane podczas migracji od legalnych metadanych daty. Ta analiza obejmuje dopasowywanie wzorców na sygnaturach znanych narzędzi migracyjnych, co pozwala zidentyfikować parazytyczne nagłówki nawet wtedy, gdy nie są od razu oczywiste.

Każdy poprawiony email jest weryfikowany indywidualnie po przetworzeniu. Oryginały są przechowywane w widocznym folderze kopii zapasowej przez 30 dni, czego żaden domowy skrypt domyślnie nie robi. Wstępny skan jest bezpłatny i pozwala dokładnie zmierzyć liczbę dotkniętych emaili przed podjęciem decyzji o korekcie.

Redate obsługuje również migracje z Google Workspace do Office 365 i korekty po migracji cPanel. Zobacz na przykład: naprawa dat emaili po migracji Microsoft 365 lub dlaczego emaile pokazują złą datę po migracji.

Najpierw skan, potem korekta

Rekomendowany punkt startowy dla każdej migracji z iCloud do Office 365, która dała nieprawidłowe daty: uruchomienie bezpłatnego skanu Redate.io na dotkniętych skrzynkach. Skan precyzyjnie identyfikuje, ile emaili ma podejrzany INTERNALDATE i w których folderach się znajdują.

Zajmuje to od 12 do 45 minut w zależności od wolumenu i daje czytelny obraz skali problemu przed jakąkolwiek interwencją. Dla MSP zarządzających wieloma skrzynkami naraz po migracji, ten zbiorczy skan pozwala uniknąć korygowania skrzynek, które tego nie potrzebują.

Jeśli daty emaili są nieprawidłowe po migracji z iCloud, zacznij od bezpłatnego skanu na Redate.io, żeby zmierzyć skalę problemu w skrzynkach Office 365.