Email is sent via a protocol called SMTP.
SMTP goes over port 25 between major senders (there are other ports but forget that for now).
Since it uses a single port, you can't distinguish between encrypted and plain text communication until you know each end supports encryption. A dated philosophy but people don't upgrade their email servers as often as they do their web browsers so it made sense at the time.
Since the plain text receiving server says "yes I can do STARTTLS", this is easy to man in the middle intercept and say "no encryption here" and the mail goes through anyway.
Even if the receiving end says all mail must arrive over TLS the man in the middle can currently circumvent that by receiving in plain text and forwarding onwards via TLS
This is an RFC to try and prevent that happening.
This stuff is hard, and email nerds (via MAAWG and various other places) have been working on this for years. We don't want to break your current email service, and bringing things up to speed without breaking a ton of eggs has been hurting email for a long time, but we spent too long stopping spam instead of thinking about these problems. Sorry!
Discovering if someone supports Protocol++ if the fallback to Protocol is insecure is a hard problem.
BUT, it's better than not doing anything.
Are we still sending basically plain text unsigned messages using something akin to the pony express? Does it matter that the pony express carriers communicates securely so no bad guys can snoop the carriers bag of messages At least in the old days you could put a wax seal on the letter to know the letter was legit and not tampered with. With email the entire system is flawed from the get go.