0729dbb69182e1ea7fb57922b6b723e94df333c7
2
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
|
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 |