What Ruber runs on, and what we did not write
Postfix, Dovecot and Rspamd, and no in-house rewrites of any of them. What that buys, and where the work went instead.
Ruber runs on Postfix, Dovecot and Rspamd. Those are the same components most mail providers run, including several that would rather you did not think about it, and we did not write our own versions of any of them.
Rewriting IMAP would make the product worse
IMAP is a large, old, adversarial protocol with three decades of client behaviour encoded in it — including the parts where clients are wrong and the server is expected to cope. Dovecot has absorbed all of that. A fresh implementation would spend years rediscovering it, and every year of that is a year not spent on the thing a customer actually touches.
The same argument covers Postfix for SMTP and Rspamd for filtering. There is a version of this company that treats writing its own mail internals as a point of pride. That company ships a worse mailbox more slowly.
What we did build
The control plane, and the parts above it: provisioning, DNS, the dashboard, the API, the client. That is where the decisions are still open and where the experience of using email is actually decided — nobody has ever chosen a provider because of its IMAP server, and plenty have left one because of its interface.
The part this makes easier to say
Standing on mature components means the boring properties are boring. Inbound mail is scored by Rspamd before delivery, with SPF, DKIM, DMARC, sender reputation and phishing heuristics feeding the score. Outbound is checked as well, which is less common, and it is what stops one bad account degrading delivery for everyone sharing the reputation.
None of that is behind a plan. It is the same in the trial as on the largest tier, because charging for authentication would be charging for the mail working.