ee240ae227778b5645a19788d1f4ddc86b23100f
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Lucas RayanandClaude Opus 5
|
ee240ae227 |
#23: show real data, unify the surfaces and make enrolment scannable
The interface was reporting things that were not true. Several screens were
mockups wired to nothing, and a reader with the console in Portuguese was
served a mixture of two languages.
Fabricated data, removed:
- The outbound queue was two invented jobs held in component state. Retry and
Freeze only edited that local array, so the screen showed the same two rows
on every deployment and reported success for actions that never happened.
"Freeze" named an operation the backend has never implemented. It now reads
/api/v1/admin/queue, which was already serving the real thing, and offers
retry and cancel, which exist.
- Every dashboard KPI fell back to an invented constant (1420 received, 890
sent, 3 queued, 18.4% disk), so an unreachable API produced a dashboard of
plausible traffic for a server that might have delivered nothing. Two of
those fields were never returned by the endpoint at all, so the fake disk
figure was what everyone always saw. DMARC did the same with 1250/98%/97%.
- The domains screen showed thirteen DNS records for example.com, all marked
VERIFIED, and posted {domain_id: "default-domain"} to endpoints expecting a
real id. DKIM rotation sends "domain", not "domain_id", so its 400 was
swallowed and a made-up TXT record displayed as though a key had been
issued: rotation had never once worked from this screen.
- The TLS panel asserted a Let's Encrypt RSA 4096 certificate and verified
DANE from static markup, on a deployment currently serving a self-signed
one. It now reads the cert watcher via /api/v1/admin/tls.
- The readiness scorecard printed "10 / 10 all checks passed" regardless of
what preflight reported, including failures.
- A message trace that found nothing invented a five-step delivery - TLS 1.3
accepted, SPF pass, spam score 0.8 - for a message that does not exist.
- Both sidebars showed a fixed admin@lambdamail.local with a hardcoded
"SUPER_ADMIN (2FA)", claiming a second factor whether or not one existed.
- Settings seeded a "[Boletim]" Sieve rule. Saving posts the whole list, so
the first edit wrote that invented filter into the account's real script.
The reconcile endpoint itself answered {records_verified: 13, status:
"VERIFIED"} for any domain id, including one that does not exist, without
resolving a name. It now reports what it does, which is record the request.
Surfaces:
The root was a chooser listing webmail and the console side by side, which
asked visitors a question they should not have to answer and advertised cookie
names and audiences to anonymous readers. It now redirects into the mail
client. Accounts that may administer the server get a link to the console from
inside the app - a link to /admin/login, so crossing over still costs the
second factor the admin audience requires - and the console gets a plain link
back, since the webmail session was never given up to get there.
Enrolment:
Both enrolment screens printed the base32 secret as text and left the operator
to type 32 characters into their phone. The enrol endpoint already returned an
otpauth:// URI; it simply was not drawn. Added a shared component that renders
it as a QR locally - the seed is already in the page, and sending it to an
image service would put it in another request log for nothing.
The recovery-code step rendered its own "sign in" button while the form's
submit button stayed visible below it: two identical buttons, and no way to
copy the codes it insisted you save. It is now terminal, with copy and
continue.
Language:
translate() had no interpolation, so "Undo Send ({seconds}s remaining)" showed
the placeholder and a second hardcoded countdown was appended after it. It now
substitutes, leaving an unmatched token visible rather than blanking it.
The pt-BR bundle had lost its diacritics - "Destinatario", "Ultimo erro",
"Acoes" - from the ASCII-source rule being applied to the translations, which
are data. Restored, and the three bundles are back in key parity at 270 each,
with roughly 120 strings that were hardcoded in the source now keyed.
Healthchecks:
web had none, despite being the only service users reach directly: a wedged
Next process kept its container running and Traefik kept routing to it. Added,
using node's own fetch since the image ships no curl. rspamd and clamav gained
the timeouts and start_periods whose absence would fail them during startup.
migrate stays without one and says why: it is a one-shot job, and a probe
would report unhealthy exactly when it has succeeded.
Verified: 36 webmail tests and 41 auth tests against a real Postgres, both new
admin/me cases confirmed to fail without the route (404). lang-lint clean,
production build clean, 0 vulnerabilities, compose validates.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Lucas RayanandClaude Opus 5
|
13fd2a9cee |
#21: ship the migrations and the Rspamd config inside images
The deployment failed on the migrate service. Coolify rewrites a relative bind mount to a path under its own application directory, and when that resolves to an empty directory golang-migrate finds no migrations and exits 1 - with nothing useful in the deployment log to say why. A deployment that pulls its images has no business also depending on files being at a particular path on the host. Both mounts are now baked into images built from the repository root: migrations - the schema, so migrate always has it rspamd - actions.conf and ratelimit.conf The Rspamd one mattered for a quieter reason: Rspamd starts happily with an empty local.d, so a mount that resolved to nothing would have left the rate limits and score thresholds unapplied. The defence would have looked configured and done nothing. Both images join the CI and release matrices, building from the root context. Verified by building them, checking their contents, and bringing the whole stack up - Rspamd reports its nine rate directives loaded from the image. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Lucas RayanandClaude Opus 5
|
f117e1e9d7 |
#21: deploy by pulling the images CI built, not by rebuilding on the server
The first deployments died building on the target: four images, and the webmail build alone was enough to sink it on a small arm64 host - the build step was killed with no BuildKit error, which is what an exhausted or overloaded machine looks like from the outside. The images already exist. CI publishes all four to GHCR for amd64 and arm64 on every merge, and they are the ones the suite ran against, so rebuilding them on the deploy target is slower, heavier and less trustworthy than pulling them. docker-compose.yaml therefore carries no build definitions, and docker-compose.build.yaml is the overlay that adds them for local development and for CI - which does have to exercise the branch rather than the published images. Both paths were run before committing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Lucas RayanandClaude Opus 5
|
cea8e7a41e |
#21: use a ClamAV image that exists for arm64
The deploy target is an Oracle Ampere host, and the default clamav/clamav tag is Alpine-based and published for amd64 only - the deployment failed pulling it with "no matching manifest for linux/arm64/v8". The Debian variant of the same upstream image is built for amd64, arm64 and ppc64le and ships the same clamdcheck.sh the healthcheck uses. Verified by pulling it, checking the manifest, and bringing the service up healthy. Every other image in the stack was already multi-arch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Lucas RayanandClaude Opus 5
|
c0387f6961 |
#21: make the stack deployable, and document how
Three things stood between this and a real deployment. A missing JWT_SECRET fell back to a constant that is published in this repository, so any deployment that forgot the variable would have accepted session tokens anyone could mint, including an admin one. The auth service now refuses to start without a secret of at least 32 characters. The test suites set it through vitest config, because ESM hoists imports and an assignment inside a test file runs too late. Session cookies were issued without the Secure attribute: it is driven by NODE_ENV, which compose never set. Behind a TLS terminator that is a downgrade waiting to happen. Nothing created the first mailbox. A fresh install has no domain and no account, and every route into the console needs one - so there was no first login. There is now a create-admin command, which also provisions the standard folders and the four system aliases. It is a deliberate command rather than a bootstrap on boot: creating an administrator as a side effect of starting a container is how a deleted account quietly comes back. Also: the production images were shipping compiled test files, since the build compiled everything under src. A separate build config excludes them while lint still type-checks them. Documentation. README.md covers what this is, how it is put together, and what is not finished - stated plainly, because a mail server that half works loses mail. docs/DEPLOYMENT.md is the Coolify path in the order it has to happen, starting with the three prerequisites no code can satisfy: outbound port 25, the PTR record, and the DNSSEC delegation. docs/OPERATIONS.md is the runbook - health states, certificates, backups, reading a delivery failure, DKIM rotation, and an explicit list of what is not automated. .env.production.example replaces guessing which of the dev defaults are safe: none of them are. docs/ was gitignored as a place for internal notes; only docs/internal/ is now, so these guides ship with the code. Every command the documentation tells an operator to run was executed against a running stack: create-admin, preflight, the health endpoint, the published mail ports, and the Secure cookie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Lucas RayanandClaude Opus 5
|
48fe3c68f3 |
#21: serve the webmail mail API from the protocols service
The mail screens had no backend at all: they rendered a hardcoded array, and the storage service that ADR-001 assigned this to is still a health stub. The API lands here instead, because the folder, UID, MODSEQ, flag and blob logic already exists and is tested in this service for IMAP. Reimplementing it in TypeScript would mean two implementations of the same semantics and two chances to disagree about what a UID means. Reads use a projected read model rather than hydrated aggregates, which is the CQRS exception PLAN.md section 2 carves out for webmail queries. Every query is scoped to the mailbox resolved from the verified session, never to an identifier taken from the request, so one account cannot read another's mail by guessing a UID - covered by a test that tries exactly that and expects 404. Sending reuses ProcessOutboundEmailUseCase, so mail written in the browser gets the same treatment as mail submitted over 587: send limits, DKIM signing, and the durable queue. The From address comes from the session and never from the request body; letting the body choose it is how a webmail becomes a relay for spoofed mail. MIME is parsed server-side because this service already depends on a MIME library. A message that will not parse still returns its raw text - an unreadable message beats an inbox that refuses to open one. Marking a message read updates the flag and the folder counter in one transaction, and only on a real transition, so re-opening a message cannot drive unread_count negative. Verified against the running stack: a message delivered over port 25 appears in the list with its decoded subject and sender, opens, marks itself read, is found by search, and a message composed in the webmail reaches outbound_jobs with the session's address as the envelope sender. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Lucas RayanandClaude Opus 5
|
3deb328bbf |
#19: repair the compose stack and wire Rspamd to Redis
"docker compose up" could not work, which means the F0 acceptance
criterion was not being met:
- ghcr.io/rspamd/rspamd:3.9 returns "denied" and clamav/clamav:1.3 does
not exist. Both were verified against the registries; the working
references are rspamd/rspamd:3.9 and clamav/clamav:1.4.
- Rspamd received RSPAMD_REDIS_SERVERS and RSPAMD_REDIS_PASSWORD as
environment variables it never reads. Confirmed in the container that
it does not expand ${VAR} in UCL: the password reached Redis as that
literal string. Greylisting and ratelimit keep their state in Redis,
so both were silently doing nothing while appearing configured. The
credential is now rendered at startup into override.d, a tmpfs, so it
touches neither the image nor a volume.
- The ratelimit module ships enabled with no rates defined, which
accepts everything. ratelimit.conf defines the per-IP, per-user and
per-recipient buckets of section 5.2.
Verified by bringing redis and rspamd up: the real password resolves, the
rates load, and a probe message returns "Action: greylist" with the state
written to Redis.
Services also gained an image: alongside build:, so the deploy host pulls
instead of compiling while "docker compose build" still works locally.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Lucas Rayan
|
d56f29d084 | #18: implement SMTP Submission (587/465), SASL PLAIN/LOGIN auth and preflight diagnostics | ||
|
Lucas Rayan
|
9fa19291d4 |
#4: implement F2 sub-project 1 - IMAP core (auth, LIST, SELECT, FETCH, STORE)
Adds a real :143 IMAP listener to the Go protocols service: a mailbox owner authenticates over IMAP (Argon2id against mailboxes.password_hash, enumeration-resistant per PLAN.md section 14.6), lists folders, selects INBOX, fetches messages F1's SMTP path already persisted - including real ENVELOPE/BODY[] built from the actual stored MIME bytes via go-imap/v2's own ExtractEnvelope/ExtractBodySection helpers, not reconstructed from denormalized columns - and sets/reads flags via STORE. - ImapSessionUseCase orchestrates auth, folder listing/selection, message querying, and flag mutation against new Postgres repositories (auth, folders, message query, flags) and a local-disk blob reader. - A github.com/emersion/go-imap/v2 (pinned v2.0.0-beta.8) Backend/Session implements 7 real methods (Login, List, Select, Unselect, Status, Fetch, Store) plus a correct no-op Poll; the other 10 of the interface's 18 methods (Create/Delete/Rename/Subscribe/Unsubscribe/Append/Idle/Expunge/ Search/Copy) are explicit stubs returning a clear "not yet implemented" IMAP error - SEARCH/EXPUNGE/COPY/MOVE, IDLE/CONDSTORE, mailbox management, and APPEND are separate follow-up sub-projects per the design doc's agreed ordering with the user. Verified end-to-end with a real go-imap/v2 imapclient (embedded Postgres, no Docker needed) driving Login -> Select -> Fetch -> Store -> List against a message seeded through F1's real SMTP use case, proving true SMTP-write/IMAP-read interop, not just isolated unit tests. Built via 8 sequential tasks under subagent-driven development, each independently reviewed, plus a final whole-branch review. Two real bugs were found and fixed before merge, both exactly the kind unit tests with fakes cannot catch: - Store's UID-set resolution silently no-op'd on dynamic ranges like "UID STORE 1:*" (the common "mark all as read" operation) after an earlier draft bypassed the folder's real message list; restored to resolve against real messages via the same pattern Fetch already used correctly, with tests proving both dynamic ranges and non-UID STORE. - go-imap/v2's server calls Session.Poll() implicitly before the status response of nearly every authenticated command (FETCH/STORE/SEARCH/ APPEND/COPY), not just IDLE as assumed - a hard-stubbed Poll broke every real command through this path; fixed to a correct no-op. - List had zero test coverage despite being committed scope; added unit tests for wildcard/delimiter matching plus a real E2E LIST assertion. Known follow-up, not blocking: a pre-existing test-fixture hygiene gap (hardcoded content_sha256 blob hashes with no cleanup, shared across several Postgres integration test files including one new to this branch) causes local-dev test collisions on repeated runs against a persistent database - invisible to CI (fresh Postgres per run) but worth a cleanup pass. |
||
|
Lucas Rayan
|
e501cdc69e |
#2: implement F1 sub-project 1 - inbound SMTP listener with EML storage
Adds a real :25 SMTP listener to the Go protocols service, giving F1's "Nucleo SMTP" milestone its first working sub-project: application, infrastructure, and presentation layers on top of F0's domain-only Clean Architecture. - ProcessInboundEmailUseCase resolves recipients against Postgres and persists accepted mail (blob dedup by content hash, transactional UID allocation + outbox event, never sending 250 OK before durable commit per PLAN.md section 6.1). - Postgres repositories via pgx/v5 (replacing lib/pq entirely). - Local-disk blob storage with content-hash dedup, rename-before-commit ordering so a DB row can never reference a file that isn't actually on disk. - A local-file TLS cert provider for STARTTLS, with an ephemeral self-signed fallback so a missing/misconfigured cert degrades gracefully instead of crash-looping the service (PLAN.md section 8.4). - A github.com/emersion/go-smtp Backend/Session adapting real SMTP traffic to the use case: unknown recipients get 550 5.1.1 before DATA, duplicate RCPT TO for the same address is deduplicated, TLS is hardened to the project's required PFS-only cipher/curve policy. - A dev-seed script and Makefile target for local testing. Explicitly out of scope (separate follow-up sub-projects): alias resolution, SPF/DKIM/DMARC/ARC verification, Rspamd/ClamAV, Submission ports with SASL auth, DKIM signing, outbound delivery, and the real Traefik acme.json cert watcher. Verified live end-to-end via WSL Docker: the full compose stack (db, redis, migrate, auth, storage, protocols, web) reaches healthy, and a real swaks SMTP session is accepted and durably persisted with correct sequential UIDs, while an unknown recipient is correctly rejected with 550 5.1.1 and zero rows persisted. Built via 10 sequential tasks under subagent-driven development, each independently reviewed, plus a final whole-branch review that caught and fixed a TLS-crash bug, a blob commit-ordering bug, missing TLS hardening, and missing CI integration coverage before merge. Known follow-up, not blocking: email_messages' partition only covers July 2026 and needs a partition-management job before 2026-08-01. |
||
|
Lucas Rayan
|
7c91182111 |
#1: fix webmail healthcheck - Next standalone binds IPv4-only, wget resolved localhost to ::1
Verified live via WSL Docker (docker compose up --wait): every other F0 service came up healthy, but web stayed unhealthy. Root cause was two compounding issues, both invisible to static review: 1. Docker auto-sets HOSTNAME to the container ID; Next's standalone server.js honors that env var and binds only to it instead of all interfaces. Fixed by explicitly setting ENV HOSTNAME=0.0.0.0 in the Dockerfile, after Docker's automatic assignment. 2. Even bound to 0.0.0.0 (IPv4), the healthcheck's `wget http://localhost` resolved localhost to ::1 (IPv6) first inside the container, where nothing was listening. Fixed by pointing the healthcheck at 127.0.0.1 explicitly instead of localhost. Full stack (db, redis, migrate, auth, storage, protocols, web) now reaches healthy end-to-end under docker compose up --wait. |
||
|
Lucas Rayan
|
eb09fa0ced |
#1: implement F0 foundation - monorepo, migrations, Go domain layer, service skeletons, CI
Stands up the LambdaMail monorepo per PLAN.md's F0 milestone: local dev scaffolding (.env.example, Makefile, .gitignore excluding PLAN.md/docs/ .superpowers/), the full initial Postgres schema as a golang-migrate migration, the complete Go domain layer for services/protocols (value objects, entities, domain events - zero external imports beyond github.com/google/uuid) with unit tests, health-checked service skeletons for auth/storage (TypeScript) and webmail (Next.js), a local docker-compose.yaml wiring all services together, a language-enforcement lint script, and a GitHub Actions CI workflow. Built via 11 sequential tasks under subagent-driven development, each with an independent implementer + reviewer cycle. Fixes applied during review: DomainName.IsPunycode() added to satisfy the promised interface; ioredis default-import typing under NodeNext; next.js bumped 15.0.3->15.5.21 to resolve high/critical CVEs; lang-lint.mjs corrected to not flag its own banned-terms list; web service healthcheck added so compose --wait actually waits on it; webmail Dockerfile's missing public/ directory: protocols go.mod version aligned with CI's Go 1.22 pin. Known follow-ups for later phases (not blocking F0): go-arch-lint isn't wired into CI yet; live docker compose up and migration apply have not been exercised in this dev environment (no Docker/psql available here) and will get their first real run in CI, which does have Docker. |