coulomb/email-connect
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add EMAIL-WP-0005 test mailbox harness workplan
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Plans a Maildir mailbox source, a containerized SMTP/IMAP test server,
deterministic test-user mailboxes, and end-to-end send-and-scan integration
tests, so automated test environments get mail accounts for test users without
a live provider.

Records the decision to use a purpose-built test server rather than integrating
s/qmail, and keeps bounce/complaint/deferral evidence on fixtures plus an
optional provider simulator tier.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-14 01:26:25 +02:00
parent 04897a149f
commit 9c0d6f1b40
2 changed files with 320 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

33
DECISIONS.md
View file

@ -127,3 +127,36 @@ We will do C and allow for early customers to easy starting serving customere bu
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-connect` is 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.
---