d8e2de2e119bfd388c42c4a0e856a768b70e3acc
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Lucas RayanandClaude Opus 5
|
d8e2de2e11 |
#24: deliver what the composer wrote, keep a copy, and store drafts
Four faults, all in the path between the compose screen and the mailbox.
**Every message sent from the webmail had an empty body.** The HTTP handler
read a field named "body"; the composer has always sent "html". The two never
matched, so the payload handed to the queue contained headers and nothing
else. The handler now reads html and text, and still accepts body so an older
client is not broken. Sending was otherwise working, which is why this went
unnoticed: the mail left, it just said nothing.
**Bcc was discarded.** The field was absent from the request struct and from
ComposeInput, so a blind copy typed into the webmail reached nobody. It now
joins the envelope recipients and is deliberately kept out of the headers,
which is what makes it blind.
**HTML was labelled text/plain.** Even once the body was carried, the composer
produces markup and the message declared text/plain, so a recipient would see
raw tags. Messages with HTML now go out as multipart/alternative with a
plain-text part derived from the markup and ordered first per RFC 2046 5.1.4.
An empty or missing text alternative is itself a spam signal.
**Sent mail left no trace.** Nothing wrote to the Sent folder, so a delivered
message vanished from the sender's view entirely. A copy is now filed after
the message is durably queued - not before, or a send refused by the rate
limit would still leave a copy - reusing the inbound persistence path so it
gets a real IMAP UID and appears over IMAP too. A failure to file is logged
and swallowed: the mail is already on its way, and reporting failure would
invite the user to send it twice.
**Drafts were never saved.** There was no endpoint at all. The composer showed
"draft saved automatically" from a setTimeout with no request behind it, so
closing the tab lost the message the screen had just promised was safe. Adds
POST /api/v1/mail/draft, storing the draft as a whole RFC 5322 message in the
Drafts folder, and debounces the composer onto it.
The composer also navigated to Sent whether or not the send succeeded, which
is how a rejected message disappears silently. It now reports the error and
stays put.
**Delay notifications were being filed as spam.** A DSN this server writes is
injected through the same inbound path as mail from the internet, but without
a client IP - so SPF can only be "none" - and its bounce-shaped content scores
highly. The warning telling you your mail was delayed landed in your own Junk
folder. Messages the server generates itself now skip content scanning; the
exemption is narrow, and a test covers that ordinary mail is still scanned so
this cannot become a way past the filter. The DSN also declared
Auto-Submitted: auto-replied, which belongs to vacation responders; a delivery
report is auto-generated (RFC 3834 section 5), and filters read that header.
Not fixed here, because it is not a code fault: outbound port 25 is blocked by
the provider, which is what the delay notification was reporting
("i/o timeout" to Google's MX - a timeout, not a refusal, is the signature of
a block). Receiving is unaffected and queued mail keeps retrying. Documented
with the two ways out, including the relay path, which is verified working
code rather than another stub.
Verified: 22 Go packages pass, 5 new compose tests and 3 for the DSN handling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Lucas RayanandClaude Opus 5
|
93d21b4752 |
#21: push new mail to the browser over WebSocket
F4 lists real-time updates and the interface had none: an open inbox only changed when the user reloaded it. Events come from the transactional outbox rather than from an in-process callback, which is what the outbox is for (PLAN.md section 9.4): the row is written in the same transaction as the message, so an event can never describe a delivery that rolled back, and a crash between commit and publish loses nothing because the row is still there on restart. The relay claims rows with SKIP LOCKED so a second instance can help without publishing anything twice. The hub fans events out per mailbox, keyed by the mailbox the session resolved to, so one account's arrivals are never visible to another even though they share the process. A subscriber that stops reading is dropped rather than allowed to stall the relay; it reconciles on reconnect. The client reconnects with capped exponential backoff and treats every successful connect as a resync, refetching the folder. Without that, a socket that dropped for a minute would leave the list quietly stale, which is worse than having no real-time updates at all. The upgrade goes through a Next rewrite, not the API route handler: a route handler sees a finished request and cannot upgrade a connection. Verified against the running stack - the handshake returns 101 through the Next server, and a message delivered on port 25 arrives as a frame on an already-open socket without the page asking for it. 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> |