Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Do not disturb

A SithBit account can carry an away schedule — do-not-disturb windows managed through any of the GUI clients (or the account service directly) and evaluated in the account’s own timezone. While a window is active, the recipient’s sithbitd does something deliberately different from the classic vacation autoresponder: it refuses the mail up front, at RCPT time, with a transient 450 4.2.1 — instead of accepting the message and firing an “I’m away” reply back at the sender.

450 4.2.1 Recipient alice is away (do not disturb); try again later

That one design choice does most of the work of this page, so it is worth spelling out.

Why refuse instead of autoreply

  • The sender’s mail server does the waiting. A 450 is SMTP for “not now”: the sender’s MTA queues the message and retries on its own schedule, transparently, for days. When the away window ends, the queued mail simply arrives — the sender resends nothing and installs nothing. An autoresponder cannot offer this; it accepts the mail and leaves the sender to guess whether anyone will read it.
  • Nothing piles up while you are away. Accept-and-autoreply means coming home to a stack of stale unread mail — and, on SithBit, to a stack of postage decisions with it, since every delivered message carries prepaid postage that settles when you delete it. It also means the pile is there, one login away, for the whole vacation. Refusing at the door keeps the mailbox genuinely quiet: no backlog to triage on return, and no temptation to “just check” business mail from the beach.
  • The sender learns at send time. An autoreply may arrive, may be eaten by a spam filter, or may never have been configured — the classic bounce-or-silence lottery. A refusal reaches the sender through their own mail server’s queue notice the moment they send, while the message is still fresh in their mind.
  • A refusal costs the sender nothing. The refusal happens before the message is accepted, so no stamp is burned and nothing needs refunding. (The postage gate still runs first — the away check only fires for a sender who could otherwise deliver.)

Two honest caveats. The schedule lives in the operator’s account store and is enforced by the recipient’s sithbitd — this is server-side behavior, not an on-chain guarantee. And DND fails open: if the store hiccups mid-lookup, the server accepts the mail rather than refusing something deliverable — do-not-disturb is a courtesy, not a security boundary.

What the refused sender sees

Out of the box, the refusal is the single line above and nothing more. When the operator sets a self-service base URL, the same line also carries a link to a schedule page the sender can open in a browser:

450 4.2.1 Recipient alice is away (do not disturb); try again later; schedule at https://mail.example.com/dnd.html?to=alice%40sithbit.net

The page answers the question the refusal raises — when should I expect delivery? — as far as the recipient allows:

  • Accepting now. If the away window has already ended, the page says so: the sender’s MTA is retrying on its own, so the mail is on its way (or a resend delivers immediately).
  • Away, schedule private (the default). The page confirms the recipient is temporarily not accepting mail but cannot say when the window ends — the sender’s server keeps retrying regardless.
  • Away, schedule shared. If the recipient opted in to sharing, the page lists the away windows — and, when the schedule ever reopens, adds “accepting mail again at …” with the exact resume instant shown in the sender’s own local time (the account service computes it in the recipient’s timezone and ships it as UTC; the page localizes it to the viewer’s clock). The windows themselves still read in the recipient’s local time. A recurring schedule covering the whole week around the clock never reopens, so no instant exists — the page then shows the windows alone.

Sharing is the recipient’s choice, off by default: the account’s expose_dnd_schedule flag (a toggle in the clients’ DND settings, or PATCH /v1/account on the account API) controls whether the anonymous schedule check returns the windows themselves — plus, while away, the resume instant — or only the yes/no “away right now” answer. Your calendar is yours; the protocol only ever needs the boolean.

Stamp refusals: the funding page

The same setting links a second page from the two postage refusals — the gate every unknown sender meets before DND is even consulted:

  • 450 4.7.0 — the sender’s frombox exists but holds no stamps. Transient: the sender’s MTA queues and retries, so once the frombox is funded the queued mail delivers on its own — no resend needed.
  • 550 5.7.0 — no frombox exists for this sender/recipient pair at all. Permanent: the message bounced for good, so after funding the sender must send it again.

With the base URL set, both append ; fund it at {base}/fund.html?to=<recipient>&from=<sender> — a funding page where the sender fixes the shortage themselves, with no account and no operator in the loop:

  1. The page resolves the recipient and quotes the price straight off the chain — the recipient’s per-stamp postage, the fixed settlement surcharge, and the live per-stamp protocol fee (waived on-chain when a recipient funds their own frombox). Nothing is trusted server-side; the quote is read from the same accounts the program enforces.
  2. The sender connects a Phantom or Ledger wallet, picks a stamp count (one stamp = one email), and buys. A first purchase creates the frombox in the same transaction — the same create-or-top-up path every client uses.
  3. The page confirms the purchase and tells the sender what happens next: after a 450, waiting is enough; after a 550, resend.

This closes the loop postage opens: pricing out strangers only works as spam defence if a legitimate stranger has a way to pay, and the refusal itself now hands them one.

For operators: one setting, two pages

Everything above is off by default — leaving the setting unset keeps every refusal byte-identical to the linkless text. A single SMTP setting turns both links on: the public base URL the two pages are served from (for example https://mail.example.com). There is nothing else to configure — the paths and query strings are built for you.

See the configuration reference for the details, and Self-service pages for refused senders for how the two pages are hosted (they ship in the onboarding web bundle, normally served by the account API’s static-file root). The standalone smtp-server dev binary carries only the funding link — the DND gate is sithbitd’s.