My email is not secure, for a number of reasons. Here are a couple.
1) I have yet to find anyone willing to accept email from me that has been encrypted before I send it and must be decrypted by them (GPG for example).
2) It is stored in plaintext on a server I do not control (I send it to someone who uses one of those big hosts like Google, Yahoo, etc).
Sending it over the wire in plaintext is probably being less of an issue now (as it seems the most used hosts are doing TLS), but that doesn't really help with bullet #2.
I think the best bet is attempting to communicate with others using some other application that is not email based (like textsecure for example). Not sure how to get regular email from corporations via another means though (monthly bills for example).
"Sending it over the wire in plaintext is probably being less of an issue now (as it seems the most used hosts are doing TLS),"
Unfortunately, no, TLS in the SMTP world is basically a joke, security-wise. It can inconvenience a passive interceptor, but crumbles in the face of an active adversary, due to the fact that $NOBODY does cert checking, and consequently, nobody can do cert checking, because it would break their mail server, because nobody does cert checking properly.
I've been thinking about experimenting with enforcing cert-checks on incoming tls/smtp. Possibly with a plain text smtp mx as fallback (through some kind of try-again-later greylist-like magic).
Providing a fallback would negate the security benefit, obviously -- but might gather enough data for a whitelist (ish) of servers/sending domains which we can demand valid certs for.
I'm not too concerned about bouncing valid email, as long as it doesn't create loops. Nor am I that worried about missing emails.
As long as all the senders are a) mailing-lists that either should do the right thing, or will actually change to do the right thing if an error is reported, b) big free services like gmail/yahoo/outlook that might be divided into groups of "does the right thing" and "blacklist"/bounce to let any friend know that they need to send from "free service y, not x" -- and c) friends that run their own email servers and can be beaten (eh, educated) to compliance.
I'd really not like to rely on some random CA list, though. I'm personally a cacert.org-fan/user -- but I suppose one might try to lean on DANE to avoid that particular hairball -- to some extent. It's either that or manual whitelist+trust on first use/some kind of pinning.
One of the biggest security gaps in SMTP is that failing to establish TLS will result in falling back to plaintext; it's opportunistic TLS. Senders and receivers don't perform path validation because a validation failure will not stop a message from being sent -- it will just be sent with plaintext.
The missing piece is widespread support for a way for receiving mail servers to declare that they support TLS (and optionally identify their CA or pin their certificate), such that it will instruct senders to connect with mandatory TLS instead of opportunistic TLS. With a protocol like this in place, senders can begin performing path validation of the receiver's certificate when they connect, but only for receivers who declare it, allowing an incremental nonbreaking rollout. Once widespread support is in place, we can begin making an effort to require validated certificates.
I'd be interested to chat with anyone about email security and ideas to improve it; feel free to reach out. I would gladly put my support behind and implement a proposal that will solve these problems.
You do realize the entire internet is run on servers and network devices you do not control, right?
A bunch of intermediary relay mail servers of course all store and forward your mails. But there's also a couple dozen firewalls, traffic shapers, tunnels, bridges, routers, and managed switches that all have your e-mail. Who cares about disk storage when your e-mail is stored in 15 network device caches?
Mail has never really been secure, from the days of Incan relay runners passing messages across thousands of miles, to the Pony Express, to the current US postal service. Unless you put an encrypted letter in your envelope, it can (and regularly does) get intercepted by malicious actors. We've gone this long with it being insecure, so I don't see what the big fuss is with the internet all of a sudden.
Also: mail should be easy and universal. That's really the point of mail: that you can send a message to anyone, anywhere in the world, with one system, and it just works [while remaining inexpensive]. Anyone messing with it should always keep that in mind.
Maybe you commented after the title changed? Original title was "How secure is your email? here's email-in-a-box" (at least that's what I remember it was).
My comment was basically "email is not secure." I think we agree on that point.
Yes. I guess I was just (badly) making the point that since it's impossible to just communicate with one server you control, a secure mail paradigm should include servers we do not control.
On Linux, http://recoll.org can provide the full-text search function, but you'll need other programs to consolidate the email and import/export between cloud services.
I'd like to use this, but AFAICT there's no way for me to ensure that the app--or future updates to the app--don't send my private keys off to a third party. Even accidentally, say as a debugging core sent on crash
1) I have yet to find anyone willing to accept email from me that has been encrypted before I send it and must be decrypted by them (GPG for example).
2) It is stored in plaintext on a server I do not control (I send it to someone who uses one of those big hosts like Google, Yahoo, etc).
Sending it over the wire in plaintext is probably being less of an issue now (as it seems the most used hosts are doing TLS), but that doesn't really help with bullet #2.
I think the best bet is attempting to communicate with others using some other application that is not email based (like textsecure for example). Not sure how to get regular email from corporations via another means though (monthly bills for example).