Как разрешить сотруднику отвечать от имени общего ящика и его алиаса в Zimbra

Доступ к папкам общего ящика в Zimbra не даёт права отвечать от его имени — это два разных разрешения, и путают их постоянно. Ниже — как я выдаю право sendAs именно на нужный адрес, включая алиас, без обходных путей через zimbraAllowFromAddress, которые в ZCS 8+ для внутренних учёток просто не работают.

Доступ к папкам и право отправки — не одно и то же

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

В Zimbra Collaboration Suite (ZCS) 8 и новее для этого есть системное право sendAs, которое выдаётся не персоне и не алиасу, а конкретной учётной записи — целиком отдельно от прав на доступ к папкам. Есть и соседнее право sendOnBehalfOf — оно не заменяет sendAs, а решает другую задачу: письмо уходит с пометкой «от имени», а не как будто отправитель — сам владелец ящика. Спутать их легко, а вот заново объяснять клиенту, почему ответы уходят не с того адреса — уже не так приятно, поэтому я сразу уточняю, какой именно эффект нужен.

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

Почему zimbraAllowFromAddress не подходит для внутренних учёток

До восьмой версии ZCS администраторы иногда решали похожую задачу через атрибут zimbraAllowFromAddress — он разрешает учётной записи указывать в поле «От» произвольный адрес. Но начиная с ZCS 8 этот атрибут предназначен только для внешних адресов. Если попытаться добавить в него внутреннюю учётную запись или список рассылки того же домена, сервер вернёт ошибку service.INVALID_REQUEST с текстом вида «zimbraAllowFromAddress may not contain an internal account» — эту проверку делает callback атрибута в исходниках zm-mailbox — Zimbra явно не позволяет использовать zimbraAllowFromAddress для внутренних адресов начиная с этой версии.

Практический вывод: если у вас общий ящик и оба адреса — внутри одного и того же домена Zimbra, единственный правильный путь — системное право sendAs, а не атрибут zimbraAllowFromAddress. Обходные схемы через этот атрибут для внутренней делегированной отправки в современных версиях ZCS не работают и приводят только к потере времени на отладку ошибки INVALID_REQUEST.

Отдельно напоминаю клиентам: zimbraAllowFromAddress никуда не делся и остаётся рабочим инструментом, но для другой ситуации — когда сотруднику компании нужно отправлять письма от внешнего адреса, который реально существует вне вашего домена Zimbra (например, унаследованный адрес на другом провайдере, который постепенно выводят из эксплуатации). Путать эти два сценария не стоит: один — про внешние адреса и работает через zimbraAllowFromAddress, второй — про внутреннюю делегированную отправку внутри одного домена и работает только через право sendAs. Это же разграничение внутренних и внешних адресов я держу в голове при настройке SPF и DKIM: если письма от делегированного адреса начинают улетать в спам при формально валидных SPF, DKIM и DMARC, первым делом проверяю, не ушло ли письмо от адреса, которого нет в SPF-записи домена — с sendAs адрес отправителя остаётся вашим доменным, поэтому эта проблема возникает реже, чем при обходных схемах через внешние адреса.

Как выдать право sendAs через zmprov

Целью гранта (target) всегда указывается основная учётная запись общего ящика — не алиас и не персона, а получателем права (grantee) — сотрудник, который будет отправлять:

zmprov grr account owner@example.com usr delegate@example.com sendAs

Здесь owner@example.com — общий ящик, от имени которого должна уходить почта, delegate@example.com — сотрудник, которому даём право. Если нужен ещё и эффект «отправлено от имени», право добавляется отдельно тем же способом с именем sendOnBehalfOf вместо sendAs — это самостоятельное право, не производное от sendAs.

Проверить, что право действует, можно командой checkRight (ckr) — она отвечает ALLOWED или DENIED и показывает, через какой грант право получено; полный список грантов на ящике выводит getGrants (gg):

zmprov ckr account owner@example.com delegate@example.com sendAs
zmprov gg -t account owner@example.com

Команду getAllEffectiveRights для этого не используйте: она принимает не целевой ящик, а grantee (gaer usr delegate@example.com) и выдаёт огромную простыню всех эффективных прав сотрудника, в которой нужная строка теряется. После выдачи права новый адрес для отправки должен появиться в выпадающем списке «От» в веб-клиенте у сотрудника — но не мгновенно: клиенту в браузере нужно обновить сессию. Если список «От» не обновился сразу после zmprov, сначала просят пользователя выйти и зайти заново или обновить страницу, прежде чем искать ошибку в правах — в большинстве случаев дело именно в кэше сессии веб-клиента.

Отдельный момент — с кого именно снимать право, если сотрудник меняет отдел или увольняется. Отзыв делается не заново через grr, а зеркальной командой revokeRight (сокращённо rvr) с тем же набором параметров:

zmprov rvr account owner@example.com usr delegate@example.com sendAs

Я всегда проверяю после отзыва через zmprov ckr, что право реально снято (ответ DENIED), а не осталось действовать через другой путь — например, если сотруднику ранее так же выдавали sendAs не лично, а через группу рассылки, отзыв персонального гранта права группы не отменит.

Как добавить в делегированную отправку именно алиас, а не только основной адрес

Отдельная тонкость — когда сотруднику нужно отправлять не от основного адреса общего ящика, а от его алиаса (например, у ящика sales@example.com есть алиас zakupki@example.com, и делегату нужен именно он). Право sendAs, выданное на аккаунт, само по себе не определяет, какие конкретно адреса появятся в списке «От» — за это отвечает отдельный атрибут zimbraPrefAllowAddressForDelegatedSender, который выставляется на самом делегирующем аккаунте (или списке рассылки):

zmprov ma owner@example.com +zimbraPrefAllowAddressForDelegatedSender "zakupki@example.com"

Это multi-value атрибут (появился в ZCS 8.0): добавлять новый адрес нужно через +, убирать — через -zimbraPrefAllowAddressForDelegatedSender, полностью заменять список — без модификатора. Вписать туда можно только основной адрес или алиас этого же ящика: чужой адрес callback атрибута отклонит ошибкой INVALID_REQUEST «value is not one of the addresses of the entry».

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

zmprov ga owner@example.com zimbraPrefAllowAddressForDelegatedSender

Я завёл себе простое правило для любой настройки общего ящика с алиасами: сразу после выдачи sendAs записываю полный список адресов, которые должны быть доступны для отправки, и одной командой привожу zimbraPrefAllowAddressForDelegatedSender в соответствие с этим списком, а не добавляю адреса по одному по мере жалоб пользователей. Это отдельный шаг, который легко забыть, потому что право sendAs формально уже выдано и кажется, что настройка закончена — а по факту без этого атрибута доступен обычно только основной адрес ящика, без алиасов. Такую же дисциплину — фиксировать итоговый список настроек одним прогоном, а не точечными правками по жалобам — я закладываю и в чек-лист хардненинга Zimbra из 16 пунктов: делегирование отправки в него стоит добавлять отдельным пунктом, если у компании есть общие ящики.

Sent-копия и что видит получатель

При использовании sendAs получатель в заголовке «От» видит адрес общего ящика — так, будто письмо отправил сам владелец, без пометок о делегировании. При sendOnBehalfOf в большинстве почтовых клиентов получателя показывается формулировка вида «имя делегата от имени owner@example.com» — разница заметна получателю, и для службы поддержки, где клиенты не должны видеть, кто именно из сотрудников отвечает, обычно выбирают sendAs, а не sendOnBehalfOf.

Куда падает копия отправленного письма — вопрос, который стоит проговорить с заказчиком заранее. С ZCS 8.6 за это отвечает атрибут zimbraPrefDelegatedSendSaveTarget на учётной записи, от имени которой отправляют: owner (по умолчанию — в «Отправленные» общего ящика), sender (в «Отправленные» делегата), both или none. В исходниках MailSender он читается у ящика-владельца при делегированной отправке, поэтому для поддержки, где вся команда должна видеть ответы коллег, я ставлю zmprov ma support@example.com zimbraPrefDelegatedSendSaveTarget both. Поведение отдельных клиентов (IMAP-клиенты кладут копию в Sent сами) всё равно проверяю тестовым письмом сразу после настройки — это минута работы.

Ещё один практический момент — уведомление клиента о том, что письмо пришло не лично от делегата. В службах поддержки и в компаниях, где важна анонимность конкретного сотрудника за общим адресом (например, чтобы клиент не писал напрямую личному адресу одного специалиста, минуя очередь), выбор в пользу sendAs — осознанное решение, а не просто «более простой» вариант. А там, где, наоборот, важно, чтобы клиент видел, кто конкретно из команды отвечает — от делегата или отдела — уместнее sendOnBehalfOf, несмотря на то что тогда в заголовках письма видна дополнительная строка.

Кейс: трастовая компания «Траст Капитал», три сотрудника и один входящий ящик поддержки

В «Траст Капитал» (35 рабочих мест) на входящий ящик support@ отвечали три сотрудника клиентского отдела по очереди. Раньше это делали через общий пароль от ящика — де-факто все три человека логинились под одной учётной записью, что плохо и с точки зрения аудита, и с точки зрения безопасности: если кто-то из них уходит, надо было бы менять общий пароль и переучивать оставшихся заново заходить.

Я развёл это на три личных аккаунта с папкой общего ящика, расшаренной всем троим для чтения и ответа, и выдал каждому право sendAs на support@example.com командой zmprov grr account support@example.com usr <сотрудник>@example.com sendAs. Отдельно проверил zimbraPrefAllowAddressForDelegatedSender на аккаунте support@ — там уже был указан алиас help@example.com, который клиенты компании знали по старой рассылке; я оставил в атрибуте оба адреса, и основной, и алиас, чтобы ни один из трёх сотрудников не потерял возможность отправлять именно с привычного клиентам адреса. Заодно включил на все три личных аккаунта двухфакторную аутентификацию в Zimbra OSE — раз мы всё равно переводили компанию с общего пароля на личные учётные записи, было логично сразу закрыть и этот момент, а не возвращаться к нему отдельным проектом позже.

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

Для директора «Траст Капитал» главным аргументом оказалась не удобство, а именно аудит: раньше в логах Zimbra все три сотрудника выглядели одинаково, потому что входили под одной учётной записью, и разобрать, кто именно из троих ответил конкретному клиенту, можно было только через ручной опрос команды. После перехода на личные учётные записи с правом sendAs в логах виден реальный отправитель, а адрес получателя по-прежнему остаётся привычным клиентам support@ или help@ — требование безопасности и требование удобства клиентов закрылись одной и той же настройкой.

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