That depends on the specific TLS setup. Badly configured TLS 1.2 would allow downgrade attacks, TLS 1.3 would not.
Why would TLS 1.3 prevent this kind of downgrade attack? The issue is that TLS has never been a requirement for e-mail servers, so for interoperability they only do TLS opportunistically. Even if you configure your own e-mail server to only talk over TLS, nobody else knows that your server only speaks TLS (or speaks TLS at all), so if somebody is pretending to be your mail server they can just claim to only speak plain text and any sender will be more than happy to default to it. If you support DNSSEC you can use DANE to advertise that your mail server speaks TLS, and even fix the certificates that are allowed, but senders will actually have to check this in order to make sure nobody can intercept your e-mail. Notably both outlook and gmail do not support this (neither for sending nor receiving!), they both instead rely on the weaker MTA-STS standard.
my guess would be that at least the big ones like gmail don’t allow unsecured communication with their servers at all
They absolutely do :).
I highly doubt the “in most circumstances” line
That was maybe too strong of a statement, at least with the recent adoption of MTA-STS this is at least less trivial to do :). The intent of this statement was more “if you are in the position to be a man-in-the-middle between two generic e-mail servers it is trivial to downgrade the connection from TLS to plaintext”. I wouldn’t be surprised if it was hard-coded that gmail and outlook should only talk to each other over TLS, for instance, which should prevent this for e-mails sent between the two (I also wouldn’t be surprised if this wasn’t hard-coded either… There’s sort of a bad track record with e-mail security, and the lack of DNSSEC from either of these parties is disappointing!). Ignoring special configuration like this, and without MTA-STS or DANE these downgrade attacks are trivial. Now with the advent of MTA-STS you’ll probably have a reasonably hard time downgrading the connections between some of the large e-mail providers. Though notably this is not universally supported either, iCloud supports neither MTA-STS nor DANE for instance, and who knows about all of the various providers you never think of. This is a bit of a tangent, but a good talk about how large mail providers might not be as well configured as you’d hope: https://www.youtube.com/watch?v=NwnT15q_PS8
Why would TLS 1.3 prevent this kind of downgrade attack? The issue is that TLS has never been a requirement for e-mail servers, so for interoperability they only do TLS opportunistically. Even if you configure your own e-mail server to only talk over TLS, nobody else knows that your server only speaks TLS (or speaks TLS at all), so if somebody is pretending to be your mail server they can just claim to only speak plain text and any sender will be more than happy to default to it. If you support DNSSEC you can use DANE to advertise that your mail server speaks TLS, and even fix the certificates that are allowed, but senders will actually have to check this in order to make sure nobody can intercept your e-mail. Notably both outlook and gmail do not support this (neither for sending nor receiving!), they both instead rely on the weaker MTA-STS standard.
They absolutely do :).
That was maybe too strong of a statement, at least with the recent adoption of MTA-STS this is at least less trivial to do :). The intent of this statement was more “if you are in the position to be a man-in-the-middle between two generic e-mail servers it is trivial to downgrade the connection from TLS to plaintext”. I wouldn’t be surprised if it was hard-coded that gmail and outlook should only talk to each other over TLS, for instance, which should prevent this for e-mails sent between the two (I also wouldn’t be surprised if this wasn’t hard-coded either… There’s sort of a bad track record with e-mail security, and the lack of DNSSEC from either of these parties is disappointing!). Ignoring special configuration like this, and without MTA-STS or DANE these downgrade attacks are trivial. Now with the advent of MTA-STS you’ll probably have a reasonably hard time downgrading the connections between some of the large e-mail providers. Though notably this is not universally supported either, iCloud supports neither MTA-STS nor DANE for instance, and who knows about all of the various providers you never think of. This is a bit of a tangent, but a good talk about how large mail providers might not be as well configured as you’d hope: https://www.youtube.com/watch?v=NwnT15q_PS8