imapsync: защита от пропавших писем

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

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

Коротко: стандартные настройки imapsync не являются планом миграции. Это лишь отправная точка. Для настоящего переноса нужны поэтапные проходы, явные правила папок и проверка до изменения MX. Если целевой системой служит TrekMail, встроенный мастер импорта в платных планах обработает принимающую сторону через панель управления. Это быстрее ручного управления каждым ящиком с помощью shell-скриптов. Планы TrekMail начинаются с $3.50/month, используют общий пул хранилища вместо оплаты за пользователей и поддерживают серверный импорт по IMAP из Gmail, Outlook, Yahoo, iCloud и любых стандартных IMAP-сервисов.

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

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

Типичные сбои скучны и дорого обходятся:

При загрузке больших сообщений истекает тайм-аут.
Папки сопоставляются неверно, и пользователи считают почту пропавшей.
Провайдер ограничивает задачу и отклоняет подключения.
Современная аутентификация блокирует обычные пароли.
Изменение состояния UID приводит к дублям при следующих проходах.
`--delete2` удаляет новую почту с целевого сервера после переключения.

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

Параметры подключения, которые поддерживают imapsync

При больших ящиках соединение часто обрывается до завершения записи. Обычно виноваты долгие операции APPEND, медленные серверы Exchange и межсетевые экраны с отслеживанием состояния. Решение простое: увеличить тайм-аут, отправлять keepalive и кешировать состояние, чтобы повторный запуск не начинался заново.

При первом серьезном проходе используйте:

imapsync \
  --host1 imap.source.tld --user1 user@source.tld --passfile1 ./pass1 \
  --host2 imap.dest.tld   --user2 user@dest.tld   --passfile2 ./pass2 \
  --timeout 120 \
  --keepalive1 --keepalive2 \
  --usecache

Назначение параметров:

Параметр	Почему он важен	Что ломается без него
`--timeout 120`	Дает медленным загрузкам и крупным вложениям время завершиться.	Сообщения пропускаются после тайм-аута сокета.
`--keepalive1 --keepalive2`	Поддерживает активность обоих сеансов IMAP во время пауз.	Межсетевые экраны или балансировщики разрывают сеанс.
`--usecache`	Сохраняет состояние сравнения локально и ускоряет повторы.	Возобновление идет медленнее и проверяет все заново.

Кеш особенно важен, потому что хорошая миграция выполняется поэтапно. После массового прохода исправляют аутентификацию и сопоставление, затем запускают один или два дополнительных прохода. С `--usecache` imapsync реже перечитывает обе стороны. Без него каждый повтор тяжелее необходимого.

Есть оговорка. Официальная документация предупреждает, что `--usecache` в некоторых случаях небезопасен в сочетании с фильтрами размера и возраста. Не добавляйте случайные фильтры только потому, что они кажутся эффективными. Первый проход должен быть простым.

Параметры сопоставления против паники из-за «пропавших папок»

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

Две главные ловушки связаны с разделителями и служебными папками.

Одни серверы разделяют уровни точками, другие косыми чертами. Если источник содержит INBOX.Clients.ProjectA, а цель ожидает INBOX/Clients/ProjectA, путь нужно преобразовать при копировании.

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --regextrans2 's/\./\//g'

Папка отправленных тоже называется по-разному. Пользователю важно лишь видеть письма в активном представлении отправленной почты.

Исходная папка	Целевая папка	Подходящий параметр
`[Gmail]/Sent Mail`	`Sent Items`	`--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/'`
`Sent`	`Sent Items`	`--regextrans2 's/^Sent/Sent Items/'`
`Gesendete Elemente`	`Sent Items`	`--regextrans2 's/^Gesendete Elemente/Sent Items/'`

Для стандартных служебных папок сначала попробуйте --automap. Для неупорядоченных, локализованных или старых ящиков cPanel надежнее явные преобразования regex. У TrekMail также есть инструкции по запуску импорта в панели и подготовке домена через добавление домена.

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

Ограничьте imapsync раньше Google или Microsoft

Для почтовых провайдеров imapsync может выглядеть как вредоносный трафик. Быстрые серии APPEND и FETCH по множеству ящиков вызывают ограничения скорости, временные блокировки или ошибки, похожие на сбой аутентификации, хотя причина в доступной мощности. Медленно и стабильно часто быстрее, чем попасть под блокировку.

Для Google Workspace или Microsoft 365 управляйте темпом:

imapsync \
  --host1 imap.gmail.com --user1 user@source.tld --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@dest.tld --passfile2 ./pass2 \
  --maxbytespersecond 500000 \
  --maxmessagespersecond 2

Это снижает всплески, запускающие защиту провайдера, и не перегружает общую среду сериями маленьких писем. Такой риск есть и на старых серверах cPanel, и в занятых тенантах Office 365.

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

Здесь особенно хорошо видна разница старого и нового подходов.

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

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

Параметры аутентификации для 2025-2026: пароль уступает OAuth

Для Google Workspace и Microsoft 365 нельзя считать обычный вход в IMAP по имени и паролю гарантированным. Google сообщает, что с 1 мая 2025 года аккаунты Workspace больше не поддерживают «менее безопасные приложения», которые входят только таким способом. Microsoft также направляет клиентов IMAP для Exchange Online к OAuth.

Это меняет запуск imapsync. Если источник поддерживает XOAUTH2, вместо обычного пароля нужен токен доступа.

imapsync \
  --host1 outlook.office365.com \
  --user1 user@source.tld \
  --authmech1 XOAUTH2 \
  --oauthaccesstoken1 "ACCESS_TOKEN" \
  --host2 imap.trekmail.net \
  --user2 user@dest.tld --passfile2 ./pass2

В Google Workspace пароли приложений могут оставаться практичным запасным вариантом для разовых переносов при включенной 2-этапной проверке. Для Microsoft 365 применяйте документированный процесс OAuth для старых протоколов. Если скрипт по-прежнему считает, что «правильный пароль означает правильную аутентификацию», он устарел.

Авторитетные источники: рекомендации Google Workspace по менее безопасным приложениям и инструкция Microsoft по OAuth для IMAP.

Параметры целостности для проблемных писем

Некоторые сообщения повреждены, и на старых серверах это нормально. В реальных миграциях встречаются отсутствующие заголовки Message-ID, некорректный MIME, огромные вложения и пустое содержимое. imapsync может обойти часть проблем, если задать правила.

Первый полезный параметр, --addheader, добавляет созданный заголовок Message-Id, когда его нет. Это важно, потому что по идентификатору imapsync определяет уже существующие сообщения.

Второй параметр, --maxsize, нужен, если целевой ящик или политика отклоняет огромные письма. Одна такая запись не должна останавливать всю задачу.

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --addheader \
  --maxsize 35000000

Это не попытка забыть о крупных письмах. Сначала перенесите 99%, затем вручную обработайте исключения по контролируемому списку.

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

Самый опасный параметр imapsync: --delete2

`--delete2` удаляет с целевой стороны сообщения, отсутствующие в источнике. Для точного зеркала это звучит полезно. Но после смены MX параметр может удалить совершенно корректную новую почту.

Последовательность сбоя:

Старая почта заранее переносится из источника в цель.
MX переключается на нового провайдера.
Новая почта начинает приходить в целевой ящик.
imapsync повторно запускается с --delete2.
imapsync видит письма только на целевой стороне и удаляет их, потому что в источнике их не было.

Это не ошибка программы. Она точно выполнила заданную команду.

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

Когда UID обманывают, сопоставляйте заголовки

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

Тогда помогает сопоставление по заголовкам:

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --useheader 'Message-Id'

Это медленнее доверия серверным UID, но безопаснее для нестабильного, перестроенного или явно непоследовательного источника. Официальная документация отмечает, что проблемы дублей часто решаются параметром --useheader "Message-Id".

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

Шаблон безопасной команды imapsync

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

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 ./pass2 \
  --timeout 120 --keepalive1 --keepalive2 \
  --usecache \
  --automap \
  --regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/' \
  --exclude '^\[Gmail\]/All Mail' \
  --maxbytespersecond 500000 \
  --maxmessagespersecond 2 \
  --dry

Три практических замечания:

Всегда сначала используйте --dry.
Исключите огромные архивные папки, ненужные в первом проходе.
Сохраните журнал и версионируйте команды для каждой группы миграции.

После переноса в TrekMail пользователи подключаются по стандартному IMAP к imap.trekmail.net через порт 993. TrekMail использует только IMAP, а не POP3. Это правильный выбор для синхронизации состояния между устройствами.

Вывод: imapsync надежен, если работать с ним как с инструментом миграции

imapsync остается правильным выбором для многих переносов, если относиться к нему как к программе миграции с состоянием, а не к простой команде копирования. Настройте тайм-ауты и keepalive, сопоставьте папки, замедляйтесь при ограничениях, применяйте современную аутентификацию и не используйте `--delete2` для почты после переключения. При сомнительном состоянии UID включите сопоставление заголовков.

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