The huge problem with email encryption right now is that you can't reasonably make it mandatory (as you can see, a lots of domain do not support it) so it can be easily be stripped à la sslstrip, and there is no such a thing as HSTS. (Again, please, build pinning into everything.)
So an active attacker able to MitM can simply turn encryption off, and those 99.9% make me wonder if that happened to the 0.1%...
Many services can make it mandatory, as long as you're willing to take the hit to convenience, so at least your outbound email is always protected (and you get some level of canary for inbound email).
This is usually for some compliance rule or another because they want enterprise business, so even the mainstream ones like Google Apps[1] and Office 365[2] have support for requiring TLS.
[1] https://support.google.com/a/answer/2520500?hl=en
[2] http://technet.microsoft.com/en-US/library/jj723154%28v=exch...
Sure you can, see pgp.
Really, its nice to see they are encrypting coms between each other but I don't really see how this affects me. If I want something secure I will use pgp. Email encryption, has and, always will be a client side problem. There is nothing the middle men and women can do for you that you can reasonably trust.
If google really wants to solve this problem they will make pgp features native to gmail. I'm guessing they're heading that way with the chrome extension being discussed here at the minute[1].
I highly doubt this. This sounds like wishful thinking.
As in, care to explain why you so highly doubt it? I have little more than anecdotal trends as evidence.
Yes, such schemes are leaky, as they allow the attacker to read it at any link between providers that haven't cooperated to set up a secure link. And it probably doesn't change the "expectation of privacy" issue, as the provider will be applying encryption to the plaintext, but it decreases the attack surface without requiring end user action.
I would propose creating single VPN tunnel between these corporate networks that all traffic destined for the other network is routed down. Just join individual private networks with encryped tiunnels. This would be completely transparent at the client level as the data would just follow a different path. It would avoid the startup cost of SSL or the higher CPU requirements of symmetric encryption. Such a setup could be required as a contract/tendering/supplier requirement.
Really if you have two companies that are sending data that may be sensitive why would you want any of the packets to ever be sent in plan view? Client side standards will never give a complete gurantee of that. It is much more enforcable to add the security at the network level.
The other times, it's when someone wants it not to work.