Перенос почты между хостингами: IMAP, папки и проверка

Перенести почту с одного хостинга на другой кажется просто, пока первый ящик не импортируется дважды, а у сотрудника не исчезает история отправленных писем. Многие руководства обходят именно этот момент. Они обращаются с почтой как с файлами, хотя перенос ящика устроен сложнее.

Вы копируете изменяющиеся данные IMAP между двумя серверами с разными правилами папок, поведением UID и представлениями о том, где должны храниться отправленные письма. Неверное предположение может привести к пустым на вид папкам, повторяющимся перепискам и почте, распределенной между старой и новой системами.

Нужны не надежды, а поэтапный перенос IMAP, четкое сопоставление папок и тщательная проверка после переключения. Если сначала требуется спланировать выбор провайдера, расходы и контроль над инфраструктурой, прочитайте руководство по деловой почте. Эта статья посвящена самому переносу.

При переходе на TrekMail начните с актуального обзора миграции IMAP, затем выберите инструкцию для Gmail или cPanel по исходному серверу. Источник описывает серверную миграцию IMAP в платных тарифах от $3.50 в месяц, бесплатный Nano без банковской карты и бесплатный пробный период на 14 дней для платных планов. Перед работой проверьте нынешние цены, доступность функций и условия пробного периода.

Что происходит при переносе почты между хостингами?

Коротко: инструмент IMAP подключается к старому ящику, читает папки и сообщения, затем копирует их в новый. Он не обязательно автоматически нормализует имена папок, устраняет дубли в исходных данных или предотвращает ошибки во времени переключения DNS. Для этого нужны отдельные шаги процесса.

Миграция IMAP копирует данные между двумя почтовыми системами. При чистом копировании исходный аккаунт сохраняется. В целевом появляются копии сообщений, папки и, в зависимости от инструмента и данных провайдера, флаги вроде «прочитано» или «не прочитано». Контакты, календари и правила в такое копирование не входят. Основной риск связан с тем, как системы распознают сообщения.

В описанной в RFC 3501 модели IMAP у каждой папки есть UID сообщений и значение UIDVALIDITY. UID действителен лишь внутри этой папки при соответствующем UIDVALIDITY, а не глобально или на другом сервере. Инструмент может использовать эти значения вместе с сохраненным сопоставлением. При изменении состояния некоторые способы синхронизации перестают узнавать ранее скопированные письма.

Поэтому первый проход может выглядеть успешным, а следующий создать проблемы. Не объявляйте пользователям перенос завершенным только потому, что панель показывает статус «завершено».

Почему при смене хостинга появляются дубли

Коротко: дубли могут возникать, когда инструмент теряет надежное сопоставление сообщений. Возможные причины: изменение UIDVALIDITY, повторное создание целевых папок или обработка ярлыков Gmail как обычных папок. В зависимости от метода сравнения уже скопированная почта воспринимается как новая и импортируется повторно.

Ловушка UIDVALIDITY

Некоторые инструменты сохраняют сопоставление UID внутри папок. Переиндексация сама по себе не обязательно меняет UID. Однако создание папки заново, изменение UIDVALIDITY или потеря состояния инструмента могут нарушить прежний учет. Не все программы работают одинаково: imapsync обычно сравнивает Message-Id и Received, а сопоставление UID использует при соответствующем режиме и с локальным кешем, не как равенство идентификаторов разных серверов.

Описанное в RFC 3501 правило требует стабильности UID при неизменном UIDVALIDITY и обнаружимости изменений. При смене UIDVALIDITY сохраненное сопоставление UID нельзя считать надежным без повторной проверки. Если подходящего сравнения сообщений нет, новый проход может снова импортировать тысячи писем.

Пример: первый проход копирует 38,000 сообщений из входящих. Администратор запускает задачу снова после тайм-аута. За ночь исходную или целевую папку создали заново. Инструмент не может использовать старое сопоставление UID и при определенном режиме копирует еще 38,000 сообщений.

Особенности ярлыков Gmail

Gmail требует отдельного подхода, поскольку его ярлыки не эквивалентны обычным папкам IMAP. Письмо может иметь несколько ярлыков, а архивированные письма находятся в «Вся почта». Справка Google описывает множественные ярлыки и то, что архивирование убирает письмо из входящих, сохраняя его во «Всей почте».

Если без плана импортировать [Gmail]/All Mail вместе с папками ярлыков, одно письмо может оказаться в нескольких целевых папках. Это увеличивает занятое место и может запутывать пользователей. Но такие копии могут быть и намеренным отображением ярлыков. Заранее согласуйте, какая структура нужна в новом ящике.

Для ручного переноса полезна инструкция TrekMail по импорту из Gmail, описывающая исходный доступ. Пароль приложения доступен не для каждого аккаунта: важны двухэтапная проверка и политика организации. Документированный прямой импорт TrekMail использует имя пользователя и пароль IMAP, а не интерактивный OAuth. Если допустимые прямые учетные данные недоступны, рассмотрите другой инструмент с OAuth или поддерживаемый способ провайдера.

Для командной строки ниже приведен пример проверочного запуска, а не универсальная готовая команда переноса:

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

Проверочный запуск не копирует письма и не проверяет весь будущий перенос содержимого. Message-ID не всегда присутствует или уникален, поэтому одного этого заголовка может быть недостаточно. Исключение «Всей почты» способно пропустить архивированные письма без других импортируемых ярлыков: отдельно спланируйте перенос всего архива. Проверьте шифрование подключений и сертификаты; не оставляйте реальные пароли в истории команд и списке процессов. Подробности работы администратора есть в руководстве по imapsync.

Почему после переноса не видны папки

Коротко: папка нередко не потеряна, а попала в другую иерархию, стала обычной вместо системной или получила префикс, который приложение отображает неожиданно. Реальный пропуск тоже возможен, поэтому структуру нужно проверять.

Различия пространств имен и разделителей

Серверы IMAP используют разные разделители и пространства имен. Один применяет точки, как в INBOX.Sent, другой слеши, как в Inbox/Sent Items, третий ожидает префикс INBOX..

Без сопоставления до импорта или во время него папки могут сменить положение. Например, Project.Alpha превращается во вложенную папку внутри Project, а системная папка отображается как пользовательская. Мобильное приложение может подписаться не на ту папку и скрыть нужную.

Разные названия папки отправленных

Отправленные письма часто первыми вызывают тревогу при переносе. Один хостинг сохраняет их в Sent, другой ожидает Sent Items, третий показывает Sent Messages.

Если исходную папку скопировали как обычную, не связав с системной папкой назначения, стандартные «Отправленные» могут остаться пустыми. Пользователю кажется, что многолетняя история исчезла, хотя сообщения сохранились в другом месте.

Для виртуального хостинга инструкция TrekMail по переносу из cPanel и других хостингов описывает распространенные параметры доступа IMAP. Она помогает подготовить подключение, но не заменяет проверку входа, пространства имен, назначения системных папок и настроек клиента. Сопоставления таблицы являются примерами.

План переноса почты в 3 этапа

Коротко: трехэтапная синхронизация помогает управлять рисками. Сначала скопируйте старую почту, выполните дополнительный проход незадолго до переключения, затем измените MX и продолжайте нужные досинхронизации. Это может уменьшить простой и вероятность дублей, но не гарантирует отсутствие сбоев.

1. Историческая синхронизация. Сначала скопируйте старые письма, например старше 30 дней. Так основную массу данных можно перенести, пока пользователи работают на прежнем сервере.
2. Досинхронизация. Выполните следующий проход для новых данных. Надежное сравнение с уже импортированной историей особенно важно. Учитывайте также перемещенные и изменившиеся сообщения и позднее поступившие письма со старой датой, а не только временной диапазон.
3. Переключение и заключительные проходы. После предварительных проверок измените MX. Сохраните прием на старом хостинге и административный доступ для синхронизации: кеши DNS и повторные попытки доставки могут направлять туда письма даже после истечения TTL.

Ошибки DNS могут оставить новые письма на прежнем сервере или вызвать отказы. Держите рядом документацию TrekMail по необходимым DNS-записям. Пример ниже иллюстративный: сверяйте текущие значения провайдера, сохраняйте все используемые источники SPF и проверяйте DKIM с выравниванием DMARC. Не включайте более строгую политику DMARC вслепую одновременно с переносом.

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

Закрывайте пользовательский доступ и запись на старом сервере только после проверки результата и переключения почтовых приложений. Прием SMTP, доступ администратора для досинхронизации и возможность отката могут понадобиться дольше. Если сотрудники продолжают работать с обоими серверами, письма и новые отправленные сообщения распределяются между ними, превращая перенос в дополнительную задачу сверки.

Поэтапный процесс может быть полезен агентствам и провайдерам управляемых ИТ-услуг (MSP). При множестве брендов и клиентских доменов координация не менее важна, чем копирование. Платформа для почтового хостинга нескольких доменов может помочь, но не принимает на себя автоматически все риски и задачи переноса.

Что проверить после переноса

Коротко: сравните число сообщений, даты первых и последних писем и иерархию папок. Не доверяйте одним гигабайтам. Сжатие, индексирование и обработка вложений могут менять показанный объем без потери сообщений.

1. Сравните количество сообщений, а не только объем

Если во входящих было 4,502 сообщения, при одинаковом охвате и согласованных исключениях ожидается 4,502 в целевой папке. Размер может отличаться. Но совпадение количества не доказывает целостность: проверяйте сами письма, содержимое, вложения, флаги, даты и сопоставление папок. Для Gmail различайте уникальные сообщения и копии по ярлыкам.

2. Проверьте начало и конец истории

Отсортируйте письма по дате и сравните самые старые и новые сообщения во входящих и отправленных. Отсутствие старых требует проверки исторического прохода; отсутствие новых требует проверки досинхронизации и переключения. Причиной также могут быть фильтры и ошибочное сопоставление.

3. Найдите неправильно расположенные папки

Проверьте папки верхнего уровня вроде INBOX.Sent, оставшиеся папки [Gmail] и повторяющиеся «Отправленные». Это признаки возможной ошибки сопоставления, которые нужно сравнить с согласованной структурой назначения.

4. Проверьте реальный прием и отправку

Отправьте письмо с внешнего ящика и ответьте из целевого аккаунта. Проверьте получение, возможные фильтры и карантин, а также сохранение ответа в нужных «Отправленных». Единичная проверка не подтверждает все реальные маршруты доставки.

5. Проверьте новые настройки приложений

Письма могут не отображаться даже после корректного копирования, если клиент подключается к старому серверу. После переключения обновите приложения по актуальным настройкам IMAP и SMTP TrekMail. Если платформа принимает почту, но сотрудники ее не видят, проверьте также вход, подписки на папки и фильтры.

Поэтому перенос данных и замену провайдера планируют вместе. Материал об альтернативе Titan Email рассматривает ту же проблему со стороны выбора сервиса: копирование ящика является лишь частью изменений.

Ручной подход и работа с TrekMail

Коротко: ручной перенос может включать повторяющиеся действия и множество частных случаев. Серверная миграция IMAP, подходящий учет дублей, общий пул хранения и единая панель могут облегчить работу, если их поддерживают текущий тариф и реальные исходная и целевая системы.

Для небольшой команды это может уменьшить административную нагрузку, для агентства помочь с расчетом расходов. Оператор может собрать задачи в одном месте вместо пяти, хотя это не делает любую прежнюю систему хуже. Сверьте актуальные тарифы TrekMail. Бесплатный Nano и бесплатный пробный период на 14 дней для платных планов описаны в источнике; действуют нынешние условия.

Итог

Если нужно перенести почту с одного хостинга на другой и снизить риск дублей, потерянных папок и простоя, рассматривайте задачу как управляемое переключение IMAP, а не передачу файлов. Сопоставьте папки, проверьте полноту переноса архива Gmail, проведите поэтапные синхронизации и проверьте не только количество писем. Закройте старый пользовательский доступ после проверки и смены настроек клиентов, сохранив необходимые прием и досинхронизацию.

Если после переноса вы рассматриваете TrekMail для хостинга, начните с trekmail.net. Проверьте текущие условия тарифной модели для нескольких доменов, общего хранения и миграции IMAP. Расходы при добавлении сотрудников и доступные лимиты зависят от плана; целостность копии и отсутствие простоя не гарантируются для любого переноса.