Почему в Zimbra любой сотрудник всё ещё может писать в all@, хотя разрешён только директор

Если после zmprov grr список рассылки all@ всё равно принимает письма от любого сотрудника, дело почти никогда не в опечатке в команде. Грант sendToDistList сам по себе — лишь запись в LDAP: письма к списку проверяет сервис Zimbra milter, и если он выключен или остановлен, ограничение не действует. Разбираю, как устроены права списков, где их проверяют и как убедиться, что запрет реально работает.

Почему список рассылки по умолчанию открыт для всех

В Zimbra списки рассылки (distribution list, DL) — это объект каталога со своим набором ACL-прав, а не просто перечень адресов. Право sendToDistList определяет, кто может отправлять письма на адрес списка. Admin Guide формулирует исходное состояние прямо: по умолчанию все пользователи могут писать во все списки рассылки. Пока на списке нет ни одного гранта sendToDistList, он открыт — и это нормальное поведение, а не дыра.

Ограничение появляется, когда на список выдают право: команда zmprov grr dl all@example.com usr director@example.com sendToDistList в документации так и подписана — доступ только конкретным внутренним пользователям. Статья базы знаний про milter уточняет механику: при включённом milter-сервере писать смогут только те, кому явно выдано право. Ключевые слова — «при включённом». Без milter грант лежит в LDAP мёртвым грузом, и почтовый поток его никак не учитывает. Именно на этом чаще всего спотыкается предыдущий подрядчик: право выдано, задача формально выполнена, а поведение списка не изменилось.

При настройке корпоративной почты я закрываю такие списки в три действия, а не в одно: выдаю право нужным людям, убеждаюсь, что milter включён и запущен на каждом MTA, и применяю изменения через zmmtactl reload. Итог я всегда проверяю командой ckr и одним реальным тестовым письмом от рядового ящика, а не полагаюсь на историю команд в shell.

Как закрыть список рассылки правильно — грант, milter и reload

Чтобы писать в all@ мог только директор, достаточно одного положительного гранта на сам список — но при условии, что milter работает. Для нескольких разрешённых отправителей удобнее выдать право группе. После каждого grr или rvr KB требует выполнить reload MTA.

zmprov grr dl all@example.com usr director@example.com sendToDistList
zmprov grr dl all@example.com grp managers@example.com sendToDistList
zmmtactl reload

Типы получателей права (grantee) стоит различать. usr — конкретный пользователь, grp — члены другого списка, dom — все пользователи домена, all — все внутренние (локальные) пользователи сервера, pub — вообще все, включая внешних отправителей, edom и gst — внешний домен и конкретный внешний адрес. Префикс «-» перед правом означает явный запрет: он нужен, когда список открыт широкому кругу (например, dom), но одному ящику писать туда нельзя — zmprov grr dl all@example.com usr intern@example.com -sendToDistList. Для задачи «пишет только директор» явный запрет всем не требуется: грант директору уже сужает круг.

Если разрешённых отправителей несколько и они уже объединены в список-группу, вместо usr указывают grp с адресом этой группы — тогда при кадровых изменениях достаточно поменять её состав, не трогая права all@. Отдельно стоит держать в голове вложенность: по KB, права родительского списка (например, pub) наследуются вложенными списками. Чтобы грант не распространялся на дочерние списки, перед правом ставят префикс «^»: zmprov grr dl parent@example.com pub ^sendToDistList. Проверять наследование нужно явно, а не по аналогии с правами папок в файловой системе.

При чём тут milter и почему выданное право может вообще не сработать

Право в каталоге и его реальное применение при доставке письма — разные вещи. Фактическую проверку прав отправителя на уровне MTA выполняет отдельный сервис — Zimbra milter. Admin Guide прямо описывает его роль: milter-сервер ограничивает, какие адреса могут писать в списки рассылки, и заодно добавляет письмам из списков заголовки Reply-To и X-Zimbra-DL. Если он не включён или не работает, Postfix пропускает письма в список рассылки без всякой проверки права, независимо от того, что записано в LDAP: грант директору в этом случае просто не проверяется.

Включение milter — отдельный шаг: глобально zmprov mcf zimbraMilterServerEnabled TRUE или на конкретном MTA zmprov ms mta.example.com zimbraMilterServerEnabled TRUE; KB подчёркивает, что включать его нужно только на серверах с ролью MTA. После этого milter стартует вместе с zmcontrol start, а вручную — zmmilterctl start. После каждой выдачи или отзыва прав изменения применяют командой zmmtactl reload — она перечитывает конфигурацию MTA без полного перезапуска почты. Проверить текущее состояние сервиса можно командой zmmilterctl status: если она показывает, что сервис не запущен, никакие права из zmprov grr физически не будут проверяться при доставке письма, и это никак не будет видно из самого письма — оно просто пройдёт, будто ограничения нет вообще.

На практике я встречал оба варианта поломки по отдельности и вместе: milter вообще не был включён атрибутом zimbraMilterServerEnabled — и грант оставался записью в каталоге; либо milter включали, но после очередного перезапуска он не поднялся, а reload после выдачи прав никто не делал. Бывает и третий вариант: на список кто-то когда-то выдал широкий грант all или pub, и новый грант директору просто добавился к нему. Симптом для директора во всех случаях один: «настроили, а не работает».

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

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

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

zmprov ckr dl all@example.com ivanov@example.com sendToDistList
zmprov ckr dl all@example.com director@example.com sendToDistList

Результат — ALLOWED или DENIED; для ALLOWED ckr в блоке «Via» показывает, откуда пришло право: тип цели, сам список (в том числе родительский), тип получателя гранта. Для рядового сотрудника после правильной настройки должно быть DENIED, для директора — ALLOWED. Если сотрудник получает ALLOWED, смотрите в «Via»: обычно там широкий грант all, dom или pub — на этом списке или унаследованный от родителя. Важно помнить: ckr проверяет только ACL в каталоге, а не работу milter. Зелёный ckr при остановленном milter ничего не гарантирует — поэтому финальная проверка у меня всегда реальным письмом от тестового ящика, который должен получить отказ «not authorized to send messages to the recipient distribution list».

Если право нужно отозвать полностью, используется отдельная команда rvr, а не повторный grr с другим значением: zmprov rvr dl all@example.com usr ivanov@example.com sendToDistList. KB прямо говорит: чтобы удалить или изменить права, используют rvr, а не grr; после этого — снова zmmtactl reload. Операции «изменить существующее» нет — только «выдать» и «отозвать», поэтому при пересмотре списка разрешённых отправителей я сначала явно отзываю всё лишнее, а затем выдаю заново то, что нужно оставить, и проверяю результат тем же ckr.

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

Когда список рассылки в компании не один — например, all@, sales@, support@ и несколько списков по отделам — проверять права вручную по каждому долго и легко что-то пропустить. Список всех DL в домене выводит zmprov gadl example.com (Get All Distribution Lists), а дальше по каждому адресу можно прогнать ту же проверку ckr в цикле, не открывая консоль администратора для каждого списка отдельно.

for dl in $(zmprov gadl example.com); do
  echo "== $dl =="
  zmprov ckr dl "$dl" ivanov@example.com sendToDistList
done

Такой прогон быстро показывает, какие списки на самом деле ограничены грантом, а какие остались открытыми просто потому, что до них не дошли руки, когда закрывали all@. В моей практике почти всегда находится хотя бы один список — например, старый sales@, заведённый ещё до текущего администратора — где право никогда не настраивали вообще, и он честно открыт для всех, включая порой внешних отправителей через pub. Полную картину грантов конкретного списка даёт zmprov gdl all@example.com | grep zimbraACE: каждая строка — идентификатор получателя, его тип (usr, grp, dom, all, pub) и право; так сразу видно забытый pub, открывающий список внешнему миру.

Итог такой проверки стоит зафиксировать отдельным документом или таблицей: список рассылки, кому реально можно писать, у кого есть широкие гранты вроде all или pub, дата последней проверки. Это не бюрократия ради галочки — при следующей жалобе «кто-то написал не по адресу» такая таблица экономит время на диагностику: сразу видно, было ли ограничение задумано вообще, или список изначально считался открытым для всех сотрудников. Та же таблица пригодится при отзыве доступов при увольнении: ушедшего сотрудника нужно убрать и из грантов sendToDistList, а не только заблокировать его ящик.

Кейс: ремонтная мастерская «Точная наладка», 18 рабочих мест

Условный клиент — ремонтная мастерская бытовой техники «Точная наладка», 18 рабочих мест: приёмка, мастера, склад запчастей и бухгалтерия. Директор попросил ограничить рассылку на all@, потому что менеджеры приёмки регулярно писали туда бытовые объявления, и важные письма о графике смен и поставках тонули в переписке не по делу. Предыдущий подрядчик выполнил zmprov grr dl all@example.com usr director@example.com sendToDistList, отчитался о выполнении задачи и закрыл заявку.

Через две недели директор снова написал: ограничение не работает, менеджеры продолжают свободно писать в all@. Проверка zmprov ckr dl all@example.com <адрес менеджера> sendToDistList вернула DENIED, для директора — ALLOWED: с точки зрения каталога всё было настроено верно. Тестовое письмо с ящика менеджера при этом спокойно дошло до всех 18 адресатов. Разрыв между «права верны» и «письмо прошло» указывал не на ACL, а на то, кто их применяет при доставке.

Проверили статус milter командой zmmilterctl status и обнаружили, что сервис на сервере не запущен: атрибут zimbraMilterServerEnabled у сервера стоял FALSE — подрядчик выдал грант, но сам milter не включил, а reload после выдачи права не выполнял. Включили milter на MTA через zmprov ms, запустили zmmilterctl start, выполнили zmmtactl reload и повторили тест реальным письмом: менеджер получил отказ о том, что не имеет права писать в список, письмо директора ушло всем. Заодно zmprov gdl all@example.com | grep zimbraACE подтвердил, что на списке нет забытых грантов all или pub.

Отдельно сверили список repair-team@ для мастеров, который физически входил в all@ дочерним списком: ограничивать его не требовалось, мастера должны были свободно писать друг другу по рабочим вопросам, запрет касался только прямой рассылки на all@ от лиц не из руководства. Заодно прогнали цикл по всем спискам рассылки компании через zmprov gadl — кроме all@ нашёлся ещё один открытый список, support@ для заявок клиентов на ремонт, на котором стоял грант pub — туда может написать кто угодно снаружи. Директор подтвердил, что этот список специально держат открытым для клиентов, поэтому его не трогали, но занесли в ту же таблицу проверки как осознанное исключение, а не забытый случай.

Итог зафиксировали письменно в регламенте: любое изменение прав списка рассылки проверяется командой ckr сразу после применения, реальным тестовым письмом, а статус milter — отдельным пунктом после каждого обновления и перезапуска Zimbra. С момента исправления посторонних писем в all@ не было четыре месяца — по словам директора, впервые за два года ограничение реально держится, а не просто числится в настройках.

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