Data Security Overview
Explanation of security in Mailsphere.
- “Customers” are the end users of Mailsphere, and not resellers/service providers
- A customer’s Email servers may of course be hosted by resellers/service providers
- There is often confusion about SMTP over TLS, vs STARTTLS (see below). Mailsphere supports both modes, though be aware when Exchange refers to TLS, it is really referring to STARTTLS.
Confusion around the different terms SSL, TLS and STARTTLS:
SSL and TLS both provide a way to encrypt a communication channel between two computers (e.g. your computer and our server). TLS is the successor to SSL and the terms SSL and TLS are used interchangeably unless you're referring to a specific version of the protocol.
STARTTLS is a way to take an existing insecure connection and upgrade it to a secure connection using SSL/TLS. Note that despite having TLS in the name, STARTTLS doesn't mean you have to use TLS, you can use SSL.
Security of routes in and out of Mailsphere.
On Boarding Existing Email
Part of the onboarding process is to import existing emails from current mail system (e.g. Exchange).
To do this, Mailsphere provides a tool that is run on the customer’s system and connects to the Exchange Webservices (EWS) locally extract emails which are then passed over HTTPS to Mailsphere.
The customer has complete control over this tool. Credentials do not leave the customer’s network. The EWS services do not have to be exposed to the internet.
Exchange User Syncing
Mailsphere provides a simple Powershell script that can be run on clients Exchange servers to synchronise mailboxes with Mailsphere.
This script runs locally on the users servers and uploads the results to Mailsphere via a secure web service.
- Connections are HTTPS with a valid certificate
- Per-customer API credentials
- The credentials should be kept safe by the customer
- These API credentials can only do the following:
- Create new Mailsphere user
- Add an email address to an existing Mailsphere user
- Mark a Mailsphere user as “archived” [not deletion and fully reversible]
- The API credentials can only act on users in the customers’ organisation
- The API credentials can be revoked on the web portal at any time
Mailsphere supports Microsoft Exchange journal emails. These are reports containing original emails, and are used to allow archiving of internal emails.
- SMTP over TLS is supported by Mailsphere
- Mailsphere can be configured to reject and/or warn about journal emails not using TLS
- Authentication is done by customer IP address: Mailsphere will reject any journaled emails not originating from the correct IP address.
Email Routing From Customers
This covers the case when a user at a customer domain sends an email to an external email address. In this situation, Exchange sends to us and we forward onto customers.
- TLS over SMTP is supported by Mailsphere
- Mailsphere can be configured to reject and/or warn about incoming customer emails not using TLS
- Mailsphere will use TLS wherever available in the onward delivery...
- ...though this is completely dependent on destination mail servers
- Authentication is done by customer IP address: Mailsphere will reject any incoming emails not originating from the correct IP address.
Email Routing To Customers
This covers the case when an external email address emails a customer. In this situation, we receive the email first and then forward it onto the customer’s mail server.
- Mailsphere supports TLS for incoming emails...
- ...but we do not force senders to use it
- Mailsphere will use TLS for the onward routing to the customer when available
- ...but it is up to the customer to configure their Exchange server to support this
- Mailsphere can be configured to reject and/or warn about onward to customer emails not using TLS...
Mailsphere Operational Security
Explanation of the security of Mailsphere in deployment.
Mailsphere user access is strictly controlled
- Mailsphere Admin credentials kept very secure
- Strong randomly generated password held in a password protected form only by key named users
- 2nd Factor authentication employed throughout
- Developer/Sysops users have limited access to system
- e.g. sysops users can restart compute instances and fix networking issues but cannot read live databases or archive
- e.g. developers only have access to test systems
- Servers use special credentials to access core systems
- Periodic renewal of passwords and security keys
- All credentials held by users/servers can be revoked at any time
- Strict network based firewall rules
- Non internet facing components of the system are kept in private subnets
- All back end systems (databases, file stores) use strong passwords and TLS
- Even servers running inside our private subnet require these credentials
- Ensures safety from local network attacks
- AES-256 at-rest encryption for all archived data