Миграция почты: 7 опасных видов сбоев

Миграция электронной почты выглядит обычным копированием, пока письма не начинают поступать в два места, пользователи не получают возвраты при ответе на старые цепочки, а кто-нибудь не обнаруживает, что ящик директора на 85GB больше предусмотренного тарифом. Если вас интересуют инструменты, начните с руководства оператора по imapsync. Эта статья представляет собой регламент для окружающих проблем: DNS, сопоставления папок, ограничений скорости, квот и неприятных крайних случаев, превращающих обычную миграцию в аварию на все выходные.

Проблема проста: люди относятся к почте как к файлам. Хуже другое: ящики продолжают меняться во время переноса, кеш DNS создает ложную картину, а серверы IMAP по-разному обрабатывают папки. Решение заключается не в подвигах, а в подготовке, проверке и отказе от упрощений, которые кажутся безобидными в 6 PM и становятся катастрофой в 9 AM понедельника.

Почему миграция почты срывается в production

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

1. Расхождение DNS вызывает первую аварию миграции

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

Microsoft рекомендует сокращать TTL для MX до переключения IMAP, чтобы обновленные записи распространялись быстрее. Совет скучный, но он спасает миграции. Если текущий TTL равен 86,400 секундам, а MX меняется в ночь переезда, вы уже потеряли контроль над графиком.

;; T-48 hours: inspect current MX TTL
example.com.  86400  IN MX 10 oldmail.example.com.

;; T-48 hours: lower it before cutover
example.com.    300  IN MX 10 oldmail.example.com.

;; T-0: switch to new provider
example.com.    300  IN MX 10 mail.trekmail.net.

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

Плохое переключение: изменить MX в 10 PM, отключить старый хостинг в 10:05 PM и в понедельник узнать, что шлюз одного поставщика хранил старую запись все выходные.

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

2. Ограничение скорости разрушает мечту о миграции за выходные

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

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

Решение состоит в поэтапной миграции:

1. Сначала предварительно перенести старую почту, обычно все старше 60 до 90 дней.
2. В течение недели позволить инструменту повторять попытки с паузами.
3. Переключить MX только после доставки основной части истории в назначение.
4. Во время переключения выполнить дельта-проход для свежей почты.

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

Старый и новый способы: старые провайдеры берут плату за каждое место, а затем отдельно продают инструмент миграции. При новом способе вы выполняете поэтапный перенос встроенным средством IMAP, платите по фиксированному тарифу от $3.50 в месяц и перестаете превращать каждый ящик в отдельное лицензионное событие.

3. UIDVALIDITY может создать три копии одного ящика

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

IMAP4rev1 (RFC 3501) неслучайно определяет UIDVALIDITY. После его изменения старым UID сообщений нельзя доверять. Для протокола это нормально, но для инструмента, полагающегося только на UID, последствия ужасны.

Типичные причины:

• Пользователь переименовывает или заново создает папку во время переноса.
• Исходный сервер перестраивает индексы.
• Администратор выполняет обслуживание, меняющее состояние ящика.

Практическая защита проста. На время миграции приостановите уборку в ящиках. Запретите пользователям переименовывать папки, перемещать тысячи сообщений в архив и очищать отправленные во время синхронизации. Используйте назначение, способное пропускать дубликаты при повторных проходах, а не слепо доверять UID папок.

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

4. Сопоставление папок быстро делает миграцию странной

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

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

Так аккуратно размеченный ящик Gmail превращается в раздутую цель с повторными письмами в отправленных, пользовательских папках и архивах. Документация Microsoft прямо называет дубликаты при использовании ярлыков Gmail, если папка [Gmail] не исключена.

# Example folder rules
^INBOX\.Sent$        -> Sent Items
^INBOX\.Trash$       -> Deleted Items
^\[Gmail\]/Trash$   -> Deleted Items
^\[Gmail\]/All Mail$ -> [SKIP]

При миграции из Gmail пропускайте [Gmail]/All Mail, если только нет конкретного исключения. Иначе вы сами просите создать дубликаты. После переезда TrekMail упрощает настройку клиентов благодаря стандартным параметрам из руководства по IMAP и SMTP для всех клиентов.

5. Огромный ящик уничтожает бюджет и график

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

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

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

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

Для наблюдения после переезда TrekMail описывает ограничения и квоты в материале о квотах хранилища ящиков.

6. Поврежденные сообщения нормальны и требуют рабочих правил

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

Здесь точность путают с компетентностью. Контрольный след нужен, а замораживать весь пакет из-за вложения, которое невозможно разобрать, не нужно.

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

Встроенный процесс TrekMail показывает прогресс и ошибки в панели. Если после переключения письма поступают не туда, начните быструю проверку с руководства «Я не получаю письма», которое охватывает MX и ящики.

7. LegacyExchangeDN является ловушкой Exchange, переживающей миграцию

Этот сбой специфичен, неприятен и распространен. Пользователи отвечают в Outlook на старую внутреннюю цепочку и получают возврат IMCEAEX или сообщение об отсутствии получателя, хотя ящик существует и новая почта работает. Причина не в SMTP, а в старом идентификаторе Exchange, встроенном в исторические письма и сохраненные адреса.

Exchange хранит прежнюю адресацию в стиле X.500 в атрибуте LegacyExchangeDN. При переносе между средами Exchange или неудачном уходе из нее ответы на старые сообщения продолжают ссылаться на этот идентификатор. Если прежнее значение не добавлено к целевому ящику как прокси-адрес X500, ответ завершится ошибкой.

# Find the old LegacyExchangeDN on source
Get-Mailbox -Identity user@example.com | Format-List LegacyExchangeDN

# Add it as an X500 proxy address on destination
Set-Mailbox -Identity user@example.com -EmailAddresses @{add="X500:/o=OldOrg/ou=Exchange Administrative Group/cn=Recipients/cn=user"}

Это затрагивает не каждую миграцию, поскольку обычный перенос IMAP не передает собственные объекты Exchange так, как полноценная миграция Exchange. Но если пользователи Outlook должны без сбоев отвечать на старые внутренние цепочки, проверьте это до приемки. Проблема часто появляется лишь после объявления проекта завершенным.

Более безопасный план переключения

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

1. Инвентаризировать объем каждого ящика и отметить необычно большие.
2. Снизить TTL для MX за 24 до 48 часов до переключения.
3. Сначала создать целевые домены и ящики.
4. Выполнить историческую синхронизацию IMAP до выходных переключения.
5. Запретить очистку папок и массовые перемещения во время последней синхронизации.
6. Переключить MX только после готовности назначения принимать почту.
7. Выполнить одну заключительную дельта-синхронизацию.
8. Проверить входящую, исходящую почту, числа в папках и ответы на старые цепочки.

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

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

Вывод: миграция почты является эксплуатационной работой, а не копированием

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

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