Domain Mail v1.0: operational boundaries
The first Domain Mail architecture moved beyond the earlier object-oriented email exercise. The repository added a Flask webmail path around real mail protocols and documented the infrastructure needed for a self-hosted domain-mail system.
What entered the codebase
- Flask webmail flows for IMAP over TLS and SMTP with STARTTLS or TLS.
- Server-side sessions and CSRF protection for browser actions.
- Docker packaging for a repeatable application boundary.
- Optional architecture for Docker Mailserver, Redis, Caddy, MTA-STS, certificates and DNS operations.
Why the architecture mattered
Mail is not only a user interface problem. Authentication, transport encryption, DNS reputation, certificate renewal, queueing and mailbox semantics all affect whether a message system is dependable.
This milestone made those operational dependencies visible and separated application code from the broader mail appliance.
What is not claimed
Repository evidence shows the implementation and deployment design, but there is no formal v1.0 release tag and no verified proof here that the complete self-hosted stack was live on 2026-07-04. A historical public Render URL is not evidence that every optional component was deployed.
Next pressure point
Once real IMAP replaced in-memory objects, message-list performance became a network problem. That led directly to the v1.1 batching change.