Как проверить телефоны сотрудников после ухода с Яндекса

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

Почему смена MX не перенастраивает телефоны

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

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

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

Для разбора беру условного перевозчика «Рейс и груз» из Москвы: 19 рабочих мест. В учебном плане предполагаю 12 телефонов — семь iPhone и пять Android; это условия примера, а не статистика выполненного проекта. Выбираю по одному устройству каждой системы для пилота. Остальные десять подключаю после успешной проверки. Обещание «DNS обновится — всё оживёт» удобно тем, что у него нет ответственного. В моём плане ответственный есть у каждого устройства.

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

Какие параметры проверить до массового подключения

Перед пилотом я готовлю карточку подключения. В ней отдельно указаны имя IMAP-сервера, имя SMTP-сервера, порты, режим защиты и формат логина. Это могут быть разные узлы. Для примера использую только условные имена imap.example.com и smtp.example.com; в рабочую памятку попадут проверенные имена организации. Полный адрес ящика часто служит логином, но это настройка сервиса, а не обязательное свойство IMAP. В новом профиле использую выданные для нового сервера учётные данные: прежний пароль или токен не обязан там действовать.

Для IMAP с TLS с начала соединения обычно используют порт 993. Для отправки выбираю один из поддерживаемых сервером вариантов: SMTP 465 с TLS с начала соединения либо SMTP 587 с обязательным STARTTLS. Такое различие описывает RFC 8314. На 587 сначала устанавливается соединение SMTP, затем выполняется переход к TLS; пароль и письмо нельзя отправлять до успешного защищённого соединения. Надпись SSL/TLS в интерфейсе обычно обозначает режим с TLS сразу. Современный протокол при этом не следует путать с устаревшими версиями SSL.

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

Предупреждение о сертификате я разбираю до массового подключения. Публичный доверенный центр упрощает работу с личными телефонами; внутренний центр тоже возможен, если доверие к нему корректно развёрнуто и поддерживается. Apple отдельно предупреждает: вручную установленный профиль с сертификатом не получает доверие для SSL/TLS автоматически. Установка неизвестного корневого сертификата по просьбе из письма — плохая замена администрированию. Кнопка согласия не продлевает сертификат и не исправляет чужое имя в нём. Для пилота я требую подключение без необъяснённых предупреждений.

• IMAP: 993, TLS с начала соединения, если этот вариант поддерживается.
• SMTP: 465 с TLS либо 587 с обязательным STARTTLS — по настройкам сервера.
• Логин и способ входа — из карточки нового сервиса.
• Получение и SMTP-аутентификацию проверить раздельно.
• На межсетевом экране разрешать только выбранные сервисы.

Как я принимаю новый профиль на iPhone

На пилотном iPhone сначала записываю версию системы и приложения. В актуальной инструкции Apple путь начинается с «Настройки» → «Приложения» → «Почта» → «Учетные записи Почты» → «Добавить учетную запись». Для ручной настройки далее вводят адрес, выбирают «Добавить другую учетную запись» и «Учетная запись Почты». Если автоматический поиск не дал правильных параметров, выбирают IMAP и заполняют серверы входящей и исходящей почты. На более старых выпусках названия и расположение пунктов могут отличаться. Памятку я сверяю с теми устройствами, которые реально участвуют в переходе.

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

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

Потом проверяю получение при закрытом приложении и заблокированном экране. Если учётная запись не поддерживает Push в Apple Mail, Apple предлагает расписание выборки новых данных. Это не обещание мгновенного уведомления для любого IMAP-сервера. Я сверяю режим загрузки и разрешения уведомлений, затем повторяю тест в обычных условиях работы сотрудника. Название папки, свежесть письма и время появления уведомления фиксирую отдельно. Галочка «аккаунт добавлен» хороша для скриншота. Для приёмки мне нужен проверенный обмен письмами.

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

Как отличить сбой Android от задержки уведомлений

Для Android я выбираю конкретное приложение и делаю памятку под него. Единого встроенного почтовика с одинаковыми меню у всех производителей нет. Например, в Gmail путь ручного подключения стороннего сервера начинается с меню профиля: добавить аккаунт → «Другой» → личный аккаунт IMAP. Далее ввожу адрес и параметры из карточки подключения. Названия пунктов зависят от локализации и версии. Порты и режим защиты беру из того же проверенного набора, что использовал на iPhone; смена марки телефона сама по себе не меняет настройки сервера.

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

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

В Android режимы Doze и App Standby могут откладывать фоновую сетевую активность. Документация не устанавливает общую задержку ровно в час и не требует универсального разрешения Google Play Services для всех сторонних ящиков. Я проверяю ограничения конкретного приложения и меняю их адресно, если тест подтвердил влияние. После изменения повторяю получение на заблокированном устройстве, затем отправку через мобильную сеть. Отключить энергосбережение всему телефону — выразительный жест, но результат проверки нужен и после него. Если штатный клиент не даёт нужного режима доставки, согласую поддерживаемую альтернативу.

• Письма нет на сервере — проверить доставку до ящика.
• На сервере есть, в приложении нет — проверить подключение и синхронизацию.
• В приложении есть, сигнала нет — проверить уведомления.
• Не уходит ответ — отдельно проверить SMTP и авторизацию.

Как проверить папки и сохранить старую переписку

Старый профиль я сохраняю на время сверки, если сервис ещё доступен. Но название «Архив» не превращает кэш приложения в резервную копию: телефон может хранить только часть содержимого, а доступ зависит от старой учётной записи. Для защиты истории нужна отдельная проверенная копия и контроль переноса на новом сервере. Удаление учётной записи с iPhone само по себе не закрывает ящик у провайдера; зато локальные данные и несохранённые черновики надо проверить заранее. Смешивать удаление профиля, удаление писем и закрытие сервиса нельзя.

Проверяю не только входящие. Важен контроль соответствия служебных папок: отправленные сообщения и удалённые письма должны попадать в нужные папки IMAP. Официальная инструкция Яндекса для The Bat! Показывает это на сопоставлении Sent и Deleted; на телефонах названия и интерфейс могут отличаться. Поэтому я отправляю новое письмо, сохраняю тестовый черновик и перемещаю специально созданное тестовое сообщение в корзину. Затем смотрю результат в веб-интерфейсе нового сервера. Автоматически создавать вторую папку с похожим названием до этой проверки не советую.

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

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

• Проверить старые письма и вложения на новом сервере.
• Сопоставить отправленные, черновики и корзину.
• Использовать только специально созданные сообщения для проверки удаления.
• Убедиться, что контакты и календари перенесены своим способом.

Как подключить остальных и закрыть старый доступ

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

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

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

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

Итог для этого примера — двенадцать заполненных карточек устройств, сверенный архив и отдельные отметки по контактам и календарям. Это критерий завершения условного проекта, не отчёт о реальном клиенте. Только после него я назначаю удаление старых мобильных профилей и закрытие лишних доступов; отключение старого сервиса согласую отдельно. Время хранения источника зависит от результатов сверки и договорённостей, а не от красивого круглого срока. Мы можем выполнить весь этот порядок за компанию: подготовить подключения, провести пилот и выдать проверенные результаты.

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

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