Purelymail is currently under maintenance for the next
. Learn more.
Note: Our documentation pages are a work in progress! If you can't find the answers you need, please email us to let us know. We'll be happy to answer your questions.
It's very important that we keep your email secure. Nobody but you should have access to your data.
This article is intended as a reference to what Purelymail does to accomplish that. It does not go in depth on our architecture or attempt to deeply explain security concerns in general; we're working on a forthcoming blog post that will tackle those issues.
How we keep your email secure
- All data is encrypted at rest
- "At rest" means any permanent storage, excluding short-lived access through RAM or cache
- Email content is encrypted with your password, meaning that even we can't read it without you supplying your password (if password recovery is disabled)
- Note that partial message content may be recoverable from search indexes without your password, which can be disabled
- All protocols (IMAP/SMTP/POP), webmail, and admin pages are SSL enabled
- This means connections between your computers and ours are confidential and secure
- Mail delivery uses SSL whenever possible.
- Passwords are encrypted at rest
- We store separately derived hashes for encryption and authentication
- We support two-factor authentication. This adds an extra layer of security to logins.
- Good security practices. This includes blocking unnecessary ports, frequent security updates, resource isolation where possible, and maintaining a minimal attack surface.
- We try to collect as little data as possible. After all, we don't need to secure what we don't have.
- Billing information is handled by the professionals at Stripe and PayPal. We never have access to it.
- Physical security through AWS
- We host our servers through Amazon Web Services, which secures all physical machine access better than we ever could.
- See here for an overview of AWS security practices.
How we'll improve in the future
- Webmail specific settings including e.g. contacts could be password-encrypted.
- We need to develop ways around some email protocol limitations:
- IMAP and SMTP protocols currently send your password to our servers unencrypted (although confidentially over SSL).
- For IMAP, message decryption currently has to be done on our servers.
- S/MIME encryption of your delivered emails. This will be optional as it may be inconvenient, but could allow fully encrypting email messages after delivery with our servers never needing or being able to decrypt them.
What we don't do
- Serverside end-to-end encryption at time of delivery. Our forthcoming blog post will explain why not; the summary is that it's not well-suited for email as a protocol, only works in rare circumstances at best, and introduces serious practical considerations. You should use an email client that supports S/MIME or a different application entirely like Signal if you need this.
About data deletion
- During our beta period, we retain backups of deleted email messages for one month. This includes original undelivered messages. We do this to prevent data loss from any mistake or accident on our part.
- We delete all system logs older than one month. These logs generally only contain event information and metadata.