Considering that STARTTLS is still optional and most MTAs don't implement it, what value is there behind storing the mail encrypted? Because governments are storing every email anyways, when they want to get to my data, why would they bother asking you to decrypt it for them (which you can't) instead of just looking at the SMTP communication between $OTHERSERVER and you.
With a very high likelyhood, that SMTP communication is unencrypted.
Of course $EVILGUY might have encrypted their message before sending it, but then you can't help the government anyways.
IMHO, as it stands currently, encrypted mail storage provides a false sense of security.
The problem is that only the body is encrypted. Who you are communicating with (and in term, who they are communicating with) is at least as sensitive as what you are writing.
But that's a different problem though, it exists outside of email. The meaning of "who you are" changes depending on how high/low you're on the OSI stack: sometimes it's 00:C0:C1:A4:C8:29 or 60.56.228.48 and sometimes it's anon2342foobar@yahoo.com
If they're wiretapping everything, there's no way for you to hide the fact of a communication taking place, but at least you can protect the data itself using client-side encryption.
> If they're wiretapping everything, there's no way for you to hide the fact of a communication taking place, but at least you can protect the data itself using client-side encryption
No, you misunderstand. With S/MIME, the email headers are not encrypted. This means someone can go to your email provider, get all your emails, and even though these are all S/MIME encrypted, build a nice graph of who you are communicating with, how often, correlate with significant dates, see the subject of each letter, file names of attached files, etc.
Here's an idea: public mail pools. The entire email message is encrypted and randomly routed to one of many addresses. Each customer downloads all the messages from all the addresses in the pool. You try to decrypt each message, and the ones that decrypt are (obviously) yours. The rest belong to someone else.
To make life tougher on spies, add fake email messages to the pool regularly.
Is it really true that most MTAs don't implement it?
Looking through a bunch of random emails of mine (on gmail), I see version=TLSv1 somewhere in the headers, which I thought indicated that STARTTLS was being used. Am I wrong about this? Or is there some intermediate MTA that might not be using TLS in this case?
Could very well be. You can try and check all Received:-Headers, but there's no obligation that the MTA actually has to write whether TLS was used, nor can you be sure that the MTAs aren't simply adding some TLS string without actually having used TLS. Of the big email providers, only Gmail supports TLS.
Of course a system such as this will not provide you with foolproof protection against any adversary ever. If that is what you need, email is not what you're looking for, period.
But there is in fact an enormous difference between the proposed system and traditional email hosting. With traditional email hosting, all it takes is one FISA rubber stamp, one hacker gaining access to the mailserver or any of its backups, one rogue or compromised employee to access the entire history of every email you have ever received or sent.
In the proposed system, assuming it is properly implemented, the only way to snoop on your emails is tapping the line between the local and remote SMTP server, easily prevented if both parties use SSL. The system could even, based on the user preferences, warn about this ("Warning: this email was not delivered via SSL, it could thus have been intercepted while on the wire") or block incoming/outgoing SMTP entirely if the remote party doesn't support SSL.
It's not a solution against (government) snooping per se, especially not a solution against a party such as the US government specifically targetting you. But it is a defense against half of the world population's email history indefinitely being stored in your friendly neighborhood NSA facility.
What about 1) requiring STARTTLS, 2) encrypting incoming mail that isn't already encrypted, using the customer's public key. The message then cannot be decrypted by anyone but the customer. (The customer experience is that all the messages they download are encrypted.)
With a very high likelyhood, that SMTP communication is unencrypted.
Of course $EVILGUY might have encrypted their message before sending it, but then you can't help the government anyways.
IMHO, as it stands currently, encrypted mail storage provides a false sense of security.