fe471dbf0145b8c38a330d0b7080c2abdfa0a7f3
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  lukasandClaude Opus 5
|
95ca1b49f6 |
Antispam plugin (M7 phase C1): classify, file, and stay out of the way
Second-pass spam filtering per SPEC Appendix C. The engine is Rspamd in its own container; this plugin is glue and policy, never a spam engine of its own. Classification (§C.4) hooks message.new, acts only on inbox arrivals of enabled accounts, and runs deny list -> allow list -> engine -> thresholds. Every failure path ends in "deliver normally, unclassified": an unreachable engine, a missing blob, an account with no Junk folder, a failed verdict write. Nothing here may delay or lose mail, so no service declares depends_on: rspamd. Two containers, started with everything else rather than behind a profile: rspamd, and a redis of its own. The separate redis is not incidental — the app's redis holds sync leases and arq queues under noeviction, and an ever-growing Bayes corpus must never be able to fail a job enqueue. This one takes RDB snapshots and evicts, because its data is derived and retrainable. Network checks (RBL/SURBL/fuzzy) are off: they leak message-derived hashes and URLs to third parties, which a self-hosted server's users did not ask for. The engine makes no outbound connections in the default configuration. The controller password is generated into .env like MASTER_KEY. It is internal; humans will reach Rspamd through the admin panel, authenticated as the ordinary administrator, rather than typing it. local.d/groups.conf zeroes six SMTP-time symbols — DATE_IN_PAST, PREVIOUSLY_DELIVERED, HFILTER_HOSTNAME_UNKNOWN, RCVD_NO_TLS_LAST, ARC_NA, DMARC_NA — and greylisting is disabled. Measured against 398 real delivered messages, those checks were firing on 44-71% of ordinary mail and pushing 11.3% of it over the banner threshold; scoring mail at rest for facts true of every delivered message is simply the wrong question. After: median 3.09 -> 0.70, p95 7.00 -> 3.40, banner rate 11.3% -> 1.0%. The spec's 12.0/6.0 thresholds were never the problem and are unchanged. Symbols are zeroed rather than removed so verdicts stay explainable, and they matter again at the M6 edge (§C.7). Still to come in C1: the §C.6 router and UI slots. C2 adds the learning loop — until Bayes is trained, genuine scams and legitimate bulk mail overlap in the 5-8 band and no threshold separates them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018SqJYt7jD7oUEkoY68sBZo |
||
|
lukasandClaude Opus 5
|
8fce86559e |
Admin panel on its own port, and a registration gate
Three strands that only make sense together, so they land together. Registration gate (migration 0016). POST /auth/register was open to anyone who could reach the port. Now the first account on an empty instance is always allowed, becomes the administrator, and closes registration behind itself; after that it takes an admin reopening it. The decision is made under a row lock on app_settings so two simultaneous first signups cannot both see an empty table and both claim administrator. Existing installs keep their oldest account as admin and start closed. Instance default quota (migration 0017). users.quota_bytes is snapshotted at creation from app_settings.default_quota_bytes, so changing the default affects later accounts only and never resizes a mailbox that exists. The panel is a separate app, not a page in the mail client. admin.html is its own Vite entry (5.8 KB next to the client's 1.7 MB; they share only the vendor chunk), with its own administrator sign-in. One nginx now serves two listeners: :80 is the mail client and 404s both /admin.html and /api/admin/*, :81 is the panel. docker-compose publishes them as WEB_PORT and ADMIN_PORT. The boundary is nginx refusing paths on one listener, not process isolation — CurrentAdmin still guards every admin route — so ADMIN_PORT must be restricted to the LAN, which the runbook now covers for both DSM and QNAP. Also QNAP: deploy/webmail.sh finds Container Station's docker under /share/*/.qpkg/container-station/bin, which is off an SSH session's PATH, before anything shells out to it. docs/nas-install.md gains a QuTS hero runbook (§2.6), splits the DSM firewall section into container-to-container (§8.1) and the egress case that makes account-add time out while autodiscovery appears to work (§8.2), and scopes both to Synology. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018SqJYt7jD7oUEkoY68sBZo |
||
|
lukasandClaude Opus 5
|
2f03bee45b |
Deploy: drop cpus: limits and stop assuming docker compose exists
Two NAS realities, both hit on a real Synology box. - "NanoCPUs" error part-way through the project build: `cpus:` maps to the NanoCPUs field, which DSM's Docker daemon rejects. Removed from all three services (and from .env.prod.example). mem_limit uses the much older Memory field and works, so memory caps remain the throttle. Noted in the header next to the other DSM constraints. - `docker compose build` on DSM: "'compose' is not a docker command". DSM and QTS ship the standalone `docker-compose` binary with no plugin subcommand, so every one of the script's 21 compose invocations was wrong for the target platform. The script now detects which is present, and only passes `--wait` when it finds v2 — on v1 it falls back to the health_gate it already had, which is also now run after `up` on both paths. That the build reached container creation before failing says their compose parses the rest of the file (anchors, profiles, service_completed_successfully, top-level name), so this was a daemon-level rejection, not a schema one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw |
||
|
lukasandClaude Opus 5
|
cc26ae7eaf |
Deploy: make the NAS GUI path work, and stop sourcing the env file
Synology Container Manager and QNAP Container Station build a project from a folder and look for `docker-compose.yml` in it. Pointing either at `docker/` finds the DEV service stack and starts the wrong thing, so production now has a root-level entry point. - docker-compose.yml at the repo root: `include`s the prod stack (relative paths resolve against the included file's directory, so the build context and backup.sh still resolve) and pins `name: webmail-prod`. A project name typed into the GUI overrides the file's, so the docs say to type the same one. - webmail.sh init now drops a `.env` symlink to docker/.env.prod in the repo root: the GUI reads `.env` from the project folder, and a symlink keeps one file to edit instead of two copies that drift. - Required-variable guards on DATA_ROOT / MASTER_KEY / POSTGRES_PASSWORD / APP_DOMAIN. A bare `docker compose up` with no env file used to interpolate DATA_ROOT to "" and bind-mount /postgres at the root of the filesystem; it now aborts with a message naming the variable. - require_env no longer sources the env file. Sourcing executed it as shell: ENABLED_PLUGINS=calendar contacts labels filters ran `contacts` as a command and broke every subcommand, and anything else in the file that holds the master key would have been executed too. Replaced with a compose-compatible KEY=VALUE parser; the template quotes the value as well. - doctor: no longer aborts on a not-yet-created DATA_ROOT (set -e + pipefail killed it inside a `df` assignment — on exactly the pre-install run where its NFS/SMB check is the one that matters), and probes the nearest existing ancestor so that check works before the directory exists. - docs §2.5 rewritten with what the GUI can and cannot do: no compose profiles (so no Meilisearch), no health-gated update, no restore; plus the Task Scheduler route for generating MASTER_KEY without enabling SSH, and why init/migrate showing "Exited (0)" is correct. Verified by running `docker compose up -d --wait` from the repo root with no -f and no --env-file (what the GUI does): all services healthy, migrations applied, app served, and deploy/webmail.sh manages the same project. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw |
||
|
lukasandClaude Opus 5
|
5553b5febe |
Deploy: production Docker stack for a single host (Synology/QNAP NAS)
Everything needed to run the app on an Intel NAS that is also doing other jobs: one published port, no host networking, memory/CPU caps and log rotation on every container, and all state in bind mounts under DATA_ROOT so mail survives image updates, project deletion in the NAS UI, and full reinstalls — and so Hyper Backup/HBS3 can actually see it. - docker/Dockerfile.backend: multi-stage, non-root (uid 10001), tini for the <10s graceful lease release. Installs the four plugins as entry-point distributions. One image, several roles via docker/entrypoint.sh (api | worker-sync | worker-jobs | migrate | reindex | plugins). - docker/Dockerfile.frontend + nginx.conf: SPA + /api reverse proxy with the WebSocket upgrade for /api/ws, and X-Forwarded-Proto preserved so the API still emits __Host-/Secure cookies when TLS is terminated by the NAS reverse proxy (identity/cookies.py keys off request scheme). - docker/docker-compose.prod.yml: project name webmail-prod, NOT webmail — docker-compose.yml (dev services) owns that name, and two compose files sharing one project name fight over each other's containers. Meilisearch is an opt-in profile; SEARCH_BACKEND=pg is the default so a small NAS pays nothing for search. - migrate runs as a one-shot (core Alembic head + every plugin branch) that everything else waits on, so a bad migration can never leave new code running against an old schema. - docker/backup.sh: nightly pg_dump verified with `pg_restore --list` before it counts as a backup, with retention and a baseline on first start. - deploy/webmail.sh: init/doctor/up/down/status/logs/update/rollback/ backup/restore/reindex/psql/shell. `update` is backup -> images -> migrate -> roll workers, api, web -> health-gate, with automatic rollback to the previous version if the gate fails. `doctor` refuses to be quiet when DATA_ROOT is on NFS/SMB (silent Postgres corruption). - deploy/build-push.sh: build images off-NAS (the frontend build wants ~2GB RAM) and push to Gitea, or --save a tar to carry over. - scripts/reindex_search.py: rebuild the search index from Postgres alone. Every SearchDoc field is already stored, so the index is derived data that never needs backing up — this closes the only real objection to running Meilisearch on a box whose volumes may be wiped. - pyproject: package-data for accounts/presets.yaml and the shared plugin Alembic env. Without it a non-editable install (i.e. any image) silently ships a package that fails at runtime. - GET /api/version, used by the deploy health gate. Verified end to end on a real stack: fresh install, all services healthy, core + 4 plugin migration branches applied, login/SPA/plugin bundles through nginx, WS upgrade returning 101, __Host- cookies under a simulated TLS proxy, backup -> restore round-trip preserving user and plugin schema, failed-update auto-rollback (both a bad migration and a boot-crashing API), and Meilisearch profile serving a live query. ruff + mypy --strict clean, 363/363 backend tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw |