Mailcow legacy — не LTS: когда закончилась поддержка

Если вы включили `./update.sh --legacy`, чтобы не менять старую авторизацию, у меня для вас короткий ответ: заявленная поддержка этой ветки закончилась в феврале 2026 года. В сентябре 2026 года это уже просроченная ветка, а не спокойная долгосрочная альтернатива stable. Я разберу, что именно изменилось в авторизации, почему откладывание выглядело разумно только первые месяцы и как я перевожу такой сервер на stable без экспериментов над рабочей почтой.

Срок был указан прямо: февраль 2026 года

Legacy появилась вместе с релизом mailcow 2025-03 и технически осталась на базе 2025-02. Разработчики обещали ей только security updates — исправления безопасности, без новой функциональности. И рядом сразу поставили предел: поддержка заканчивается в феврале 2026 года. Не «как минимум до февраля», не «пока есть пользователи», не бессрочно. Точной даты внутри месяца объявление не задавало, поэтому спорить о 1 или 28 февраля бессмысленно: к сентябрю 2026 года срок в любом прочтении прошёл.

Здесь IT-директору важно правильно назвать состояние актива. Legacy не была LTS-редакцией и не стала вторым стабильным каналом. Это был временный мост для тех, кому релиз 2025-03 ломал привычный сценарий входа. Stable остаётся рабочей веткой развития, а документация описывает для неё регулярный цикл обновлений. Когда мост закончился, сервер мог продолжить принимать SMTP и отдавать IMAP, но обещание выпускать для этой ветки даже security fixes уже не действует.

Я не считаю сам выбор legacy в марте 2025 года ошибкой. Если после обновления в понедельник утром половина офиса не может открыть веб-почту, временно отступить — нормальная инженерная мера. Ошибка начинается в тот момент, когда временной мере не назначили владельца, дату выхода и тестовый стенд. Флаг в скрипте приняли за лицензию ничего не делать.

• Ветка: legacy, база — mailcow 2025-02.
• Объём поддержки: только исправления безопасности.
• Объявленный конец поддержки: февраль 2026 года.
• Состояние на сентябрь 2026 года: объявленный срок истёк, продления в документации и блоге mailcow нет.

Почему после 2025-03 показалось, что сломалась авторизация

В 2025-03 разработчики разделили точки входа: администратор идёт на /admin, администратор домена — на /domainadmin, пользователь — на /. Неаутентифицированный запрос к /SOGo теперь перенаправляется на /, прямой вход SOGo отключён. Одновременно появилась поддержка внешних Identity Provider: Keycloak, LDAP/AD и Generic OIDC. Для ящиков с включённой 2FA почтовые протоколы требуют app password. Это не косметика, а изменение пользовательского маршрута и границ учётных данных.

Из практики первым делом ломается не Dovecot и не Postfix. Ломаются закладки на /SOGo, инструкция со скриншотом пятилетней давности, ссылка в корпоративном портале и ожидание администратора, что форма на / обязана принять его пароль. Следом обнаруживаются телефоны и клиенты, где у пользователя с 2FA сохранён основной пароль вместо отдельного пароля приложения. Люди говорят «почта упала», хотя входящая очередь идёт, SMTP отвечает, а проблема находится в конкретном способе входа.

Поэтому я разделяю проверку на четыре независимых контура: административный веб-вход, пользовательский веб-вход, IMAP/SMTP и EAS/DAV. Откат всей платформы из-за неверного URL администратора — слишком дорогая реакция. А вот если в компании нет списка 2FA-пользователей и управляемого способа раздать app passwords, перенос действительно надо сначала подготовить. Спорное место здесь не stable, а качество инвентаризации клиентов.

• Проверить ссылки и reverse proxy для `/`, `/admin`, `/domainadmin` и перенаправления `/SOGo`.
• Выделить пользователей с 2FA и внешними почтовыми клиентами.
• Отдельно протестировать IMAPS 993, submission 587, EAS/DAV и веб-интерфейс.
• Не путать сброс пароля администратора с переходом на новую точку входа.

Условный учебный центр «Каска»: 13 рабочих мест и год отсрочки

Покажу на условном, обезличенном примере — учебном центре охраны труда «Каска», 13 рабочих мест; это не раскрытие реального клиента. В модели 16 ящиков (13 сотрудников плюс общие адреса для заявок, бухгалтерии и рассылки удостоверений), 85 ГиБ почты, 11 телефонов по ActiveSync, около 20 одновременных IMAP-сессий, 6 постоянных пользователей SOGo и 4 ящика с TOTP. ВМ: Debian 12, 4 vCPU, 12 ГиБ RAM, 250 ГиБ SSD; Docker Engine 27.5 и Compose 2.32. Документация называет минимум 6 ГиБ RAM плюс 1 ГиБ swap и советует около 8 ГиБ уже для 5–10 пользователей, поэтому 12 ГиБ здесь — запас, а не роскошь. ClamAV и полнотекстовый поиск я оставил включёнными: центр постоянно получает от слушателей сканы документов во вложениях, и антивирус на входе там нужен.

В апреле 2025 года пробное обновление с 2025-02 до 2025-03 провели прямо в коротком вечернем окне. Технически контейнеры поднялись. Но трое из пяти пилотных пользователей открывали старую закладку SOGo, администратор шёл на корень сайта, а у двух TOTP-пользователей телефоны продолжали предъявлять основной пароль. За 30 минут получили 6 обращений — для офиса на 13 человек это почти половина штата. Опыт остановили, восстановили предварительный full backup на прежней версии и выбрали ./update.sh --legacy. Важная деталь: сам флаг переключает ветку обновлений, но не откатывает данные и миграции. Как аварийное решение возврат был разумным. Неразумно было записать в протоколе «остаться на legacy» без крайней даты.

На сервере сохранили обычную конфигурацию ресурсов: SKIP_CLAMD=n и SKIP_FTS=n. Проблема была не в этих настройках и не в железе. Почти год приходящий администратор обновлял ОС, следил за очередью и бэкапами, но сам переход откладывал: почта же работает, а в разгар набора групп на обучение трогать её никто не хотел. В феврале 2026 года объявленное окно поддержки закончилось, а к августу stable дошла до 2026-07b (18 августа 2026 года). Этот релиз обновил Redis до 7.4.10, SOGo до 5.12.10, ClamAV до 1.4.6 — с формулировкой об исправлении нескольких проблем безопасности в этих компонентах — и добавил мелкое усиление web UI и Nginx. Я не утверждаю, что каждая уязвимость обязательно эксплуатируема на конкретной legacy-инсталляции. Утверждаю другое: рассчитывать на перенос этих исправлений в ветку после её срока уже нельзя.

Мы восстановили полный backup на изолированной копии, переключили её на stable, обновили памятку для сотрудников и провели пилот. Итоговый простой production составил 35 минут при окне 60 минут, окно выбрали в субботу, когда нет очных занятий. Из 13 сотрудников троим понадобилась ручная помощь: двоим заменили закладки, одному заново настроили app password на телефоне. Потери писем не было, накопившаяся на отправителях очередь пришла в течение нескольких минут после запуска. Главный результат — не новый экран входа, а возврат сервера в поддерживаемый поток обновлений.

• Лабораторное восстановление 85 ГиБ на стенде: 1 час 10 минут.
• Пилот: 5 пользователей, включая 2 ящика с TOTP, 2 телефона с ActiveSync и Thunderbird по IMAP.
• Окно production: 60 минут; фактическая недоступность веба и протоколов — 35 минут.
• После миграции: 3 ручных обращения, 0 потерянных сообщений.

Сначала инвентаризация и восстановление, потом `--stable`

Я начинаю не с нажатия update, а с фиксации состояния. Нужны текущая ветка, незакоммиченные изменения, состояние контейнеров, объём maildir, свободное место, список кастомных override-файлов и фактические способы входа. В каталоге установки выполняю базовую проверку; вывод сохраняю в заявку на изменение.

cd /opt/mailcow-dockerized
git status --short --branch
git branch --show-current
./update.sh --check
docker compose ps

Затем делаю полный backup штатным скриптом. Для 4 vCPU ставлю два потока: документация советует брать число ядер минус два, чтобы mailcow хватило процессора. Каталог резервной копии находится не на том же виртуальном диске. Команда для стенда выглядела так:

cd /opt/mailcow-dockerized
MAILCOW_BACKUP_LOCATION=/srv/backup/mailcow THREADS=2 \
  ./helper-scripts/backup_and_restore.sh backup all

Но наличие каталога mailcow_DATE ещё ничего не доказывает. Я проверяю читаемость копии и выполняю restore на отдельной пустой, уже инициализированной и запущенной mailcow. При переносе обязательно сверяю исходный mailcow.conf, особенно MAILDIR_SUB: несовпадение способно дать пустые папки при фактически сохранённых письмах.

Восстановление — отдельный регламент и отдельная команда. Флаг --stable не является rollback и не восстанавливает данные. На тестовой ВМ я запускаю интерактивный restore, выбираю нужную точку и все компоненты, затем уже переключаю ветку:

MAILCOW_BACKUP_LOCATION=/srv/backup/mailcow THREADS=2 \
  /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh restore
cd /opt/mailcow-dockerized
./update.sh --stable

Если restore не был реально выполнен, окно миграции я не согласую. Снимок гипервизора полезен как дополнительный предохранитель, но не заменяет компонентный backup: вы должны уметь восстановить SQL, crypt, vmail, Redis, Rspamd и Postfix, а не просто надеяться, что crash-consistent snapshot загрузится.

• Зафиксировать ветку, локальные изменения и версии до работ.
• Сделать полный backup вне диска production.
• Восстановить копию на изолированном стенде.
• Только после успешного restore выполнить `./update.sh --stable` на стенде.

Как я принимаю stable перед рабочим окном

На стенде мне мало зелёного docker compose ps. Я вхожу как системный администратор через /admin, как администратор домена через /domainadmin, затем обычным пользователем через /. Проверяю ожидаемое перенаправление старого /SOGo. После этого отправляю письма наружу и внутрь, отвечаю на сообщение, открываю вложение, ищу старое письмо, проверяю карантин и DKIM-подпись. Отдельные тестовые учётные записи проходят IMAP, SMTP submission, ActiveSync и DAV.

Для TOTP-пользователей я не отключаю второй фактор только ради сохранения старого пароля. В stable пользователь создаёт app password в настройках ящика и этим секретом авторизует внешний клиент. Если компания уже использует Keycloak, LDAP/AD или OIDC, можно настроить внешний IdP и переводить источники авторизации по ящикам. Но я не добавляю IdP в тот же вечер, когда выхожу с legacy: это отдельное изменение с собственным планом отката. Меньше движущихся частей — быстрее понятна причина сбоя.

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

• До окна: пилот минимум на администраторах, TOTP, SOGo, IMAP/SMTP и EAS/DAV.
• В окне: финальный backup, `./update.sh --stable`, проверка контейнеров и smoke-тесты.
• После окна: наблюдение очереди, ошибок входа, свободного места и обращений пользователей.
• План отката: только к проверенной точке восстановления, с учётом писем, поступивших после backup.

Другие «сроки» mailcow: Docker Compose, платформа, версия скрипта

Когда меня спрашивают о прекращении поддержки mailcow, в одну кучу обычно сваливают несколько разных вещей. Датированный срок у проекта в этой истории один — legacy-ветка до февраля 2026 года. Для Docker Compose v1 отдельного объявления с календарной датой я в документации и блоге mailcow не нашёл, и придумывать его не буду. Зато есть требования к установке, которые действуют прямо сейчас: Docker версии не ниже 24.0.0 и Docker Compose не ниже 2.0. Standalone-бинарь docker-compose первой ветки этим требованиям не отвечает, значит, сервер на нём уже вне поддерживаемой конфигурации, независимо от выбранной ветки обновлений.

Обратная ловушка появилась в декабре 2025 года: вышел плагин Docker Compose 5.0, а старые копии update.sh проверяли версию по шаблону «2.x» и падали с сообщением Cannot find Docker Compose with a Version Higher than 2.X.X. Разработчики разбирали это в issue #6939 на GitHub; практический выход — сначала подтянуть из репозитория актуальный update.sh, а уже потом запускать обновление. На legacy-ветке, которая после февраля 2026 года не сопровождается, рассчитывать на подобные исправления совместимости тем более не стоит: обновили Docker из репозитория ОС — и скрипт обновления mailcow может перестать запускаться.

cd /opt/mailcow-dockerized
docker version --format '{{.Server.Version}}'
docker compose version
git fetch origin
git checkout origin/master update.sh
./update.sh --check

Третья группа — платформа. Официально поддерживаются архитектуры x86_64 и ARM64, виртуализация KVM, ESX и Hyper-V. Установка на NAS Synology/QNAP, OpenVZ, LXC и другие контейнерные платформы документацией прямо запрещена. Если учебный центр когда-то поднял почту на NAS «чтобы не покупать сервер», это не вопрос даты окончания поддержки: такая схема не поддерживалась никогда, и переход на stable логично совместить с переносом на нормальную ВМ.

• Проверить `docker version` и `docker compose version`: Docker ≥ 24.0.0, Compose ≥ 2.0, без standalone v1.
• Перед обновлением с Compose 5.x убедиться, что `update.sh` взят из актуальной ветки, а не из копии 2025 года.
• Сверить архитектуру (x86_64/ARM64) и тип виртуализации с разделом требований к системе.
• Не называть «дедлайном» то, чего нет в release notes: единственный объявленный срок — legacy до февраля 2026 года.

Решение для IT-директора: не продлевать legacy своими силами

Моя позиция однозначна: в сентябре 2026 года оставаться на legacy ради привычной формы входа нельзя считать управляемой стратегией. Срок поддержки закончился в феврале. Собственная сборка патчей теоретически возможна, но тогда вы становитесь сопровождающей стороной всего стека — от web UI и SOGo до Nginx, Redis и антивируса. Для учебного центра на 13 рабочих мест без штатного администратора это почти всегда дороже нормальной миграции и хуже проверяется.

Первый приоритет — не немедленно обновить production, а в течение нескольких дней доказать восстановление и собрать матрицу авторизации. Второй — прогнать stable на копии с реальными объёмами данных. Третий — назначить короткий пилот и рабочее окно. На косметику интерфейса, идеальный текст памятки и автоматизацию каждой проверки можно временно забить. Нельзя откладывать backup/restore, app passwords для 2FA и проверку всех используемых протоколов.

Если прямо сейчас сменить ветку нельзя, я оформляю это как временно принятый риск с владельцем и датой закрытия, ограничиваю доступ к административному интерфейсу, усиливаю мониторинг и ускоряю стенд. Но это компенсирующие меры, не продолжение официальной поддержки. Команда ./update.sh --legacy выбирает legacy, а ./update.sh --stable возвращает stable; ни один флаг не снимает с нас обязанности проверить данные и пользовательские сценарии.

• Назначить владельца миграции и дату выхода с legacy.
• Зафиксировать временный риск в реестре, а не в переписке администратора.
• Не совмещать переход на stable с внедрением нового IdP без необходимости.
• После перехода вернуть регулярный цикл проверки release notes и обновлений.

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