Record format
@flashyos/mail
mail/1 and the estate’s mail control plane: a lane policy that refuses, a capture that demands a consent basis, a content-free event record, and a transport seam so the provider is a variable.
version 0.3.0 · audit of 2026-10-04 · source: flashyos/packages/mail
npm i @flashyos/mailNot a mail provider; the provider is a constructor argument. The record is content-free by construction — a log that kept subjects and addresses could never be published — and every outcome writes a leaf, refusals included, because a refusal that leaves no trace is indistinguishable from a message nobody tried to send. `held` is a success: a draft waiting for its human is the product.
Edge cases — each one paid for once
An address is never hashed into a leaf
An email address is drawn from a small, enumerable space, so a hash of one is a reversible identifier. The leaf carries the lane, the outcome and the time; nothing that names a person, hashed or not.
Ownership is measured, never asserted
Verifying a sender proves a domain authenticates mail; it does not prove the organisation controls it. The second is a nonce this platform issues and the tenant publishes in their zone, and no argument, field or route sets it — only a resolver returning it. `unasked` is never `absent`.
A published projection is an aggregate, never a per-message row
Order separates recipients inside one domain, and a rare domain at a known minute is a near-identifier. The footer receipt on every outgoing message therefore carries the organisation and the lane and nothing else, because a footer link ends up in spam corpora and forwarded threads.