Миграция cPanel: грешни дати

Понеделникът, от който боли главата

Току-що сте финализирали миграцията от споделен хостинг с cPanel към Google Workspace или Microsoft 365. Всичко е минало добре, пощенските кутии са достъпни, потребителите се свързват. После, към 9:15, пада първият тикет: "Старите ми имейли показват всички една и съща дата - тази от изминалия уикенд." После втори. После десет.

Това не е изолиран бъг. Това е пряка последица от начина, по който миграциите от cPanel обработват (или по-скоро не обработват) метаданните за дата на имейлите.

cPanel, Roundcube, Horde: особен IMAP контекст

Споделеният хостинг с cPanel е Linux сървър, който изпълнява IMAP сървър (обикновено Dovecot) с Roundcube или Horde като уеб поща. Нищо екзотично в това. Но този контекст има няколко особености, които правят миграциите към корпоративни платформи по-сложни, отколкото изглеждат на пръв поглед.

На първо място, пощенските кутии в cPanel натрупват имейли с години, понякога цяло десетилетие. Клиент, хостил домейна си при споделен доставчик от 2013 г., може да има много дълбоки архиви. Този обем, комбиниран с начина на извършване на миграцията, създава плодородна почва за проблема с датите.

На второ място, инструментите за тези миграции са обикновено или вграденият инструмент на cPanel ("Migrations" в WHM), или imapsync, стартиран от командния ред от хостинг доставчика или IT изпълнителя, или решения за широка публика като GSMMO за миграция към Google Workspace.

Защо датите се повреждат след миграция от cPanel

За да разберем проблема, трябва да схванем два различни концепта: заглавието Date: на имейла и IMAP INTERNALDATE.

Заглавието Date: се записва в суровото тяло на съобщението в момента на изпращането му, съгласно RFC 2822. То указва кога имейлът е бил написан и изпратен. Това заглавие никога не се променя, освен при умишлена манипулация на съобщението.

INTERNALDATE пък е метаданна, която IMAP сървърът свързва с всяко съхранено съобщение. Тя е отделна от съдържанието на съобщението. Когато имейл пристига нормално на сървър, INTERNALDATE се определя от заглавията Received: на съобщението или от датата на депозиране, ако съобщението е подадено директно. Тази стойност е тази, която Outlook, Thunderbird и повечето имейл клиенти използват за сортиране на съобщенията.

При IMAP миграция съобщенията се копират от един сървър на друг. Проблемът: инструментът за миграция трябва да създаде всяко съобщение на сървъра на местоназначение. И при много инструменти INTERNALDATE на новосъздаденото съобщение съответства на датата на миграцията, не на оригиналната дата на съобщението. Успоредно с това, заглавие Received: с времеви печат от датата на миграцията се добавя в началото на веригата от заглавия, което допълнително обърква имейл клиентите, използващи го за изчисляване на показваната дата.

Резултатът: имейл от 2019 г. пристига в Google Workspace с INTERNALDATE, зададен за деня на миграцията, и заглавие Received: с вчерашна дата. Outlook го показва в пощенската кутия сякаш току-що е пристигнал. Цялата хронология на архива е унищожена.

Инструментът за миграция WHM / cPanel

Вграденият инструмент в WHM за миграция на cPanel акаунти към друга платформа генерира този проблем почти систематично, когато дестинацията е външен IMAP сървър (Google Workspace, Microsoft 365). Той копира съдържанието на Maildir директориите на новия сървър чрез IMAP без да запазва оригиналния INTERNALDATE. Всяко съобщение получава времевия печат на момента на операцията.

imapsync и ръчните миграции от cPanel

imapsync е мощен инструмент, но поведението му по подразбиране не винаги запазва датите. Без правилните параметри (и правилната версия) може съвсем спокойно да копира 40 000 съобщения, присвоявайки им на всички датата на изпълнение на скрипта. (Ако сте четели логовете на imapsync ред по ред, за да диагностицирате проблем с дати в кутия с 25 000 съобщения, знаете, че това е преживяване, което не искате да повторите.)

За да сме точни: imapsync разполага с опции за опит за запазване на датата, но тези опции взаимодействат по различен начин в зависимост от изходния и целевия сървър, и тяхната ефективност не е гарантирана при всички конфигурации cPanel / Dovecot.

GSMMO и инструментите за широка публика

Google Workspace Migration for Microsoft Outlook (GSMMO) е предназначен за миграция от Outlook, не от голи IMAP сървъри. Когато се използва за миграция от cPanel (чрез IMAP акаунт, конфигуриран в Outlook), датите претърпяват същото третиране: INTERNALDATE в Google Workspace се задава на датата на миграцията. Проблемът с GSMMO и датите на имейлите е документиран отделно, толкова е разпространен.

Кои имейл клиенти са засегнати?

Повреждането на датите не се проявява по един и същи начин в зависимост от използвания клиент.

Outlook е най-засегнатият клиент. Той използва INTERNALDATE (или заглавието Received: от миграцията) като основен критерий за сортиране в папките. След лошо управлявана миграция от cPanel, кутия в Outlook може да показва хиляди архивирани имейли с датата на уикенда на миграцията. Коригирането на датите от imapsync в Outlook е едно от най-търсените решения.

Gmail (Google Workspace) обикновено показва датата от заглавието Date: в списъка с имейли, но сортирането пак може да бъде повлияно от INTERNALDATE в определени случаи. Потребителите съобщават за непредсказуемо поведение при търсене и сортиране по дата.

Apple Mail и Thunderbird имат по-нюансирано поведение, но нито единият, нито другият са имунизирани срещу проблема, особено когато заглавието Received: от миграцията е в началото на веригата.

Добрата новина: оригиналната дата е все още там

Това е техническият детайл, който променя всичко. Оригиналното заглавие Date: на съобщението е записано в суровото тяло на имейла. Миграцията не го докосва. Когато отворите засегнат имейл и прегледате суровите заглавия (в Gmail: "Покажи оригинала", в Outlook: Файл > Свойства), виждате оригиналния Date: непокътнат, последван от едно или повече заглавия Received:, чието първо носи датата на миграцията.

Тази информация е винаги налична. Тя може да бъде използвана за коригиране на метаданните. Точно това прави двигателят за корекция на Redate.io.

Защо "да го оправя сам" е по-рисковано, отколкото изглежда

Изкушението е голямо. Проблемът изглежда прост: прочети оригиналната дата, коригирай метаданните, мини към следващия. Но между разбирането на механизма и коригирането на 12 000 имейла в продукция без да изгубиш нито един, разликата е огромна.

Няколко реалности, които домашните скриптове обикновено не предвиждат:

S/MIME подписани или PGP криптирани имейли: всяка промяна в структурата на съобщението прави криптографския подпис невалиден. Имейл, преминавал проверката на подписа преди корекцията, вече не я преминава след нея. Потребителите в регулаторно-съответствена среда (адвокатски кантори, финансов сектор, здравеопазване) откриват този проблем в най-лошия момент.
Non-ASCII заглавия и RFC 2047 кодиране: пощенските кутии в cPanel натрупват години имейли от много разнообразни имейл клиенти. Някои заглавия съдържат символи, кодирани по RFC 2047. Лошо написан скрипт, който реконструира заглавията, може да повреди тези кодирания по незабележим начин.
Вложени MIME структури: имейл с три прикачени файла и алтернативно HTML тяло има сложна multipart структура. Най-малката грешка в MIME границите прави съобщението нечетимо, или по-лошо: прикачените файлове изчезват без съобщение за грешка.
API квоти и rate limiting: Google Workspace и Microsoft 365 налагат строги ограничения върху броя IMAP операции в минута. Скрипт, който не реализира правилно exponential backoff, задейства грешки 429 в 3 сутринта, и се събуждате с наполовина завършена миграция, без да знаете точно къде се е спряла.
Невъзможен rollback: ако нещо се обърка по средата, към какво състояние се връщате? Оригиналите там ли са още? Имате ли дубликати? Redate.io запазва оригиналите в видима резервна папка за 30 дни, именно за да не попадате никога в тази ситуация.

Скрипт, работещ с 50 тестови имейла в dev среда, не е задължително да работи с 18 000 съобщения от продукционна кутия, наследена от cPanel хостинг от 2011 г.

Как Redate.io коригира датите след миграция от cPanel

Redate.io се свързва директно с пощенската кутия на дестинацията (Google Workspace чрез domain delegation, Microsoft 365 чрез Azure AD, или директен IMAP сървър) и започва с безплатно сканиране за идентифициране на имейлите, чиито метаданни за дата са несъвместими с оригиналното заглавие Date:.

Многоетапният анализ прилага съпоставяне на шаблони върху подписите на заглавията Received:, за да идентифицира тези, въведени от инструментите за миграция (и да ги различи от легитимните заглавия). Целевата корекция на метаданните се извършва без изменение на съдържанието на съобщението: текстът, прикачените файлове, оригиналните заглавия - всичко остава непокътнато. Всеки коригиран имейл се проверява индивидуално, преди операцията да бъде потвърдена.

За миграции специфично от cPanel, двигателят разпознава типичните подписи на миграции от Dovecot към IMAP и на imapsync скриптове, включително честите конфигурационни варианти при споделените хостинг доставчици.

Специфични ръководства според вашата дестинация

В зависимост от целевата платформа на вашата миграция от cPanel, следните ръководства описват точните стъпки:

Мигрирахте от cPanel и потребителите ви виждат грешни дати? Стартирайте безплатно сканиране в Redate.io, за да установите точно колко имейла са засегнати, без никакви промени преди вашето съгласие.

Грешни дати след миграция от cPanel | Redate.io