Slashdot Mirror
Ask Slashdot: Secure, Yet Accessible E-mail Archive Storage?
New submitter mlts writes: As of now, I just leave E-mail in a 'received-2015' subfolder on my provider's server, adding a new folder yearly. With the rise of E-mail account intrusions (where even though I'm likely not a primary target, but it is a concern), what is a secure, but yet accessible way to archive E-mail? I'm far less worried about the FBI/NSA/Illuminati, as I am about having stuff divulged to all and sundry if a mass breach happens. A few alternative I've considered: 1) Running my own physical IMAP server. The server would run on a hypervisor (likely ESXi), have Dovecot limited to the VPN I use, and use other sane techniques to limit access. 2) Archive the E-mail files through a cloud provider, with a client encryption utility (EncFS, BoxCryptor, etc.) In this case, E-mail would be stored in a different file a week. 3) Move it to local storage on a virtual machine, and if access is needed, use LogMeIn or another remote access item to fire up Thunderbird to access it. What would be a recommended way to secure E-mail that sits around, for the long haul, but still have it accessible? Even if you're not specifically worried about it, keeping older email around on a provider's server opens you up to warrantless access by U.S. law enforcement officials.
All that said, why are you keeping it all?
A better question is "Why delete it?" Keeping it involves near zero effort and near zero cost. If deciding what to delete takes more than a few seconds, it is not cost effective. I have every email I have sent or received for the last 30 years (except for spam) and it fits in 10 cents worth of storage. Even if you count backups and redundant copies, it is under $1. My archive has come in handy many times, including helping a third party dismiss a $150,000 lawsuit from a patent troll by documenting prior art. That was worth $1.
While I have not tried the following, I think it may be a pretty swell idea...
* Use S/MIME encryption for your encryption
* Setup a filter (could use fetchmail+procmail, or your email client's native filter stuff, or an external process in python/perl/whatever)
* On new mail receipt, get copy of email, encrypt the body via S/MIME ("openssl cms"; man cms; don't use the misleadingly named "openssl smime"), and save back to the server in a different folder.
* On all your email clients, just check that new folder only.
There may be some fudging necessary either when encrypting or when reading the email, since the emails aren't from you, so the default client behavior of using the FROM address to determine the encryption key will not work. However, you could either alter the from to your own while filtering, and backup the real from to X-From:, and update your client to display the X-From instead of the From... or trick your client into treating the folder as a sent mail folder (sent encrypted emails get encrypted by your own cert and saved to your sent mail folder already... and reading those already works).
While it may take a little bit of a kludge to get it working, once it works, it'd just work. All your emails would be separately stored on whatever IMAP server you like. You'd be able to read them via any client with S/MIME support (assuming you have your private key with you). FYI, there are browser plugins that make S/MIME work with some webmail providers too.
All the other suggested solutions I've seen boil down to:
* download to local computer
* encrypt it somehow and make encrypted backups
Those have many layers of things that are not easily accessible. I'd be more likely to go that route anyway (just fits the way I work already), but encrypting the messages within the IMAP server may be a nice solution for many other users.