Naprawa dat imapsync

Obietnica --syncinternaldates (i dlaczego się nie sprawdza)

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. Technicznie rzeczywiście próbuje. Ale "próbuje" robi w tym zdaniu bardzo dużo pracy.

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 zachowanie dat nie zależy wyłącznie od imapsync 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.

Problem: serwer docelowy nie jest zobowiązany do honorowania tej daty.

Dlaczego serwery docelowe ignorują INTERNALDATE

Specyfikacja IMAP (RFC 3501) mówi, że jeśli z poleceniem APPEND podano datę-czas, serwer POWINIEN jej użyć. "SHOULD" w języku RFC oznacza "rób to, chyba że masz dobry powód, żeby nie". Kilka dużych platform pocztowych zdecydowało, że ma dobry powód.

Microsoft 365 to największy winowajca. Gdy wiadomość przychodzi przez IMAP APPEND, pipeline transportowy Exchange dodaje nowy nagłówek Received z bieżącą datą, a następnie ustawia INTERNALDATE na podstawie tego znacznika dostarczenia. Bez znaczenia, jakiej daty zażądał imapsync. Serwer M365 ją nadpisuje.

Google Workspace (Gmail) zachowuje się inaczej, ale też może powodować problemy. Implementacja IMAP Gmaila w większości przypadków honoruje INTERNALDATE z APPEND, ale dodaje własny nagłówek Received. Jeśli klient e-mail priorytetyzuje nagłówki Received nad INTERNALDATE do wyświetlania (a Outlook dokładnie to robi), daty i tak wyglądają źle.

Częste błędy wiersza poleceń imapsync psujące daty

Zapomnienie o --syncinternaldates

Flaga nie jest włączona domyślnie. Bez niej imapsync nawet nie próbuje zachowywać dat.

Użycie --syncinternaldates z --addheader

Dodawanie nagłówków modyfikuje wiadomość, co może spowodować, że serwer docelowy potraktuje ją jako "nową".

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.

Opóźnienia negocjacji SSL powodujące dryft znaczników czasu

Przy migracji przez TLS z --ssl1 i --ssl2 setup połączenia dodaje opóźnienie, które w dużych migracjach się kumuluje.

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

imapsync generuje szczegółowe logi. Ale w kwestii dat wynik może być mylący.

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

Obie daty się zgadzają. To oznacza, że imapsync wysłał prawidłowy INTERNALDATE do celu. Ale nie oznacza, że serwer docelowy faktycznie zapisał tę datę. imapsync raportuje to, o co poprosił, nie to, co zaakceptował serwer.

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. Migracja działa przez weekend. W poniedziałek rano macie 200 skrzynek z zepsutymi datami i łącznie 1,2 miliona e-maili ze znacznikiem migracji.

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ść; problem wyświetlania powoduje obsługa metadanych przez serwer docelowy.

Redate.io łączy się bezpośrednio ze skrzynką pocztową (Google Workspace, Microsoft 365 lub dowolny serwer IMAP), skanuje e-maile z anomaliami dat i stosuje celowaną korektę metadanych przez zastrzeżony pipeline analizy łańcucha nagłówków i rekonstrukcji dat.

Każdy poprawiony e-mail jest weryfikowany indywidualnie. Oryginały przechowywane są w widocznym folderze Redate.io - Originals przez 30 dni.

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ć