Mailboxes

What is a mailbox?

A mailbox is the on-chain account that stores the email settings for one wallet address. A wallet needs a mailbox before it can receive SithBit mail, and each wallet can own only one.

Every GUI client shows a mailbox’s settings in its Mailbox pane — see the webmail, Chrome, Thunderbird, or Outlook client pages.¹

Mailbox settings

A mailbox stores five pieces of information:

• Mail count. The total number of messages sent to the mailbox since its creation.
• Default postage. The price, in lamports, that an unknown sender must prepay for one message. A new frombox inherits this price. New mailboxes start at 1 SOL, deliberately a wall rather than a suggested everyday rate; you can lower it for everyone or set a different price for a known sender. Strangers pay, and you keep roughly 90% of the settled postage. Senders you fund yourself write without a protocol fee.
• Domain. The authorized internet domain that routes SMTP mail for the mailbox. You can change it at any time. To route correctly, the domain must be registered with the protocol and served by compatible MX servers.
• No IPFS. Whether delivered bodies stay in the operator’s store instead of public IPFS. When enabled, the on-chain message contains a local-only marker rather than a fetchable CID. This setting is off by default; see IPFS storage: benefits to users for the trade-off.²
• Funder. The wallet that paid the mailbox’s refundable rent deposit: either you, or the domain authority that sponsored the mailbox. Closing the mailbox refunds that deposit to the funder.³ Postage earnings never accumulate in the mailbox itself; they settle from the sender’s frombox through each message account to the recipient.

Creating a mailbox also claims an alias

Creating a mailbox does one more thing besides writing these settings: it automatically registers your wallet’s own address string as a self-alias pointing back at you. That claim is a namespace reservation: aliases are one global, case-folded namespace, and the self-alias takes your address’s spelling out of it so nobody else can ever hold a name that reads as your wallet. It is not what routes your mail — every SithBit resolver treats a string that is a wallet address as that wallet before it consults the alias registry at all, so an alias registered under an address’s spelling never redirects mail sent to the address. See Aliases for the resolution rule from the alias side, including why most users never need to register an alias by hand.

Sponsored mailboxes: a domain provisions for its users

Normally the wallet that signs a mailbox create is the wallet the mailbox belongs to. A domain’s on-chain authority may additionally provision a mailbox for a different owner — an employer setting up receiving mailboxes for its staff’s wallets under the corporate domain before those wallets have ever transacted. Three guards keep this from becoming a spam or squatting vector:

• Only the named domain’s registered on-chain authority may pay for another owner’s mailbox; anyone else is refused.
• The new mailbox’s default postage is forced to the 1-SOL spam floor, whatever the sponsor asked for — a sponsor cannot open cheap send channels into a stranger’s mailbox. The owner lowers prices for known senders afterwards, exactly as with a self-created mailbox.
• No self-alias is bundled (the sponsor must not squat the owner’s address string); the owner claims their own alias when they first act.

The sponsor is recorded on-chain as the mailbox’s funder, and closing the mailbox refunds its rent to the sponsor rather than the owner. In every other way the mailbox belongs wholly to the owner from the moment it exists: the sponsor keeps no control over it.⁴

Opting out of IPFS storage

A mailbox’s no-IPFS setting (above) is off by default, meaning delivered bodies are pinned to public IPFS and the on-chain message carries a fetchable CID. Turning it on is a deliberate trade: your operator keeps the sealed body in its own store instead, and decentralized clients like the trustless viewer can no longer read it — availability then depends entirely on that one operator. See IPFS storage: benefits to users for the full trade-off, and Create a mailbox or Update a mailbox for how to set it.

Mail is sealed to your wallet by default

Mail bodies are encrypted before they are pinned to IPFS, so that only the mailbox owner can read them, and this needs no setup at all by default. A wallet address is an Ed25519 public key, and its X25519 twin is a valid encryption key: mail servers seal every message straight to the recipient’s wallet address as a libsodium sealed box — no published key, no key account, no rent. See Appendix: How sealed-box encryption works for a full walkthrough of the protocol, with diagrams. Decrypting is just a matter of having the wallet keypair file.

Hardware and browser wallets are the exception: they only sign, and never reveal the secret needed to derive the wallet’s decryption key. Such users instead generate a delegated X25519 keypair client-side and publish its public key on-chain as an optional mailbox setting; mail servers then seal to the published key instead of deriving one from the wallet address, and the delegated key file (not the wallet keypair) opens the mail. Every GUI client’s Encryption-key pane publishes, rotates, and clears the delegated key — see the Chrome or Outlook client pages.⁵

1. From the terminal: Looking up a mailbox. ↩

2. Set it at create or update time from the terminal: Create a mailbox or Update a mailbox. ↩

3. From the terminal: Close a mailbox. ↩

4. Sponsors are typically domain operators scripting provisioning — see Create a mailbox — sponsored creation for the command. ↩

5. From the terminal: Mailbox keys. ↩