While what you're saying is how it may play out in practice (which is, I argue, the case for any closed-source client), it's not necessary when using threshold

While what you're saying is how it may play out in practice (which is, I argue, the case for any closed-source client), it's not necessary when using threshold encryption; you can construct an encrypted message such that K out of N keys can be combined to decrypt the ciphertext. If those public keys are on the client, it does not require the message to be sent to a trusted server. mtgx's comment points to some practical implementation and logistics issues, though. Never mind how one would handle key revokations... --- In case of the main article, though, that's irrelevant, as an e-mail provider necessarily has access to each unencrypted e-mail as they deliver them to and from the user. I can see it being the least bad way to log messages (if they would need to do so). Rather than logging in cleartext, or encrypting with a single key, it could be a threshold encryption where, say, more than one entity inside law enforcement/high court/etc are required in order to decrypt intercepted traffic. I think our learned instinct has become to say "yeah, would be nice but good luck making anyone implement that"... But why not?