Migracja cPanel: błędne daty e-maili

Poniedziałkowy poranek, którego nikt nie chce

Właśnie zakończono migrację ze współdzielonego hostingu cPanel do Google Workspace lub Microsoft 365. Wszystko przebiegło sprawnie, skrzynki są dostępne, użytkownicy się logują. Potem, około 9:15, wpada pierwszy ticket: "Stare e-maile pokazują tę samą datę - z ubiegłego weekendu." Potem drugi. Potem dziesięć.

To nie jest pojedynczy błąd. To bezpośrednia konsekwencja tego, jak migracje z cPanel traktują (a raczej nie traktują) metadanych daty e-maili.

cPanel, Roundcube, Horde: specyficzny kontekst IMAP

Hosting współdzielony na cPanel to serwer Linux z Dovecot jako serwerem IMAP i Roundcube lub Horde jako interfejsem webmail. Nic egzotycznego. Ale ten kontekst ma kilka właściwości, które sprawiają, że migracje na platformy enterprise są bardziej skomplikowane, niż wyglądają na pierwszy rzut oka.

Po pierwsze, skrzynki na cPanel często gromadzą e-maile przez całe lata, a niekiedy przez dekadę. Klient, który hostował swoją domenę na współdzielonym serwerze od 2013 roku, może mieć bardzo głębokie archiwa. Taka objętość, połączona ze sposobem przeprowadzania migracji, tworzy idealne warunki do problemu z datami.

Po drugie, narzędzia używane do tych migracji to zazwyczaj albo wbudowane narzędzie cPanel ("Migrations" w WHM), albo imapsync uruchamiany z linii poleceń przez dostawcę hostingu lub firmę IT, albo rozwiązania konsumenckie, jak GSMMO do migracji do Google Workspace.

Dlaczego daty są uszkodzone po migracji cPanel

Żeby zrozumieć problem, trzeba poznać dwa odrębne pojęcia: nagłówek Date: w e-mailu oraz INTERNALDATE w IMAP.

Nagłówek Date: jest zapisany w surowej treści wiadomości w chwili jej wysłania, zgodnie ze standardem RFC 2822. Wskazuje, kiedy e-mail został napisany i wysłany. Ten nagłówek nigdy się nie zmienia, chyba że ktoś celowo zmodyfikuje wiadomość.

INTERNALDATE to z kolei metadana, którą serwer IMAP przypisuje do każdej przechowywanej wiadomości. Jest ona odrębna od treści wiadomości. Kiedy e-mail normalnie trafia na serwer, INTERNALDATE jest ustalany na podstawie nagłówków Received: wiadomości lub daty dostarczenia, jeśli wiadomość jest złożona bezpośrednio. To właśnie tę wartość Outlook, Thunderbird i większość klientów pocztowych używa do sortowania wiadomości.

Podczas migracji IMAP wiadomości są kopiowane z jednego serwera na drugi. Problem polega na tym, że narzędzie migracyjne musi na nowo stworzyć każdą wiadomość na serwerze docelowym. W przypadku wielu narzędzi INTERNALDATE nowo utworzonej wiadomości odpowiada dacie migracji, a nie oryginalnej dacie wiadomości. Jednocześnie do łańcucha nagłówków dodawany jest nowy nagłówek Received: opatrzony datą migracji, co jeszcze bardziej dezorientuje klientów pocztowych odwołujących się do niego przy wyświetlaniu daty.

Efekt: e-mail z 2019 roku trafia do Google Workspace z INTERNALDATE ustawionym na dzień migracji i nagłówkiem Received: datowanym na wczoraj. Outlook wyświetla go w skrzynce odbiorczej jak świeżo odebraną wiadomość. Cała chronologia archiwum zostaje zniszczona.

Narzędzie migracji WHM / cPanel

Narzędzie wbudowane w WHM do migracji kont cPanel na inną platformę generuje ten problem niemal systematycznie, gdy miejscem docelowym jest zewnętrzny serwer IMAP (Google Workspace, Microsoft 365). Kopiuje zawartość katalogów Maildir na nowy serwer przez IMAP APPEND bez zachowania oryginalnego INTERNALDATE. Każda wiadomość otrzymuje tym samym znacznik czasu z momentu wykonania operacji.

imapsync i migracje manualne z cPanel

imapsync to potężne narzędzie, ale jego domyślne zachowanie nie zawsze zachowuje daty. Bez odpowiednich parametrów (i właściwej wersji) może spokojnie skopiować 40 000 wiadomości, przypisując każdej datę wykonania skryptu. (Swoją drogą, jeśli ktokolwiek przeglądał logi imapsync linijka po linijce, diagnozując problem z datami na skrzynce z 25 000 wiadomości, wie, że to doświadczenie, którego się nie pragnie powtórzyć.)

Żeby być precyzyjnym: imapsync posiada opcje pozwalające próbować zachować datę, ale te opcje działają różnie w zależności od kombinacji serwerów źródłowych i docelowych, a ich skuteczność nie jest gwarantowana we wszystkich konfiguracjach cPanel / Dovecot.

GSMMO i narzędzia konsumenckie

Google Workspace Migration for Microsoft Outlook (GSMMO) jest przeznaczony do migracji z Outlooka, nie z gołego serwera IMAP. Gdy jest używany do migracji z cPanel (przez konto IMAP skonfigurowane w Outlooku), daty przechodzą przez to samo przetwarzanie: INTERNALDATE w Google Workspace jest ustawiany na datę migracji. Problem GSMMO z datami e-maili jest zresztą opisany oddzielnie, tak szeroko jest rozpowszechniony.

Które klienty pocztowe są dotknięte?

Uszkodzenie dat nie objawia się tak samo w każdym kliencie pocztowym.

Outlook jest najbardziej narażony. Używa INTERNALDATE (lub nagłówka Received: migracji) jako głównego kryterium sortowania w folderach. Po niestarannie przeprowadzonej migracji z cPanel skrzynka w Outlooku może wyświetlać tysiące zarchiwizowanych e-maili z datą weekendu migracyjnego. Naprawa dat imapsync w Outlooku to jedno z najczęściej zgłaszanych zapytań.

Gmail (Google Workspace) na ogół wyświetla w liście wiadomości datę z nagłówka Date:, ale sortowanie może mimo to być zaburzone przez INTERNALDATE w pewnych przypadkach. Użytkownicy zgłaszają nieregularne zachowanie podczas wyszukiwania i sortowania po dacie.

Apple Mail i Thunderbird mają bardziej złożone zachowanie, ale żaden z nich nie jest odporny na ten problem, szczególnie gdy nagłówek Received: z migracji jest na szczycie łańcucha.

Dobra wiadomość: oryginalna data wciąż tam jest

To techniczna kwestia, która zmienia wszystko. Oryginalny nagłówek Date: wiadomości jest zapisany w surowej treści e-maila. Migracja go nie dotyka. Gdy otworzy się dotknięty problem e-mail i spojrzy na surowe nagłówki (w Gmailu: "Pokaż oryginał", w Outlooku: Plik > Właściwości), widać nienaruszony oryginalny Date:, po którym następuje jeden lub kilka nagłówków Received:, a pierwszy z nich nosi datę migracji.

Ta informacja jest zawsze dostępna. Można ją wykorzystać do korekty metadanych. To dokładnie to, co robi silnik korekcji Redate.io.

Dlaczego "naprawienie tego samodzielnie" jest bardziej ryzykowne, niż się wydaje

Pokusa jest silna. Problem wydaje się prosty: odczytać oryginalną datę, poprawić metadane, przejść do następnej wiadomości. Ale między zrozumieniem mechanizmu a poprawieniem 12 000 e-maili na produkcji bez utraty jednego jest ogromna przepaść.

Kilka realiów, których domowe skrypty zazwyczaj nie uwzględniają:

E-maile podpisane S/MIME lub zaszyfrowane PGP: jakakolwiek modyfikacja struktury wiadomości unieważnia podpis kryptograficzny. E-mail, który przed korektą przechodził weryfikację podpisu, po niej jej nie przejdzie. Użytkownicy w środowiskach regulowanych (kancelarie prawne, sektor finansowy, ochrona zdrowia) odkrywają ten problem w najgorszym możliwym momencie.
Nagłówki nie-ASCII i kodowanie RFC 2047: skrzynki na cPanel gromadzą latami e-maile wysyłane przez bardzo różne klienty pocztowe. Niektóre nagłówki zawierają znaki zakodowane zgodnie z RFC 2047. Źle napisany skrypt, który odbudowuje nagłówki, może niewidocznie uszkodzić te kodowania.
Zagnieżdżone struktury MIME: e-mail z trzema załącznikami i alternatywną treścią HTML ma złożoną strukturę multipart. Najmniejszy błąd przy granicach MIME sprawia, że wiadomość staje się nieczytelna, lub gorzej: załączniki znikają bez żadnego komunikatu o błędzie.
Limity API i rate limiting: Google Workspace i Microsoft 365 narzucają ścisłe limity liczby operacji IMAP na minutę. Skrypt, który nie implementuje poprawnie wykładniczego backoff, wywołuje błędy 429 o 3 w nocy, a rano okazuje się, że migracja jest w połowie i nie wiadomo dokładnie, gdzie się zatrzymała.
Brak możliwości cofnięcia zmian: jeśli coś pójdzie nie tak w połowie drogi, do jakiego stanu można wrócić? Czy oryginały nadal istnieją? Czy są duplikaty? Redate.io przechowuje oryginały w widocznym folderze kopii zapasowych przez 30 dni, właśnie po to, żeby nigdy nie znaleźć się w takiej sytuacji.

Skrypt, który działa na 50 testowych e-mailach w środowisku deweloperskim, niekoniecznie zadziała na 18 000 wiadomościach produkcyjnej skrzynki odziedziczonej po hostingu cPanel z 2011 roku.

Jak Redate.io naprawia daty po migracji cPanel

Redate.io łączy się bezpośrednio ze skrzynką docelową (Google Workspace przez delegację domeny, Microsoft 365 przez Azure AD lub bezpośrednio z serwerem IMAP) i rozpoczyna od bezpłatnego skanu, który identyfikuje e-maile, których metadane daty są niespójne z oryginalnym nagłówkiem Date:.

Następnie wieloetapowy pipeline analizy stosuje dopasowywanie wzorców na sygnaturach nagłówków Received:, żeby wskazać te wprowadzone przez narzędzia migracyjne (i odróżnić je od legalnych nagłówków). Ukierunkowana korekta metadanych odbywa się bez żadnych modyfikacji treści wiadomości: tekst, załączniki, oryginalne nagłówki - wszystko pozostaje nienaruszone. Każdy poprawiony e-mail jest weryfikowany indywidualnie przed zatwierdzeniem operacji.

W przypadku migracji z cPanel silnik rozpoznaje typowe sygnatury migracji Dovecot-do-IMAP oraz skryptów imapsync, w tym warianty konfiguracji powszechnie stosowane przez europejskich dostawców hostingu współdzielonego.

Przewodniki według docelowej platformy

W zależności od platformy docelowej migracji z cPanel, poniższe przewodniki opisują konkretne kroki:

Przeprowadzono migrację z cPanel i użytkownicy widzą błędne daty? Uruchom bezpłatny skan na Redate.io, żeby sprawdzić dokładnie, ile e-maili jest dotkniętych problemem, bez żadnych modyfikacji przed udzieleniem zgody.

Błędne daty e-maili po migracji cPanel / Roundcube