Hope MSG Gateway — руководство администратора

Актуально на 19 октября 2026.

Руководство описывает Hope MSG Gateway 0.2: установку, первичную настройку и ежедневную работу администратора. Разделы идут в том порядке, в каком шлюз обычно вводят в работу.

Назначение и путь письма

Hope MSG Gateway стоит на границе сети (в DMZ) между Интернетом и почтовым сервером организации. Он принимает входящую почту, проверяет её и передаёт дальше, а исходящую подписывает DKIM и доставляет по MX получателей. Кроме того, у шлюза есть собственные ящики с веб-почтой, IMAP, ActiveSync и CalDAV.

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

Исходящие письма сотрудников не проверяются антиспамом и SPF, DKIM, DMARC: шлюз подписывает их DKIM и отправляет через ту же очередь.

Установка и обновление

Шлюз ставится на Debian или Ubuntu одним скриптом install_msg.sh; с Windows его запускает deploy_msg.cmd из папки _deploy. Повторный запуск безопасен: скрипт обновляет бинарник, сохраняя данные и настройки.

Что делает скрипт:

1. Создаёт пользователя hopemsg — служба работает от него, без прав root.
2. Кладёт бинарник в /usr/local/bin/hope-msg-gateway, данные — в /var/lib/hope-gateway/msg_local_data.
3. Создаёт мастер-ключ /etc/hope-msg/master.key (только root). Им шифруются ключи сертификатов, пароли S3, VRRP, прокси и ключ бэкапов. Сохраните копию ключа: без него секреты не расшифровать.
4. Регистрирует службу systemd hope-msg-gateway и открывает порты в ufw или firewalld.
5. Ставит keepalived (плавающий IP) и ClamAV (если памяти не меньше 2 ГБ; отключить — HOPE_SKIP_CLAMAV=1).
6. Ставит три root-помощника для действий, которые служба сама сделать не может: применение настроек keepalived, установка обновлений шлюза и обновление антивирусных баз. Каждый сам перепроверяет то, что ему передала служба.
7. Сохраняет текст лицензионного соглашения в /usr/local/share/doc/hope-msg-gateway/EULA.txt (командой hope-msg-gateway --eula).

ClamAV и keepalived не входят в поставку шлюза: скрипт ставит их из репозитория ОС, и они используются на условиях своих лицензий (GNU GPL v2).

Служба запускается без аргументов. Допустимы только --version, --eula (текст соглашения с редакцией и SHA‑256) и --help; любой другой аргумент печатает подсказку и завершает работу с кодом 2, не запуская шлюз.

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

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

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

{
  "stable": { "version": "22", "url": "hope-msg-gateway_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-msg-update.path (его устанавливает скрипт развёртывания): бэкап бинарника, установка, перезапуск, при неудаче — откат.

Первый вход в админку — https://<IP шлюза>:6443, логин admin, пароль 123456; система сразу попросит его сменить. Затем полный администратор принимает лицензионное соглашение (см. «Лицензия и лицензионное соглашение»). Дальнейшие обновления шлюза можно ставить из админки («Настройки MSG → Обновления»): онлайн или пакетом «Из архива». Если новая версия не запустится, шлюз сам вернёт прежнюю.

Первичная настройка

После установки нужно сказать шлюзу, для каких доменов он принимает почту и куда её передавать, а затем опубликовать записи DNS.

Тот же порядок ведёт панель «Начало работы» (см. ниже).

1. Домены. Свой домен с ящиками на самом шлюзе — раздел «Домен», только в лицензии Enterprise. Это внутренний домен шлюза: к AD и LDAP шлюз не подключается, учётные записи и пароли ящиков свои. Домены, почта которых живёт на другом сервере (например, в Hope Mail), — маршруты в «Правила фильтрации → Relay»: домен и адрес сервера, куда передавать письма.
2. Доверенные отправители. В том же разделе Relay укажите серверы организации, которым разрешено отправлять почту во внешний мир. Их письма не проверяются антиспамом и подписываются DKIM.
3. Имя и IP шлюза. «Правила фильтрации → SPF, DKIM, DMARC → Отправка», шаг 1: внешнее имя (например, mail.hopedc.ru) и постоянный внешний IP. Под этим именем шлюз представляется другим серверам. Имена вроде localhost или localdomain крупные почтовые службы отвергают.
4. Ключ DKIM. Там же, шаг 3: создайте ключ для каждого домена. Подпись включается сразу, поэтому запись в DNS публикуйте сразу же.
5. Записи DNS. Шаг 2 на той же закладке показывает готовые значения для каждого домена; кнопка «Проверить» сверяет их с DNS.

Несколько доменов. Внешнее имя шлюза (FQDN) одно на сервер — это имя самого шлюза, а не домена: им шлюз представляется в SMTP, на него указывают MX всех доменов, ему соответствует PTR внешнего IP. Через один шлюз публикуется сколько угодно доменов: у каждого свой маршрут в Relay, свой ключ DKIM (подпись выбирается по домену в From) и свои записи SPF, DKIM, DMARC; MX всех доменов указывает на одно имя, например 10 mail.hopedc.ru. Проверка подлинности (DMARC) смотрит на домен из DKIM-подписи и конвертного отправителя, поэтому общее имя шлюза ей не мешает. Ограничение одно: собственный домен с ящиками на самом шлюзе (раздел «Домен», Enterprise) пока один; несколько — в плане релиза 1.0.

SPF начинайте с ~all, DMARC — с p=none: через 2–4 недели без жалоб переводите в -all и p=quarantine. Проверка после настройки: отправьте письмо в Gmail или Яндекс, откройте «Показать оригинал» — должно быть spf=pass dkim=pass dmarc=pass.

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

В панель встроен путеводитель (как в HopeDC и Hope Mail Server). Кнопки — в верхней строке рабочей области.

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

Состояние пунктов проверяется по реальным настройкам при каждом открытии. Пункт, сделанный иначе, полный администратор может отметить вручную («Отметить» / «Снять отметку»); ручные отметки общие для шлюза.

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

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

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

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

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

Настройки хранятся на шлюзе в ui_prefs.json каталога данных, зашифрованном мастер-ключом. В кластере файл не реплицируется: настройки хранятся на узле, где их выбрали.

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

Приём почты и фильтрация

Проверки идут от дешёвых к дорогим: сначала по адресу сервера, потом по адресам отправителя и получателя, и только затем по содержимому. Белый список и доверенные серверы (Relay) пропускают антиспам и SPF/DKIM/DMARC, но не антивирус.

1. Подключение. Белый и чёрный списки по IP (адреса, подсети CIDR, IPv6), затем DNSBL, лимит подключений с одного IP и проверка PTR.
2. Отправитель (MAIL FROM). Белый и чёрный списки по адресу и домену.
3. Получатель (RCPT TO). Домен должен быть своим или из Relay; здесь же срабатывает грейлистинг.
4. Текст письма (DATA). Правила «Regex контент», затем антивирус и запрещённые вложения, SPF/DKIM/DMARC и оценка спама.

Лимиты сессии: письмо до 50 МБ, до 100 получателей, строка команды до 4096 байт, простой до 5 минут, до 20 неверных команд.

SPF, DKIM, DMARC (закладка «Приём»). Каждая проверка включается отдельно. Отсутствие записи у домена отправителя — не ошибка, а ошибки DNS никогда не ведут к отказу. По умолчанию SPF fail даёт +3 балла спама, неверная подпись DKIM — +2, а письмо, не прошедшее DMARC, уходит в карантин (а не отклоняется), чтобы ничего не потерять. Проверка «Что будет с письмом от отправителя?» показывает решение шлюза до того, как партнёр пожалуется.

Антиспам считает баллы и сравнивает с тремя порогами.

Пороги по умолчанию: от 5 — пометить (тема с [SPAM] и заголовок X-Spam-Flag: YES), от 8 — в карантин, от 15 — отклонить. Грейлистинг откладывает первое письмо от незнакомого отправителя на 5 минут и помнит прошедших 36 дней. Spamhaus не отвечает на запросы через публичные DNS (8.8.8.8 и подобные) — используйте свой DNS-сервер.

Антивирус и обновление баз

Каждое письмо проверяется ClamAV (служба clamd). Настройки — «Правила фильтрации → Антивирус → Настройки»:

• Адрес clamd — unix:/var/run/clamav/clamd.ctl на этом сервере или tcp:хост:3310 на другом. clamd нужно около 1,5 ГБ памяти.
• Найден вирус — отклонить (554) или в карантин.
• Антивирус недоступен — принимать без проверки (с записью в журнал) или временно отклонять (451), чтобы отправитель повторил позже.
• Опасные вложения — блокировка по расширению (exe, scr, js, iso и другие), в том числе «двойному» (счёт.pdf.exe) и внутри пересланных писем. Работает и без ClamAV.

Кнопка «Проверить антивирус (EICAR)» отправляет безопасную тестовую строку: если clamd её не опознал, баз нет или они не загружены.

Обновление баз

Базами управляет сам шлюз (закладка «Обновление баз»); системный freshclam установщик отключает, чтобы два обновлятеля не мешали друг другу. Вверху закладки видны версии main, daily и bytecode, дата выпуска и версия, загруженная в clamd. База daily старше 2 дней помечается жёлтым, старше 7 — красным.

Онлайн. Шлюз запускает freshclam по расписанию (от раза в час до раза в сутки, по умолчанию каждые 4 часа) или по кнопке «Обновить сейчас». Источник:

• Серверы ClamAV (database.clamav.net). С 2022 года они отказывают российским IP с ошибкой 403.
• Зеркало — например, https://packages.microsoft.com/clamav, или своё зеркало в локальной сети (утилита cvdupdate: cvd update, затем cvd serve). При смене источника шлюз сбрасывает паузу, которую freshclam делает после отказа 403/429.
• При необходимости — HTTP-прокси с логином и паролем (пароль хранится зашифрованным).

Первая загрузка — около 250 МБ, дальше скачиваются только изменения. Журнал freshclam последнего запуска открывается прямо на закладке.

Офлайн. Для серверов без Интернета: загрузите файлы main, daily, bytecode (.cvd или .cld) или архив с ними (.tar, .tar.gz, .zip) и нажмите «Установить». Где взять файлы:

1. На другом шлюзе Hope MSG с Интернетом — кнопка «Скачать базы (.tar)» на этой же закладке.
2. На компьютере с Python: pip install cvdupdate, cvd update — файлы в ~/.cvdupdate/database.
3. На Linux с ClamAV: freshclam, файлы из /var/lib/clamav.
4. С зеркала напрямую, например https://packages.microsoft.com/clamav/daily.cvd.

Перед установкой шлюз проверяет заголовок, контрольную сумму и цифровую подпись ClamAV и сравнивает версию с установленной. Более старую версию он поставит только с флажком «Разрешить более старую версию». После установки clamd перечитывает базы без остановки проверки. Если за 3 минуты он не загрузил новую версию, шлюз сам вернёт прежние базы. Все операции попадают в «Историю обновлений» и в журнал аудита.

Если clamd работает на другом сервере, закладка показывает только загруженную версию: базы обновляются на том сервере.

Отправка и очередь доставки

Каждое принятое письмо сначала ложится в очередь на диске (msg_local_data/queue), поэтому сбой сервера получателя или перезапуск шлюза не теряет почту. Доставка идёт в 8 потоков.

• Повторы. Временная ошибка (код 4xx, нет связи) — повтор через 1, 5, 15, 30 минут, затем 1, 2, 4 и 8 часов, всего до 5 суток.
• Отказ. Постоянная ошибка (5xx, домен не существует) или истечение 5 суток — отправитель получает отчёт о недоставке.
• Раздел «Очередь доставки» показывает письма в ожидании с причиной последней неудачи и историю. Письмо можно отправить повторно сразу (одно или все) или удалить.
• DKIM-подпись. Подписываются письма из веб-почты, почтовых программ (587/465 с паролем) и доверенных серверов Relay, если домен в заголовке From совпадает с доменом ключа. Почта из Интернета не подписывается.
• Квоты. Письмо в переполненный ящик шлюза не принимается; отправитель получает отказ.

Многие провайдеры закрывают исходящий порт 25. Если письма висят в очереди с ошибкой соединения со всеми получателями сразу, попросите провайдера его открыть.

Карантин, журнал и SIEM

Карантин хранит письма, задержанные антивирусом, антиспамом, DMARC или правилами Regex, с причиной задержки. «Выпустить» кладёт письмо в очередь доставки и показывает результат; «Удалить» удаляет его безвозвратно. Чтобы партнёр с неверными записями DNS не попадал туда снова, добавьте его в белый список.

Жалобы пользователей на спам — вторая вкладка карантина. Сотрудник ящика шлюза жалуется кнопкой «Это спам» в веб-почте или переносом письма в папку «Спам» из Outlook, Thunderbird (IMAP) или с телефона (ActiveSync). Письмо уходит в «Спам», отправитель — в личный список блокировки сотрудника (его следующие письма этому сотруднику сразу попадают в «Спам»; список виден в «Настройках» веб-почты, «Не спам» снимает блокировку и отзывает жалобу). Жалоба попадает на вкладку: одна строка на отправителя, счётчик сотрудников, кто и когда пожаловался, пример письма.

• Порог. Когда пожаловались N разных сотрудников (по умолчанию 3), отправитель автоматически попадает в чёрный список «Списков доступа» (тип «email», комментарий «Жалобы на спам…») и отклоняется при приёме кодом 550. Порог и автоблокировка настраиваются на вкладке; права — «Карантин» (просмотр/изменение).
• Решение администратора. «Заблокировать» — в чёрный список сразу; «Не спам» — жалоба закрыта, блокировка, поставленная по жалобам, снимается из чёрного списка.
• Точный адрес сильнее домена. Блокируется адрес (spammer@gmail.com), а не домен. Запись «email» в чёрном списке теперь срабатывает, даже если домен отправителя в белом списке (например доверенный gmail.com); явная запись «email» в белом списке по-прежнему главнее. Белый список по IP клиента, как и раньше, отключает проверки отправителя.
• Внутренние адреса (собственный домен шлюза) автоматически не блокируются.
• При доставке в ящик шлюз добавляет Return-Path с конвертным отправителем — по нему ведутся жалобы. Письма, помеченные антиспамом (X-Spam-Flag: YES), доставляются в ящики шлюза сразу в «Спам»; правила ящика и автоответ к письмам в «Спаме» не применяются.

Жалобы от Hope Mail Server. Если почтовые ящики живут в Hope Mail за шлюзом, их жалобы тоже могут учитываться на шлюзе. На вкладке «Жалобы пользователей» нажмите «Создать ключ» (ключ показывается один раз), в Hope Mail откройте «Настройки сервера → Шлюз MSG»: адрес https://<шлюз>:6443, ключ в поле «Ключ интеграции», «Получить и закрепить» для самоподписанного сертификата, флажок «Передавать жалобы на спам», «Проверить соединение». Жалобы Hope Mail отмечены источником («Hope Mail <имя сервера>») и считаются в пороге вместе с жалобами ящиков шлюза, «Не спам» в Hope Mail отзывает жалобу. Домены из Relay считаются своими и автоматически не блокируются. Приём идёт по POST /api/integration/complaint с ключом в Authorization: Bearer; если включён белый список IP для API («Сетевой доступ»), добавьте туда адрес Hope Mail. «Новый ключ» заменяет прежний, «Отозвать» отключает приём.

Ответ на HTML-письма в веб-почте сохраняет оформление: цитата вставляется как в Gmail и Outlook («дата, отправитель пишет:» и исходное письмо с полосой слева), ответ и пересылка уходят в HTML, черновики сохраняют форматирование. Из цитаты удаляются скрипты, обработчики событий, стили страницы и формы.

Журнал аудита записывает входы и выходы администраторов, каждое изменение настроек (кто, что, результат), события антивируса, антиспама и очереди. Он хранится в msg_local_data/audit/audit.jsonl: до 5 файлов по 20 МБ, старые удаляются автоматически.

SIEM («Настройки MSG → SIEM») пересылает те же события в вашу систему мониторинга:

• формат — CEF, syslog (RFC 5424) или JSON;
• транспорт — UDP или TCP, адрес и порт приёмника;
• по желанию — события почтового потока (каждое принятое и отклонённое письмо), а не только административные.

Кнопка «Тестовое сообщение» передаёт пробное событие; рядом показан пример события в выбранном формате. Журнал можно выгрузить в CSV.

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

Кластер. Два шлюза делят плавающий IP через keepalived (VRRP): если на активном узле перестал отвечать порт SMTP, адрес переезжает на второй. Настройки — «Настройки MSG → Кластер»: роль (MASTER или BACKUP), сетевой интерфейс, номер группы VRRP, приоритет, плавающий IP и пароль (кнопка генерирует случайный; на обоих узлах он должен совпадать). Очередь, ящики и антивирусные базы у каждого узла свои: письма из очереди отказавшего узла уйдут, когда он вернётся.

Безопасность.

• Служба работает без прав root; файлы данных создаются с правами 0600.
• Секреты в настройках зашифрованы AES-256-GCM ключом /etc/hope-msg/master.key; сам ключ лежит вне каталога данных, поэтому копия каталога секреты не раскрывает.
• Доступ администраторов разграничен ролями: для каждого раздела — право на просмотр или изменение («Настройки MSG → Роли и права»).
• Доступ к панели открывается после принятия лицензионного соглашения (см. ниже).

Белые списки IP панели («Настройки MSG → Сетевой доступ», вкладки «Доступ к Панели (UI)» и «Доступ к API»). Оба списка действуют на весь порт админки 6443: запрос пропускается, если адрес клиента есть хотя бы в одном включённом списке. Поэтому если включён только список API, в нём должны быть и адреса администраторов, и адрес Hope Mail Server (жалобы на спам). Запись — адрес (192.0.2.10, 2001:db8::1), подсеть CIDR (192.0.2.0/24) или маска (192.0.2.*).

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

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

Редакции. Без ключа шлюз работает в редакции Free: приём, фильтрация и пересылка почты, антиспам, антивирус, SPF/DKIM/DMARC, карантин и очередь. Платная лицензия (Standard) добавляет кластер (HA), Enterprise — собственный почтовый домен с ящиками. Ключ привязан к серверу (идентификатор машины и установки); при переносе на другой сервер или переустановке ОС нужен новый ключ. Шлюз не обращается к вендору при активации и проверке ключа: отпечаток передаётся вендору файлом .req из раздела «Лицензия».

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

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

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

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

Резервные копии. Раздел «Резервное копирование» создаёт архив настроек и почты вручную или по расписанию, по желанию зашифрованный паролем. В архив секреты попадают расшифрованными, чтобы его можно было восстановить на другом сервере с другим мастер-ключом, — поэтому задавайте пароль архива и храните его отдельно.

Диагностика

Большинство проблем видно в админке: «Трафик шлюза» (журнал соединений), «Очередь доставки» и история обновления баз. На сервере пригодятся команды:

journalctl -u hope-msg-gateway -n 100      # журнал службы шлюза
journalctl -t hope-msg-avdb -n 50          # помощник обновления антивирусных баз
systemctl status hope-msg-avdb.path hope-msg-update.path hope-msg-keepalived.path
cat /run/hope-msg-avdb/status.json          # итог последнего обновления баз
ss -ltn | grep -E ':(25|6443|6444)\b'       # слушают ли порты