Curriculum · Mail as a record (mail/1)

The Record of Sending: Mail Without Leaking

5 lessons · For: Anyone who sends on an organization's behalf and needs the sending itself to be a record — without that record becoming a surveillance log

Outbound mail was, for a long time, the one channel an organization sent through with no record and no gate — which is exactly the channel where a mistake is least visible and most costly. mail/1 makes sending a record, without letting that record become a log of who was contacted when.

The design is a single send path and a content-free log: every outcome writes a leaf — a refusal as much as a delivery — and the leaf is built so it can be published, because it carries no subject, no address, and nothing that could reconstruct one.

Five lessons. You will finish able to say why every rule here is about the same thing: a record that is honest about sending and impossible to turn into surveillance.

Lessons

A record of sending that can be published

You should be able to: Explain what "content-free by construction" means and why it is the enabling constraint.

A record of sending is only useful if you can trust it, and only safe if you can publish it. Those pull in opposite directions the moment the record keeps subjects and addresses: a log that remembers who you wrote to and about what can never be shown to anyone. So mail/1 keeps neither.

The log is content-free by construction — not "we redact it before publishing," but "there was never anything sensitive in it to redact." A leaf records that a message of a certain kind, on a certain authority, reached a certain outcome; it does not record the message or the recipient.

That constraint is what makes the record publishable at all, and everything else in the format follows from protecting it. A single send path — one place all mail goes through — is what makes the guarantee real rather than aspirational, because a second path is a second, ungated channel.

Source: FlashyOS — @flashyos/mail (mail/1)

Every outcome writes a leaf — refusals included

You should be able to: Explain why a refusal must leave a trace and what "held is a success" means.

Every outcome writes a leaf, and that emphatically includes refusals. A refused send that leaves no trace is indistinguishable from a message nobody ever tried to send — and those two need opposite responses. A record that only logs successes cannot tell you what it declined to do, which is often the more important fact.

So a refusal is a first-class entry: the system tried, the gate said no, and the record says so. This is the estate's rule that silence and a real event must never look alike, applied to a channel where the difference is easy to lose.

And a held message — a draft waiting for a human to approve it — is recorded as a success, not a failure. A draft awaiting its human is the product working as designed: the point of gating the channel is that some messages stop and wait, and the record treats that as the intended outcome it is.

Source: FlashyOS — every outcome writes a leaf

Why an address is never hashed

You should be able to: Explain why hashing a small-space identifier does not hide it.

The obvious way to "anonymize" a recipient is to store a hash of the address instead of the address. It does not work, and mail/1 forbids it. An email address is drawn from a small, enumerable space: an attacker who suspects a given address simply hashes it and compares. A hash of a small-space identifier is a reversible identifier wearing a disguise.

So an address is never hashed into a leaf, because doing so would put a reversible identifier on a public log while looking like it protected one — the most dangerous kind of mistake, the one that reads as safe. The only safe handle is one with no relationship to any recipient value at all.

This is a rule the estate learned across several formats: a Telegram id, an email, any identifier from a bounded space cannot be hidden by hashing. The identity service keeps the same rule for its verification leaves, for the same reason.

Source: FlashyOS — an address is never hashed into a leaf

The aggregate rule

You should be able to: Explain why a published projection is an aggregate and never a per-message row.

A published projection of the mail log is an aggregate — counts and rates — never a per-message row. The reason is subtle and load-bearing: order separates recipients within one domain, and a rare domain contacted at a known minute is a near-identifier even with no address attached. Per-row data leaks identity through timing and rarity, not just through fields.

So the public form aggregates, and the private per-leaf detail stays behind the gate. This is the same rule the estate keeps for its other public projections: an aggregate is safe to publish, a per-row trace is not, and the distinction is not about which columns you dropped but about what the rows themselves reveal.

It is also why the footer receipt on every outgoing message carries only the organization and the lane — nothing else. A footer link ends up in spam corpora and forwarded threads, so whatever it points at must be safe fully public, which an aggregate is and a per-message record never could be.

Source: FlashyOS — a published projection is an aggregate

Ownership is measured, not asserted

You should be able to: Distinguish authenticating a domain from controlling it, and say who can settle the second.

Verifying a sender proves a domain authenticates its mail — that messages genuinely come from it. It does not prove the organization controls that domain, and mail/1 refuses to conflate the two. The second is a stronger claim, and no field, route or argument sets it.

Control is established the only way it honestly can be: the platform issues a nonce, the tenant publishes it in their own DNS zone, and a resolver returns it. Ownership is something a resolver measures, never something the record asserts — and a resolver that did not answer is recorded as "unasked," never as "absent," because not having checked is not the same as having found nothing.

This closes the theme of the whole course. Every rule — content-free leaves, logged refusals, no hashed addresses, aggregate projections, measured ownership — is the same instinct: record what actually happened, refuse to assert what was not measured, and never let the record of sending become a record of who was sent to.

Source: FlashyOS — ownership is measured, never asserted

Frequently asked

How can a mail log be both auditable and safe to publish?

Because it is content-free by construction — never redacted after the fact. A leaf records that a message of a kind, on an authority, reached an outcome, with no subject and no address. There is nothing sensitive in it to leak, which is what lets the record of sending be public at all.

Why record refusals, and why is a held message a success?

A refusal that leaves no trace is indistinguishable from a message nobody tried to send, and those need opposite responses — so every outcome writes a leaf, refusals included. A held message is a draft waiting for a human to approve it, which is the gated channel working as designed, so the record treats it as the success it is.

Why not hash the recipient address to anonymize it?

Because an address is drawn from a small, enumerable space, so anyone can hash a suspected address and compare — a hash of a small-space identifier is a reversible identifier. mail/1 never hashes an address into a leaf, and its public projection is an aggregate rather than per-message rows, because timing and a rare domain can identify a recipient even with no address stored.