A slightly less extreme position would be "Don't use email for anything where encryption is required; email encryption should happen transparently; users should

A slightly less extreme position would be "Don't use email for anything where encryption is required; email encryption should happen transparently; users should assume that their email (or at least its metadata) is or will be unencrypted". I think that position is at least as defensible as the alternative being offered, which is effectively "Always use a messaging system where the apps and servers are controlled by a single entity that you have to trust will never release compromised apps or log your metadata (and you don't mind giving your phone number to)". Anyway, transparently encrypted emails look something like [0], and the metadata problem could be largely (but not perfectly) solved if email providers offered a switchboard@recipient.tld address which Alice could send emails to (with the actual bob@recipient.tld hidden inside an encrypted email payload, so that the MTAs between sender.tld and recipient.tld couldn't read that the email was intended for Bob). [0] https://autocrypt.org/ https://autocrypt.org/