Roundcube вместо SOGo в mailcow: что теряется и как сохранить календари на телефонах

SOGo в mailcow многим не нравится внешне, и первая мысль — заменить его на Roundcube. Проблема в том, что SOGo — это не просто веб-почта: он же отдаёт ActiveSync на телефоны и CalDAV/CardDAV для календарей и контактов. Просто поставить Roundcube эти службы не заменит. Показываю, как я развожу эти два слоя на кейсе садового центра на 37 рабочих мест.

SOGo и Roundcube решают разные задачи, а не конкурируют один в один

Когда клиент просит поменять веб-интерфейс корпоративной почты на mailcow, чаще всего речь именно про внешний вид: SOGo выглядит функционально, но устаревше, а сотрудники видели красивые интерфейсы в других сервисах. Технически SOGo в mailcow — это не только веб-клиент. Контейнер sogo-mailcow одновременно отдаёт Microsoft ActiveSync для мобильных клиентов и CalDAV/CardDAV для синхронизации календарей и контактов на компьютерах и телефонах. Установка Roundcube сама по себе ни одну из этих служб не заменяет и не переносит — она добавляет альтернативный веб-интерфейс к тому же самому IMAP/SMTP, и не более того.

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

Разница чувствуется и на уровне протоколов, а не только «красиво/некрасиво». SOGo реализует ActiveSync — протокол, который Outlook и штатные почтовые клиенты Android и iOS используют не только для писем, но и для двусторонней синхронизации встреч и контактов без ручной настройки. Roundcube — это классический IMAP/SMTP-веб-клиент: он показывает письма красиво и удобно, но сам по себе ничего не знает ни про ActiveSync, ни про CalDAV/CardDAV, потому что это просто другой класс задач, для которого в Roundcube нет встроенного сервера.

Почему нельзя просто снести SOGo

Документация mailcow прямо предлагает два способа поставить Roundcube: Integrated Install, при котором файлы Roundcube кладутся в data/web/rc и исполняются в существующем контейнере php-fpm-mailcow, а база roundcubemail создаётся в том же mysql-mailcow, и Standalone Install — отдельные контейнеры roundcube (образ roundcube/roundcubemail) и roundcube-db на MariaDB 10.11, описанные в docker-compose.override.yml, что даёт более чистую изоляцию от остального mailcow. Ни один из этих вариантов не заменяет SOGo автоматически: ActiveSync и CalDAV/CardDAV как были завязаны на sogo-mailcow, так и остаются на нём, если вы явно не отключили сервис.

Это не значит, что стандартную установку Roundcube отдельно от mailcow стоит игнорировать как источник знаний — базовая механика подключения к IMAP/SMTP там та же. Разница в контексте: там Roundcube — единственный и основной клиент на самостоятельном почтовом сервере, здесь — дополнительный интерфейс поверх экосистемы mailcow, где параллельно уже работает SOGo со своими протоколами синхронизации. Смешивать эти два сценария и переносить советы один в один — источник половины проблем, которые я потом разбираю у клиентов.

Практическая схема, которую я использую чаще всего: SOGo остаётся включённым и отвечает за ActiveSync и CalDAV/CardDAV в фоне, а Roundcube ставится как дополнительный веб-интерфейс для тех, кому нужна именно веб-почта. Сотрудники, которым календари не нужны или кто синхронизируется через телефон напрямую по ActiveSync, вообще не замечают, что где-то рядом всё ещё крутится SOGo — они просто открывают адрес Roundcube в браузере.

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

Как настроить Roundcube в mailcow: Integrated или Standalone

В обоих вариантах установки Roundcube подключается к тем же внутренним контейнерам mailcow, что и остальная почта: IMAP через dovecot:143, SMTP — через postfix:588, а управление фильтрами и автоответами через managesieve по адресу dovecot:4190. Это внутренние имена в сети mailcow-network, не публичные хосты — наружу их выносить не нужно, но прописываете их вы сами: в config.inc.php при Integrated или в переменных окружения контейнера при Standalone. И обязательный шаг, который пропускают чаще всего: Dovecot в mailcow по умолчанию разрешает вход открытым паролем по незашифрованному соединению внутри контейнерной сети только для SOGo, поэтому в data/conf/dovecot/extra.conf добавляется блок remote с disable_plaintext_auth = no для подсети mailcow и перезапускается dovecot-mailcow (docker compose restart dovecot-mailcow). Без этого Roundcube покажет ошибку входа при верном пароле.

Из плагинов документация особо выделяет managesieve — он даёт пользователям интерфейс серверных фильтров и автоответов на отпуск, без него правила пересылки и отпускные автоответы придётся настраивать где-то ещё; acl — управление доступом к общим IMAP-папкам; markasjunk — кнопку «это спам», которая переносит письмо в папку «Спам», а штатные sieve-фильтры mailcow превращают этот перенос в обучение rspamd — того же движка, что фильтрует почту во всём mailcow. Я включаю все три по умолчанию: без managesieve и acl Roundcube в связке с mailcow ощутимо беднее по функциям, чем привычный сотрудникам SOGo.

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

Roundcube 1.7 и обязательный public_html: грабли, о которые спотыкаются чаще всего

С версии Roundcube 1.7.0, вышедшей 10 мая 2026 года, каталог public_html стал обязательной точкой входа для веб-сервера — это официально задокументированное breaking change, а не опция. Все статические ресурсы теперь отдаются через public_html/static.php, а не напрямую из корня установки. Если конфигурация nginx для Roundcube в mailcow писалась под старую версию и указывает корнем сайта не public_html, а корень всего пакета Roundcube, после обновления интерфейс либо не откроется вовсе, либо начнёт отдавать 404 на CSS и JS вперемешку с рабочим backend.

При Integrated Install маршрут /rc/ задаётся отдельным файлом data/conf/nginx/site.roundcube.custom: location ^~ /rc/ с alias на /web/rc/public_html/ и вложенным PHP-блоком, который передаёт PATH_INFO для static.php, — так наружу отдаётся только публичный каталог, а конфиги, плагины и временные файлы закрыты. Пример из документации mailcow совместим и с 1.6, поэтому поменять его стоит ещё до апгрейда. Я всегда сверяю этот файл при любом апгрейде Roundcube, даже минорном: изменения в списке защищаемых путей случаются чаще, чем кажется, а цена ошибки — открытая наружу директория с конфигом почтового клиента.

Требование public_html действует для любой установки Roundcube 1.7, но бьёт оно в первую очередь по Integrated: там веб-сервер настраиваете вы. При Standalone тот же файл site.roundcube.custom содержит только proxy_pass на контейнер roundcube:80, а структуру каталогов внутри обслуживает сам официальный образ — поэтому при обновлении достаточно сменить тег образа в docker-compose.override.yml и прочитать release notes.

Кейс: садовый центр «Солнечный оазис», 37 рабочих мест

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

Я показал директору ровно ту развилку, что описана выше: полная замена SOGo на Roundcube сломает ActiveSync для девяти разъездных менеджеров и их синхронизацию встреч на телефонах, а тридцати кассирам эта разница вообще не важна. Решение — Standalone Roundcube для всех как основной адрес входа в почту, включённый managesieve для автоответов на время отпуска (актуально для сезонного бизнеса) и acl для общего ящика заказов, который делят продавцы. SOGo остался работающим в фоне только ради ActiveSync и CalDAV — и его адрес выдали персонально девяти менеджерам, чтобы календарь на телефоне продолжал синхронизироваться так же, как раньше.

Итог: три часа на настройку Standalone-контейнера и nginx-маршрутов, ещё час на проверку синхронизации календарей у одного тестового менеджера перед раскаткой на остальных. Жалоб на «некрасивый интерфейс» не стало, календари не сломались ни у одного из девяти разъездных сотрудников — потому что SOGo никто не выключал, просто перестал быть общим адресом для входа.

Когда вообще не стоит трогать SOGo

Если у компании нет активного использования ActiveSync и CalDAV — например, все календари ведутся отдельно, в стороннем сервисе, а почта нужна только как почта, — замена веб-интерфейса действительно становится простой задачей: ставите Roundcube, отключаете или прячете ссылку на SOGo, готово. Проверить это перед изменениями просто: в логах mailcow видно активные ActiveSync-подключения, а спросить у сотрудников, чем они синхронизируют календарь на телефоне, занимает пять минут и экономит вечер отладки после релиза.

Если же ActiveSync и CalDAV/CardDAV активно используются, а претензия только к внешнему виду веб-почты, я рекомендую именно параллельную схему, как в кейсе выше, а не полную миграцию. Полный переход имеет смысл рассматривать не в сторону «Roundcube вместо SOGo», а в сторону замены всей платформы целиком, если компании нужен не только другой интерфейс, но и другой groupware-стек — например, я разбирал такой сценарий на примере Carbonio CE как наследника Zimbra, где веб-почта, календари и синхронизация приходят из одного продукта, а не собираются из двух независимых компонентов, как в связке mailcow + Roundcube + SOGo.

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

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

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