Interestingly, this is another security issue with STARTTLS. The whole concept of first establishing an unencrypted connection and only then upgrading to encryption is fragile in multiple ways.
Admittedly, this is a pet peeve of mine, as I've co-authored a paper about it. I wonder why mailbox.org does not recommend that users switch from STARTTLS to implicit TLS for SMTP/POP3/IMAP, as this would mitigate such issues more generally. This is also in line with current RFCs (RFC 8314).
Thank you for writing this, I use it as a reference when explaining the difference STARTTLS and implicit TLS and why people should choose one over the other.
Another nice one is that implicit TLS is SNI routable (and thus much easier to route) -- this is the main reason for me, and I wish the standard had been updated to encourage more people to try 465 (or have a way to specify port in DNS records for example). Huge missed opportunity.
It's not just explicit vs. implicit TLS that's an issue with MUAs. Assuming good implicit TLS configuration there's still no proper way to harden such connections against an active MITM - we don't have an usable MUA-STS standard.
Admittedly, this is a pet peeve of mine, as I've co-authored a paper about it. I wonder why mailbox.org does not recommend that users switch from STARTTLS to implicit TLS for SMTP/POP3/IMAP, as this would mitigate such issues more generally. This is also in line with current RFCs (RFC 8314).
https://nostarttls.secvuln.info/