Hope Mail Server — Руководство администратора

Руководство описывает администрирование Hope Mail Server (HopeDB): домены и ящики, маршрутизацию почты, TLS-сертификаты, очереди, журналы и обслуживание. Развёртывание описано отдельно в Развёртывание.

1. Архитектура в двух словах

HopeDB состоит из: - Почтового сервера (hopedb-server, Rust) — REST API (HTTPS, 8443) для веб-клиента и админки, а также SMTP (25 / submission 587), IMAP (143), POP3 (110), CalDAV/CardDAV (8090, HTTPS) и ActiveSync/EAS (8092, HTTPS). - Ядра-хранилища (hopedb-core) — журнал (WAL) метаданных и blob-хранилище тел писем на диске. - Веб-приложений (hopedb-web): apps/admin — панель администратора, apps/client — веб-почта.

Внешняя почтовая «граница» (антиспам, SPF/DKIM/DMARC, публичный MX) выносится в сопутствующий продукт Hope MSG Gateway; HopeDB отвечает за внутреннее хранение почты, доступ клиентов и групповые функции.

2. Доступ в админку

Админ-панель — это приложение apps/admin, обращающееся к REST API сервера. Вход выполняется учётной записью администратора (роль с соответствующими правами). Права роли определяют доступные разделы и доменный скоуп — администратор может быть ограничен своим набором доменов.

Путеводитель: «Начало работы» и подсказки

В панель встроен путеводитель (как в HopeDC). У него две части.

1. Панель «Начало работы» — чек-лист первичной настройки сервера. Кнопка «Начало работы N/M» — в шапке панели; N/M — сколько обязательных пунктов выполнено. При первом входе полного администратора панель открывается сама. Каждый пункт объясняет, зачем он нужен и где настраивается; «Перейти» открывает нужный раздел.

Состояние пунктов определяется по реальным настройкам при каждом открытии панели. Если пункт сделан иначе, чем проверяет панель, полный администратор может нажать «Отметить»; ручные отметки общие для сервера и снимаются кнопкой «Снять отметку». Чек-лист виден только полному администратору.

2. Подсказки по страницам — пошаговые экскурсии. При первом открытии каждого раздела (и каждой вкладки рабочей области домена) панель подсвечивает ключевые элементы и объясняет, что с ними делать. Управление: «Далее» / «Назад» (или стрелки ←/→), «Пропустить» или Esc — закрыть подсказку этой страницы, «Не показывать подсказки» — выключить их для своей учётной записи. Кнопка «?» в шапке в любой момент повторяет подсказку текущей страницы. Повторить все подсказки заново — ссылка внизу панели «Начало работы».

Подсказки видят все пользователи панели, но только по доступным им разделам. Прогресс (пройденные подсказки, выключены ли они, открывался ли чек-лист) хранится на сервере отдельно для каждой учётной записи в onboarding.json каталога данных (права 0600), поэтому в другом браузере подсказки повторно не показываются.

API. GET /api/onboarding — состояние путеводителя текущей учётки (и чек-лист — для полного администратора). POST /api/onboarding с полем action: tour_done (+id), tours_reset, tours_off, tours_on, checklist_seen, mark (+id, done; только полный администратор).

Тема оформления и язык панели

В шапке панели, рядом с переключателем RU/EN, — переключатель темы из трёх кнопок: ☀ «Светлая тема», ☾ «Тёмная тема», 🖥 «Как в системе» (следует настройке ОС и меняется вместе с ней). Тема меняется сразу, без перезагрузки, с плавным переходом; при открытии страницы нет вспышки светлого экрана.

Тема и язык — личные настройки учётной записи. Они хранятся на сервере и восстанавливаются при входе с любого браузера и устройства; на общем компьютере у каждого администратора своя тема. При первом входе учётки тема светлая (а не та, что выбрал предыдущий пользователь в этом браузере), а язык запоминается тот, с которым вошли. Страница входа одинакова в обеих темах.

Настройки хранятся в ui_prefs.json каталога данных (права 0600). В кластере файл не реплицируется: настройки хранятся на узле, где их выбрали.

API. GET /api/prefs → { "theme": "", "lang": "" } текущей учётки (пусто — не выбирали). POST /api/prefs с полями theme (light | dark | system) и/или lang (ru | en); другие значения — ошибка 400.

3. Домены

Раздел управления доменами позволяет добавлять обслуживаемые почтовые домены (company.ru). Для каждого домена задаётся: - имя домена; - признак изолированного blob-хранилища (isolated_blobs) — тела писем домена хранятся в отдельном пространстве имён (полезно для мультитенантности и раздельного удаления данных).

Домен должен присутствовать в системе, иначе приём почты для его адресов и создание ящиков невозможны.

4. Ящики (mailboxes)

Для каждого домена создаются ящики. Параметры ящика: - local_part и домен (итоговый адрес local_part@domain); - пароль (хранится как bcrypt-хэш; локальная аутентификация принимает только $-хэши); - квота (МБ); - признак активности (is_active) и «мягкое удаление» (deleted_at); - привязка к почтовой базе (database_id).

Занятое место по ящику считается автоматически. Пользователь может сам сменить пароль и настроить подпись/автоответ/алиасы из веб-клиента.

Пароли. У локальных ящиков пароль хранится как bcrypt-хэш. Ящики домена, привязанного к HopeDC, входят паролем домена (раздел 4а). Ящики на внешней аутентификации AD/LDAP без HopeDC через веб-почту не пускаются.

4а. Домен на HopeDC: вход по паролю домена

Почтовый домен можно привязать к каталогу HopeDC. Тогда пользователи входят в почту своим доменным паролем во всех протоколах: IMAP, POP3, SMTP (587), веб-почта, ActiveSync, CalDAV/CardDAV. Раздавать отдельные почтовые пароли не нужно.

Как проверяется пароль. Hope Mail делает LDAP simple bind к HopeDC по LDAPS. HopeDC сверяет пароль со своим хранилищем; отключённую учётную запись не пускает. Пароли приложений (раздел 2FA веб-почты) работают и для таких ящиков.

Настройка («Службы каталогов» → каталог HopeDC):

Затем создайте почтовый домен с источником «HopeDC» и выберите этот каталог. Имя почтового домена может отличаться от домена Windows (corp.ru при домене corp.local): ящики ищутся по почтовым адресам учёток.

Чем можно входить: почтовый адрес или алиас (ivanov@corp.ru), UPN (ivanov@corp.local), логин (ivanov) или CORP\ivanov.

Защита и кэш. - 5 неверных паролей за 15 минут блокируют вход в ящик на 15 минут (событие пишется в журнал домена). HopeDC сам перебор пока не ограничивает. - Успешный вход запоминается в памяти на 5 минут (почтовые клиенты переподключаются часто). Если HopeDC недоступен, ранее подтверждённый пароль принимается до 12 часов. - Синхронизация ящики не удаляет и не отключает. Отключённая в каталоге учётка не может войти, а почта на её адрес продолжает приниматься — как у Exchange.

Состояние перехода (кнопка «Переход» у каталога): сколько пользователей с почтой, сколько ящиков, у скольких пароль уже есть в HopeDC. Списки: кто ещё не входил, у кого есть адрес, но нет ящика, ящики без учётки в каталоге, отключённые учётки с ящиками. Там же «Синхронизировать сейчас» и «Проверить вход пользователя» — тот же путь, что у IMAP/SMTP, с пошаговым разбором.

Переход с MS AD + Exchange

1. Подключите HopeDC к AD (интеграция в HopeDC). Создайте каталог HopeDC в Hope Mail с включённым режимом перехода и автосозданием ящиков.
2. Создайте почтовый домен (например, corp.ru) с источником HopeDC. Ящики появятся по атрибутам mail/proxyAddresses.
3. Перенесите содержимое ящиков и переключайте пользователей на Hope Mail — см. раздел 4б. Каждый вход в почту сохраняет пароль пользователя в HopeDC — следите за долей «Пароль в HopeDC» в окне «Переход».
4. Когда все переключены — «Завершить переезд» (4б), выведите Exchange, затем примите роль KDC в HopeDC и отключите Windows-DC. Пользователи с паролем в HopeDC продолжают входить; остальным сбросьте пароль в HopeDC.
5. После «Отключить от AD» в HopeDC выключите режим перехода в каталоге Hope Mail.

MSG Gateway к домену не подключается.

HopeDC v129: без корневого CA домена HopeDC при каждом перезапуске создаёт новый сертификат LDAPS. После перезапуска HopeDC вход в почту остановится с ошибкой «сертификат сервера изменился» — закрепите отпечаток заново («Получить и закрепить») или временно задайте HOPE_LDAP_INSECURE_TLS=1. Исправление запрошено у команды HopeDC.

4б. Переход с Exchange: перенос ящиков и сосуществование

Домен → «Переход с Exchange». Поддерживаются Exchange 2013, 2016, 2019 (EWS, аутентификация NTLM или Basic). Пользователи переезжают партиями: содержимое копируется заранее, затем пользователь переключается, и почта начинает доставляться в Hope Mail. Пока переезд не завершён, почта неперенесённых пользователей продолжает ходить через Exchange — письма не теряются ни в одну сторону.

Что переносится

Не переносятся: Исходящие, журнал, заметки, «Дни рождения», кэш получателей, архивный ящик (In-Place Archive), общедоступные папки, правила и делегирование ящика, вложения у событий и задач, флажки «к исполнению» у писем, почтовые адреса контактов. Повторы «вторник и четверг» переносятся как еженедельная серия по дню начала, «второй вторник месяца» — как ежемесячная по дате; такие серии проверьте после переноса. Письма крупнее лимита (по умолчанию 50 МБ) пропускаются и учитываются в счётчике «пропущено».

Перенос повторяемый: уже перенесённые элементы запоминаются (exchmig/<id>.ids в каталоге настроек), повторный запуск («Догрузить») докачивает только новое.

Подготовка Exchange

1. Сервисная учётка (например CORP\svc_hope) с правом олицетворения. Один раз в Exchange Management Shell: powershell New-ManagementRoleAssignment -Name "HopeMail-Impersonation" -Role ApplicationImpersonation -User "CORP\svc_hope"
2. EWS доступен с сервера Hope Mail: https://<сервер Exchange>/EWS/Exchange.asmx. Если сертификат Exchange выдан внутренним CA или самоподписанный — «Получить и закрепить» в настройках закрепит его отпечаток SHA-256.
3. SMTP Exchange (порт 25) принимает почту от сервера Hope Mail: в Exchange 2013–2019 для этого достаточно стандартного коннектора приёма «Default Frontend» — письма приходят как от внешнего отправителя на принятые домены.
4. Домен маршрутизации — служебный домен, по которому Exchange отдаёт в Hope Mail почту уже переключённых пользователей, например hope.corp.ru. Его не нужно публиковать в DNS и не нужно заводить в Hope Mail как почтовый домен: Hope Mail сам принимает адреса логин@hope.corp.ru и доставляет их в ящик логин@corp.ru.
5. Скрипт для Exchange («Пользователи» → «Скрипт»): блок «1. Один раз» создаёт в Exchange коннектор отправки «Hope Mail (переезд)» на адрес Hope Mail для домена маршрутизации и разрешает в него автопересылку. Этот блок нужен при любом способе переадресации — без него Exchange не знает, куда слать почту домена маршрутизации, и блокирует пересылку наружу. Если транспортных серверов несколько, добавьте к New-SendConnector параметр -SourceTransportServers.

Настройки

«Сохранить и проверить» с тестовым ящиком проверяет вход в EWS и олицетворение (видно число элементов во входящих, календаре, контактах и задачах), доступ к правилам и приветствие SMTP Exchange. Настройки меняет только глобальный администратор; администратор домена видит вкладку и может переносить и переключать пользователей своего домена.

Порядок переезда

1. Настройте и проверьте подключение, выполните в Exchange блок «1. Один раз» из скрипта, включите сосуществование.
2. Если выбран вариант «MX → MSG → Hope Mail» — переведите MX домена на MSG/Hope Mail. До первого переключения вся почта по-прежнему оказывается в Exchange.
3. Перенести — фоновое копирование выбранных ящиков; ход виден в таблице (папка, элементы, ошибки). Объёмные ящики переносите заранее, за день-два до переключения.
4. Переключить — Hope Mail делает финальную догрузку, отмечает пользователя как переключённого (с этого момента почта ему доставляется в Hope Mail), ставит правило EWS и ещё раз догружает то, что успело прийти в Exchange за время переключения. Если выбран скрипт — выполните строки Set-Mailbox для переключённых.
5. Пользователи настраивают почтовые клиенты на Hope Mail (Autodiscover/Autoconfig) и входят тем же паролем домена.
6. Вернуть — откат пользователя на Exchange: правило EWS удаляется, почта снова идёт в Exchange. Перенесённое в Hope Mail остаётся. Строку отката Set-Mailbox … $null из скрипта выполните вручную.
7. Когда переключены все — Завершить переезд: сосуществование выключается, почта домена больше не пересылается в Exchange. Если кто-то не переключён, Hope Mail предупредит и предложит «Завершить принудительно». После этого переведите MX на Hope Mail (если ещё не сделано) и выводите Exchange.

Защита от петель: письмо, уже пересланное Hope Mail в Exchange, помечается заголовком X-Hope-Coexist; если Exchange вернёт его обратно, Hope Mail доставит его локально и запишет предупреждение в журнал. Переносы, переключения и завершение пишутся в журнал событий домена (категория EXCHANGE). Незавершённые задания после перезапуска сервера продолжаются; в кластере перенос выполняет только лидер.

5. Маршрутизация исходящей почты — коннекторы (Send Connectors)

Раздел Коннекторы задаёт, как отправлять письма во внешние домены (аналог Send Connector в MS Exchange).

Коннектор описывает: - адресные пространства (домены получателей, к которым он применяется; * — по умолчанию); - способ доставки: smart host (переслать на указанный релей/шлюз) или DNS/MX (прямая доставка по MX-записям получателя); - параметры узла (хост, порт), при необходимости — учётные данные.

При отправке письма сервер подбирает коннектор по домену получателя. Если подходящего коннектора нет, письмо помечается «нет коннектора» и не уходит — пользователь видит подсказку. Для внутренних адресатов доставка идёт напрямую в ящик, минуя коннекторы.

Хранится в smtp_connectors.json.

6. Очереди исходящей почты

Раздел Очереди показывает письма, ожидающие внешней доставки. Для каждого элемента видны отправитель, получатель, тема, статус и попытки. Очередь обрабатывается фоново; повторные попытки выполняются автоматически. Хранится в smtp_queue.json.

7. Приём внешней почты

Входящий SMTP (порт 25) принимает письма только для существующих локальных ящиков (open-relay запрещён). Полученное письмо кладётся во «Входящие» получателя, к нему применяются пользовательские правила и, при включённом автоответчике, отправляется автоответ (с защитой от циклов). Приём фиксируется в журнале домена (действие SMTP_IN).

При доставке сервер добавляет заголовок Return-Path с конвертным отправителем. В папку «Спам» (системная папка 4, в IMAP — Junk с флагом \Junk) сразу попадают письма отправителей из личного списка блокировки получателя и письма с меткой антиспама шлюза X-Spam-Flag: YES; правила и автоответ к ним не применяются. Отправители из списка блокировки организации (раздел «Жалобы на спам») отклоняются уже на MAIL FROM с кодом 550.

Алиасы адресов учитываются при приёме: письмо на алиас попадает в основной ящик.

7а. Жалобы на спам

Раздел «Жалобы на спам» (только глобальный администратор). Сотрудник жалуется кнопкой «Это спам» в веб-почте или переносом письма в папку «Спам» по IMAP (Outlook, Thunderbird, телефоны). Тогда:

1. Письмо переносится в «Спам», отправитель попадает в личный список блокировки сотрудника — его следующие письма этому сотруднику сразу идут в «Спам». Сотрудник видит и правит список в «Настройках» веб-почты; «Не спам» снимает блокировку и отзывает жалобу.
2. Жалоба появляется в разделе: одна строка на отправителя, счётчик сотрудников и шкала до порога, кто и когда пожаловался, тема последнего письма, пример письма (.eml).
3. Когда пожаловалось N разных сотрудников (по умолчанию 3, настраивается), отправитель автоматически попадает в список блокировки организации: его письма отклоняются при приёме (550). Отключается флажком «Автоматически блокировать…».

Действия администратора: «Заблокировать» (в список блокировки сразу, без порога), «Не спам» (жалоба закрыта, блокировка, поставленная по жалобам, снимается), удалить. Внизу раздела — сам список блокировки организации: записи по жалобам и ручные, адрес или домен через @ (@example.com).

Особенности: - Блокируется точный адрес отправителя (spammer@gmail.com), а не домен: один спамер с бесплатной почты не перекрывает почту всем её пользователям. - Ключ жалобы — конвертный отправитель (Return-Path), иначе адрес из From. Если они различаются, в личный список попадают оба. - Адреса собственных доменов автоматически не блокируются (жалоба на коллегу остаётся на рассмотрении). - Данные — spam_complaints.json (жалобы, настройки, список блокировки) и blocked_senders.json (личные списки) в каталоге настроек DB_DATA_DIR. - Передача на шлюз Hope MSG Gateway. Если перед Hope Mail стоит шлюз, жалобы можно передавать ему: тогда порог считается на шлюзе, и заблокированный отправитель отклоняется ещё на входе в организацию. Настройка — «Настройки сервера → Шлюз MSG»: адрес API шлюза (https://<шлюз>:6443), ключ интеграции (создаётся на шлюзе: «Карантин писем → Жалобы пользователей → Создать ключ»), «Получить и закрепить» для самоподписанного сертификата шлюза, флажок «Передавать жалобы на спам», затем «Проверить соединение» — оно входит в API шлюза по ключу. Передаются жалобы и отзывы («Не спам») вместе с примером письма до 512 КБ; жалобы на адреса своих доменов не передаются. Если шлюз недоступен, жалобы ждут в очереди (spam_complaints.json) и отправляются повторно до 3 суток; состояние видно вверху раздела «Жалобы на спам» и у каждой строки. Локальный порог и список блокировки Hope Mail при этом продолжают работать. Если на шлюзе включён белый список IP для API, добавьте туда адрес Hope Mail.

8. TLS-сертификаты и submission

Раздел TLS управляет сертификатом, которым защищаются STARTTLS-соединения (submission 587, входящий 25, IMAP 143, POP3 110), REST API (8443), CalDAV/CardDAV (8090) и ActiveSync/EAS (8092).

Возможности: - Загрузка «настоящего» сертификата из УЦ — файлы сертификата и приватного ключа (PEM). Заменяет самоподписанный, применяется «на лету» без перезапуска. - Генерация CSR (запроса на сертификат) прямо в админке — с указанием CN, организации, страны и списка SAN. Полученный CSR отправляется в удостоверяющий центр, выданный сертификат затем загружается обратно. - Просмотр статуса текущего сертификата.

Файлы сертификата/ключа хранятся в каталоге TLS сервера. Submission-порт (587) требует TLS и SMTP AUTH (PLAIN/LOGIN).

Постоянный самоподписанный сертификат. Если свой сертификат не загружен, сервер один раз генерирует самоподписанный и сохраняет его на диск (DB_DATA_DIR/selfsigned_cert.pem и selfsigned_key.pem). Он не меняется при перезапусках, поэтому единожды принятое в браузере исключение остаётся действительным. Для продакшена загрузите сертификат от УЦ.

8а. Защищённые соединения и безопасность

Начиная с этой версии, значения по умолчанию — безопасные; ослаблять их следует осознанно и только когда это оправдано (например, за TLS-терминирующим прокси на loopback). Управление — через переменные окружения (полный перечень в Развёртывание).

• HTTPS по умолчанию для REST API (8443, HOPE_API_TLS), CalDAV/CardDAV (8090, HOPE_DAV_TLS) и ActiveSync/EAS (8092, HOPE_EAS_TLS). Эти протоколы аутентифицируют по паролю (HTTP Basic / JWT), поэтому без TLS их можно перехватить.
• JWT-секрет. Токены сессий подписываются секретом из HOPE_JWT_SECRET; если он не задан — генерируется случайный и сохраняется в DB_DATA_DIR/jwt_secret.key. Встроенного «секрета по умолчанию» больше нет. В кластере задайте один общий HOPE_JWT_SECRET на всех узлах, иначе токен одного узла не примут остальные.
• CORS. По умолчанию к API допускаются только источники с localhost/127.0.0.1. Для доступа к админке/почте с внешнего адреса перечислите их в HOPE_CORS_ORIGINS (через запятую). Раньше по умолчанию допускался любой источник (*).
• AD/LDAP. TLS-сертификат контроллера домена проверяется. Для внутреннего AD с самоподписанным сертификатом проверку можно отключить HOPE_LDAP_INSECURE_TLS=1 (небезопасно, только для изолированного стенда).
• HopeDC. Отправка учётных данных на удалённый контроллер домена по http:// запрещена (loopback и https:// — разрешены). Осознанное исключение — HOPE_DC_INSECURE_HTTP=1. HTTPS API и LDAPS HopeDC проверяются по закреплённому отпечатку SHA-256 или по системному хранилищу сертификатов. LDAP без TLS к удалённому HopeDC запрещён (исключение — HOPE_DC_INSECURE_LDAP=1); HOPE_LDAP_INSECURE_TLS=1 отключает и проверку сертификата LDAPS HopeDC.
• Доставка в Hope MSG Gateway не откатывается на незашифрованное соединение, если STARTTLS не поднялся. Открытый канал возможен только при явном выборе security = none в коннекторе.
• Приём почты от Hope MSG Gateway (/internal/messages/receive) закрыт по умолчанию: требуется общий секрет HOPE_INTERNAL_TOKEN (в заголовке X-Internal-Token), одинаковый на HopeDB и в шлюзе. Без секрета эндпоинт отклоняет запросы — иначе через него можно было бы впрыснуть письмо в любой ящик. Канал шифруется TLS (API по HTTPS).

Белые списки IP («Настройки сервера → Сетевой доступ»)

Два списка: «Доступ к панели администратора» и «Доступ к API». Оба действуют на весь порт админки (8443) и на порт веб‑почты: запрос пропускается, если адрес клиента есть хотя бы в одном включённом списке. Запись — адрес (192.0.2.10, 2001:db8::1), подсеть CIDR (192.0.2.0/24) или маска (192.0.2.*).

• Тумблер и список — черновик: добавлять, выключать и удалять записи можно и при выключенном ограничении. Действовать изменения начинают после кнопки «Сохранить»; «Отмена» возвращает сохранённое состояние.
• Под списком показан ваш адрес, каким его видит сервер, и кнопка «Добавить мой адрес», если его нет в списке.
• Защита от самоблокировки. Сервер не сохраняет изменение, после которого адрес администратора, нажавшего «Сохранить», потеряет доступ: включить ограничение без своего адреса или удалить и выключить запись, по которой вы сейчас работаете, нельзя. Панель предупреждает об этом заранее.
• Доступ с самого сервера (127.0.0.1, ::1) разрешён всегда. Если доступ всё же потерян (например, сменился ваш внешний адрес), зайдите через SSH‑туннель: ssh -L 8443:127.0.0.1:8443 <сервер>, затем откройте https://127.0.0.1:8443/ и исправьте список.
• За обратным прокси (nginx) прокси обязан передавать адрес клиента: proxy_set_header X-Real-IP $remote_addr; и proxy_set_header X-Forwarded-For $remote_addr; во всех location, ведущих на Hope Mail. Без этого все запросы через nginx выглядят как пришедшие с самого сервера (127.0.0.1) и белый список их пропускает — ограничение фактически не работает. Заголовки учитываются только от доверенных прокси из HOPE_MAIL_TRUSTED_PROXIES (по умолчанию 127.0.0.1 и ::1); прокси на другой машине добавьте туда. Проверка: при входе через прокси строка «Ваш адрес» под списком должна показывать адрес рабочего места, а не 127.0.0.1. Подробно — Развёртывание, п. 6.1.

Аварийный доступ. Если в системе не осталось активного суперпользователя или утерян пароль admin, задайте HOPE_ADMIN_RESET=<новый-пароль> и перезапустите сервер — учётная запись admin будет создана/сброшена как суперадминистратор. Сразу после входа снимите переменную, иначе пароль будет сбрасываться при каждом запуске. Удалить единственного активного суперпользователя система не даёт (защита от блокировки доступа).

9. Журналы и мониторинг (SIEM)

Раздел журналов/SIEM показывает события домена: приём и отправку почты, ошибки доставки, действия администратора. Записи содержат домен, актора, сообщение и уровень (SUCCESS/INFO/ERROR). Журнал полезен для расследования проблем доставки и аудита.

10. Лицензия и лицензионное соглашение

Редакции и ключ

Без ключа сервер работает в редакции Free (3 домена, 3 почтовые базы, 100 ящиков в домене). Редакции Standard и Enterprise включаются подписанным ключом лицензии; ограничения и функции задаёт ключ, типовые значения — в Приложении 1 к лицензионному соглашению. Кластер (HA) — только Enterprise.

Ключ привязан к серверу через отпечаток: SHA‑256 от идентификатора ОС (/etc/machine-id) и идентификатора установки (install_id в каталоге данных). Получить ключ: «Настройки сервера → Лицензия» → «Сформировать .req файл» → отправить файл вендору или партнёру → вставить полученный ключ и нажать «Применить». Сервер не обращается к вендору ни при активации, ни при проверке ключа.

• Отпечаток меняется при переустановке ОС, смене machine-id или каталога данных — тогда нужен новый ключ.
• Раньше отпечаток считался по переменной HOSTNAME; у службы systemd её нет, поэтому отпечаток был одинаковым у всех серверов. Ключ старого формата, установленный до обновления, при первом запуске новой версии привязывается к этому серверу (license.bind) и продолжает работать. Перенесённый на другой сервер — не принимается. Новые ключи выпускаются только по новому отпечатку.

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

Лицензионное соглашение (EULA)

Текст соглашения встроен в сервер. При первом входе в панель (и после выхода новой редакции) вместо разделов открывается окно с текстом, галочкой «Я прочитал(а)… принимаю от имени организации… подтверждаю полномочия» и кнопками «Принимаю» / «Не принимаю» (выход).

• Принять может только полный администратор (роль с правом *). Остальные видят «Соглашение должен принять полный администратор панели».
• Пока соглашение не принято, API панели отвечает 428 с "code": "eula_required", кроме входа и выхода, проверки прав, двухфакторной аутентификации своей учётки и самого соглашения.
• Почта работает всегда: SMTP, IMAP, POP3, CalDAV/CardDAV, ActiveSync, веб‑почта (/api/user/*), приём от шлюза (/internal/*), межузловые эндпоинты кластера и проверки health/ready от принятия не зависят.
• Факт принятия — редакция, SHA‑256 текста, учётная запись, IP‑адрес, браузер и время — записывается в eula_acceptance.json каталога данных (права 0600) и в журнал событий. У каждого узла кластера своя запись: соглашение принимается на каждом узле.
• Раздел «Лицензия» показывает карточку «Лицензионное соглашение»: кто и когда принял, кнопка «Открыть соглашение». Публичная страница с текстом — https://<сервер>:<порт>/eula, ссылка на неё есть на странице входа.
• В английском интерфейсе текст показывается на русском с пометкой, что юридически действует русский текст.
• Для автоматизированных стендов: переменная HOPE_MAIL_EULA_ACCEPTED=1 в юните считает соглашение принятым (в карточке это видно).

Документы «Лицензионное соглашение» (EULA.html) и «Компоненты третьих лиц» (THIRD_PARTY.html, THIRD_PARTY_NOTICES.txt) входят в комплект документации. Перечень компонентов в продукт не встраивается и предоставляется по запросу.

11. Пользовательские данные и файлы состояния

Данные хранятся в каталоге DB_DATA_DIR (по умолчанию ./hopedb_data) в JSON-файлах и WAL, тела писем — в BLOB_DATA_DIR (./hopedb_blobs). Ключевые файлы:

Все файлы состояния — часть резервной копии. См. раздел бэкапов в Развёртывание.

12. Обслуживание

• Резервное копирование. Регулярно копируйте DB_DATA_DIR и BLOB_DATA_DIR целиком (желательно при остановленном сервере или атомарным снапшотом ФС).
• Ротация журналов. Журналы домена растут — предусмотрите архивирование.
• Компакция WAL. Удаление писем оставляет «тумбстоны» в WAL; периодическая компакция (в разработке) уменьшит объём. Пока используйте резервные копии и следите за местом.
• Смена сертификата. Загружайте новый сертификат до истечения текущего — применение происходит без перезапуска.
• Проверка доступа клиентов. После изменений TLS проверьте подключение по IMAP/SMTP/DAV живым клиентом.

Обновление из панели и номера выпусков

Выпуски нумеруются, как в HopeDC: v22, v23, … Номер виден в разделе «Настройки сервера → Обновления», в шапке панели и в ответе hope-mail-server --version (hope-mail-server 22 (semver=22.0.0)). Пакет обновления называется hope-mail-server_v22.gz, в манифесте номер пишется без буквы: "version": "22" (с буквой v22 тоже принимается). До v22 версии были вида 1.0.21; v22 считается новее 1.0.21, а пакет 1.0.21 на v22 распознаётся как откат на старую версию.

Манифест онлайн-источника:

{
  "stable": { "version": "22", "url": "hope-mail-server_v22.gz", "sha256": "<SHA-256 файла .gz>", "notes": "v22: …" },
  "beta":   { "version": "23-beta", "url": "…", "sha256": "…", "notes": "…" }
}

Обновление с 1.0.21 до v22. Онлайн — как обычно: сервер 1.0.21 возьмёт номер 22 из манифеста. Из архива (закрытый контур) — в поле «Версия» укажите 22: сервер 1.0.21 не умеет сам читать номер выпуска из пакета и без этого поля откажет. Начиная с v22 номер определяется сам.

Номер выпуска для сборки — старший номер версии в Cargo.toml (22.0.0 → v22); при следующем выпуске его увеличивают на единицу. Обновление ставит root-помощник hope-mail-update.path (его устанавливает скрипт развёртывания): бэкап бинарника, установка, перезапуск, при неудаче — откат.

13. Диагностика