Naprawa dat imapsync

Obietnica --syncinternaldates (i gdzie się zatrzymuje)

Uruchomiliście polecenie imapsync. Dodaliście --syncinternaldates, bo przeczytaliście dokumentację i podeszliście do tego odpowiedzialnie. Migracja się zakończyła, log mówi, że wszystko przeniesione, zero błędów. Potem otwieracie skrzynkę w Outlooku i każdy e-mail pokazuje wczorajszą datę.

To jedna z najczęstszych frustracji związanych z imapsync i myli ona administratorów systemów co najmniej od 2017 roku. Flaga --syncinternaldates ma zachowywać IMAP INTERNALDATE podczas migracji. I rzeczywiście to robi: nadaje każdej kopii wewnętrzną datę, którą przechowuje serwer źródłowy. Właśnie tam kryje się pułapka.

imapsync to narzędzie open source w Perlu napisane przez Gilles'a Lamirala i naprawdę dobrze robi to, do czego zostało stworzone. Obsługuje transfery skrzynek IMAP-do-IMAP z niezawodnością, której zazdrości większość komercyjnych narzędzi. Ale imapsync może skopiować tylko te daty, które znajdzie na serwerze źródłowym, i tu sprawy się komplikują.

Jak naprawdę działają daty IMAP

W każdym e-mailu istnieją trzy różne "daty" i większość ludzi (włącznie z niektórymi administratorami IT) je myli:

Nagłówek Date: (RFC 2822) - data, którą klient e-mail nadawcy umieścił na wiadomości podczas tworzenia. Żyje wewnątrz treści wiadomości i nigdy nie jest modyfikowany przez serwery pocztowe.
Nagłówki Received: - każdy serwer pocztowy obsługujący wiadomość dodaje jeden z własnym znacznikiem czasu. Tworzą łańcuch od nadawcy do odbiorcy. Najwyższy (najnowszy) nagłówek Received to ten, który niektóre klienty e-mail używają do wyświetlania.
INTERNALDATE - serwerowy znacznik czasu IMAP kontrolujący kolejność sortowania wiadomości w skrzynce. Ustawiany przy pierwszym zapisie przez IMAP APPEND.

Gdy imapsync przenosi wiadomość, czyta ją z serwera źródłowego (włącznie z INTERNALDATE) i zapisuje na serwerze docelowym przez IMAP APPEND. Flaga --syncinternaldates mówi imapsync, żeby przekazał źródłowy INTERNALDATE do serwera docelowego podczas APPEND.

Dobra wiadomość: Microsoft 365, Outlook.com i Gmail zachowują datę, którą otrzymują. Gdy więc daty wychodzą błędne, problem leży gdzie indziej.

Dlaczego daty mogą być mimo to błędne

Serwery IMAP z rodziny Dovecot zwykle również zachowują datę z APPEND. Niezależnie więc od serwera docelowego, pytanie jest to samo: jaką datę przechowywało źródło? Microsoft 365, Outlook.com i Gmail zachowują ją: kopia, która niesie swoją oryginalną datę, ją zatrzymuje.

To, co przekazuje imapsync, to jednak data, którą serwer ŹRÓDŁOWY przechowuje dla każdej wiadomości, nie data jej wysłania. W zdrowej skrzynce te dwie daty się zgadzają. W skrzynce, która była już wcześniej migrowana albo przywrócona z kopii zapasowej, źródło może przechowywać datę tamtej wcześniejszej operacji, a imapsync wiernie ją kopiuje.

Gmail jest osobnym przypadkiem tylko wtedy, gdy kopia przechodzi przez własne API importu Gmaila, a nie przez IMAP: to API dodaje linię Received: z datą dnia kopiowania, a Outlook może wyświetlić właśnie tę datę. imapsync mówi protokołem IMAP, więc go to nie dotyczy.

Częste błędy w poleceniach imapsync (i błędne obwinianie)

Kopiowanie ze źródła, którego daty już były błędne

Flaga --syncinternaldates jest włączona domyślnie: imapsync nadaje każdej kopii wewnętrzną datę, którą przechowuje serwer źródłowy (jej dokumentacja mówi: "Sets the internal dates on host2 as the same as host1"). Jeśli skrzynka źródłowa sama jest wynikiem wcześniejszej migracji albo przywrócenia z kopii zapasowej, jej wewnętrzne daty mogą już być datami tamtej operacji, a imapsync wiernie kopiuje błędną datę. To najczęstsza przyczyna, i najłatwiej ją przeoczyć, bo log pokazuje dwie identyczne daty.

Użycie --syncinternaldates z --addheader

Dodanie nagłówka modyfikuje wiadomość (o jedną linię więcej na początku), ale nie zmienia daty, którą przekazuje imapsync, więc to nie wyjaśnia błędnych dat. Kopia po prostu nie jest już identyczna z oryginałem, co ma znaczenie, jeśli porównujecie te dwie wersje.

Mylenie --minage i --maxage z zachowaniem dat

Te flagi filtrują wiadomości do migracji po wieku. Nie wpływają na obsługę dat po stronie docelowej.

Obwinianie TLS o przesunięte daty

Przy migracji przez TLS z --ssl1 i --ssl2 ustanawianie połączeń dodaje opóźnienie, które przy dużej migracji (50 000+ wiadomości) narasta do wielu godzin. Na daty to nie wpływa: każda kopia niesie datę, którą przekazuje imapsync, niezależnie od tego, o której faktycznie trafia do celu.

Czytanie logów imapsync: co naprawdę mówi wynik

To jedna z najbardziej frustrujących stron debugowania problemów z datami: czysty log, dwie identyczne daty, a mimo to błędna data w Outlooku, bo błąd powstał zanim imapsync w ogóle zaczął działać.

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Jeśli zwrócona data nie jest datą wysłania e-maila, sprawdź tę samą wiadomość w źródle: znajdziesz tam tę samą błędną datę. Log nie skłamał, po prostu skopiował to, co otrzymał. A Microsoft 365, Outlook.com i Gmail zachowują datę, którą otrzymują. Ale dwie identyczne daty dowodzą tylko, że kopia jest wierna ŹRÓDŁU: jeśli data źródłowa już była błędna, obie kolumny pokazują tę samą błędną datę.

Migracje imapsync na dużą skalę

Migracja pojedynczej skrzynki z imapsync jest irytująca gdy daty się psują. Ale MSP i działy IT uruchamiające imapsync na setkach skrzynek mierzą się z zupełnie inną skalą problemu.

Typowy scenariusz korporacyjny: przenosicie 200 skrzynek z serwera Zimbra do Microsoft 365. Piszecie skrypt wrapper przetwarzający CSV użytkowników i testujecie go flagą --dry, ale --dry tylko symuluje transfer: pokazuje daty, które imapsync by przekazał, nie to, czy są to daty faktycznego wysłania e-maili. Nic nie ostrzega, że daty źródłowe są już błędne. Migracja działa przez weekend, a jeśli problemem były daty w źródle, drugie uruchomienie skopiuje te same błędne daty ponownie. W poniedziałek rano macie 200 skrzynek z błędnymi datami i łącznie 1,2 miliona e-maili noszących datę migracji. Czy wystarczy po prostu ponownie uruchomić imapsync, aby to naprawić?

Samodzielne naprawy i ich ograniczenia

Szukając na forach i listach mailingowych znajdziecie sugestie od kreatywnych po niebezpieczne. Wszystkie mają te same fundamentalne problemy: jak obsłużyć S/MIME, zagnieżdżone MIME, RFC 2047, PGP? Skrypt działający na 50 testowych wiadomościach nie wytrzyma starcia z produkcyjną skrzynką 30 000 wiadomości.

Jak Redate.io naprawia daty po imapsync

Oryginalny nagłówek Date: jest zawsze nienaruszony po migracji imapsync. imapsync wiernie przenosi surową wiadomość; błędna data znajduje się w metadanych, które otrzymała kopia, a nie w samej wiadomości.

Redate.io łączy się bezpośrednio ze skrzynką pocztową (Google Workspace, Microsoft 365 lub dowolny serwer IMAP), skanuje e-maile, których wyświetlana data nie zgadza się z ich oryginalną datą, niezależnie od narzędzia, które przeprowadziło migrację, i stosuje celowaną korektę metadanych.

Każdy poprawiony e-mail jest weryfikowany indywidualnie. Oryginały przechowywane są w widocznym folderze Redate.io - Originals do momentu ich samodzielnego usunięcia.

Darmowe skanowanie łączy się ze skrzynką, identyfikuje każdy e-mail z anomalią daty i raportuje dokładną liczbę i koszt. Bez karty kredytowej, bez instalacji oprogramowania:

Redate.io działa również na migracjach sprzed miesięcy lub lat. Nagłówek Date: nie wygasa, podobnie jak możliwość naprawy.

Migrowaliście z imapsync i utknęliście z błędnymi datami? Uruchomcie darmowe skanowanie, aby zobaczyć ile e-maili jest dotkniętych.

imapsync: daty nie zachowane? Jak je naprawić