For the case of mail submission, there is a lot of legacy hardware/firmware out there still in use that simply doesn't support TLS, and is mission-critical, and is likely to become obsolete before anyone upgrades it. A lot of that traffic is considered nonsensitive by those who need it so trying to force them to be secure isn't going to go over well. Despite that, RFC 8314 recommends that MSPs deprecate cleartext submission and mail access, but it doesn't specify a timetable because the situations vary too widely from one provider to another.

For message relaying, your proposal might indeed work. The vast majority of inter-domain mail traffic goes through a very small number of providers. No mail provider can afford to not be able to exchange mail with gmail, or office365, or ...

This type of thinking is how we get ants.

It is trivial to set up a mail server with TLS and if you don't have fucking TLS bounce it through a protocol upgrade server. If you understood the type of secrets that are getting trivially intercepted you'd realize that a couple hard days for a couple of lazy sys admins is a tiny price to pay for the drastic increase in security.

People are literally getting killed because we're so fucking lazy. Even three letter agencies are sending mail without TLS, this is madness.

What mission critical legacy hardware/firmware doesn't support TLS and is sending email to gmail?

Anyone running that mission critical hardware is free to keep using insecure email, no one is going to stop that. If they really need to send email from that old hardware to gmail, they can set up their own relay that accepts non-tls connections but relays using TLS.

Nearly every printer/copier with a scan-to-email feature in a small-to-medium size business that has moved their all their servers and email into the cloud.

Even if they define a 5 to 10 years warning before "deprecating" it is better than finding ourselves in the same hole the same amount of years from now.

It's drastic enough not to be realistic, it would break mail for too many people, who would blame it on Gmail.

What the big sites can do is add a delay when receiving from a plaintext relay, in a manner similar to greylisting and tarpiting that are widely deployed. The mail is not rejected, just delayed. The delay can be proportional to the amount of mail sent by a domain, and set to increase in time. The same can be done for outgoing mail to domains that don't advertise STARTTLS, drop the connection and retry later.

In the first phase, just issue a warning then drop the first submission attempt, to fillup the logs with a clear message that STARTTLS is strongly preferred. Gradually increase the delay so that large sites have trouble emptying their queue, and continue to increase the delay until the last holdouts can be simply shut out.

The advantage with this approach is that the user of Gmail, Yahoo etc. does not see a problem with his account, while the smaller sites and users will have delays when sending mail and receiving mail and be forced to take action.

I'm pretty sure users would also blame delays on the receiving provider, not the sender (and they wouldn't be wrong, technically). I can picture a user saying "Oh, sometimes it takes ages for mail to arrive to my Gmail address, please send that document to username@<minor provider which doesn't delay mail>".

The key here is to have an implementation schedule crafted so there is a massive differential impact on a selected group of small providers and a negligible impact on overall performance. After issuing warnings for a few months, put a cap on the number of plain-text submissions per domain, large enough to affect just the worldwide top 5-10 domains in that group. As more domains comply, roll that window, so as to keep just a very small fraction of total mail volume delayed, both incoming and outgoing. Since mail delays are common, the risk of switching by your own customers is low, and special exceptions can be made for accounts that communicate with an affected domain often.

It's essential that the major email domains work together so that the users of small non-encrypting domains feel a generalized performance impact, not just a problem with Gmail or just Yahoo.