> Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase.

That doesn't have anything to do with whether it stays encrypted once it's sitting on the client device. You don't know that an email client isn't fetching the encrypted email, decrypting it, and then storing it in plain-text on the device. And there's nothing in the protocol that forces them not to do that.

You might want them to store contents encrypted on the client device, you might think it's best practice for them to do that, but you don't know that client will do that.

> They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to.

They're not going to do either of those things, it's like asking if I'm more likely to swim the Pacific or the Atlantic ocean. Neither scheme actually works in practice for a mass communication platform. People do not use email asynchronously, they treat it like long-form text in a messaging client, the same way they treat SMS or Signal or Element or whatever.

----

There's nothing special about email that means people are more likely to use a passphrase every time they want to access it on their phone. And even if they did (which they won't), there are risks other than client device access that forward-secrecy protects against. "On the network" in this case means that your encrypted emails are getting stored on a server that can be either compromised or accessed with a warrant. It is not true that the only way to gain access to E2EE archives is through the client device itself.