What it is
Credentials the client never holds.
An agent — or any client — talks to Darbaan over standard IMAP to read mail and SMTP to send it, and Darbaan enforces policy in front of the real mailbox. It holds the upstream credentials and the bounce-signing key, so a compromised client only ever holds Darbaan credentials, never the real mailbox. Outbound is default-deny; inbound is a synced, recency-bounded view rather than the live account.
Outbound is trapped and approved before it leaves; inbound is a synced, gated copy.
Not an authenticity source. Darbaan is a proxy; it does not itself verify that a message genuinely came from its claimed sender. The provenance it stamps is only as trustworthy as the upstream mail server's own sender authentication (SPF, DKIM, DMARC).
Key features
Two properties define it.
Outbound is default-deny
Every submission is trapped in a sluice — queued, not sent. Nothing a client submits leaves until a human approves it.
A human decides
An operator approves or rejects each held message from a CLI or from Telegram. The client never approves its own mail.
Signed release or bounce
On approval Darbaan delivers and signs the message; on rejection it returns a DKIM-signed bounce the client can cryptographically trust.
Gated inbound sync
Mail is pulled into Darbaan's own store incrementally, with lazy bodies and a recency cutoff, then served over IMAP as a single inbox.
Credentials stay behind the gate
Darbaan holds the upstream credentials and bounce-signing key; a compromised client holds only Darbaan credentials, never the real mailbox.
Localhost-only admin
The agent faces bind to loopback by default; the admin API is always localhost-only, with per-client least-privilege tokens.