Почта с Яндекса переехала: какие расхождения допустимы

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

Что зафиксировать в Яндексе до контрольного замера

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

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

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

Следующий вопрос — что происходило во время замера. Я прошу сотрудников на согласованный короткий интервал прекратить перемещения и удаления писем, фиксирую состояние правил и автоматической очистки. Если работу остановить нельзя, отмечаю изменения и повторяю проверку затронутых папок. Общий порядок уже разобран в статье про сверку после переноса почты. Здесь мой отдельный предмет — приёмка источника на Яндексе: доступные папки, соответствие меток и учёт поступлений на старую сторону. Без этих границ два честных замера легко отвечают на разные вопросы.

• Перечислить все переносимые ящики и адреса назначения.
• Записать включённые папки и согласованные исключения.
• Зафиксировать время замеров и изменения между ними.
• Проверить чтение источника и доступность резервной копии.

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

Я сравниваю структуру по карте соответствия. Слева — полный путь папки источника, справа — путь назначения, рядом — назначение папки и решение по ней. Посимвольное равенство названий требовать нельзя: серверы могут использовать разные разделители вложенности и префиксы, а системные папки получают другие имена. Это описано в документации imapsync о сопоставлении папок. Переименованные «Отправленные» не становятся потерянными только из-за нового имени. Но я проверяю, что их содержимое действительно попало в назначенную папку и её использует почтовый клиент.

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

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

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

Почему одинаковые счётчики ещё ничего не доказывают

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

В экспертной базе есть полезная конкретика: imapsync по умолчанию узнаёт сообщения по заголовкам Message-Id и Received. Разработчик подтверждает это в README. Эти поля помогают разобрать, какие письма инструмент счёл уже перенесёнными, но один Message-Id я не превращаю в безусловное доказательство уникальности. Для спорной пары сравниваю дополнительные заголовки и содержимое. Также учитываю обработку дублей самим инструментом: если требуется сохранить каждое исходное вхождение, это условие надо проверить до массового запуска. Молча объявить одинаковые сообщения мусором — тоже изменение данных, на которое нужна договорённость.

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

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

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

Как проверить вложения, даты и поиск по существующим письмам

Содержимое я проверяю на заранее выбранных письмах, которые точно есть у источника. Беру старую и свежую переписку, разные форматы вложений, крупные сообщения и вложенные письма. На назначении открываю текст, скачиваю вложения и сверяю их с оригиналами; при споре разбираю исходное сообщение целиком. Выборка выявляет характерные повреждения, но не позволяет обещать побайтовую проверку всей переписки. Если именно такая полнота нужна по договору, её обеспечивают отдельной проверкой всех включённых сообщений с описанным способом сравнения. Пара открытых договоров весь архив не аттестует.

Лимит размера сообщения не объясняю сказкой про автоматически отрезанный файл. При неудачном добавлении письма через IMAP частичная запись не допускается — это прямо установлено RFC 9051. Крупное сообщение может быть отклонено сервером или пропущено настройками мигратора; точную причину ищу в журнале. Если тело письма есть, а вложения нет, сравниваю исходник и результат, проверяю обработку сообщения и ограничения интерфейса. Увеличивать лимит наугад бессмысленно: сначала надо установить, на каком этапе изменились данные и действительно ли сам файл отсутствует в перенесённом письме.

С датами тоже нужна точность. Заголовок Date и внутренняя дата IMAP — разные свойства; INTERNALDATE отражает получение сообщения сервером. Я сравниваю их раздельно и учитываю отображаемый часовой пояс. Дата на диске и время загрузки в интерфейсе не заменяют эти проверки. Затем смотрю прочитанность, отметку важного и другие согласованные свойства на тех же письмах. Пользовательские категории не обещаю сохранить одинаково во всех продуктах. Если нужного представления нет, фиксирую ограничение и показываю сотруднику, каким способом будет доступна его рабочая подборка.

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

Как догрузить дельту и не затереть работу сотрудников

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

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

Перед исправляющим проходом проверяю область отбора. Ограничение по размеру или возрасту может законно оставить часть писем вне задания; отсутствие ошибки тогда не означает полного переноса. В документации imapsync такие ограничения описаны отдельно от ошибок передачи. Если первая загрузка охватывала только свежую переписку, завершённый процесс не доказывает наличие старого архива. Я не сужаю догрузку на глаз до последних дней: даты доставки и даты внутри сообщений могут расходиться. Сначала проверяю, какие сообщения действительно не попали в назначение и почему.

Когда причина установлена, исправляю её и повторяю перенос нужной области. После этого заново проверяю папки, спорные сообщения и согласованные свойства. Заранее назначать три обязательных цикла я не буду: завершение определяет результат, а не красивое число запусков. Отдельным контрольным письмом проверяю входящую и исходящую доставку после переключения. Успех этой проверки не закрывает архив, как и успешное копирование архива не закрывает доставку. В ведомости у них отдельные строки; иначе один зелёный значок незаметно начинает отвечать сразу за всю почту.

Что получить в акте приёмки до отключения Яндекса

Разберу учебный пример для условного туристического агентства «Маршрут дня» из Москвы с 31 рабочим местом. Допустим, переносим 24 ящика: количество рабочих мест и количество адресов не обязаны совпадать. Перед переключением я отвожу отдельное согласованное окно на контрольный замер, а длительность копирования определяю по пилоту. В папке договоров исходный счётчик показывает 1200 писем, целевой — 1199. До выяснения причины я ставлю ящику статус «не принят». Эти числа — условия примера, а не результат вымышленного проекта и не норматив допустимых потерь.

Пусть журнал и отбор сообщений показали, что одно крупное письмо не вошло в задание из-за установленного ограничения. Я меняю согласованную область переноса, догружаю сообщение и повторяю проверку папки: теперь 1200 на обеих сторонах. Затем открываю именно спорное письмо и сравниваю вложение с источником. Одного нового счётчика для закрытия этого дефекта мало. Если за время работы на источник поступили ещё два сообщения, они образуют отдельную дельту и должны получить собственное подтверждение переноса. В итоговой ведомости остаются исходное расхождение, его причина и результат повторного контроля.

Контакты и календарь в акте стоят отдельно от писем. В экспертной базе это ограничение указано прямо; документация Microsoft также подтверждает, что IMAP-миграция не переносит контакты, события и задачи. Если они входят в договор, я согласую отдельный способ переноса и контроль: нужные контакты, будущие встречи, повторы и доступы. Для правил сортировки нужен функциональный тест. Подписи и настройки сотрудников тоже не объявляю автоматически восстановленными из архива писем. Любое обещанное свойство получает проверку, а исключение — явное согласование до подписания результата.

На выходе я передаю перечень всех ящиков, карту папок, замеры с временем, журналы, объяснения разницы и результаты ручных тестов. Плюс состояние доставки, поиска, резервной копии и отдельный список нерешённых вопросов. Универсального срока ожидания до отключения Яндекса здесь нет: дату определяют условия перехода, контроль старых поступлений и согласованное хранение. Источник сохраняю доступным до завершения проверки и подтверждённого резервного копирования. Затем согласую отключение и отзыв временных доступов. Процесс проверен тогда, когда по каждому пункту есть свидетельство; обещание стопроцентной сохранности без такой ведомости остаётся рекламной фразой.

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

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