Ask Slashdot: Secure, Yet Accessible E-mail Archive Storage? 74
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.
pop3 to local machine, then backup (Score:5, Insightful)
Pull it down to your local machine either via pop3 or just moving messages from your imap inbox to a local folder.
Then whenever you like, archive that off somewhere. You could even convert maildir format to mbox and then run something like mhonarc on it to make web pages of 'em all wtih indexes and such, and just archive off the HTML onto a CD/DVD/whatever.
All that said, why are you keeping it all? I've kept all of my work related email for 18 years now (same employer) on my local machine. I've gone thru a few things more than a year old just for giggles, and one time I needed a license number that was locked up in a filing cabinet but didn't have my keys that day... But mostly an email that is 2 months old or older just isn't needed (by me, for my work, your needs probably vary).
Re: pop3 to local machine, then backup (Score:1)
You're assuming it is actually deleted from the server.
Newb.
Re:pop3 to local machine, then backup (Score:5, Interesting)
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.
Re: (Score:1)
Keeping it involves near zero effort and near zero cost.
Huh? Keeping it seems to be sufficiently problematic to warrant an "Ask Slashdot". That doesn't sound like "near zero effort" at all.
Re: (Score:2)
Re: (Score:2)
Because the moment you decide to put a low power home server (say a sub 20W mini-ITX device) on your internet connection always on access to all your email becomes trivial that why not?
The combination of dovecot, fetchmail, roundcube and z-push running on top of CentOS is a tough combination to beat. Of course you might want to run a calendaring server as well.
Once you are down this path how about a Plex or Emby server; actually handling DVD's or BlueRays is for suckers :-)
If you don't fancy building it all
Re: (Score:2)
All that said, why are you keeping it all?
I keep every email sent and received (excluding spam) on a local Dovecot server. It's a wonderful resource. Every event important to me ends up in an email to somebody. I use the archived emails in lieu of a journal or diary as an effortless way to record my personal history.
Re: (Score:3)
Print it? (Score:1)
On paper
Local! (Score:5, Informative)
Back it up locally and encrypt the backup on an external drive.
then, either lock that in a safe-deposit box, have a friend hold it, or hide it in some random but physically secure location. A fire-proof safe in your basement would work.
It is the only way, if any still exists at all
And yes, I like to have access to 1990's emails sometimes. Or need to. The world does not need to see them. BTW, law enforcement, under USA PATRIOT or CISA or some court ruling, do not need a warrant to read any email older than one year.
Re: (Score:1)
Keep in mind that most Emails are sent unencrypted. Even when it is encrypted, it does not stop the remote side from storing it without encryption (or with a decryption key that is readily available on the same system). Although you can go crazy with security on your local side, if your remote side has no security all that info may still be compromised.
Think carefully about your trust model and how you use Email. If the contents of your Inbox is really that sensitive, then perhaps you should not be using pu
Re:Local! (Score:4, Interesting)
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.
Re: (Score:2)
So let's be reasonable. Encrypt when needed, and take reasonable precautions, but don't make yourself a target.
If you only encrypt** that which needs special precautions, then you're making it EXTREMELY easy to target the messages that are important.
If you're going to encrypt, encrypt everything. This advice is also good for things like vpn use, proxy use, tor use, etc.
** ... or do anything out of the ordinary, like deleting it, or moving it to a different folder, or only downloading those messages, etc.
None of your bullet points are a negative to S/MIME use. The only edge case one is that the NSA may hold all your
Re: (Score:2)
It is a good idea, but for transport encryption, S/MIME should be used between clients, or even better, PGP/GnuPG because it isn't relying on a root CA key for security.
For DAR (data at rest), I have done complex setups in the past which have bitten me in the rear more often than not... these days, I wind up using gnupg for files, EncFS for directories, VeraCrypt for file based drive images, and the OS's native block encryption (BitLocker, FileVault, LUKS) for physical drives.
Long term, I should consider se
Re: (Score:2)
That doesn't matter as much as you may think.
Of course, the people are having a copy of my mails. But when somebody searches my mails at my provider, they have everything concerning me. When they need to search the recipient/sender mailboxes, they have to search hundreds of mailboxes. And they need to know, whom to search. Without a copy of the mail in my mailbox or addressbook (online) its hard to know.
Using an Archive on a cloud provider... (Score:4, Informative)
... is just INCREASING your attack surface, not reducing it! I'd go with the local backup if I were you.
Re: (Score:2)
Re: (Score:2)
I dunno... ask Kim Dotcom. Is it really a reliable archive if it disappears overnight? If the online host is the ONLY place you keep your archive, then it's really not anymore secure than keeping it at your house... and for the record, I've lost more data to belly-up hosts than I have to house fires and bad drives, so statistically speaking, my house is more secure. Granted this is just one data point, but who knows... maybe OP has had a lot of house fires or something.
One other point I'd like to make, i
If it's ever touched a major provider's server (Score:1)
Expect it to be indexed and viewable at will by the United States or just about any other modern Western government. It doesn't matter if it's "archived" there or not, it's archived there. Once it hits a server and gets replicated for backups and redundancy, it exists forever. Deletion does nothing. A log is kept (even if it's just in the backups) of every email, chat, IM, SMS, etc. you've ever sent or received. You can bet on it.
Re: (Score:2)
One feature of M$ Lookout is it's built in VTP (virus transport protocol). And it is very effective, from what i've been told.
Run your own IMAP server (Score:5, Insightful)
Get an email account with any domain provider, and set it up to forward to your private server. Read mail by connecting to an account on the private IMAP server. No need to run your own SMTP server; outgoing mail can be handled by your domain provider.
Problem solved.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3)
And I'm sure your domain provider is happy to pass a copy over to the NSA.
It's pretty hard to send a fucking email without using the network, but luckily that's not the threat model being discussed. If you want to keep email secure from network surveillance, you encrypt it. If you want to reduce vulnerability to a storage breach, you store it locally.
Hillary is that you? (Score:4, Funny)
Re: (Score:2)
modern filesystems have no 255 char limit.
My "solution" (Score:4, Informative)
My ISP (Comcast) won't allow me to run a fully functional mail server due to so many ports being blocked so I host my domain/mx record at Google for your Domain (got a free account way back when). I then have Thunderbird running 24/7 alongside my home mail server, automatically sucking down new mail from my gmail account and putting them in the inbox of my own server. I still have to periodically go and delete all mail on gmail because I've not figured out how to automatically & permanently delete them (or sent mail) from an IMAP client. I also use Google's servers as a smart host for outbound mail, so when an email client it setup to send/receive mail to my server, it all works, just on alternate ports. TLS all around.
So.... there's a limited amount of my email sitting in gmail trash at any given moment, while I have access to all of my email on my own server via imap on all of my devices.
It was the best I could come up with on my very low budget. I do it less from a fear of google/government snooping (though that bothers me) than from a fear of hackers getting into my gmail account. My own server is a much smaller and more obscure target...
money (Score:2)
you could set up journaling locally. decent solutions exist to dedupe compress and encrypt.
The Only Safe Place (Score:2)
Archive Software (Score:1)
Re: (Score:1)
Re: (Score:2)
--I looked into that, downside is that it seems to be Windows-only. Would prefer a Linux-based solution because MS/Windows "as we know it" may not be around 5 years from now**. Piler software looks interesting.
/ **although don't get me started on Linux+ systemd, that's a whole other gripe
Re: (Score:1)
Ask Hillary (Score:1)
Monica's ex-boyfriend's wife can tell you how to do this.....
Re: (Score:2)
Own IMAP server (Score:2)
As some others recommended, I use my own IMAP server – both for holding my complete mail archive (I once used the aid4mail tool to transfer my mail client based archive from Thunderbird to the IMAP server) and for continuously receiving (fetching) current e-mail from every active mail account I have. It is the one point of access for my email, whether I'm at home or on the road, from whatever device, and I have access to every single mail I have ever received or written (and not discarded...) from whe
Thunderbird Local Folder (Score:3)
I personally store archives emails in a local folder in Thunderbird on my primary workstation.
I then have it backup regularly to a secondary ("backup") drive installed in the system.
From there I have the backup drive encrypt and sync to a backup server (in a vm on a dedicated box) I have in a datacenter for disaster recovery.
Thunderbird automatically creates an Archives folder, with sub-folders of each year, when you use the "Archive" button.
Works for me. YMMV.
My own solution (Score:2)
I have my own domain which I host at zoho.com for free since I only need one account. I only use that for incoming mail and spam filtering. Anything I want to keep I transfer over to the IMAP server that's running on my Synology NAS.
UNIX mail spool files will be accessible forever (Score:2)
Just keep standard UNIX mail spool files locally, if you're worried about it.
Also, a mail server is not physical if it runs under a hypervisor, unless you physically have the box that runs both in your possession. You'll all see - hypervisors will be shown to be manipulated by cloud providers and/or TLA agencies to extract data from virtual machines without the virtual machines' admins knowing anything about it.
Re: (Score:2)
I should have been a tad clearer in my post. The machine would physically sit at a location I (hopefully) control, so it would be in my physical possession. The reason for a hypervisor is so that the VM used for stashing archived mail would be able to be passed from bare metal to bare metal install as time goes on, without need to rebuild the system. It makes backups easy as well, where I just power the VM off, plug a USB drive into the host, mount a VeraCrypt volume, export the VM as a .OVA file, dismou