It is misleading to call email a plaintext protocol, because most email operations are encrypted in current practice (same as web browsing, despite HTTP 1 being

It is misleading to call email a plaintext protocol, because most email operations are encrypted in current practice (same as web browsing, despite HTTP 1 being a plaintext protocol). SMTP (the delivery email protocol) began supporting encrypted transport in 2002, which means that for over a decade most email has been encrypted in transit [5] (as well as during retrieval, because of POPS/IMAPS and HTTPS-secured webmail). The method is TLS (same protocol used by HTTPS, all of our web browsing traffic). Competent mail servers and services, such as exim [1] and GMail [2], let you choose to abort delivery if the destination server does not support encryption (or, since you are concerned about state actors, if there's a STARTTLS-stripping server in the middle). Furthermore, DANE [3] and TLSA [4] can be used (requiring DNSSEC to be set up for the domain) to bind a mail server record to a specific TLS certificate, further reducing meddling opportunities by state-level actors and allowing a "we do allow insecure mail delivery, but since this destination has DANE it is implied they have TLS and we will fail delivery if TLS cannot be established with this destination with the DANE-specified parameters". [1] https://www.skytale.net/blog/archives/32-Outgoing-TLS-verification-in-exim.html https://www.skytale.net/blog/archives/32-Outgoing-TLS-verifi... [2] https://support.google.com/a/answer/2520500?hl=en https://support.google.com/a/answer/2520500?hl=en [3] https://www.rfc-editor.org/rfc/rfc6698 https://www.rfc-editor.org/rfc/rfc6698 [4] https://www.rfc-editor.org/rfc/rfc7671 https://www.rfc-editor.org/rfc/rfc7671 [5] https://www.eff.org/deeplinks/2020/04/winding-down-starttls-everywhere-project-and-future-secure-email https://www.eff.org/deeplinks/2020/04/winding-down-starttls-...