SELECTED WORK · SES INBOX
I needed a mail system I could own: receive real email, keep it until I chose to delete it, and recover it safely. I built SES Inbox with coding agents—and directed the decisions that made it fit for my own production use.
A few thoughts before we begin…
Here is the updated version.
Good to compare ideas.
Hello,
I’ve attached the project notes. We can use these as a starting point for our next conversation.
What would you change?
Filed in this address’s inbox01 / THE PRODUCT
The starting point was practical: replace a hosted mailbox for two domains I run. I wanted ordinary mail tasks to feel straightforward, with explicit rules underneath for the actions that matter.
Switch between domains and addresses, read conversations, compose replies, keep drafts, work with attachments, and search by words or quoted phrases. Each address has its own folders, unread state, drafts and conversation history. A message delivered to two addresses becomes two independent copies.
That separation is a product decision as much as a storage decision: reading or filing mail for one address should not silently change the other.
02 / THE ENGINEERING
Four requirements shaped the implementation. Each has a consequence the owner can understand.
A timeout must not turn one email into two.
The system stores the sent copy and records the attempt before calling SES. A definite rejection is marked failed. An ambiguous result stays uncertain for review, with no automatic resend.
The owner can investigate an uncertain send instead of silently sending it again.
A restore must respect what I chose to delete.
Permanent deletion records an independent deletion intent and a database tombstone. Recovery applies the latest deletion ledger, including deletions made after the backup.
An older backup cannot quietly reverse a later deletion.
Testing a backup must not put live mail at risk.
Backups include checksums and a committed manifest. Restore tooling verifies the data and requires an empty, isolated destination; it refuses to overwrite the live mailbox.
Recovery can be exercised and inspected before the restored system is used.
Mail sent on my behalf should be visible in Sent.
Participating website and product mailers submit a copy through a source-scoped, write-only intake. The worker imports that copy into the appropriate address’s Sent folder.
Personal correspondence and captured application mail can be reviewed in the same mailbox.
ONE DECISION, MADE VISIBLE
A missing confirmation does not prove a message was rejected. Repeating the send could create a duplicate.
The application preserves that uncertainty for a person to review. Here, stopping is part of the design.
From hello@example.com
To alex@example.org
Hello Alex,
Here are the notes for our next conversation.
Project-notes.pdfThe result is uncertain. Review the attempt before sending again.
No automatic resendTHE SYSTEM BEHIND THE MAILBOX
Mail content and metadata have separate homes. The application connects them; recovery checks them together.
Receiving and capture workers write to the same content and metadata stores used by the mailbox.
SES receipt rules store incoming mail in S3 and notify an SNS/SQS queue. A worker parses each message, stores its parts, and updates relational metadata and positional search indexes in Aurora DSQL. The owner accesses the application through CloudFront and an authenticated Lambda endpoint. Sending uses SES v2; delivery events return through the queue. A separate maintenance process creates checksummed backups, while source-scoped capture imports participating applications’ outbound mail.
Explore the architecture in the repository03 / DIRECTING THE WORK
The work moved quickly because agents could research, implement and test. My responsibility was to decide what to accept, what to challenge and what needed explicit approval.
Replace a hosted mailbox. Retain mail until deliberate deletion. Make recovery dependable.
Agree the scope of experiments and costs. Review consequential deployments and DNS changes before execution.
Review architecture and search behavior against the needs of a small, personal mailbox.
Ask what was checked, which revision was deployed, and what a result actually establishes.
Read real mail, try the phone layout, challenge gaps, and turn observations into the next change.
04 / OUTCOMES & LIMITS
The project records document real production mail, a complete backup restored into an isolated cloud destination, and matching database digests and content checksums. A separate drill exercised deletion filtering and retention behavior. These records support specific checks rather than a general reliability guarantee.
The scale matters: one owner and two domains. Recovery is scoped to the same AWS account and region; the documented backup interval is about 24–25 hours. Recovery time has no established service-level guarantee, and the design has bounded snapshot sizes.
SES Inbox serves my own mail. Its source and project records are published so others can examine the implementation, the decisions and the remaining work.
EXPLORE THE WORK
The repository includes source, infrastructure, tests and runbooks. The hosted mailbox remains private.