Миграция почты между провайдерами через IMAP

MAATRIX

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

Принцип IMAP-миграции: два подключения вместо ручного переноса

IMAP — это протокол, через который почтовый клиент читает письма и папки на сервере, не скачивая их окончательно (в отличие от POP3, где письмо после загрузки обычно удаляется с сервера). Инструменты для IMAP-миграции пользуются именно этим: они одновременно открывают два IMAP-подключения — одно к старому серверу (источник, «читаем»), второе к новому (назначение, «пишем») — и построчно копируют папки и письма из первого во второе.

Здесь и кроется главное практическое преимущество такого подхода. Вам не нужен доступ к файловой системе старого сервера, root или SSH туда — а если старый сервер это чужое облачное решение (корпоративная почта на аутсорсе, хостинг с почтой в комплекте, любой сервис, где вы арендатор, а не администратор), такого доступа у вас и не будет. IMAP же почти всегда открыт для конечного пользователя — это тот же протокол, которым пользуется Outlook или Thunderbird, просто вместо человека к нему подключается программа-синхронизатор. Она видит те же папки и письма, что видели бы вы в почтовом клиенте, и переносит их один в один, включая непрочитанные флаги и (при правильных настройках) исходные даты писем.

Важно сразу разграничить это с миграцией на собственный почтовый сервер, где вы сами администрируете и старый, и новый узел, — там на первый план выходит переключение MX-записи и «хвост» доставки после него, это отдельная тема, подробно разобранная в статье про миграцию почты без потери писем. Здесь же речь о более общем случае: перенести содержимое ящиков между двумя IMAP-серверами, кто бы ими ни владел.

Готовим IMAP-доступ на старом и новом сервере заранее

Прежде чем запускать перенос, убедитесь, что рабочий IMAP-доступ есть на ОБЕИХ сторонах — это тот шаг, который экономит больше всего времени, если сделать его до, а не во время миграции. Типичная ошибка — настроить и проверить только новый сервер, а на старом внезапно упереться в заблокированный пароль приложения или неверный порт.

Проверьте на каждом сервере:

• Учётные данные. Логин и пароль для IMAP не всегда совпадают с паролем от веб-интерфейса почты — у многих провайдеров (Google, Яндекс, Mail.ru) для внешних IMAP-клиентов нужен отдельный пароль приложения, который включается в настройках безопасности аккаунта.
• Порт и хост. Стандартные варианты — 993 (IMAP поверх TLS, самый частый случай) или 143 (обычно с последующим STARTTLS). Хост может отличаться от домена почты — например, imap.yandex.ru, а не просто yandex.ru.
• TLS-настройки. Убедитесь, что сертификат сервера валиден и соединение реально устанавливается, а не просто «порт открыт».

Быстрая проверка порта и TLS-хендшейка с обеих сторон:

# порт 993 — IMAP поверх TLS
openssl s_client -connect imap.old-provider.com:993 -crlf -quiet

# порт 143 — обычно с STARTTLS
openssl s_client -connect imap.new-provider.com:143 -starttls imap -crlf -quiet

Если соединение устанавливается, после короткого TLS-рукопожатия появится приглашение вида * OK ... IMAP4rev1 ... — это сервер отвечает и готов к аутентификации. Если вместо этого вы видите таймаут или connection refused, разбираться нужно ДО того, как запускать основной перенос — иначе инструмент синхронизации просто откажется подключаться к одной из сторон, и вы потратите время на диагностику в разгар миграции. Если новый сервер — ваш собственный, а не готовый провайдер, и вы поднимаете IMAP с нуля, порядок настройки Dovecot и типичные грабли с портами и TLS разобраны в статье про установку IMAP-сервера Dovecot с нуля.

Отдельно проверьте лимиты старого провайдера: у некоторых сервисов есть ограничение на число одновременных IMAP-подключений или на скорость выгрузки для одного аккаунта — если перенос идёт заметно медленнее ожидаемого или обрывается, часто причина именно в throttling на стороне источника, а не в инструменте синхронизации.

Выбираем инструмент для IMAP-to-IMAP переноса

Специализированных утилит именно для переноса писем между двумя IMAP-серверами несколько, и почти все они работают по одной схеме — принимают параметры подключения к источнику и назначению отдельными блоками и запускаются из командной строки (что удобно для автоматизации и логирования) или через GUI-обёртку для разового переноса без работы с терминалом.

Наиболее известный вариант в командной строке — imapsync: свободный инструмент, написанный специально под эту задачу, умеющий докопировать только новое при повторном запуске (это выручает, если перенос большого архива пришлось прервать и продолжить позже) и сохранять флаги прочитанности писем. Пример базового запуска для одного ящика:

imapsync \
  --host1 imap.old-provider.com --user1 'ivanov@example.com' --password1 'STARYI_PAROL' --ssl1 \
  --host2 imap.new-provider.com --user2 'ivanov@example.com' --password2 'NOVYI_PAROL'   --ssl2 \
  --automap --syncinternaldates \
  --logfile /var/log/imapsync/ivanov.log

Разберём ключевые флаги:

• --host1/--user1/--password1/--ssl1 — блок параметров подключения к старому серверу (источник, откуда читаем).
• --host2/--user2/--password2/--ssl2 — точно такой же блок для нового сервера (назначение, куда пишем).
• --automap — пробует автоматически сопоставить одноимённые папки на обеих сторонах.
• --syncinternaldates — сохраняет исходную дату получения письма вместо даты переноса, иначе почтовый клиент отсортирует всё «сегодняшним числом».

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

imapsync --dry \
  --host1 imap.old-provider.com --user1 'ivanov@example.com' --password1 'STARYI_PAROL' --ssl1 \
  --host2 imap.new-provider.com --user2 'ivanov@example.com' --password2 'NOVYI_PAROL'   --ssl2 \
  --automap --syncinternaldates

Если ящиков много, вынесите параметры в список и запустите циклом, чтобы не повторять команду вручную для каждого сотрудника:

#!/bin/bash
# accounts.txt: строки вида email:пароль_на_старом:пароль_на_новом
while IFS=: read -r email pass_old pass_new; do
  imapsync \
    --host1 imap.old-provider.com --user1 "$email" --password1 "$pass_old" --ssl1 \
    --host2 imap.new-provider.com --user2 "$email" --password2 "$pass_new" --ssl2 \
    --automap --syncinternaldates \
    --logfile "/var/log/imapsync/$email.log"
done < accounts.txt

Помимо imapsync существуют и другие пути решения той же задачи — вплоть до готовых мастеров переноса, встроенных в панели управления некоторых почтовых платформ (по сути то же самое IMAP-to-IMAP копирование внутри, просто параметры подключения спрятаны за формой). Для типового переноса между двумя обычными ящиками такой встроенный мастер может оказаться проще в настройке, чем консольный инструмент, хотя гибкости и логов у него обычно меньше. Для нетипичных случаев — нестандартная структура папок, десятки ящиков, повторные докачки — командная строка чаще даёт больше контроля.

Сопоставление папок: не полагайтесь на автоматическое угадывание

Разные почтовые системы по-разному называют и структурируют одни и те же служебные папки. То, что на одном сервере называется INBOX.Sent, на другом может быть Sent Items или [Gmail]/Отправленные; папка со спамом — Junk, Spam или [Gmail]/Спам; черновики — Drafts или INBOX.Drafts. Разделитель вложенности папок тоже может отличаться (точка . у одних серверов против слэша / у других).

Автоматическое сопоставление (--automap в imapsync и аналогичные опции в других инструментах) неплохо справляется с очевидными совпадениями по названию, но не гарантирует правильного результата, если названия и структура заметно расходятся между старой и новой системой. Стоит явно проверить результат сопоставления папок перед боевым запуском — через тот же тестовый прогон (--dry), который покажет, во что превратится каждая папка источника на стороне назначения.

Если автоматика ошиблась или папки нужно свести вручную, задайте сопоставление явно. У imapsync для этого есть --folder (перенести конкретную папку) и --regextrans2 (переименовать по регулярному выражению на стороне назначения):

# перенести только конкретную папку, а не весь ящик
imapsync --folder "Sent Items" \
  --host1 imap.old-provider.com --user1 'ivanov@example.com' --password1 'STARYI_PAROL' --ssl1 \
  --host2 imap.new-provider.com --user2 'ivanov@example.com' --password2 'NOVYI_PAROL'   --ssl2

# переименовать папку "Junk" источника в "[Gmail]/Спам" на назначении
imapsync \
  --host1 imap.old-provider.com --user1 'ivanov@example.com' --password1 'STARYI_PAROL' --ssl1 \
  --host2 imap.new-provider.com --user2 'ivanov@example.com' --password2 'NOVYI_PAROL'   --ssl2 \
  --regextrans2 's/^Junk$/[Gmail]\/Спам/'

Не считайте эту проверку формальностью для одного тестового ящика — прогоните её на ящике с наиболее сложной структурой папок в вашей организации (обычно это самый старый аккаунт, где годами копились вложенные подпапки) и убедитесь, что результат вас устраивает, прежде чем запускать перенос по всем остальным.

Сколько времени закладывать на перенос

Продолжительность переноса напрямую зависит от общего объёма писем и вложений в ящике, а также от скорости и ограничений обеих сторон (пропускной способности сети, лимитов провайдера-источника на число запросов). Небольшой ящик на несколько тысяч писем без крупных вложений может перенестись за минуты; архив на десятки гигабайт с многолетней историей вложений способен занять часы, а при жёстких лимитах источника — растянуться на день и больше. Точную цифру предсказать заранее сложно — закладывайте разумный запас времени, а не рассчитывайте на мгновенный перенос «пока пьёте кофе».

Практические выводы из этого:

• Запускайте перенос крупных ящиков в фоне (nohup ... &, screen или tmux), а не в интерактивной сессии терминала, которую можно случайно закрыть.
• Ведите отдельный лог-файл на каждый ящик (--logfile у imapsync) — по нему потом можно свериться, сколько писем реально перенеслось и не было ли ошибок аутентификации или обрывов соединения на середине.
• Если ящиков много, не запускайте все переносы одновременно без ограничения — упрётесь в лимиты старого сервера на число одновременных подключений с одного клиента. Разумнее запускать в несколько параллельных потоков, но не «все сразу».
• Повторный запуск того же инструмента после первого прогона обычно происходит намного быстрее первого — большинство инструментов синхронизации умеют докопировать только новое, не перекачивая уже перенесённые письма заново.

Не отключайте старый сервер сразу — держите его как страховку

Даже после того, как перенос отчитался об успешном завершении, не спешите отказываться от старого ящика или удалять с него данные. Разумная практика — держать старый сервер доступным ещё некоторое время (речь не о конкретном числе дней — ориентируйтесь на то, сколько времени вам реально нужно, чтобы всё проверить и начать полноценно работать в новом ящике), пока не появится полная уверенность, что весь необходимый объём писем и папок перенесён корректно.

Это особенно важно, если старый провайдер вы уже покидаете безвозвратно — обратной дороги за «забытым» письмом потом может не быть. Если переезд происходит на собственный сервер и вы одновременно переключаете MX-запись для приёма НОВОЙ входящей почты, добавляется отдельный риск «хвоста» доставки уже после переключения — этот сценарий разобран в статье про миграцию почты без потери писем. Если же вы просто переносите содержимое ящика между провайдерами без смены точки приёма почты, оставить старый ящик активным на какое-то время всё равно стоит — хотя бы ради возможности свериться.

Проверяем результат до полного переключения

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

• Даты писем. Открытые письма должны показывать исходную дату получения, а не дату переноса — если даты «съехали» на день миграции, скорее всего не сработала опция сохранения внутренних дат при переносе, и стоит перезапустить синхронизацию с правильным флагом.
• Вложения. Откройте несколько писем с вложениями и убедитесь, что файлы открываются и не повреждены — крупные вложения иногда обрезаются при сетевых обрывах посреди переноса.
• Кодировка текста. Особенно важно для старой переписки — письма в нестандартных кодировках иногда отображаются криво после переноса между разными почтовыми системами; если увидели «кракозябры» в паре старых писем, проверьте на выборке побольше, не системная ли это проблема.
• Количество писем в папке. Простое, но полезное сравнение — число писем в конкретной папке на старом и новом сервере должно совпадать (с поправкой на то, что могло прийти новое за время переноса).

Только убедившись, что выборочная проверка не выявила проблем, переключайте реальное использование (клиенты, автоматические уведомления, интеграции) на новый ящик и постепенно сворачивайте зависимость от старого.

Частые вопросы