Standards and RFC coverage

SithBit reinvents email’s economics — sender-paid postage settled on-chain, addresses you own outright — but it deliberately reinvents almost nothing about the wire. Your existing mail client already speaks SMTP, IMAP, and POP3, and SithBit’s servers speak them back, to the letter of the specifications that have carried email for four decades. That is the whole point: you get a spam economy that finally works without throwing away Thunderbird, Outlook, Apple Mail, or the mobile client already on your phone.

Standards-completeness matters more for email than for almost any other protocol. Email’s interoperability is adversarial — a message crosses servers written by strangers, in languages you’ll never see, and a single misread reply code or dropped capability turns into a silently lost message or an open relay. So the reference servers don’t implement “enough of” each protocol to pass a smoke test; they implement the published grammar, advertise exactly the capabilities they honor, and reject out-of-sequence commands structurally rather than hoping clients behave. Where a specification is only partially implemented, this page says so plainly in the Notes column — no overclaiming.

The tables below enumerate every RFC each SithBit server and subsystem implements, grouped by the component that owns it. Each links to the canonical text at the RFC Editor. If you are weighing a from-scratch server or an existing MTA against simply running sithbitd, this is the coverage you’d be matching.

SMTP — sending and relaying mail

The SMTP surface is the sans-io smtp_session state machine (the wire grammar and its extensions) driven by the smtp_server binary (STARTTLS, SASL, delivery, and the SithBit sender-authentication policies). Enhanced status codes are structural: the class digit is derived from the reply code so a mismatch is unrepresentable.

IMAP — reading and managing mail

The IMAP surface is the sans-io imap_session semantics core over the typed imap-types AST, driven by imap_server over the imap-next flow layer. The baseline is IMAP4rev1; the rev2 extensions SithBit implements are advertised individually rather than by claiming rev2 as a whole.

POP3 — simple mailbox download

The POP3 surface is the sans-io pop3_proto typestate machine driven by pop_server. Commands invalid for the current session state are unrepresentable rather than merely rejected at runtime.

Authentication (SASL)

SASL mechanisms are shared by all three protocol servers through server_common. Wallet-signature SASL PLAIN is verified against the connecting address with no stored secret; CRAM-MD5/APOP serve clients limited to challenge-response.

The LOGIN mechanism (widely deployed, never standardized as an RFC) is also supported for legacy clients. DIGEST-MD5 and NTLM are deliberately dropped.

Message format and abuse-report handling

Message parsing and generation are adopted rather than hand-rolled — every consumer names one set of versions through mail_message, which itself owns only the RFC 5321 envelope layer (source routes, the null reverse-path, the domainless postmaster recipient) that the format crates don’t model.

Anti-abuse and transport hardening

Beyond these wire standards, the on-chain layer is where SithBit’s own contribution lives: the MailInstruction ABI, PDA derivations, and sealed-box encryption described in the Program & PDA reference and How sealed-box encryption works. Any server that speaks the RFCs above and those on-chain conventions is a first-class participant — see Protocol conformance for custom mail servers.