Ruber

Features

86 things it does, and the ones it does not.

Open any card for what it actually does and how. Anything working with a condition attached says so on the card and explains it inside; anything that does not work is at the bottom of the page rather than left out of it.

Mail and reading

Real mailboxes, read the way you want to read them.

  • Real IMAP mailboxes

    Every address is a real maildir on Postfix and Dovecot with its own credentials — not a forwarding rule, and not an alias pointing at an inbox somewhere else.

    That is what makes the rest of it true: a folder you create in Thunderbird appears in Ruber, and one you create in Ruber appears in Thunderbird, because there is only ever one folder. Nothing is synchronised between a proprietary store and a standards-shaped view of it.

  • Unified inbox

    Every address on the account read at once, with the counts added up per folder. Switching to a single address narrows the same view rather than loading a different product.

    Smart mailboxes only, by design. A Private mailbox stands behind its own unlock gate, and quietly folding it into a unified list would mean either breaking that gate or showing a mailbox that cannot be read.

  • Conversations, two ways

    Threads are built from the Message-ID, In-Reply-To and References headers in the index, so a conversation holds together across clients and across people who reply badly.

    The same thread renders two ways, as an account preference: stacked message cards, or a chat transcript with bubbles. Both read the same data — it is a way of looking at a conversation, not a different kind of conversation.

  • Optimistic triage with a durable outbox

    Archive, star, move and mark-read paint immediately and batch behind the scenes. Nothing spins while the server catches up.

    The pending batch is written to IndexedDB *before* the request leaves the tab, so closing the laptop mid-action does not lose it — the next load replays what was owed.

    Only actions that name a destination are queued this way, because those are the ones that are safe to repeat. A send is never in the outbox: replaying one would mean sending twice.

  • Message provenance panel

    Per message: From, To, Cc, Date and Subject, plus who it was mailed by, who signed it with DKIM, whether the last hop used TLS, and the SPF, DKIM and DMARC verdicts.

    Those verdicts are parsed from the Authentication-Results header the receiving server wrote, not guessed from the sender's name. The list's "verified sender" badge is driven by the same stored result.

  • BIMI logos, DMARC-gated and proxied

    A sender who publishes BIMI artwork and passes DMARC gets their real logo beside the message. It is resolved on our side, cached, and served from Ruber's own origin.

    That last part is the point: opening a message never pings the sender's server for an image, so the logo cannot double as a read receipt. The lookup is cache-only, which also means the feature is not a request-forging surface pointed at whatever domain a stranger puts in a header.

  • Remote images blocked per message

    Every remote image in an HTML message is rewritten server-side before the message reaches the browser, and a notice says how many were held and why.

    Tracking pixels are the reason. A remote image loaded automatically tells the sender you opened the message, when, and roughly where from. You can load them for one message, or turn the blocking off entirely if you would rather.

  • Server-side HTML sanitising

    Inbound HTML runs through an allowlist of tags and attributes before it is ever rendered. Scripts and javascript: URLs are stripped, and links are forced to open in a new tab without handing the destination a reference back to the app.

    The same sanitiser runs over mail you compose, so what you send is held to the standard we hold other people's mail to.

  • Hardened attachments and risky-file warnings

    An attachment is served with the type the sender declared only when that type is plainly inert. Everything else is downgraded to a generic binary, marked no-sniff, and never displayed inline.

    Around fifty-five executable and macro extensions also earn a visible warning, anchored on the *final* extension — which is how invoice.pdf.exe gets caught. It is a warning rather than a block: it is your mail, and we would rather tell you than decide for you.

  • On-device mail translation

    Translate a message into any of forty-two languages using the browser's own built-in translation engine. Nothing leaves the tab — which is the only reason it can be offered on Private mail at all.

    Never automatic, and the original is always one click away. The bar names both languages rather than silently replacing what somebody wrote.

    Needs a browser with the built-in Translator API — Chrome 138 and Edge 148 or newer today. Firefox and Safari report it as unavailable and the app says so rather than failing quietly.

  • A reading layout you set once

    The line between the list and the conversation is draggable, clamped so neither side can be squeezed into uselessness, remembered per browser, and adjustable from the keyboard.

    The reading pane can also sit beneath the list instead of beside it, and rows come in two densities. None of it changes what a message is — only how much of the screen it gets.

  • Honest empty states

    A mailbox we cannot reach is classified and said out loud — unavailable, no access, or no such mailbox — rather than rendered as an empty inbox.

    The distinction matters more than it sounds. "Inbox is empty" and "we could not open your inbox" look identical on screen and mean opposite things, and only one of them is a reason to check your DNS.

  • Persisted offline read cache

    Successful reads are cached to IndexedDB, keyed by user and schema version, so a reload paints from the last known state before the first request comes back.

    Mutations are never persisted this way — only what the server has already confirmed.

  • Cheap new-mail detection

    New mail is noticed by polling one integer per mailbox every four seconds — an index version — rather than re-reading whole folders on a timer.

    It is the cheapest read in the app, which is what makes it affordable to do often. The mail agent can also hold an IMAP IDLE session and push the moment the server reports a change.

    The IDLE push path is configuration-gated on the mail plane. Without it, new mail appears on the next poll rather than the same instant.

Composing and sending

Everything between deciding to write and the message leaving.

  • The composer

    The composer floats bottom-right so the list behind it stays readable, and minimises, expands and closes without losing what you typed.

    A failed send leaves everything intact rather than throwing the draft away and apologising.

  • From picker across addresses and aliases

    Pick any address on the account, including aliases — the picker names which are aliases and where they deliver.

    The choice is a request, not an instruction. The mail server re-validates the sender against the credentials that authenticated, and rejects a mismatch. A bug in the dashboard cannot forge a From address, because the dashboard is not what decides.

  • Recipients and autocomplete

    To, Cc and Bcc as removable chips with arrow-key completion, suggesting people you have actually corresponded with rather than a bought directory.

    Bcc reaches the envelope only. It never becomes a readable header, which is the bug that has embarrassed more than one mail client.

  • Rich text without the font menu

    Bold, italic, underline, strikethrough, lists, blockquote, links, and undo — with markdown-style input rules as you type.

    Deliberately no fonts, sizes or colours. Mail that arrives styled to somebody's taste rather than their reader's is mail that is harder to read, and the output goes through the same sanitiser as everything inbound anyway.

  • Undo send

    Send waits five seconds before it actually goes. Undo cancels a request that was never made, rather than trying to recall a message that has already left.

    That distinction is why it always works. Nothing needs to be chased down at the other end.

  • Schedule send

    Presets for tomorrow morning or Monday, plus a bounded picker up to a month out.

    The runner claims each due message with a row lock before sending, so two overlapping runs cannot send the same message twice, and three consecutive failures stop the retry rather than looping. Scheduled messages can be cancelled until they go.

  • A byte-identical Sent copy

    The message is composed once and submitted as raw bytes, so the copy filed in Sent shares its Message-ID and MIME boundaries exactly with the one that was delivered.

    Most clients rebuild the Sent copy, which is why replies sometimes fail to thread against it and why forensic questions about what you actually sent are hard to answer.

  • Send limits that hold

    Fifty an hour per mailbox, a short burst allowance, and a platform-wide ceiling above that.

    Keyed on the owning mailbox rather than the address, which is what stops a catch-all domain from turning one mailbox into unlimited senders. The API send path runs the same limits as the composer — there is no faster door.

  • Attachments and autosaved drafts

    Up to ten files and eight megabytes per message, staged before the send so a large attachment does not block the editor.

    Drafts autosave as you type into a Drafts view of their own, rather than into the IMAP Drafts folder — which keeps a half-written message out of every other client until you mean to send it.

    Both need the object store configured on the deployment.

Organising

Folders, labels and rules — all of them standard underneath.

  • Custom folders

    Folders you make in Ruber and folders you make in any mail client are the same folders, listed live with their counts.

    There is no proprietary construct here to be trapped in. That is the whole argument for building on IMAP rather than on top of it.

  • Labels as IMAP keywords

    Labels are IMAP keywords with a catalogue row for the name and colour, so a message can carry several and a client that knows nothing about Ruber still sees them.

    Clicking a label narrows the folder you are in rather than navigating somewhere else; clicking it again clears it. Deleting a label leaves the mail alone.

  • Filters and rules

    One condition — sender, recipient or subject, matched as contains or exactly — and one action: move to any folder, star, mark read, or apply a label. First matching rule wins.

    Worth knowing exactly when they run: rules are applied when the mailbox is read, not at the moment mail is delivered. If nothing opens the mailbox, nothing is filed. It is the same honesty contract as blocked senders and forwarding, and it is a real difference from providers that run rules server-side at delivery.

    Rules run on a sweep when the mailbox is opened, not at delivery, and each rule takes one condition rather than several combined.

  • Blocked senders

    Block an address or an entire domain. Blocked mail is swept to Spam and used to train the filter, and the sender is never told — a bounce would confirm the address is real.

    Blocking currently happens on the same read-triggered sweep as filters, so it files mail rather than refusing it at the door.

    Applied when the mailbox is read. Stopping blocked senders at the mail server itself is not built yet.

  • Forwarding and auto-reply

    Forward to an external address from the moment you switch it on — never retroactively over everything already in the mailbox — with the original left where it is.

    A keyword written onto each message means the same mail is never forwarded twice, even though the sweep itself keeps no state. An away message works the same way, replying at most once per sender per week.

    Private mailboxes get the away message but never forwarding: forwarding ciphertext is a promise the recipient cannot open.

    Both run on the read-triggered sweep, a batch at a time.

  • Spam training from any mail app

    Marking something junk in Thunderbird or Apple Mail trains the filter exactly as marking it in Ruber does, because the training fires on the IMAP move rather than on a button in our UI.

    Encrypted mail is deliberately excluded. Feeding ciphertext to a Bayesian classifier would teach it that high-entropy text is spam, and degrade filtering for everybody on the host.

Privacy and encryption

Two kinds of mailbox, and the trade stated on the switch itself.

  • Smart and Private mailboxes

    Smart means Ruber can read that mailbox to sort it into categories, search it by meaning, and run labels and rules over it. Private means only your devices can read it, and those features are unavailable.

    The trade is written on the control itself rather than in a help page, because it is the one decision on the account that cannot be casually undone. It is set per mailbox, so one account can hold both.

  • Receipt-time encryption at delivery

    A proxy sits between the receiving mail server and the mailbox store. For a Smart recipient it passes the bytes through; for a Private one it replaces the message with an encrypted envelope before it is ever written to disk.

    That ordering is the point. The plaintext is never stored and then encrypted later — there is no window in which it existed at rest on our side.

    The decision function has no default. An unreachable database, an unknown mode or a timeout all defer the message rather than guessing, because the only wrong guess is the one that writes somebody's mail in the clear.

  • Client-side sealed send and reading

    A Private message is built, signed and encrypted in the browser. The recipient's key chain is verified first, and a broken chain blocks the send — it is never a warning you can click past.

    Reading works the same way in reverse, in the tab, after an unlock.

    Sealed reading covers the main folders today. Custom folders, the Starred view and search inside a Private mailbox are not there yet, and nor is sealed reading on mobile.

  • Three ways to stay unlocked

    Unlock for this tab, for this device, or behind a device PIN. The device option seals the key under a non-extractable browser key, so script running in the page can use it but can never export it.

    The PIN adds a server-held pepper released only for the right PIN, with escalating lockout and a fall back to the password after ten wrong attempts. A device can be forgotten remotely, which deletes its pepper and leaves its stash unopenable — done without ever being able to read the mail.

  • Three recovery secrets

    A recovery key you type back whole, a twelve-word phrase checked at three random positions so it cannot simply be pasted, or a recovery file you re-upload to prove it really reached your disk.

    One field takes all three — it works out which kind of secret you pasted rather than asking first. And the recovery form says, before a code is spent, whether the proof you hold recovers the account only or the mail as well.

  • Sealed calendar events

    Event titles, descriptions and locations are sealed in the browser for a Private calendar, with a database constraint that refuses any row holding both a sealed blob and plaintext.

    Times are not sealed, deliberately: it is what lets a booking link know an hour is taken without learning what is in it, and lets a reminder fire saying "a private event" and the time.

  • One encryption identity

    One account has one encryption identity, one credential and one recovery set. Turning on a second Private mailbox asks for nothing.

    There is deliberately no way to turn Private off. A downgrade would have to decide the fate of mail that is already encrypted, and every answer to that is worse than not offering it.

Security

What runs before a message reaches you, and who can get in.

  • Every message scored before delivery

    Every inbound message is scored on SPF, DKIM, DMARC, ARC, Bayesian analysis and reputation lists before it is delivered — one modern filter rather than five overlapping legacy ones.

    Outbound mail is checked too. A compromised account sending spam is a deliverability problem for every other customer on the platform.

  • Executables rejected at the door

    Executable attachments are refused during the SMTP transaction itself, across roughly sixty extensions, so the sending server bounces with a reason rather than the mail vanishing into a quarantine nobody reads.

    Macro documents and archives are deliberately not on that list. They are too often legitimate, and they are warned about in the client instead.

  • TLS posture

    Submission on 465 and IMAP on 993, both implicit TLS. No opportunistic-upgrade ports are published at all, because a port that can be downgraded is a port that will be.

    Outbound delivery requires encryption on the wire, and certificates are issued and renewed automatically.

  • Two-factor and passkeys

    Time-based one-time codes, with the enrolment verified before it counts so a half-scanned QR cannot lock you out. Turning it off costs a fresh code.

    Passkeys are offered as a sign-in method rather than a second factor, because a passkey with user verification already is multi-factor and treating it as half of one is theatre.

    Passkeys need the capability enabled on the deployment; the app says so plainly when it is not.

  • Sign-in history

    The last fifty sign-ins with device, address and time, and chips marking which is this device, which are still live, and which used two-factor.

    Recorded by a database trigger on the session table rather than by the app, so it captures every session however it was opened — including ones that never touched our sign-in form. A failure to read it says so instead of showing an empty list.

  • Rate limiting throughout

    Twenty-four named policies — sign-up, sign-in, domain checks, booking, API keys — that fail closed in production rather than letting traffic through when the limiter is unreachable.

    The subject of each limit is hashed, so the store that enforces them is not also a log of who uses the product and when.

  • Sender ownership enforced at the MTA

    The mail server validates the sender against the credentials that authenticated and rejects a mismatch, so a bug anywhere in the dashboard or the API cannot forge a From address.

    Repeated failed logins are throttled with a retry hint rather than a flat refusal, so a misconfigured client backs off instead of forgetting its password.

Domains and addresses

Your domain, its records, and every address on it.

  • Add your own domain

    Prove the domain with a TXT record, then get MX, SPF, DKIM and DMARC written for you, each value individually copyable and never truncated.

    DMARC is marked recommended rather than shown as an error, because a domain without it is not broken — it is just less protected than it could be.

  • DNS verification that does not flap

    Records are re-checked every fifteen minutes, plus a manual button that runs exactly the same code.

    A domain is never demoted because of a resolver hiccup. A record that is genuinely absent counts; a timeout changes nothing. Watching a verified domain flip to failed because somebody else's DNS was slow is how people stop trusting a status light.

  • Addresses and aliases

    Every account gets a working address on our domain immediately, so mail works while DNS propagates — or while you decide whether you want a domain at all.

    Aliases add extra addresses that deliver into an existing mailbox, one target each so chains and loops cannot be expressed. The required role addresses cannot be removed.

  • Catch-all addresses

    Every address on a domain can deliver into a nominated mailbox, with guards that stop a catch-all from swallowing a real or suspended mailbox that already exists.

    It is what makes a per-shop address at a checkout free rather than a chore.

  • Discovered identities

    An address you invented at a checkout is noticed the first time mail arrives for it, and the message that discovered it carries the prompt: keep it, or block it.

    Keeping it writes a real alias you can then send from. It closes the loop that every other provider leaves open — catch-all mail arrives, and nothing ever turns it into an address you own.

  • IMAP and SMTP client access

    Host, ports and every value copyable, for Apple Mail, Outlook, Thunderbird or anything else.

    Each mailbox gets its own app password, generated in the browser from an alphabet with no confusable characters, shown once and stored hashed. Revoking one client does not disturb the others.

Calendar

Time that behaves, and links that let people take some of it.

  • Six views

    Day, three days, week, month, year and agenda. Three days exists because it is the range that fits a laptop screen without the week's columns becoming too narrow to read.

    Agenda skips empty days and crops each one to the hours it actually uses. Year is a heat map of how busy each day was, and clicking a day jumps to it.

  • Recurrence that survives daylight saving

    A repeating rule is expanded in wall-clock time and only then mapped to the zone — the order RFC 5545 defines. It is why "every weekday at 09:00" is still nine o'clock the Monday after the clocks go back.

    Expand the same rule in UTC instead, which is the easier thing to write, and the hour slides by one the moment the offset changes and stays slid until spring. The same expander serves the grid, the reminders and booking availability, so they cannot disagree with each other.

  • Change one occurrence, keep the series

    Drag an occurrence and choose whether the change applies to that one, to this and everything following, or to the whole series.

    A single moved occurrence is stored as an exception to the rule rather than as a copy that has stopped following it, so the rest of the series carries on being the series.

    Editing the scope of a change is available when dragging. Changing or cancelling a single occurrence from the event card itself is not wired up yet.

  • A second time zone, alongside

    A second time zone runs down the grid beside your own, with live clocks for both and per-hour conversion — so a week containing a clock change is right on both sides of it.

    Events also keep their own zone rather than being stored in yours, which is what makes a dragged event land where you meant when the two disagree.

  • Publish a link with a duration, a buffer between meetings, which days and which hours. Someone picks a slot and the event appears; they need no account to do it.

    Availability is computed entirely on the server, so a stranger receives a list of free slots and never the shape of your day. A taken slot is simply not offered, and a missing, disabled or rate-limited link all return the same response — which is what stops the page being a way to enumerate them.

    Duration, buffer, days, hours and time zone are all settable in the app. Lead time and booking horizon exist in the API but the web form does not send them yet, so links take the defaults.

  • Multiple calendars, undoable edits

    Several calendars per mailbox with their own colours, shown or hidden independently, and the whole surface can be narrowed to a single address.

    Creating and deleting are undoable, and undo re-inserts the original row — same id, same uid, including sealed content — rather than making a new event that looks like the old one.

  • Event reminders

    Reminders at the time, or five minutes to a week ahead, with a per-account default. They are keyed on the event, the offset and the occurrence, so a retry cannot deliver the same reminder twice.

    A sealed event's reminder says "a private event" and the time. It cannot say more, and it does not pretend otherwise.

    Reminder delivery runs on a background job runner. Whether that runner is connected is a deployment question, and on a deployment where it is not, a reminder is written and never sent.

Contacts

An address book that learns from your mail and asks nobody else.

  • A record that fits real people

    Given, middle and family names, a nickname and pronouns — stored as separate fields rather than one string with spaces in it.

    Somebody with two family names, or a name that does not split the way English expects, is stored correctly rather than nearly. Several labelled emails, phones, websites and postal addresses each, plus custom fields of your own when the shape does not fit.

  • Relationship history

    Messages, conversations, received, sent, first contact, last contact, last from them, last from you — and a median reply time that is suppressed below three samples rather than computed from one.

    All of it from your own message index. Nothing is looked up, bought or enriched: there is no broker, no social graph and no vendor being asked who this person is.

  • Instant search and scopes

    Search runs in the browser over the whole book with a cached haystack and a deferred value, so typing never blocks — no request per keystroke, and no waiting.

    The rail scopes the list too: starred, birthdays this month, missing an address, by company, by group, or by mailbox.

  • Groups and dial codes

    Groups with colours, created and renamed in place, with membership toggled straight from a contact.

    Phone numbers get a dial-code picker with a real example for the chosen country, so the placeholder shows what a number actually looks like there rather than a generic string of digits.

  • Birthday reminders

    One email a day naming everyone whose birthday it is, with ages where the year is known.

    It goes to you, never to the contact. A product that mails your friends on your behalf is a product that will eventually embarrass you.

    Delivery runs on the same background job runner as the other reminders.

Tasks

Seven states, dates you type, and notes that hold a document.

  • Seven states, rows or board

    To do, In progress, In review, QA, Done, Cancelled and Hold. Review and QA are separate because they are usually different people doing different work, and Hold is not Cancelled — one is waiting, the other is over.

    The same tasks render as rows or as a board, over the same scoped data.

  • Due dates you type

    "next friday", "eow", "in 3 weeks", "sept 15", "3d", "24h" — a grammar rather than a list of accepted formats.

    It is code-split out of the bundle, so somebody who never types a date never downloads the parser for one.

  • Six date buckets

    Overdue, Today, Tomorrow, Upcoming, Someday and Completed. Someday is the bucket for a task with no date, which is most of the ones people actually keep.

    An all-day task only goes overdue once the day is over, rather than at midnight the morning it is due.

  • Notes that hold a document

    A slash menu for headings, bullets, numbered lists, checklists, quotes, dividers, images and syntax-highlighted code, with markdown input rules as you type.

    Checklist progress is computed by the database rather than the client, nested items included, so the badge on the row cannot drift from what is in the note.

    Images in notes need the object store configured.

  • Reordering without a renumber

    Dropping a card between two others writes one fractional number rather than renumbering the column, so two people rearranging the same board at the same time do not fight over it.

    Priority uses the iCalendar 0–9 scale shown as five bands, so a value set by an import or a script keeps its ordering instead of being flattened into high, medium and low.

  • Comments and an automatic record

    Comments with an edited stamp, and an activity log written by the app rather than typed by anyone — so the record of what happened is not a matter of whether somebody remembered to note it.

    Names still resolve for people who have left the organisation.

    Assigning a task is available from the detail pane; the composer and row menus do not offer it yet.

Developers

About seventy-five endpoints, signed webhooks, and scoped keys.

  • A public REST API

    Mailboxes, aliases, messages, attachments, threads, folders, labels, drafts, scheduled sends, filters, blocked senders, forwarding, domains, webhook endpoints, contacts, groups, tasks, calendars, events, occurrences, booking links, bookings, availability, members and usage.

    Around seventy-five endpoints across forty-three route files, documented with a published reference. This page used to describe four of them.

  • Stripe-shaped restricted keys

    Eighteen resources, each None, Read or Write, with Write implying Read. Sending and Booking are resources of their own, because folding them into something broader is how over-permissive keys get minted.

    There is deliberately no wildcard or admin scope. The moment one exists it becomes the default everybody picks, and the whole point of scoping is lost.

    A key is shown once and hashed before it reaches the database, so the secret never enters a query log. Auth failures all return the same sentence; a scope failure names the scope, because that one is a programming error rather than an attack.

  • Signed webhooks

    Signed with HMAC-SHA256 over the timestamp and the raw body, with the timestamp inside the signed string so a captured request cannot be replayed later.

    Delivery is queued with backoff held in the database rather than in a worker's memory — so a crashed worker's lease simply expires and the schedule is the same schedule for everyone. Six attempts, then exhausted.

    The destination is re-checked for private and loopback addresses on every attempt, not just at registration, because DNS can be repointed afterwards.

  • The API is not a side door

    A folder or label created through the API is a real IMAP folder or keyword, so it appears in Thunderbird immediately. There is only ever one of them.

    API sends run the same rate limits, the same plan allowance, the same sanitiser and the same Sent-copy path as the composer. There is no faster, looser door for programs.

  • Private mailboxes over the API

    Private mailboxes are listed by the API and then refused, rather than hidden.

    Hiding them would make an integration report a mailbox as missing when it is simply unreadable by design — and sending somebody to debug a mailbox that is working correctly is worse than telling them no.

Settings and accessibility

Thirty-one settings sections, eighteen themes, and the keyboard.

  • Eighteen themes

    Nine hues in light and dark, tinting surfaces and borders rather than only an accent colour, plus a Match system option.

    The choice is set as a cookie so the first byte of HTML paints in the right theme — there is no flash of the wrong one. Each swatch is a miniature of the real window under that theme, so a preview cannot drift from what it is selling.

  • Accessibility as a constraint

    Contrast measured across all eighteen palettes rather than checked in one and assumed in the rest, reduced-motion honoured throughout, visible focus rings, and errors announced rather than only coloured.

    Scrollbars are drawn by the app so they belong to the theme instead of being a grey channel from the operating system.

  • Quick settings

    Layout, density, conversation style, remote images, clock, week start, second time zone, language, theme and the away switches — all from a panel beside the mailbox, without leaving it.

    The full settings surface is thirty-one sections in seven groups, with an exit that returns you to whichever surface you came from rather than to a fixed home.

  • In-app support with self-diagnostics

    A drawer that measures the mail service, the web app and each of your mailboxes — domain, DNS, the row, storage, and whether IMAP can actually open it — and colours the result with any operator notice.

    A report never carries the contents of anyone's mail. Neither does the diagnostic snapshot behind the keyboard shortcut, which copies the state of the client rather than the mail in it.

  • Keyboard shortcuts

    Command-K searches everywhere, Escape closes, C composes, Command-Enter sends, and a shortcut copies a diagnostic snapshot.

    The shortcuts sheet lists only bindings that are actually wired. A sheet that omits the obvious one reads as incomplete rather than as restrained — so the honest fix is to wire it, not to list it.

    The set is deliberately small. There is no j/k list navigation and no single-key triage, and the calendar's own five bindings are not yet in the sheet.

Portability and account

Getting mail in, getting it out, and the account around it.

  • Import and export your mail

    Import mbox and .eml — Gmail Takeout, Thunderbird, or an export from Ruber itself — into a folder you pick. Messages arrive byte-identical and marked read, so an import does not light up as hundreds of unread.

    It reports what imported and what failed rather than claiming success, and warns that running it twice duplicates.

    Twenty-five megabytes and five hundred messages per import, so a large Takeout has to be split by hand. Export is capped per folder and covers the standard folders rather than custom ones.

  • Leaving is a DNS change

    The domain was always yours and the MX record is what moves mail, so leaving is pointing it somewhere else and taking the mail with you.

    That is not a feature anybody builds — it is the consequence of not building a lock-in. It is listed because most providers cannot say it.

  • What expiry actually does

    Reading and export stay open after a trial lapses, and an expired account keeps its storage so incoming mail is still accepted. Sending is what stops.

    Locking somebody out of their own correspondence to make a sale is not a decision, it is a hostage.

  • Self-serve account deletion

    Delete the account yourself, with a seven-day grace period, a warning to the recovery address, and a countdown with a way back.

    You type your own address to confirm rather than the word DELETE — a word anybody can type without reading is not a confirmation.

    The request and the grace period work. The purge that follows runs on the background job runner.

  • Storage you can actually audit

    Six storage prefixes with their sizes, file counts, largest object and newest date, plus mail per address read live over IMAP.

    And a published list of what is not counted, with the reasoning. A usage figure that quietly excludes things is worse than one that says what it left out.

    The enforced quota currently bounds the object store rather than mail volume, so a large mailbox can read as smaller than it is.

What it does not do

Every page like this one lists what a product is good at, which is why that list tells you nothing. These are the limits, named before you find them.

  • 01

    Mail and tasks are not joined up yet

    There is no snooze, no recurring task, no subtask nesting, and no way to turn a conversation into a task. The mail surface and the task surface are neighbours rather than one thing, and anything claiming otherwise on this site before now was wrong.

  • 02

    The calendar does not sync or invite

    No CalDAV, no subscribed feeds, no .ics import or export, and no invitations — no attendees, no accept or decline, no checking whether somebody else is free. Booking links are the only path from another person to your calendar, and they run the other way round.

  • 03

    Contacts cannot be imported or exported

    No vCard, no CardDAV, no CSV, in either direction. An address book you keep elsewhere stays elsewhere for now, and the one here is built from the mail you already have rather than from an import.

  • 04

    Rules run when you open the mailbox

    Filters, forwarding, auto-reply and blocked senders are applied when a mailbox is read, not at the moment mail is delivered. A forwarding rule on a mailbox nothing ever opens forwards nothing. Providers that run rules server-side at delivery do this differently, and the difference is worth knowing before you rely on it.

  • 05

    No notifications when the browser is closed

    Notifications work while a tab is open. There is no web push, no service worker and no app to receive one — so a closed browser is a silent one. Reminder emails cover the gap where the background runner is connected.

  • 06

    There is no mobile app yet

    A mobile client is in development and is not released. There is no App Store or Play listing, and native sign-in is blocked by a captcha requirement that has no React Native implementation. The web app works on a phone in the meantime.

  • 07

    Private does not cover search, custom folders or mobile yet

    Private is open and a Private mailbox has carried real mail: enrolment, unlock, sealed send, sealed reading and receipt-time encryption at delivery are all in production, with three kinds of recovery behind them. What is not finished is the edges of reading — sealed messages open in the main folder views but not yet in custom folders, Starred or Drafts, there is no search inside a Private mailbox because searching it means decrypting it in the client first, and the mobile app still shows a sealed pane.

  • 08

    No team invitations during the beta

    An organization has the people it was created with. Inviting a teammate, changing a role and removing a member are not built, and the controls say so rather than failing when pressed.

  • 09

    Some edges are still unfinished

    Renaming or deleting a folder has to be done from a connected mail client, deleting a mailbox is suspend-only, and MTA-STS is published as a policy file without the DNS record that would make it enforceable. Each of these is a half-step rather than a plan.

All of it is in the 30-day trial — there are no features held back for a higher tier.

Start the trial

Before you ask

Questions worth asking.

The 8 that come up most. There are more behind the switch, grouped by what they are about.

Still deciding?

hello@ruber.me