После mailcow 2025-03 ссылка /SOGo ведёт на другой вход: как сразу открывать пользователю веб-почту

Сотрудник заходит по старой закладке `https://mail.domain.ru/SOGo`, а вместо привычной веб-почты видит общую страницу входа mailcow — и после логина попадает не туда, где раньше сразу открывались письма. Это не сломанная ссылка и не забытый пароль: с релиза mailcow 2025-03 прямой вход в SOGo намеренно отключён. Разбираю, что изменилось в схеме входа и как настроить переход сразу в веб-почту без лишних кликов и ненужных сбросов паролей.

Симптом: старая закладка на /SOGo ведёт не туда

После обновления корпоративной почты на mailcow у части сотрудников перестают работать старые закладки браузера на прямой адрес веб-почты вида https://mail.domain.ru/SOGo. Вместо привычного интерфейса SOGo с папками и письмами открывается общая страница логина mailcow — та же самая, с которой раньше заходили только в админку.

Дальше начинается путаница похуже: сотрудник вводит свой обычный пароль от почты, успешно логинится — и попадает либо в панель настроек своего ящика (mailbox settings в интерфейсе mailcow), либо куда-то ещё, но точно не сразу в письма, как было раньше. Часть сотрудников решает, что пароль устарел, и сама идёт его сбрасывать, хотя пароль абсолютно рабочий.

Администратор в этот момент получает волну обращений в поддержку одновременно от десятков пользователей и первым делом подозревает, что при обновлении что-то сломалось в проксировании SOGo через nginx — начинает смотреть логи nginx-mailcow и sogo-mailcow в поисках ошибки, которой там нет, потому что редирект — это не ошибка, а новое штатное поведение системы.

Ситуация усугубляется тем, что визуально новая страница входа почти неотличима от старой — тот же логотип, та же форма «логин / пароль» — и пользователь не понимает, что физически попал на другой URL с другим набором последующих действий. Единственный видимый признак — изменившийся адрес в строке браузера, на который большинство сотрудников просто не смотрит.

Что изменилось: релиз 2025-03 разделил вход на три адреса

Релиз mailcow 2025-03 от 25 марта 2025 года, который в официальном блоге проекта называют «the Moorch 2025 Update — the update which changed the cow», внёс архитектурное изменение в схему авторизации: прямой вход в SOGo отключён полностью. Любое неаутентифицированное обращение к пути /SOGo теперь автоматически перенаправляется на корень / — то есть на общую страницу входа mailcow, а не сразу на форму логина SOGo, как было раньше.

Одновременно с этим релиз развёл входные точки по ролям: /admin — вход для администратора сервера, /domainadmin — отдельный адрес для администраторов конкретных доменов, и / — общий вход для рядовых пользователей почты. Раньше все три роли по факту могли попадать через одни и те же формы с разным результатом в зависимости от прав учётной записи, теперь маршруты разведены явно на уровне URL.

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

С точки зрения обычного пользователя разница между старым и новым поведением на самом деле минимальна по числу кликов — один лишний переход через общий вход вместо прямого попадания в SOGo. Но психологически смена привычного маршрута после многих месяцев или лет работы по старой ссылке воспринимается как крупная поломка, особенно если никто заранее не предупредил команду об обновлении и его видимых последствиях.

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

Важно понимать: это не откат бага и не временное решение, которое стоит обходить — это осознанное изменение: в релизной заметке оно вынесено в Breaking Changes с предупреждением, что обновление «сильно меняет процесс аутентификации». Мотивы ниже — моя инженерная интерпретация, а не цитата разработчиков. До релиза 2025-03 у mailcow фактически существовало два параллельных входа в систему: через саму mailcow (для управления ящиками, доменами, настройками) и напрямую в SOGo (для веб-почты), с частично пересекающейся, но не идентичной логикой проверки пароля и сессий.

Разведение точек входа по ролям (/admin, /domainadmin, /) и принудительный редирект неаутентифицированных запросов к /SOGo на общий вход убирают путаницу в том, какой из двух механизмов авторизации на самом деле проверяет пароль в конкретный момент, и снижают поверхность атаки — больше нет двух независимых точек входа, у которых могла бы разъехаться логика блокировки после неудачных попыток или парольная политика.

Для администратора это значит: не нужно и не стоит искать способ вернуть старое поведение прямого входа в /SOGo через кастомные правки nginx-конфига или обход редиректа — это будет воспроизводить архитектуру, от которой разработчики сознательно ушли, и рискует сломаться при следующем обновлении ещё раз, уже без предсказуемого объяснения в changelog.

Я видел на других проектах (не mailcow) похожие попытки «вернуть как было» кастомным location-блоком в nginx поверх обновлённого стека, который поставляется и обновляется самим приложением. Итог обычно один: при следующем крупном обновлении кастомная правка либо ломает штатный механизм обновления (update.sh перезаписывает или конфликтует с изменённым конфигом), либо тихо перестаёт работать без видимой причины, и разбираться приходится заново, уже без понимания, что именно было переопределено полгода назад.

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

Правильное решение — не бороться с редиректом, а настроить целевую точку после успешного входа для конкретного ящика или для всех пользователей домена так, чтобы после ввода пароля на общей форме / человек сразу оказывался в SOGo, а не в панели настроек mailcow. Соответствующая настройка находится в карточке ящика: в панели mailcow при редактировании mailbox это флажок «Direct forwarding to SOGo» с пояснением «After logging in, the user is automatically redirected to SOGo». Администратор сервера видит его всегда, а администратору домена он доступен, если в его правах включено «Allow management of SOGo access». Если флажок не стоит, пользователь после входа попадает в свою панель mailcow, где кнопка «Webmail» всё равно открывает SOGo без повторного ввода пароля.

Практический порядок действий для команды поддержки: обновить внутреннюю базу знаний и типовой ответ на тикет «пропала почта/просит пароль заново» — с инструкции «зайдите на /SOGo» на «зайдите на https://mail.domain.ru/ и войдите обычным логином и паролем, вас перенаправит в веб-почту автоматически»; для старых закладок сотрудников либо разослать новую прямую ссылку на корень, либо, если это критично для конкретных ролей, включить флажок «Direct forwarding to SOGo» на уровне ящика. Если в компании уже есть общий единый вход (SSO) для сотрудников, стоит сразу проверить, не потребует ли новая схема входа mailcow дополнительной настройки интеграции — обычно нет, но лучше свериться до жалоб пользователей.

Отдельно стоит предупредить пользователей и коллег из поддержки о смежном нюансе, который часто путают с этой же проблемой: смена пароля прямо внутри интерфейса SOGo, если она включена (SOGoPasswordChangeEnabled в sogo.conf), не работает и не должна использоваться при входе через функцию «Login to Webmail» (Auth Proxy) из панели mailcow — документация прямо предупреждает, что в этом режиме смена пароля из SOGo не учитывает парольную политику, заданную в самой mailcow, и может привести к рассинхронизации паролей. В целом требования к самим паролям я разбирал отдельно в материале про парольную политику в небольшом офисе — она применима и к почтовым ящикам mailcow.

• Прямой вход /SOGo больше не существует с релиза 2025-03 — это ожидаемое поведение
• Новые точки входа: /admin (сервер), /domainadmin (домен), / (пользователи)
• Куда попадает пользователь после логина — управляемая настройка на уровне ящика
• Смена пароля внутри SOGo при входе через Auth Proxy — не работает, не использовать

Кейс: «Digital-двор», 15 рабочих мест

Клиент — digital-агентство «Digital-двор», 15 рабочих мест, небольшая, но активная команда, у половины сотрудников почта была прибита прямой ссылкой на /SOGo в закладках браузера ещё с момента первоначальной настройки сервера. После планового обновления mailcow до актуальной версии в течение одного дня пришло семь одинаковых обращений: «почта просит пароль заново, ввожу — не открывается».

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

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

Решение заняло около часа на всех 15 ящиков: включили флажок «Direct forwarding to SOGo» для всех сотрудников агентства (кроме двух администраторов, которым по роли нужен вход в панель управления), разослали короткую памятку с новым адресом https://mail.domain.ru/ вместо старого /SOGo, и отдельно предупредили, что смену пароля стоит делать только через панель mailcow, а не пытаться менять его внутри самой веб-почты.

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

Что проверить перед следующим обновлением mailcow

Этот случай — хороший повод завести привычку читать changelog релиза перед обновлением production-сервера, а не только после того, как посыпались обращения пользователей. Релизы mailcow иногда меняют не технические детали конфигурации, а видимое пользователю поведение интерфейса — и такие изменения дешевле объявить сотрудникам заранее одним письмом, чем разбирать потом десяток одинаковых тикетов в панике.

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

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

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