AI on your mail without sending it to a vendor

Every mail product has AI features now, and every one of them has a paragraph about how much it respects your privacy. Those paragraphs are all true when written and none of them is structural. A policy is a promise about what a company will choose to do with data it has.

The alternative is not having it.

What bring-your-own inference means

MailDock runs no inference service. There is no endpoint here for a request to pass through, so there is no version of this product in which we quietly start looking at your mail. When a user asks for a thread summary, the request goes from their server to the provider they configured, authenticated with their key.

That has consequences we cannot undo later, which is the point:

• We do not see the request. Not the content, not the metadata, not the fact it happened.
• Your relationship with the model provider is yours. Their enterprise terms — including whether they train on your inputs, which for the major providers’ business tiers is no — apply directly to you, without us in the middle claiming to have negotiated on your behalf.
• If you configure nothing, the features are simply absent. Not degraded, not upsold. Absent.
• If you point it at Ollama or vLLM on your own hardware and set localOnly, no request leaves the machine at all.

The trade

This is not free. We give up a bundled inference tier we could charge for, and you take on choosing and paying a provider. Somebody who just wants it to work has one more decision to make.

We think that is the right trade for this product specifically, because the whole proposition is that the mail is yours and on your machine. An AI feature that quietly routed the contents of it through us would be the one part of the system that contradicted the rest.

There will probably be a bundled tier eventually, for people who want it. It is on the roadmap and not in the product, and if it ships it will be an addition rather than a replacement — with its own DPA, because that would genuinely make us a processor and the paperwork should say so.

Two design decisions underneath

Two switches, not one. An administrator sets a per-domain policy for what is available; a user opts in for their own mailbox. Neither alone is enough. An administrator cannot switch AI on for somebody else’s mailbox, and a user cannot enable something the domain forbids. (The user’s switch is in webmail, under Settings → AI features, from 0.4.0; at 0.3.0 it was an API call made as themselves, PUT /ai/opt-in.)

The admin copilot cannot write. It has read-only tools. When it wants to change something it writes a proposal that a human approves by id. That is not caution for its own sake: an assistant grounded in your mail is an assistant reading text that arrived from strangers, and a prompt-injected instruction in an email must not be able to become an action on your server. Taking the write away is the only version of that defence that does not depend on the model behaving.

Attachments are excluded unless an administrator allows them for the domain, and no feature reads one yet. The audit log records that a feature was used, not what it was used on. Provider keys are encrypted at rest.

The full detail is on the privacy page, and the legal version is in the DPA — which says, in the section a DPA in this market usually gets wrong, that we are not a processor of the mail on your server and your AI provider is not our sub-processor.