tegwick
89fd13ac2d
Adds tests/harness/docker-compose.yml running GreenMail 2.1.12 (digest-pinned) with SMTP 3025, IMAP 3143 and the API bound to 127.0.0.1 only, plus a config/harness-imap.yml scanner profile and harness README. Auth is disabled and no users are declared, so a mailbox is created on first login and per-test users need no provisioning. GreenMail standalone offers no STARTTLS, only plaintext or implicit TLS, while SMTPProvider hardcoded starttls() -- so no send could reach it. SMTPProvider now takes a security mode via EMAIL_CONNECT_SMTP_SECURITY, defaulting to starttls. plaintext is refused for any non-loopback host, and hostnames are never resolved to decide that, so a misconfigured deployment fails at startup rather than sending credentials in the clear. Trusting GreenMail's self-signed cert was rejected as the wider risk; see DECISIONS.md. Verified end to end against the live harness: SMTPProvider.send -> GreenMail -> ImapMailboxSource, and the documented scan-mailbox CLI. Suite: 52 passed with the harness down. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
6.9 KiB
Decision Log
Auto-generated by the Custodian State Hub.
Defer daily send-quota privilege tiers (anti-spam / abuse)
Date: 2026-08-12
Decided by: human (via agent note)
Status: deferred — do not implement in EMAIL-WP-0004
Idea
Outbound email is high-abuse surface if credentials or a caller is compromised. The platform should treat daily send volume as a privilege, not an unlimited side effect of holding a send token.
Proposed daily ceilings (per sender / tenant / grant — exact subject TBD):
| Tier | Mails / day |
|---|---|
| minimal | 10 |
| low | 100 |
| standard | 1_000 |
| elevated | 10_000 |
| high | 100_000 |
| bulk-capable | 1_000_000 |
| unlimited | unlimited (explicit break-glass only) |
Default for ordinary transactional use (e.g. invitation/verification) should land at the low end of the scale until a use case justifies more.
Why not now (EMAIL-WP-0004)
Current scope is a single approved caller (user-engine), fixed templates, NetworkPolicy ingress lock, and one shared ingest bearer. Abuse surface is real but narrow. Building the full tier model inside T03 custody/deploy or T04 failure proof would delay the invitation path without a multi-tenant grant story.
Existing interim controls that stay:
- template allow-list (no arbitrary body/sender)
- NetworkPolicy: user-engine only
- bearer ingest token (OpenBao custody, CCR-2026-0010)
- idempotency on event id
When to revisit
Promote to a dedicated workplan when any of:
- a second caller / tenant may send through email-connect
- the ingest token is treated as a long-lived platform grant
- marketing-adjacent or high-volume notification use appears
- flex-auth or credential-broker can bind a send quota claim to the caller
Design sketch for later (not committed)
- Enforce in email-connect at accept time (before provider call), with a durable counter (not only in-process).
- Classify over-quota as permanent denial for the day (or retryable after window), redacted diagnostics, no SMTP detail leak.
- Bind tier via platform auth/grant (flex-auth / OpenBao policy metadata / caller registration), not a free-form request field the client can raise.
- Unlimited is operator-issued break-glass, audited, not a default.
- Coordinate with suppression/complaint handling so quota and reputation share one abuse narrative.
Home for implementation later
New workplan under email-connect (suggested slug theme:
send-quota-privilege-tiers / EMAIL-WP-00xx), with a hand-off to
flex-auth / railiance-platform if the tier is a platform grant claim rather
than a local ConfigMap.
Operate at build-stage security posture; defer production policy enforcement
Date: 2026-07-02
Decided by: human
We are in build stage with the infrastructure as a whole. We will tighten security step by step but it is not yet strictly necessary.
SECRETS-WP-0004 — approve warden-sign auth-capability lane prod apply
Date: 2026-07-02
Decided by: human
I want to move to more automation, this is one step needed to go on.
Defer consumer-side contract-parity drift mode (WHYNOT-WP-0003 T09)
Date: 2026-07-02
Decided by: human
Sufficient for now
DR-3: External identity path for business clients (lightweight vs NK-WP-0011 Keycloak)
Date: 2026-07-09
Decided by: human
We will go with A for the lightweigt version and just follow up with B if we meet actual demand later.
DR-1: Tenancy model for vergabe-teilnahme commercial offering
Date: 2026-07-09
Decided by: human
We will do C and allow for early customers to easy starting serving customere but move on to resource cost optimization early.
DR-2: coulomb.social rebuild architecture (Core Hub extension vs standalone app)
Date: 2026-07-09
Decided by: human
We will go for B as Coulomb Social is it's own Application. Managed by connecting it with our infrastructure but destinct in its purpose and operations model. It is an Application for the Binky Hedgehog GmbH as another App might be provided to other clients. It should not be relevant the the ecosystem as a whole is provided by Binky Hedgehog as the organization creating coulomb and holding the domain and forgejo repos.
Test mailbox harness: purpose-built test server over s/qmail
Date: 2026-08-14
Decided by: human
Automated test environments need mail accounts for test users. We will build a test harness (EMAIL-WP-0005) around a Maildir mailbox source plus a containerized SMTP/IMAP test server, rather than integrating s/qmail.
Reasons against s/qmail here:
- qmail lineage is an MTA — SMTP transport and Maildir delivery. Test users need IMAP mailboxes, which would require bolting on Dovecot or Courier anyway, so s/qmail solves the half we least need.
- Running it means operating a real mail server for test purposes: DNS, TLS, rDNS, SPF/DKIM/DMARC, queue and spam handling. That is ongoing ops cost charged against test infrastructure.
- It inverts the repo's scope boundary.
email-connectis provider-neutral and deliberately does not own an MTA; absorbing one makes us the provider we are supposed to abstract over. - Configuration is idiosyncratic and container/CI recipes are thin compared to purpose-built test servers, which raises the debugging-budget risk.
If a long-lived, internet-facing test domain with many persistent accounts is ever needed, revisit with docker-mailserver (Postfix + Dovecot) or Stalwart before reconsidering s/qmail.
Bounce, complaint, and deferral evidence is explicitly not obtainable from a local server; those classes stay on crafted fixtures plus an optional provider simulator tier.
Test harness mail server: GreenMail, and plaintext SMTP for loopback only
Date: 2026-08-14
Decided by: codex (EMAIL-WP-0005-T02)
GreenMail 2.1.12 (digest-pinned) is the harness mail server. It serves SMTP
and IMAP from one container and, with greenmail.auth.disabled, creates a
mailbox on first login — so per-test users need no provisioning step. Mailpit
was the alternative but offers no IMAP, which would leave the scanner's IMAP
source untested.
GreenMail standalone supports only plaintext or implicit-TLS setups; it has no
STARTTLS option (verified against the shipped jar's property builder). The
transactional service previously hardcoded starttls(), so no send could reach
it.
SMTPProvider therefore takes a security mode, EMAIL_CONNECT_SMTP_SECURITY,
defaulting to starttls. plaintext is refused for any non-loopback host, and
hostnames are never resolved to decide this — a name pointing at 127.0.0.1 today
is not a durable guarantee. A misconfigured deployment fails at startup instead
of putting credentials on the wire.
The alternative was trusting GreenMail's self-signed certificate for implicit TLS, which would have meant shipping certificate-verification bypass code in the send path. A loopback-guarded plaintext mode is the narrower risk.