# Sharing a Mailbox Is Not the Same as Giving It Away

A rental-outreach pipeline had a mailbox with a history: `rental@mail.openonion.ai`
had been the sender for months, replies landed there, and a CRM's dedupe rules
were written around that one address being the one identity. A newly deployed
agent needed to send the first-touch enquiries from that same address, and
ownership in the email system was exclusive — one account, one address, no
exceptions.

Every workaround was a worse trade than the problem. Moving the address to
the agent took it away from the person who still needed it. A new address for
the agent split the conversation across two inboxes that nothing reconciled,
and looked, to anyone replying, like mail from a stranger. Sharing the
private key solved the technical problem and created a real one: one
identity now sat on two machines, with no way to tell which had sent what,
and revoking access meant rotating the key for everyone who held it.

The system already had a mechanism for moving an address between accounts —
two signatures, a fixed-order message, one irreversible transaction. It's the
right tool for handing a mailbox over for good. It was the wrong tool here,
because nothing was ending: the person kept using the address exactly as
before, and the agent needed to use it too, starting now and stopping the
moment anyone changed their mind.

What was missing sat in between owning an address and losing it: a grant.
Revocable, and checked on every request rather than proven once with a
signature — the natural shape once you notice the server already sits in the
middle of every send. Nobody has to sign anything offline for a permission
the server can just look up. `co email share rental@mail.openonion.ai --with
<agent> --can send` writes one row; `co email unshare` deletes it. Attribution
falls out of the existing schema for free: every sent-mail record already
carried the identity of whoever actually sent it, so a shared address stays
one conversation, sent by two accounts, with no ambiguity about which one did
what.

The design question worth naming: not every "let account A act as account B"
problem needs cryptography. A signed, offline-verifiable grant is for the
case where nobody trustworthy is online to ask — a proxy dialing out through
a home connection at 3am, say. A mailbox share is answered on every request
by a server that was already the arbiter. Reaching for the stronger tool
there wouldn't have made the feature more correct. It would have solved a
problem this one doesn't have.