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

Дать сотрудникам доступ к info@ в mailcow под их собственными логинами можно без единого общего пароля, но настраиваются для этого три вещи, а не одна: делегирование ящика в SOGo, общий доступ к нужным папкам и право «Allow to send as» в админке mailcow. Пропустите любую — и сотрудник либо не увидит писем, либо не сможет ответить от info@. Ниже — порядок, грабли и кейс.

Кейс: пять человек, один пароль и рассинхрон при увольнении

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

Проблема вскрылась, когда уволившийся полгода назад стажёр всё ещё мог зайти в info@ с личного телефона — пароль ему никто не менял, потому что «неудобно». Мы ведём для них корпоративную почту на mailcow, и первым делом я объяснил управляющему партнёру: в mailcow не нужно раздавать пароль от общего ящика вообще — есть штатный механизм, который даёт каждому сотруднику доступ под собственным логином, а ящик info@ можно закрыть паролем, который не знает никто, кроме администратора.

Почему здесь два механизма, а не один — и как их путают даже в официальном трекере mailcow

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

Первая надстройка — серверное право «отправлять от имени». Документация формулирует так: администраторы и администраторы домена могут редактировать ящики, чтобы разрешить конкретным пользователям отправлять письма от имени других ящиков (по сути — «делегировать» им это право); можно выбрать конкретных пользователей или вовсе отключить проверку отправителя для домена. В интерфейсе это поле «Allow to send as» в карточке ящика того сотрудника, которому вы даёте право, — туда вписывается info@. Без него Postfix отклонит письмо с чужим From, даже если в SOGo адрес выбрать можно.

Вторая надстройка живёт в SOGo. Документация прямо говорит: если вы хотите выбрать в качестве адреса отправителя другой существующий ящик, его владелец должен делегировать вам доступ через SOGo, и дополнительно нужно разрешение администратора. То есть именно делегирование в SOGo добавляет info@ в список «От кого», а галочка в админке делает так, чтобы сервер это письмо принял. Эту раздельность ещё в 2019 году заметил автор issue #2530 в GitHub-трекере mailcow: он вписал чужой адрес в «Allow to send as», ожидал, что тот появится в SOGo, но заработало только после того, как владелец ящика сделал делегирование в самом SOGo. Синхронизации между двумя механизмами нет и сейчас. А третья деталь — папки: как разобрали на форуме mailcow в треде «Delegation falsch verstanden?», делегирование даёт адрес отправителя, но не показывает дерево папок чужого ящика, их открывают отдельно.

• «Allow to send as» — настраивает администратор в карточке ящика сотрудника, без этого сервер не примет письмо с From: info@
• делегирование в SOGo — делается из-под самого info@, без него адрес не появится в списке «От кого»
• общий доступ (Sharing) к папкам info@ — тоже из-под info@, каждая папка отдельно: Входящие, Отправленные и т. д.
• пропуск любого пункта даёт симптом «почти работает», поэтому проверять все три

Шаг 1: создаём info@ и разрешаём сотрудникам отправлять от его имени

Ящик info@ должен существовать как полноценный mailbox, а не как алиас на чей-то личный ящик и не как catch-all — тот же принцип «отдельный ящик, а не общая учётка» мы закладывали, когда делали клиентам миграцию компании на mailcow. Разница принципиальна: алиас расширяет для владельца список адресов, от имени которых он и так может отправлять, а catch-all-адрес — это адрес, на который принимаются все письма без конкретного получателя, но он не даёт права отправки в принципе — это отдельная модель в той же документации mailcow, и я видел, как администраторы путают её с делегированием, а потом удивляются, что catch-all «не даёт отвечать».

Поэтому первый шаг — создать info@ как обычный ящик с длинным случайным паролем, который вы сразу положите в сейф паролей и никому не передадите. Дальше администратор (или администратор домена) открывает карточку каждого сотрудника, которому нужен общий ящик, и в поле «Allow to send as» добавляет info@ — это и есть серверная часть права отправлять от чужого имени. Для «ФондРоста» это два аналитика, ассистент и два партнёра — пять конкретных ящиков, а не «все в домене».

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

После этого шага в SOGo у сотрудников ещё ничего не изменилось: info@ в списке «От кого» не появился, папок общего ящика не видно. Это ожидаемо — мы сделали только серверную часть, которая скажет Postfix «этому пользователю можно ставить From: info@». Видимую часть настраиваем из-под самого info@.

Шаг 2: делегируем доступ к самому ящику через SOGo

Вторая половина задачи решается не в админке mailcow, а внутри SOGo, из-под самого info@. Раздавать ради этого пароль не нужно: если в mailcow.conf включить ALLOW_ADMIN_EMAIL_LOGIN=y (по умолчанию n), администратор сможет войти в SOGo под любым ящиком прямо из админки, без пароля. Внутри почтового модуля SOGo в меню с тремя точками рядом с адресом ящика есть пункт делегирования — туда я добавляю каждого из пяти сотрудников. После этого info@ появляется у них в списке «От кого».

Важный нюанс, который хорошо разобран в треде форума mailcow «Delegation falsch verstanden?» (сентябрь 2025): делегирование не открывает дерево папок ящика — у автора адреса в поле отправителя появились, а папок не было. Папки открываются отдельно, через общий доступ (Sharing) на каждую папку info@: правой кнопкой по папке, добавить пользователя, отметить права. Как минимум «Входящие», чтобы сотрудник видел новые заявки. Весь ящик одной галочкой не расшарить — только папку за папкой.

Для «ФондРоста» мы открыли всем пятерым «Входящие» и пару тематических подпапок с правами на чтение, пометку прочитанным и перемещение, но без права удалять и стирать письма — в диалоге общего доступа SOGo права выставляются по отдельности. Здесь есть нюанс, о котором заранее предупредил партнёров: ответ, отправленный от имени info@, попадает в «Отправленные» того сотрудника, который его написал, а не в «Отправленные» info@. Если нужно, чтобы вся исходящая переписка общего ящика лежала в одном месте, это решается отдельно — например, копией через sender-зависимые BCC-карты mailcow в info@ и правилом Sieve; схему я каждый раз проверяю на тестовом ящике до включения. Только когда все три части на месте, info@ у сотрудника ведёт себя как дополнительный ящик под его собственным логином.

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

Как это выглядит у сотрудника изнутри

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

Когда он нажимает «Ответить», в поле «От кого» у него есть выбор — свой личный адрес или info@. Этот пункт появился благодаря делегированию в SOGo, а сервер пропускает письмо благодаря «Allow to send as». Он выбирает info@, стартап получает ответ с адреса info@fondrosta.example, а не с личного адреса аналитика, хотя фактически письмо ушло из его сессии SOGo под его собственным паролем.

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

Где это ломается на практике

Первая типичная ошибка — сделать только серверную часть и решить, что этого достаточно. Галочка «Allow to send as» стоит, а info@ в списке «От кого» в SOGo нет — ровно та путаница, с которой открыт issue #2530 в трекере mailcow: админка и делегирование в SOGo — две разные вещи, и одна не включает другую автоматически.

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

Вторая ошибка — обратная: делегирование и общий доступ к папкам в SOGo сделали, а «Allow to send as» в карточке сотрудника забыли. Тогда info@ в списке «От кого» есть, письма видны, но при отправке сервер отказывает — в логе Postfix это выглядит как отказ по несовпадению отправителя и учётной записи. Неприятно вдвойне, потому что выглядит как «почти работает», и сотрудник чаще пишет в поддержку «почта сломалась», чем описывает, что именно произошло.

Отдельный вариант второй ошибки — сделать делегирование, но не расшарить папки. Это ровно ситуация из треда «Delegation falsch verstanden?»: адрес для отправки есть, а писем не видно. Автору в итоге посоветовали подключить остальные ящики в SOGo как дополнительные IMAP-аккаунты — но это снова требует пароля от общего ящика, так что для нашей задачи правильный путь — общий доступ к папкам.

Третья ошибка — оставить catch-all-адрес там, где нужен был настоящий ящик. Catch-all по определению не даёт права отправки, это чисто входящий маршрут для писем без явного адресата в домене, и я видел компании, которые годами пытались «на всякий случай» повесить на catch-all делегирование — это не работает и не должно работать, потому что catch-all не создаёт полноценный mailbox с собственными правами.

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

Когда делегирования мало: публичные папки Dovecot как альтернатива для больших команд

Схема из двух шагов отлично работает, пока делегированных сотрудников немного — пять человек в «ФондРоста» настраиваются за час. Но если общих ящиков несколько, а доступ к каждому нужен десяткам сотрудников по всей компании, делегировать каждого по отдельности в SOGo для каждого ящика становится утомительно: это N×M настроек, которые к тому же не видны администратору централизованно, а хранятся внутри самого SOGo у владельца ящика.

Для такого масштаба в документации mailcow описан отдельный механизм — публичные папки на уровне Dovecot, а не делегирование конкретного ящика. Они задаются не через веб-интерфейс, а через дополнительный конфиг data/conf/dovecot/extra.conf, где создаётся отдельное пространство имён type = public с собственным расположением на диске, отдельным от личных ящиков пользователей. Такая папка становится общей точкой на уровне всего сервера, а не персональной настройкой одного mailbox.

Права на публичную папку раздаются не через диалог делегирования, а прямо в контейнере dovecot командой doveadm acl set, и документация приводит пример именно для группы «все аутентифицированные пользователи», а не для конкретных адресов:

docker compose exec dovecot-mailcow doveadm acl set -A "Public/Develcow" "authenticated" lookup read write write-seen write-deleted insert post delete expunge create

По сути это тот же переход, что я делаю, когда служба поддержки клиента переезжает с общего ящика на нормальную систему заявок — см. кейс с переездом с общего ящика без потери истории: меняется не сама почта, а то, кто и как получает доступ к общей переписке. Для «ФондРоста» с пятью сотрудниками я не стал городить эту схему — обычное делегирование проще и понятнее в интерфейсе, и его видно прямо в SOGo без захода на сервер по SSH. Но если ко мне придёт клиент с десятком общих ящиков и полусотней сотрудников, я в первую очередь оценю именно публичные папки Dovecot — они административно централизованы, хотя и требуют работы с конфигом и консолью, а не с одним диалогом в веб-интерфейсе.

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