Как открыть общие календари и адресные книги SOGo между двумя доменами одного mailcow

На одном mailcow часто крутится несколько доменов, и по умолчанию SOGo держит их изолированными — сотрудники разных доменов не находят друг друга в поиске. Если двум командам нужно делиться календарями, а остальные домены трогать нельзя, помогает параметр SOGoDomainsVisibility. Показываю точный синтаксис и что он реально открывает на кейсе PR-агентства с двумя брендовыми доменами.

По умолчанию домены в SOGo друг друга не видят — и это правильно

Когда я разворачиваю корпоративную почту на mailcow для компании с несколькими юрлицами или брендами, часто оказывается удобнее держать их как отдельные домены на одном сервере, а не разносить по разным инсталляциям. Это же поведение видно на мультитенантных площадках, где на одном mailcow живёт сразу несколько независимых клиентов. SOGo по умолчанию изолирует домены друг от друга: пользователь домена А не найдёт коллегу из домена Б ни в адресной книге, ни при попытке расшарить календарь — с точки зрения SOGo это два разных, ничем не связанных мира.

Это осознанное поведение, а не недоработка. На сервере, где почтовый провайдер или ИТ-подрядчик обслуживает несколько клиентов через один mailcow, изоляция доменов — это ровно то, что нужно по умолчанию: сотрудники клиента А не должны даже теоретически видеть в поиске сотрудников клиента Б. Проблема возникает только тогда, когда два домена на одном сервере принадлежат одной организации или связанным брендам и им действительно нужно делиться расписанием.

Я специально проверяю это поведение на каждом новом мультидоменном mailcow, который принимаю на обслуживание: завожу тестового пользователя в каждом домене и убеждаюсь, что поиск по адресной книге между ними действительно пустой. Один раз обнаружил, что предыдущий подрядчик клиента когда-то открыл видимость между всеми доменами разом «для удобства» и забыл об этом — сотрудники двух формально не связанных компаний годами могли видеть друг друга в общем поиске SOGo, просто никто не обращал внимания.

SOGoDomainsVisibility: где живёт настройка и как выглядит синтаксис

Параметр, который управляет видимостью доменов друг для друга, — SOGoDomainsVisibility, задаётся в конфиге data/conf/sogo/sogo.conf. По умолчанию значение — пустой массив, то есть та самая изоляция, описанная выше. Документация mailcow даёт пример для трёх доменов: SOGoDomainsVisibility = ((example.org, example.com, example.net));, а сама SOGo подтверждает формат — это массив массивов, где каждая внутренняя группа скобок описывает набор доменов, видимых друг другу.

Формат именно так и работает — группами, а не общим списком: можно указать несколько независимых групп в одном параметре, и домены из разных групп друг друга не увидят, даже если оба параметра заданы в одном SOGoDomainsVisibility. Например, ((brand-a.ru, brand-b.ru), (partner-x.ru, partner-y.ru)) — две отдельные пары, не связанные между собой. Именно эта возможность и решает задачу мультитенантного mailcow: открыть видимость только между нужными доменами, не трогая остальных клиентов на том же сервере.

После изменения sogo.conf настройка не подхватывается на лету — нужно перезапустить контейнер командой docker compose restart sogo-mailcow (или docker-compose restart sogo-mailcow для Standalone-версии Docker Compose). Я всегда проверяю после рестарта, что конфиг синтаксически корректен: sogo.conf — это plist-формат, и лишняя или недостающая скобка либо точка с запятой в SOGoDomainsVisibility ломает разбор файла, поэтому сразу после рестарта смотрю docker compose logs --tail=50 sogo-mailcow и открываю веб-интерфейс, а не считаю задачу выполненной по факту рестарта.

В самом файле sogo.conf, который поставляется с mailcow по умолчанию, уже есть закомментированный пример именно на две независимые группы: блок // SOGoDomainsVisibility = ( (domain1.tld, domain5.tld), (domain3.tld, domain2.tld) ); под комментарием «Multi-domain setup. Domains are isolated, you can define visibility options here». Я обычно не удаляю этот комментарий при правке, а дописываю рядом свою группу — так следующему администратору видно, что это штатный механизм mailcow, а не самодеятельность, оставленная кем-то без объяснений.

Видимость — это не то же самое, что доступ к календарю

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

Реальный доступ к чужому календарю или адресной книге в SOGo всегда выдаётся вручную и децентрализованно: каждый пользователь сам, через список прав доступа (Access Control List) в интерфейсе SOGo, назначает конкретным коллегам права — причём для календаря отдельно по категориям событий (публичные, конфиденциальные, личные): только дата и время (DAndTViewer), полный просмотр (Viewer), ответ на приглашения (Responder) или редактирование (Modifier), плюс отдельные права на создание и удаление событий. В интерфейсе они называются «View the Date & Time», «View All», «Respond To», «Modify». Штатного механизма, которым администратор домена одним действием сделает календарь сотрудника общим для всех, в mailcow нет: роли по умолчанию (SOGoCalendarDefaultRoles) лишь подставляются, когда владелец сам добавляет человека в список доступа, а суперпользователь SOGoSuperUsernames — инструмент для служебных интеграций, а не для раздачи доступа. Решает владелец календаря.

SOGo дополнительно умеет уведомлять по почте о том, что права доступа к календарю или адресной книге изменились — за это отвечает параметр SOGoACLsSendEMailNotifications. Я включаю его на всех мультидоменных инсталляциях: это простой способ дать пользователю понять, что кто-то из другого домена только что получил доступ к его расписанию, и вовремя это заметить, если доступ выдали по ошибке.

Почему нельзя просто добавить все домены в одну группу

На мультитенантном mailcow, где под одной инсталляцией живут несколько независимых клиентов ИТ-подрядчика, соблазн решить любую заявку «сделайте видимость между доменами» одной большой группой — самая частая ошибка, которую я вижу у коллег. SOGoDomainsVisibility применяется на уровне всей инсталляции SOGo, а не персонально для конкретного пользователя: если добавить в одну группу три домена ради одной заявки, все пользователи всех трёх доменов внезапно смогут искать и добавлять друг друга — включая тех, для кого это вообще не планировалось.

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

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

Кейс: PR-агентство «PR-гавань», 11 рабочих мест

У клиента — PR-агентства «PR-гавань» на 11 рабочих мест — на одном mailcow, который я же и обслуживаю, крутится несколько доменов: основной домен агентства, домен смежного бренда digital-подразделения, который агентство ведёт как отдельное юрлицо с частично тем же составом сотрудников, и ещё два домена совершенно других клиентов подрядчика, к агентству отношения не имеющих. Задача — чтобы дизайнеры и аккаунт-менеджеры видели общий календарь встреч между агентством и digital-брендом, но чтобы остальные два домена на сервере остались как были: полностью изолированными.

Решение заняло десять минут правки конфига: в SOGoDomainsVisibility добавил ровно одну группу из двух нужных доменов агентства, ничего не трогая для двух других клиентских доменов на этом же mailcow. После docker compose restart sogo-mailcow аккаунт-директор агентства расшарила свой календарь встреч с клиентами коллеге из digital-бренда с ролью Viewer — теперь при планировании общих питчей видно, что уже занято с обеих сторон, без звонков «а ты свободен в четверг».

Отдельно включил SOGoACLsSendEMailNotifications: агентство работает с конфиденциальными брифами клиентов, и владелец календаря должен точно знать, если кто-то получил к нему доступ. За месяц эксплуатации ни один из двух посторонних клиентских доменов на сервере ни разу не появился в поиске у сотрудников PR-агентства — группа осталась минимальной, как и планировалось.

Как внедрить это безопасно на своём mailcow

Порядок действий, которого я придерживаюсь на любой мультидоменной инсталляции: сначала фиксирую точный список доменов, которым реально нужна взаимная видимость, и ничего сверх этого списка. Затем открываю data/conf/sogo/sogo.conf, нахожу закомментированную или пустую строку SOGoDomainsVisibility и добавляю ровно одну группу из нужных доменов — по синтаксису массива массивов, как в примере документации. Отдельно проверяю, не попал ли по невнимательности в скобки домен, который туда не планировался: забытая пара внутренних скобок — ((a.ru, b.ru, c.ru)) вместо ((a.ru, b.ru), (c.ru, d.ru)) — объединит в одну группу домены, которые должны были остаться раздельными.

После правки — обязательный docker compose restart sogo-mailcow, и сразу проверка на тестовом пользователе из каждого затронутого домена: находится ли коллега из соседнего домена через поиск, и — отдельно — не открылся ли доступ к его календарю без явного расшаривания через ACL. Я всегда прошу представителя клиента подтвердить: именно эти домены и именно в эту сторону, потому что цена ошибки в мультидоменной группировке — это чужие календари, которые вдруг стали видны не той компании.

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

И последнее, о чём часто забывают: изменение SOGoDomainsVisibility не требует остановки почты целиком, а затрагивает только контейнер sogo-mailcow. Postfix и Dovecot продолжают принимать и доставлять письма во время рестарта SOGo, так что менять эту настройку можно в рабочее время, не предупреждая всю компанию о плановых работах — недоступной на несколько секунд окажется только веб-почта и синхронизация календарей, а не приём писем.

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