docs: D3 backup tar path, D4 README/compose fixes, D5 plan sync

Document stopped-container tar backup with WAL warning and manifest
consumption; refresh status banner and port-587 note; align
implementation-plan B.1 with actual session behaviour on password change.

Co-authored-by: Cursor <cursoragent@cursor.com>

CHANGELOG.md

@@ -22,6 +22,14 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); version
 
 ### Changed
 
+- docs (D3): README backup — stopped-container `tar` of `./data` (with live-container
+  WAL warning), `manifest.json` consumed after a matching restore.
+- docs (D4): README status banner (v1.0 implemented, links to open questions and
+  documentation pass); new *Published ports* note for 587; compose usage comment
+  corrected (TLS via `./certs` bind mount, not `.env`).
+- docs (D5): `implementation-plan.md` B.1 — password change signs out other
+  sessions only (implementation diverged from original plan; README was already
+  correct).
 - docs: documentation plan now targets retiring `specification.md` after D9 —
   migration map to `product.md`, `architecture.md`, `development.md`, and
   expanded `security.md`; D9 added to the release gate.

README.md

@@ -11,10 +11,11 @@ SelfPost sends mail straight to the internet from your own IP, with DKIM
 signing, and is configured once through the panel. It is **outbound only** — it
 does not receive mail, provide mailboxes, or offer webmail.
 
-> **Status: under active development.** See [docs/specification.md](docs/specification.md)
-> for the full requirements, [docs/implementation-plan.md](docs/implementation-plan.md)
-> for the phased build plan, and [docs/security.md](docs/security.md) for the
-> security trade-offs that were accepted knowingly.
+> **Status: v1.0 implemented; pre-release polish in progress.** Open v1.x
+> questions: [docs/implementation-plan.md](docs/implementation-plan.md).
+> Documentation pass before the next tag:
+> [docs/documentation-plan.md](docs/documentation-plan.md). Accepted security
+> trade-offs: [docs/security.md](docs/security.md).
 
 ## Requirements (site checklist)
 
@@ -262,10 +263,20 @@ Two related but distinct operations — spec 7.5:
   ```
   **Restore** means unpacking that archive into a fresh `/data` bind mount and
   starting a container of the **exact same image version** that created it —
-  SelfPost refuses to start otherwise and tells you which tag to use. This is
-  why the compose file below pins a fixed tag rather than `:latest`: without a
-  known version, there'd be no way to tell which image restoring a given
-  backup actually requires.
+  SelfPost refuses to start otherwise and tells you which tag to use. On the
+  first successful start after restore, `manifest.json` from the archive is
+  **deleted** — it guards only that one boot, so a later in-place upgrade is
+  not blocked. This is why the compose file below pins a fixed tag rather than
+  `:latest`: without a known version, there'd be no way to tell which image
+  restoring a given backup actually requires.
+
+  **Alternative: archive `./data` while stopped.** If the service can be taken
+  offline, `docker compose down` then `tar czf selfpost-data.tar.gz ./data` on
+  the host is safe — nothing is writing to SQLite. Do **not** tar `./data` while
+  the container is running: the database uses WAL mode and a naive copy can
+  capture an inconsistent snapshot. The panel/CLI backup remains preferable when
+  you cannot afford downtime because it takes a consistent SQLite snapshot via
+  the Backup API on a live container.
 
 - **Export/import a single domain** (domain page → *Export domain* to write the
   file, *Backup* → *Import a domain* to read it back in): moves one domain — its DKIM key and its applications' **working**
@@ -278,6 +289,13 @@ backup) or working application credentials (domain export) in the clear or in
 directly reversible form. Treat them like any other credential material:
 encrypt at rest, restrict who can read them, don't email them around.
 
+## Published ports
+
+`deploy/docker-compose.yml` maps **465** and **587** to the host. Port 465
+(smtps) is always active. Port **587** is published even when
+`SUBMISSION_ENABLE=false`; nothing listens until you set it to `true` — harmless,
+but it can look like an open port in external scans.
+
 ## Fixed image tag
 
 `deploy/docker-compose.yml` pins an explicit version (`ghcr.io/mixeme/selfpost:X.Y.Z`),

deploy/docker-compose.yml

@@ -11,7 +11,8 @@
 # Usage:
 #   1. Copy this file (and .env.example as .env) next to your own ./data and
 #      ./certs directories, or adjust the paths below.
-#   2. Fill in .env (hostname, at least one strong TLS_CERT/KEY path).
+#   2. Fill in .env (at minimum SELFPOST_HOSTNAME). Put PEM files in ./certs —
+#      TLS paths are fixed in this file to match that bind mount, not .env.
 #   3. docker compose up -d
 #
 # The image tag below is FIXED on purpose (spec 10 p.10, 7.5.A): backup
@@ -66,6 +67,8 @@ services:
       # the host network at 127.0.0.1:8080 (see the vhost fragment), so the
       # panel is never directly reachable from the internet without TLS.
       - "465:465"
+      # 587 is mapped even when SUBMISSION_ENABLE=false; Postfix listens only
+      # when the variable is true — see README "Published ports".
       - "587:587"
       - "127.0.0.1:8080:8080"
     # Hardening (spec 10 p.6). SelfPost's entrypoint still needs to run as

docs/implementation-plan.md

@@ -31,7 +31,7 @@ v1.0/v1.x: открытые вопросы для согласования. Об
    - срок — **скользящий, 7 дней бездействия**, задаётся `PANEL_SESSION_IDLE_DAYS` (целое число дней, как `SEND_LOG_RETENTION_DAYS`). Абсолютного потолка нет **сознательно**: у админа, заходящего регулярно, сессия живёт неограниченно долго;
    - **мониторинговые опросы сессию не продлевают.** Четыре фрагмента (`/status/fragment`, `/queue/body`, `/logtail/body`, `/sendlog/rows`) опрашивают сервер `every 5s`; продлевай их — и забытая открытая вкладка держала бы вход вечно, а «7 дней бездействия» означало бы «7 дней без открытой вкладки». Активностью считается переход по странице или действие, то есть всё, кроме GET-запросов с заголовком `HX-Request`;
    - `Max-Age` cookie равен сроку и переставляется ровно тогда, когда продлевается строка в БД (запись в БД — не чаще раза в час, чтобы не писать на каждый клик);
-   - смена пароля завершает **все** сессии, включая ту, из которой её делают → редирект на `/login`.
+   - смена пароля завершает **все остальные** сессии; текущая остаётся активной (`DeleteOtherSessions` в [sessions.go](../internal/store/sessions.go)). **Изменение при реализации:** первоначально планировалось «все, включая текущую → редирект на `/login`»; от этого отказались — оператор, только что сменивший пароль, не должен повторно входить; панель сообщает «Any other signed-in sessions were signed out» ([handlers_account.go](../internal/web/handlers_account.go)).
 
    Известное свойство, вытекающее из хранения в БД: восстановление старого бэкапа возвращает и строки сессий, поэтому сессия, разлогиненная уже после снятия бэкапа, оживёт — если её браузер всё ещё хранит cookie и срок не истёк.
 2. **Ротация `mail.log` — решено: отказаться от `copytruncate` в пользу «переименовать + `postfix reload`».** Прежняя формулировка («несколько строк мониторинга, приемлемо как известное свойство») занижала проблему: тот же тейлер, что рисует экран лога, сверяет и финальные статусы доставки — `UpdateStatus` вызывается **только** из [internal/logtail](../internal/logtail/logtail.go), больше ниоткуда. Значит потерянная строка `status=sent` — это строка журнала отправки, навсегда застрявшая в `queued`, то есть тихая порча данных, а не пробел в мониторинге. Окон потери при `copytruncate` два:
@@ -111,7 +111,7 @@ v1.0/v1.x: открытые вопросы для согласования. Об
 
 5. **Проверка на уязвимости моделью Fable — решено: отдельный проход после B.1–B.3 и C.4, до тега релиза.**
 
-   **Почему после всех четырёх, а не по ходу каждого.** Каждый пункт трогает ровно ту поверхность, которую аудит ТЗ 7.6 на v1.0 видел в другом виде: B.1 переписывает аутентификацию (сессии в SQLite, SHA-256 от токена, скользящее продление, разлогин всех при смене пароля), B.2 меняет обращение с дескриптором лога и вешает `postfix reload` на logrotate, B.3 добавляет разбор значения переменной в shell до старта supervisord, C.4 приносит переработанный релизный workflow и compose-override с **сознательно ослабленными** настройками (`PANEL_COOKIE_SECURE=false`, самоподписанный сертификат, заниженные лимиты), которому нельзя утечь в прод. Ревизия по пунктам дала бы четыре среза, а смотреть надо итоговое состояние — и заведомо один раз, а не четыре.
+   **Почему после всех четырёх, а не по ходу каждого.** Каждый пункт трогает ровно ту поверхность, которую аудит ТЗ 7.6 на v1.0 видел в другом виде: B.1 переписывает аутентификацию (сессии в SQLite, SHA-256 от токена, скользящее продление, разлогин остальных сессий при смене пароля — текущая остаётся), B.2 меняет обращение с дескриптором лога и вешает `postfix reload` на logrotate, B.3 добавляет разбор значения переменной в shell до старта supervisord, C.4 приносит переработанный релизный workflow и compose-override с **сознательно ослабленными** настройками (`PANEL_COOKIE_SECURE=false`, самоподписанный сертификат, заниженные лимиты), которому нельзя утечь в прод. Ревизия по пунктам дала бы четыре среза, а смотреть надо итоговое состояние — и заведомо один раз, а не четыре.
 
    **Объём.** Диф от тега `v1.0.0` до состояния перед следующим тегом целиком — то есть вместе с Фазами 12–14, которых в аудите v1.0 не было, — плюс повторный проход по чек-листу ТЗ 7.6, а не только по изменённым строкам: регресс в 7.6 возможен и в нетронутом коде, если рядом поменялся вызывающий. Приоритет задаёт то, что панель публично доступна (ТЗ 2.4): аутентификация и сессии, валидация ввода, запись в конфиги и map-файлы (injection), `os/exec` без shell, права на файлы в `/data`, обращение с секретами (пароли приложений, `sasldb2`, архив бэкапа).
 

docs/progress.md

@@ -43,7 +43,7 @@
 - **B.2 реализован** (не выкачен на прод): ротация `mail.log` ушла с `copytruncate` на «переименовать + `postfix reload`» — `build/logrotate-mail.conf` (`nocreate` заменён на `create 0644 root root` **не по плану, а по стендовой проверке**: после reload Postfix пересоздаёт лог сам только в момент следующей фактической записи и с режимом `0600`, недоступным непривилегированной панели, — `create` в logrotate закрывает это, отдавая файл ей же на 644 сразу после переименования); `follow()` в `internal/logtail/logtail.go` при обнаружении смены inode дочитывает старый дескриптор ещё раз перед переключением; `readLogTail()` в `internal/web/handlers_monitor.go` считает отсутствующий файл пустым экраном, а не ошибкой. Проверено на стенде (`selfpost.example.com`, отдельный контейнер `selfpost:b2test2`): цикл трафик → принудительная ротация → файл пуст и сразу читаем непривилегированным uid панели (0 читает `mail.log` сразу после rename, без окна недоступности) → новый трафик после ротации уходит в новый файл на 644, ничего не потеряно по обе стороны rename. `go vet`/`go test ./...`/`gofmt -l .` чистые (на dev-сервере; локально на Windows `TestFollowTailsAndRotates` падает — rename открытого файла запрещён ОС, к делу не относится).
 - **B.3 реализован** (не выкачен на прод): `build/entrypoint.sh` проверяет `SELFPOST_HOSTNAME` до `postfix-config.sh` и до `supervisord` — при пустом значении `exit 1` с развёрнутым текстом ошибки (что это за имя, почему обязательно, пример, где задаётся); плюс синтаксическая проверка через `case`: минимум одна точка, без схемы/порта/пробелов (`*://*`, `*:*`, пробел/таб — тот же класс тихого спам-отказа, что и пустое значение). `saslRealm()` и fallback в `postfix-config.sh` не тронуты — после гейта эти ветки мертвы. Заодно отмечена обязательность переменной в `README.md` и `deploy/.env.example`. Проверено на стенде (`selfpost.example.com`, отдельный образ `selfpost:b3test`, cap-list как в поставляемом compose): без переменной — `exit 1` с ожидаемым текстом, без бесконечного тихого retry; `https://mail.example.com:465` и `localhost` отклонены с понятными сообщениями; валидный `mail.example.com` — обычный старт, все процессы supervisord поднимаются. `go vet`/`go test ./...` чистые.
 - **C.4 реализован** (не выкачен на прод — это CI/тестовая инфраструктура, а не образ): герметичный контейнерный e2e отдельным Go-модулем `test/e2e/` (свой `go.mod`, не подхватывается `go test ./...` основного модуля) поверх поставляемого `deploy/docker-compose.yml` плюс `test/e2e/compose.override.yml` (самоподписанный сертификат, `PANEL_COOKIE_SECURE=false`, `SELFPOST_HOSTNAME=mail.e2e.test`, высокие порты `20465/20587/20080`, изолированный compose-проект `selfpost-e2e`, свой `--project-directory` — прод на том же хосте не задет). Герметичная почта: CoreDNS (`test/e2e/dns/Corefile` — авторитетна только для `e2e.test`, `file`-плагин с саб-директивой `reload` перечитывает `db.zone` по mtime, без сигналов) плюс `smtp-sink` из пакета postfix (`test/e2e/sink/`) как sink-MX. Сценарий (`test/e2e/*_test.go`): старт контейнера → все supervisord-программы `RUNNING` (`postfix-reload` — `STOPPED`) → токен из `/data/setup-token` → setup → login → добавление домена → DKIM-запись **скраплена со страницы панели** и опубликована в фейковую зону → добавление приложения → SMTP AUTH на 465 → письмо на sink → DKIM-подпись проверена (`go-msgauth/dkim` с кастомным `LookupTXT` через CoreDNS) против ключа **из DNS**, не из панели напрямую → send-log `queued → sent`. Негативы: без AUTH, relay на чужой домен без AUTH, sender/login mismatch (`reject_sender_login_mismatch` репортится Postfix'ом на RCPT, не MAIL — `smtpd_delay_reject=yes` по умолчанию), L1-лимит (anvil, override `RATE_LIMIT_MESSAGES_PER_IP=50` — специально высокий, чтобы остальные под-тесты не расходовали общий бюджет по IP раньше времени; сам тест шлёт до 60 раз, ждёт отказа), L2-лимит через панель (домен/приложение → `rejected`-строка в send-log), fail-open journal-milter'а (`supervisorctl stop panel`, письмо всё равно принято, контейнер жив), пустой/синтаксически неверный `SELFPOST_HOSTNAME` (отдельный один-разовый контейнер, не общий стенд), сессия переживает `docker restart` (плюс явное ожидание готовности smtps-порта после рестарта — панель и Postfix поднимаются независимо). `make e2e` — локальный/dev-server прогон. Найдено и исправлено по ходу стендовой проверки: `reload` — саб-директива `file`-плагина CoreDNS, а не отдельный топ-левел плагин (топ-левел `reload` следит за самим Corefile, не за зоной); `docker compose build.context` резолвится относительно `--project-directory`, а не относительно файла, где объявлен; `smtp-sink` отказывается стартовать от root без `-u`; `html/template` эскейпит `+` в `+` даже в тексте — скрапер значений со страницы обязан `html.UnescapeString`; проверки состояния сразу после `up`/`restart` должны поллиться, а не разово опрашиваться (supervisord/postfix поднимаются не мгновенно). **Проверено на dev-сервере (`selfpost.example.com`)**: `make e2e` — зелёный (`go vet`/`gofmt -l` тоже чистые в обоих модулях). `release.yml` переработан: job `prepare` (версия из тега) → матрица `[ubuntu-latest, ubuntu-24.04-arm]` — каждая нативно собирает образ (`--load`), прогоняет e2e, пушит тег `X.Y.Z-amd64`/`X.Y.Z-arm64` → job `merge` — `docker buildx imagetools create` в единый тег `X.Y.Z`; `setup-qemu-action` убран. Не проверено вживую (нельзя без реального тега): сам workflow на GitHub Actions — синтаксис вычитан, логика идентична локальному `make e2e` пути.
-- **Дальше — документация:** [documentation-plan.md](documentation-plan.md) — состав пакета (ТЗ 11), метод сверки с кодом, результаты первого прохода (11 находок: нет раздела «эксплуатация» по ТЗ 11 п.7, нет справочника env-переменных, битая ссылка на «Rate limiting» из `.env.example`, не отражена оговорка ТЗ 9 про прямой `tar`) и задачи D1–D7. Часть предрелизного гейта наравне с e2e и ревизией безопасности.
+- **Документация (D1–D5 закрыты):** [documentation-plan.md](documentation-plan.md) — D1 Operations/Rate limiting, D2 env-справочник, D3 бэкап через остановленный контейнер + `tar` и потребление `manifest.json`, D4 точечные правки README/compose (баннер, 587, комментарии), D5 синхронизация `implementation-plan.md` (B.1 — смена пароля гасит остальные сессии, не текущую). Остаются D6–D9 (HEALTHCHECK, регресс-тест env, architecture/development, вывод specification). Часть предрелизного гейта наравне с e2e и ревизией безопасности.
 - **Дальше:** пункт **D.5** плана — предрелизная проверка на уязвимости моделью Fable по всему дифу от `v1.0.0` плюс повторный проход по ТЗ 7.6; вместе с e2e (C.4, готов) это гейт перед тегом релиза.
 - **Дальше — то, что перечислено в `implementation-plan.md`:** открытые вопросы закрыты, раздел E теперь только указатель на объём 2.x (входящий релей O1+ и роль администратора домена; 2FA снята с рассмотрения); остаются принятые риски безопасности (переехали в [security.md](security.md): `POST` без `Sec-Fetch-Site`/`Origin` пропускается, CSRF-токенов нет) и опциональная **Фаза O1+** (входящий релей, линия 2.x.x, требует согласования).
 - **Прод:** `selfpost.example.com`, реальный Let's Encrypt сертификат, живой e2e (DKIM/SPF pass). Контейнер там всё ещё на образе v1.0 — Фаза 14 в него не выкатывалась. При апгрейде: админа один раз разлогинит (сменилось имя cookie), а от reverse-proxy требуется передача исходного `Host` (Apache-фрагмент из `deploy/` это делает).