sithbitd: the mail daemon

Default port(s): SMTP 2525, IMAP 1430, POP 1100, health 8190. The submission listener is disabled by default and has no distinct default port (it would inherit SMTP’s 2525) — always set its bind_addr when enabling it. The docker-compose files rebind everything to the 2xxx convention (2525/2587/2143/2110) explicitly.

The combined mail daemon — SMTP MX and submission, IMAP, POP, and the spooler workers (chain pin/send, relay, DSN generation, reconciliation) all in one process. This is the production mail-handling binary; every deployment needs it.

When you need it: always — this is the core of a SithBit deployment. Run exactly one sithbitd per SQLite store (IMAP IDLE push and per-wallet SendMail ordering are in-process); a cloud store (aws/azure) lifts that limit, letting you run one per fleet member — see Scaling out.

Every role is a toggle: each listener section has its own enabled switch, and [spooler] enabled = false skips all the background workers — relay, DSN, chain pin/send + delete, auto-settle, reconciler, repin — for a listeners-only instance. Accepted mail is still spooled; a worker-enabled sibling over the same shared store drains the queues. The DMARC RUA/RUF reporting workers keep their own section switches, and the embedded IPFS swarm is unaffected. Presets and the role matrix are in Role-split topologies.

Quickstart:

cargo run -p mail-spooler --bin sithbitd

Config file sithbitd.toml, or point SITHBITD_CONFIG at an alternate path.

Note: an empty or missing config runs a loopback dev stack with the chain pipeline disabled — delivered mail stays in state received. This is the expected zero-config shape, not a bug.

Running as an OS service

sithbitd service installs the daemon under the host’s service manager. Both platforms record the current directory as the service’s working directory (config, .env files, and relative store paths resolve there) and, with --config, an absolute config path:

cd /srv/sithbit          # becomes the service's working directory
sithbitd service install --config sithbitd.toml

systemd (Linux). service install writes /etc/systemd/system/sithbitd.service (--unit-path <path> overrides the destination; --print renders the unit to stdout instead) and prints the activation step — it never touches systemd state itself:

systemctl daemon-reload && systemctl enable --now sithbitd

The generated unit restarts on failure and orders after network-online.target. Commented User= and AmbientCapabilities=CAP_NET_BIND_SERVICE lines are included for running unprivileged while still binding the standard low mail ports. sithbitd service uninstall removes the unit file (disable the service first).

Windows. service install, from an elevated prompt, registers an auto-start service named sithbitd with the service control manager; start it with Start-Service sithbitd. The registration launches this same binary with the internal service run verb, which re-anchors the recorded working directory before loading config (SCM services otherwise start in System32). sithbitd service uninstall stops the service and deletes the registration.

At-rest sealing (automatic)

On a chain-enabled deployment (a [grpc] gateway configured), delivered mail for password-less accounts is sealed at rest automatically — there is no switch. The per-account rule is the only gate: an account with a stored mail password keeps a readable copy (its CRAM-MD5/APOP logins could never unwrap one); a wallet-signature-only account gets its body envelope-sealed at spool time, with the recipient-facing IPFS copy and reply-linkage ids computed in the same pass (the stored body can never be re-parsed, and re-sealing later would change the pinned CID — the spool-time facts are canonical, so a reading key rotated between delivery and pinning takes effect from the next message). The chain-less dev stack has no gateway to resolve reading keys and stays all-plaintext.

Two operational consequences:

• Accepting mail for a password-less recipient asks the gateway for their published key at SMTP DATA time. A gateway outage tempfails the submission (451) — the same posture as the postage checks at RCPT — rather than silently downgrading anyone to plaintext.
• The wallet-signature AUTH on SMTP refuses a reading-secret suffix (base58(sig).base58(secret) is an IMAP/POP/webmail login shape): the submission path never decrypts, so a client shipping the secret there is leaking it, and the misconfiguration fails loudly instead.

See the Configuration reference for the full key/default table.