Designing Trust Boundaries in Self-Hosted Webmail

Calling Veda Mail a mail server would blur responsibilities that the architecture keeps separate. The provider remains responsible for domains, mailboxes, message storage, and mail protocols. Veda Mail connects through the included Stalwart JMAP adapter or the standard IMAP and SMTP adapter, then presents inbox, reader, search, compose, reply, star, archive, and delete flows to the member.

That separation makes provider independence a concrete design constraint. UI components do not need to know whether a mailbox is reached through JMAP or IMAP and SMTP. Provider-specific behavior stays behind a server-side adapter, where another provider can be added without redefining the member experience.

Browser -> Veda Mail -> provider adapter -> existing mail server

Veda Mail owns the webmail experience; it does not pretend to own the organization’s mail system.

A fresh deployment begins with a one-time setup wizard protected by an installation token. The operator creates a distinct administrator account, configures organization and product names, chooses branding, supplies provider endpoints, and lists the email domains whose members may sign in. Once completed for that data volume, setup is locked and later organization or provider changes move to the administrator area.

Administrator authentication and member mailbox authentication are separate. The administrator can enable authenticator-app two-factor authentication and receives one-time backup codes. Members can also use provider-independent authenticator 2FA with backup codes. A setup token is neither an administrator password nor a recovery credential, and the administrator recovery token is separate again. Giving each secret one job makes the operating model easier to reason about.

White-label controls sit inside the same administrative boundary. Organization name, product name, logo, primary and accent colors, allowed domains, provider configuration, and an optional repository link can be managed without giving members access to deployment controls.

Member sessions use opaque HttpOnly cookies. Mailbox passwords do not enter browser storage, and provider credentials are held only in process memory. The persistent data directory stores installation state, the administrator password hash, a random session-signing secret, branding, and protected provider configuration; it does not store mailbox messages or member passwords.

Enabled authenticator secrets are encrypted, while backup codes are stored as salted digests. Sanitized HTML mail removes scripts and remote images before display. These choices do not make webmail risk-free, but they define where sensitive material is allowed to exist and remove several unnecessary places where it could linger.

The in-memory member credential model has an operational consequence: restarting the process signs members out. That is an explicit tradeoff rather than a hidden failure mode. The current deployment guidance is to run one replica unless a shared encrypted session repository and distributed rate limiter are added.

A production Veda Mail deployment requires a public HTTPS origin and an allowlist of provider hostnames. Proxy trust stays disabled unless the reverse-proxy deployment meets the documented requirements. The supplied Docker and Compose paths make the application repeatable to deploy, but the operator still has to configure the public boundary, provider endpoints, secrets, backups, and upgrades deliberately.

The setup token proves that the person claiming a fresh installation can read its deployment secrets. It remains secret even after setup, although the installation lock is authoritative. The separate recovery token is accepted only by the documented interactive container recovery command, never by a public HTTP endpoint.

We think self-hosting is strongest when it exposes responsibility instead of erasing it. Veda Mail makes clear which system stores mail, which process temporarily holds credentials, which volume contains configuration, and which operator controls the public origin. The result is not “mail infrastructure in one click.” It is a focused webmail layer with boundaries an organization can inspect.