Security

What we can reach, how it is logged, and how you take it away.

The short version

  1. inbox.camp never holds a credential to your mail server. The server's administrative password is generated on the server itself, stays there, and is mirrored only into your own AWS Parameter Store. Our database records that it exists, not what it is.
  2. Every command we run on your server is in your own logs. We reach the server through AWS Systems Manager, never SSH. Your Run Command history and CloudTrail show each script, verbatim, when it ran and what it did.
  3. Revocation is one deletion. Our only path into your account is one IAM role created by one CloudFormation stack. Delete the stack and we are locked out instantly. Your server keeps running.
  4. The policy is published. The exact permissions the role grants are in the template you deploy, with a comment on each statement saying which step needs it.

What lives where

In your AWS account: the mail server (an EC2 instance running the open-source Stalwart mail server), its disk and hourly snapshots, an S3 bucket holding every message body (versioned), your SES identity and a send-only SMTP user scoped to your domains, your Route 53 records, and the one IAM role.

In ours: your organization's name, your users' addresses and group memberships, the configuration you set in the console, operational events, and a heartbeat your server sends us every minute (version, queue depth, disk usage). No message content, no subject lines, no passwords, no server credentials.

In your browser: the webmail is a static page served by us; it talks directly to your server over the JMAP protocol. Your mail never transits inbox.camp, not even while you read it.

What we can do, honestly

In the standard deployment we operate your server the way a managed service provider would: through a role you created, limited to the published policy, with every action logged in your account. That means we can run commands on the server. It is how we provision, migrate, back up, upgrade, and fix things at 3 a.m. Organizations that cannot accept any standing access can ask for the enterprise deployment, in which no role exists at all and an agent on your server pulls its tasks from us over an outbound connection.

Backups and recovery

Snapshots of your server's disk are taken hourly and kept for two days, and daily and kept for thirty, in your account, by AWS Data Lifecycle Manager. Message bodies live in a versioned S3 bucket. If your server fails, it is relaunched with its own disk; if the disk is gone, from the latest snapshot. Mail sent to you during an outage is held by the sending servers and delivered when you're back; that is how SMTP works.

Migration

Your WorkMail mailboxes are copied by a small program running on your own server, from WorkMail's IMAP interface to the new server, with the credentials kept in your AWS account. We count what arrived before we let you switch your MX, and switching is a button you press. The previous MX value is recorded so it can be put back.

Deliverability

Outbound mail leaves through Amazon SES in your account, so recipients see Amazon's IP reputation and your domain's authentication: SPF (aligned through a custom MAIL FROM), DKIM signed by both SES and your server, DMARC, MTA-STS and TLS reporting, all published for you. Inbound mail is checked for SPF, DKIM and DMARC and spam-filtered on your server. TLS certificates come from Let's Encrypt and renew themselves.

What we are not

We are not a mail provider. We do not run your mailboxes on our servers, we do not hold your mail, and if we disappeared tomorrow your server would keep receiving and sending mail exactly as before. That is the point.

Questions from your security team? Get in touch or email security@inbox.camp.