Как я проверяю права общих ящиков Яндекс 360

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

Как отличить общий ящик от рассылки

Первым делом я выясняю, что скрывается за адресом отдела. В Яндекс 360 общий ящик — самостоятельный объект без конкретного владельца, а делегированный — ящик сотрудника, доступ к которому открыли коллегам. Группа рассылки доставляет сообщения участникам. Алиас добавляет адрес существующему ящику. Одинаковое имя sales@example.com ещё ничего не говорит об устройстве почты. В проектах по переносу корпоративной почты я начинаю с этой классификации: иначе можно сохранить адрес, но потерять привычный способ работы отдела.

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

Алиас в Яндекс 360 не рассылает письмо сразу нескольким сотрудникам: входящее попадает в тот ящик, к которому добавлен дополнительный адрес. При разрешённых настройках с алиаса можно и отправлять письма. Поэтому я убираю ложный выбор между «быстрым алиасом» и «медленным общим ящиком». Это разные задачи. Если нужна доставка нескольким людям, я проверяю группу или правила пересылки. Если нужна единая переписка отдела, я выбираю совместное хранилище и заранее определяю порядок работы с ответами.

Я также проверяю связи, которые легко пропустить при выгрузке списка сотрудников: адрес на сайте, получателей уведомлений, автоответы, правила сортировки и пересылки. Доступ к папке на Диске не доказывает доступ к почтовому ящику: это отдельные настройки разных сервисов. Вместо требования показать «историю прав за год» я сохраняю текущие назначения и доступные записи аудита; наличие нужной глубины журнала сначала проверяю. Общий порядок переноса адресов уже разобран в статье про ящики, алиасы и рассылки. Здесь я проверяю именно права и результат работы сотрудника.

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

Какие права нужно перенести отдельно

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

В Exchange разрешение Full Access позволяет открыть ящик, просматривать, добавлять и удалять содержимое, но не включает отправку. Send As разрешает отправить письмо так, чтобы получатель видел общий ящик отправителем. Send on Behalf показывает, что сотрудник пишет от имени этого ящика. Я согласую нужный вариант с руководителем отдела и проверяю письмо на внешнем получателе. Добавление ящика в Outlook не назначает ни одно из этих разрешений на сервере. Меню клиента не выдаёт доверенность, как бы убедительно оно ни выглядело.

Различие режимов есть и в Яндекс 360. В веб-интерфейсе совместного ящика поддерживается отправка «как», а возможность отправки «от имени» в почтовой программе зависит от выданных прав и поддержки клиента. Поэтому я записываю ожидаемый вид отправителя до переезда. Если раньше адрес сотрудника был виден, а после исчез, это изменение рабочего процесса, даже когда письмо успешно доставлено. Названия Full Access и Send As я использую только в контексте Exchange; на другой платформе проверяю её собственные роли и ограничения.

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

Где искать историю и как сохранить папки

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

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

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

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

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

Как я провожу пилот на условной лаборатории

Для разбора беру заданную лабораторию «Метр и проба», Москва, 26 рабочих мест. Это условный сценарий проверки, а не отчёт о состоявшемся проекте. Для примера закладываю два общих адреса: sales@example.com и buh@example.com. Домены и адреса здесь демонстрационные. Количество рабочих мест не означает, что всем нужен доступ к обоим ящикам: отдел продаж работает со своей перепиской, бухгалтерия — со своей. До настройки я получаю согласованный список участников и действий, включая отдельно оговорённый доступ руководителя.

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

Матрицу пилота я оформляю до назначения прав. В этом сценарии она выглядит так; разрешения на изменение и удаление записываю отдельными колонками в рабочем реестре, поскольку одного разрешения читать для их описания недостаточно. | Роль пилота | История продаж | Ответ с общего адреса | |---|---|---| | Сотрудник продаж | Доступна | Разрешён | | Согласованный наблюдатель | Доступна | Запрещён | | Посторонний сотрудник | Недоступна | Запрещён |

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

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

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

Почему общий ящик не виден в Outlook

Если ящик открывается в браузере, но отсутствует в Outlook, я не объявляю виновными права без проверки. Сначала уточняю целевую систему, используемый клиент, тип подключения и учётную запись. Затем проверяю назначенные разрешения, способ добавления ящика, авторизацию и ошибки соединения. В Exchange Online автоматическое подключение к профилю работает при определённых условиях; выдача Full Access через группу не включает такое подключение для её участников. Отсутствие ящика в списке папок ещё не доказывает отсутствие серверного доступа.

В Яндекс 360 для совместного ящика почтовую программу настраивают по отдельной инструкции. В ней используется технический логин вида example.com/user/shared и собственный пароль приложения сотрудника. Это пример формата, а не готовые реквизиты для входа. Пароль чужой учётной записи для совместного доступа не нужен. Я сверяю настройку с документацией именно этого режима: обычное добавление личного IMAP-ящика и подключение делегированного ящика решают разные задачи. Запись в адресной строке «От кого» также не заменяет право отправки.

Отдельный тест — общие «Отправленные». В Exchange Online письмо, отправленное делегатом, может сохраняться в его личной папке, поэтому наличие общего ящика ещё не обеспечивает общую историю ответов. Я проверяю сохранение копии для нужного режима отправки на стороне сервера. На другой платформе проверяю её механизм, а не переношу настройку Exchange по памяти. После изменения отправляю новое тестовое письмо и открываю его из учётной записи второго участника. Если ответ видит только автор, задача совместной переписки ещё не решена.

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

Когда можно отключать старую почту

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

Если в переходный период нужна пересылка, я проверяю отдельный адрес назначения или явно настроенный маршрут и исключаю возврат письма по кругу. Само правило sales@example.com → sales@example.com не задаёт доставку на другой сервер. Обычная пересылка Яндекс Почты обрабатывает новые входящие; она не переносит уже накопленный архив и отправленные письма. Поэтому её нельзя считать проверкой всей истории. Условия, подтверждение адреса и сохранение копии проверяю заранее. Подробности разобраны в статье про пересылку на переходный период.

Резервную копию я делаю до изменений и обновляю перед окончательным отключением источника. В официальной справке Яндекс Почты экспорт писем описан через почтовые программы; универсальную кнопку «Экспорт данных» для всей корпоративной почты я не обещаю. Сначала убеждаюсь, что выбранный клиент получил нужные сообщения полностью, затем сохраняю их поддерживаемым способом и проверяю открытие копии отдельно от рабочего ящика. Настройки доступа и список участников сохраняю отдельным документом. Архив писем не заменяет описание того, кому и что было разрешено.

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

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