Миграция почтового ящика кажется простой до первого входа пользователей. Не видны отправленные, растет число непрочитанных, десятилетняя история выглядит полученной сегодня. Нужно переносить не только сообщения, но и поддерживаемое состояние. Общий порядок есть в руководстве администратора по imapsync. При смене всей платформы также полезны ясные стандарты и проверка.
Копирование содержимого с немедленным объявлением успеха не учитывает работу пользователей. Одного перенесенного содержимого RFC 5322 недостаточно. Нужны ожидаемая папка отправленных, корректный статус прочтения и понятный поиск. Сбои в этих трех областях могут вызвать заявки уже в первый рабочий день.
Руководство объясняет типичные проблемы, проверку результата и возможную роль TrekMail. Источник описывает встроенный импорт IMAP начиная со Starter и тарифную оплату от $3.50 в месяц без оплаты за каждого пользователя. Уточняйте нынешние функции и лимиты, переносите один ящик или сто. Для планирования см. деловую почту малого бизнеса и хостинг почты нескольких доменов.
Почему проблемы видны после переключения MX
Сообщения могут прийти без нужного состояния ящика. Четыре важные области проверки: папки, флаги прочтения, внутренние даты и ярлыки Gmail. Их проверка снижает риск, но не гарантирует безошибочную миграцию.
Новый прием после смены MX еще не доказывает целостность. MX меняют только для собственного управляемого домена при смене приема, после создания адресов и проверки предварительной копии. Пользователям нужен прежний рабочий процесс, а не просто доступный сервер.
Рассматривайте перенос как миграцию базы данных. Письмо имеет содержимое, флаги, расположение и серверную дату. При потере метаданных ящик открывается, но ведет себя иначе.
Пример: руководитель видит 8,000 непрочитанных сообщений и считает виноватым провайдера. В этом примере скопировано содержимое, но не состояние \Seen. В реальной ситуации нужно проверить и другие причины.
Четыре незаметные причины сбоев
Проверьте папку отправленных, \Seen, INTERNALDATE и повторные представления Gmail All Mail. Такие различия часто обнаруживаются при работе, а не на полосе прогресса.
1. Отправленные попадают не в ту папку
Системы могут называть папки по-разному: Sent, Sent Items, у cPanel часто INBOX.Sent, у Gmail [Gmail]/Sent Mail.
При неверном сопоставлении история попадает в обычную папку, а клиент сохраняет новые сообщения в папку отправленных с соответствующим специальным назначением. Пользователь видит пустую привычную папку, хотя старые письма находятся в другом месте.
RFC 6154 описывает специальные назначения папок, позволяющие распознавать отправленные, черновики, спам и корзину. Важны реальное назначение и клиентские настройки, а не одно имя.
2. Проблема флага \Seen
Состояние прочтения нужно сохранять, если источник и инструмент его поддерживают. Иначе обработанная за годы почта может снова оказаться непрочитанной и затруднять работу.
RFC 3501 описывает системные флаги, включая \Seen. Проверяйте их при пробном переносе: формально завершенная копия не гарантирует правильных отметок.
\Recent отличается. В прежней модели IMAP он связан с сеансами и не переносится как статус прочтения; современные реализации могут уже не использовать его так. Старая почта может отображаться как недавно появившаяся для целевого сеанса. Предупредите об этом заранее.
3. Сброс INTERNALDATE
Заголовок Date отличается от внутренней даты сервера. Клиенты могут сортировать по внутренней дате, поэтому ее изменение способно сдвинуть историю даже при сохраненном сообщении.
RFC 3501 описывает APPEND с необязательной датой и временем: при передаче рекомендуется использовать их для внутренней даты, без них берется текущее время. Так десятилетний архив может оказаться под сегодняшним днем. Передавайте предоставленный сервером INTERNALDATE со смещением часового пояса и поддерживаемой точностью. Заголовок Date не восстанавливает неизвестное исходное время поступления на сервер.
4. Повторные копии Gmail All Mail
Gmail использует ярлыки, представленные в IMAP как папки. Несколько представлений могут содержать одно сообщение, и инструмент создает из него несколько копий.
Импорт [Gmail]/All Mail вместе со входящими, отправленными и ярлыками может увеличить объем и число результатов поиска. Но копии по папкам могут быть намеренным отображением ярлыков. Согласуйте структуру; исключать «Всю почту» допустимо только после плана полного переноса архива, включая письма без других импортируемых ярлыков.
| Исходная система | Исходное имя папки | Пример целевого имени | Риск неверного сопоставления |
|---|---|---|---|
| cPanel / Courier | INBOX.Sent | Sent Items | Старые отправленные кажутся отсутствующими |
| Старый Linux-сервер | Sent Messages | Sent Items | История распределена по папкам |
| Немецкий хостинг | Gesendete Elemente | Sent Items | Клиент не показывает привычную историю |
| Gmail | [Gmail]/Sent Mail | Sent Items | Письма вне нужной системной папки |
| Обычный IMAP | Trash | Deleted Items | Неодинаковая работа корзины |
Как сопоставлять папки при переносе
Разные имена требуют нужного сопоставления. Автоопределение помогает, но не заменяет теста. Целевые имена таблицы являются примерами, не универсальными стандартами или гарантированными папками TrekMail.
Для ручного imapsync можно применять проверенные регулярные выражения. Исходный пример ниже не готов к запуску: избыточное экранирование правил INBOX не соответствует ожидаемым именам папок. Преобразования применяются после автоматической обработки префиксов и разделителей, последовательно к результату предыдущего правила. Проверьте и исправьте собственную рабочую копию по фактическим целевым путям. Команда реально копирует и не задает проверку TLS и сертификатов, пароли указаны в аргументах. Нужны контролируемый тестовый ящик, настоящий пробный режим при поддержке, защита секретов и проверка шифрования, цепочки сертификата и имени сервера:
imapsync \
--host1 old.example.com --user1 user@old.example.com --password1 'oldpass' \
--host2 new.example.com --user2 user@new.example.com --password2 'newpass' \
--regextrans2 's/^Sent Messages$/Sent Items/' \
--regextrans2 's/^INBOX\\.Sent$/Sent Items/' \
--regextrans2 's/^INBOX\\.Trash$/Deleted Items/' \
--exclude "\\[Gmail\\]/All Mail"После пилота отправьте реальное письмо из целевого ящика. Проверьте, что новая отправка и старая история находятся в одной предусмотренной папке. Исправьте сопоставление до переноса остальных пользователей.
Для TrekMail начните с актуального обзора миграции IMAP. Источник описывает шаблоны Gmail, Outlook, Yahoo, iCloud и IMAP, списки папок с числами, фоновые задачи и учет дублей. Проверяйте текущие функции и результат: Message-ID и UID не дают общей гарантии целостности. Прямой импорт использует имя и пароль, не интерактивный OAuth. Пароль приложения зависит от политики; при необходимости нужен другой разрешенный способ подключения с OAuth. Подготовку описывают перенос из Gmail и перенос из cPanel.
Проверка миграции по реальным данным
Сравните количество, непрочитанные, отправленные и даты. Гигабайты ненадежны из-за MIME, индексов и накладных расходов хранения. Совпадающие числа тоже не доказывают целостность: открывайте содержимое и вложения, проверяйте журналы и папки.
Зеленый статус сообщает о задаче, но не гарантирует сохранение пользовательского опыта. Проверяйте сами данные.
- Сравнить сообщения по согласованным исходным и целевым папкам: входящие, отправленные, архив.
- Проверить непрочитанные. При 50 в источнике и 4,000 в целевом ящике исследуйте флаги, разный охват, фильтры и текущие изменения, а не считайте разницу доказательством одной причины.
- Открыть старые письма: 2019 при сохраненных датах должен оставаться в 2019.
- Отправить новый тест и сравнить его папку с перенесенной историей отправленных.
Небольшие различия возможны из-за MIME, исключений или непочтовых объектов. Каждую существенную разницу нужно объяснить. Размер не заменяет сравнения сообщений, флагов, вложений и времени.
После переключения нужны правильные клиенты. Актуальные параметры есть в руководстве IMAP/SMTP TrekMail. Источник описывает IMAP без POP3; до удаления старых профилей сохраняйте локальные и несинхронизированные письма. Проверяйте актуальный режим TLS, цепочку сертификата и имя сервера, входите полным адресом и паролем ящика, а не учетными данными панели.
Повторный перенос изменений, дубли и UIDVALIDITY
После первой копии обычно нужен хотя бы один дополнительный проход, а после переключения дальнейшая досинхронизация. Учитывайте поздние письма со старой датой, перемещения между папками и флаги. Старый SMTP-прием, административный доступ и откат сохраняют для кешей и повторных доставок: снижение TTL не очищает прежний кеш сразу.
UIDVALIDITY определяет действительность UID внутри папки. Восстановление, ремонт или переиндексация могут изменить его, но не обязательно меняют. Инструмент может потерять сопоставление и в зависимости от метода повторить копию. UID не глобален и не доказывает сохранность содержимого.
Так пятничный успешный на вид перенос может дать дубли в понедельник. Отложите необязательное обслуживание. Необходимый ремонт согласуйте: приостановите перенос, проверьте состояние и повторно подтвердите безопасный запуск, а не запрещайте любые важные работы.
Многие инструменты добавляют сообщения, не зеркалируя удаления. Удаление в источнике после первой копии тогда не обязательно удаляет письмо в целевом ящике. Это может защищать новую целевую почту, но требует плана конфликтов. Пользователи работают в одной активной системе; два одновременно изменяемых ящика не являются безопасной двусторонней синхронизацией.
Зеркальное удаление разрешайте только после отдельной проверки направления, времени, резервной копии и теста. Неверное предположение способно удалить нужные данные.
Ручная миграция и управление TrekMail
Ручной перенос может требовать отдельных команд, регулярных выражений и проверок. Единый IMAP-процесс способен объединить работу, но пригодность тарифной или пользовательской оплаты зависит от потребностей и лимитов.
| Область | Возможный ручной подход | Подход TrekMail: проверьте текущие возможности |
|---|---|---|
| Подготовка | CLI, проверки хоста и сопоставление | Ассистент импорта в поддерживаемых тарифах со Starter |
| Источники | Особенности провайдера проверяет администратор | Шаблоны Gmail, Outlook, Yahoo, iCloud и IMAP с проверкой доступа |
| Дубли | Зависят от параметров и повторений | Документированный учет дублей, результат тестируется |
| Работа | Объем действий может расти с ящиками | Тарифное управление доменами для подходящих требований |
| Цены | Пользовательские тарифы могут увеличивать расходы | Исторический пример от $3.50 в месяц, текущие ограничения и расходы нужно сверить |
Для множества ящиков экономика важна вместе с протоколом. Сюда входят подготовка и контроль. Дополнительные материалы: массовое создание почтовых учетных записей и управление почтой клиентов.
TrekMail не заменяет проверку. Панель нескольких доменов, общее хранилище, IMAP и свой или включенный SMTP могут облегчать управление в рамках тарифа. Новые пользователи, хранение и функции по-прежнему ограничены текущими условиями.
Перед переносом сравните тарифы TrekMail. Бесплатный Nano без карты, платные планы от $3.50 в месяц и бесплатный пробный период платных тарифов на 14 дней с банковской картой являются сведениями источника; проверяйте актуальные условия.
Вывод: признаки успешной миграции
Цель: отправленные в нужном месте, понятное число непрочитанных, правильная историческая сортировка и осознанное представление ярлыков Gmail. Результат проверяют по настоящим письмам, а не одному индикатору.
Сопоставьте папки до основного прохода, сохраните поддерживаемые флаги вроде \Seen и доступный INTERNALDATE при APPEND. Исключайте Gmail «Всю почту» только после проверки полного охвата архива. Сравнивайте количество, содержимое, вложения, даты и журналы, не один размер.
Эти шаги превращают копию в контролируемый переход и снижают риск доработок, но не гарантируют отсутствие потерь или простоя. Алиасы, пересылки, календари, контакты и другие функции нужно отдельно восстановить и проверить.
Основы протокола: RFC 3501 для IMAP и RFC 6154 для специальных назначений папок.
