VESmail
any standard email client
no plugins, no new address
Regular email
Regular email is encrypted by TLS only while
in transit between devices (blue arrows).
It sits unencrypted, indefinitely, on both the sender's and the
recipient's mail servers (red boxes) — servers neither of them controls.
VESmail
With VESmail, the message body and headers are encrypted before they
reach the outgoing server, and stay encrypted at rest on both
servers (blue boxes). The providers only ever store ciphertext.
A transparent proxy
VESmail is a stream encryptor for RFC 5322 / MIME messages, wrapped in
transparent IMAP4rev1 and ESMTP proxy servers, written in C.
Point your existing email client at the proxy instead of at your provider.
Outgoing mail is encrypted on the fly; incoming mail is decrypted on the fly.
Your provider, your client and your workflow stay exactly as they are.
Standards-preserving format
The MIME structure is kept intact: each body part becomes application/vnd.ves.encrypted, encrypted headers travel as X-VESmail-Header, and a plaintext banner part is injected so clients without VESmail still render something sensible. The format is documented in the ves-mime specification.
Run it where you want
An instance can run on your own machine, a home server, a company server,
or a cloud host. When the instance runs on hardware under your control,
encryption and decryption happen entirely on your side of the wire —
end-to-end encryption in the strict sense.
A hosted instance is also available for evaluation, with the same code
and the same encrypted-at-rest result — you trust the instance
operator instead of running your own.
Per-message keys
Each message gets a random encryption key. That key is encrypted to every recipient's VES public key and deposited in the VES repository; each recipient unwraps it with their own keychain. Message content is never visible to VES — only wrapped keys are.
Recoverable, without a backdoor
Losing a device doesn't mean losing your mail. VESrecovery™ rebuilds a lost keychain through a network of friends, without any shared master key and without any party being able to read your content on their own. The mechanism is covered by US patent 10,911,237. See The Math for the failure-odds model.
The dependency, stated plainly
The VESmail proxy is open source (Apache-2.0). Key custody and exchange use the hosted VES repository at vesvault.com — a VESmail instance needs connectivity to the VES API to unlock keys. Developer documentation for VES and libVES is at ves.host.
HideThe problem it solves
Mail clients expect a server with a real hostname and a publicly trusted TLS certificate. A VESmail instance on your laptop or home server has neither — no public IP, no domain, no CA-issued cert.
The connector
SNIF (Server Name Identification Forwarding) gives an instance a unique
public hostname with a publicly trusted, end-to-end TLS certificate —
the private key never leaves the instance, and the relay in the middle
sees only TLS ciphertext. The SNIF connector is built into VESmail.
SNIF is open source, with an IETF Internet-Draft describing the protocol.
Learn more about SNIF
Compliance audit
Encrypted email without oversight doesn't work for organizations. A VESmail enterprise instance can designate audit accounts that receive a copy of every message key, giving compliance access to encrypted correspondence. Admission is by invitation and RSVP, restricted to the enterprise's own domain, so the mechanism can't be quietly pointed at outsiders.
VESrecovery Inheritance
An admin can pre-select the recovery network that every user inherits on joining, so the organization has a robust key-recovery net from day one without depending on each user to set one up.
Hide