Листи з невірними датами після міграції з 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, який запускається з командного рядка хостинг-провайдером або ІТ-консультантом, або споживчі рішення, як 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 на новий сервер без збереження оригінального 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 виробничих листів без втрати жодного з них.

Кілька реалій, які самописні скрипти зазвичай не враховують:

Скрипт, який працює на 50 тестових листах у середовищі розробки, не обов'язково витримає 18 000 повідомлень у виробничій поштовій скриньці, успадкованій від облікового запису cPanel, що працює з 2011 року.

Як Redate.io виправляє дати після міграції з cPanel

Redate.io підключається безпосередньо до поштової скриньки призначення (Google Workspace, Microsoft 365 через простий вхід, або прямий IMAP) і починає з безкоштовного сканування, щоб виявити листи, метадані дат яких не відповідають оригінальному заголовку Date:.

Багатоетапний конвеєр аналізу потім застосовує зіставлення шаблонів до сигнатур заголовків Received:, щоб виявити ті, що були додані інструментами міграції (і відрізнити їх від законних заголовків). Цілеспрямоване виправлення метаданих застосовується без зміни вмісту листа: текст тіла, вкладення, оригінальні заголовки - все залишається недоторканим. Кожен виправлений лист перевіряється окремо, перш ніж операція буде підтверджена.

Для міграцій з cPanel зокрема, механізм розпізнає типові сигнатури міграцій Dovecot-в-IMAP та скриптів imapsync, включно з варіантами конфігурації, поширеними серед провайдерів спільного хостингу.

Спеціальні посібники за платформою призначення

Залежно від того, куди потрапила ваша міграція з cPanel, ці посібники охоплюють точні кроки:

Мігрували з cPanel, і ваші користувачі бачать неправильні дати? Запустіть безкоштовне сканування на Redate.io, щоб дізнатися, скільки саме листів це стосується, без жодних змін до вашого підтвердження.