You're very correct about the various terrible fallbacks. In some cases your own email client, totally capable of "E2E" encryption, might send out letters unenc

You're very correct about the various terrible fallbacks. In some cases your own email client, totally capable of "E2E" encryption, might send out letters unencrypted (against our explicit request) without a warning! However I don't think all of email's current use-cases have to be covered perfectly with each attempt at an improvement to achieve a meaningful increase in integrity or confidentiality. This is also why I really wish these issues are kept as separate as possible. Am I wrong to assume that our difference in perspective is how absolute of a confidentiality we're trying to achieve? The level I think you're describing is very difficult if not impossible even with the best we have right now. However I don't think that should be a showstopper. I also disagree on the part about a "wholly new email", it's not really practically achievable. Email is very unique in the sense that it's a massive ecosystem, but the components are really rather independent. Say if clients did S/MIME well we wouldn't have to care that much about MTA-STS for example, we absolutely should, but we wouldn't have to. A bit of a tangent, but something like letter-strict-transport-security (LSTS) would be totally doable, we could add a header that makes email clients add additional safeguards against potential downgrades. "The letter you're trying to forward was requested to be kept confidential, are you sure you want to send it unencrypted to this recipient x?" After a decade passes we'll probably have a lot of clients that prevent basic mistakes.