Almost all mail clients (MUAs) I've seen will validate the TLS certificate.
Almost no mail servers (MTAs) will validate the TLS certificate. This is because a) TLS isn't required, so a MITM could just strip the STARTTLS and everything would need to continue to work, and b) It doesn't provide any security.
TLS on the client is really securing the client credentials - not the email. TLS on the server is per hop - not to the final destination, so it doesn't protect a MITM attack.
If you want encrypted email, encrypt the email - don't use per hop encryption.
Right. This is what I was referring to -- sorry, I could have been more clear.
You have to either add an exception (works, but not ideal), or find the exact hostname which will pass Thunderbird's certificate validation (dreamhost uses a wildcard certificate for * .mail.dreamhost.com, so after digging on its wiki you find out that the correct alternative is in the form of subn.mail.dreamhost.com, where n is the same number on the mail server's real hostname, which you cannot use because it has two components where the * can match only one).
(Edit: can't make the asterisks show up correctly.)
(Edit: misread MTA as MUA. Yeah, most MTA's can't validate the certificates.)
If you are running a mail system like Postfix, with DNSSEC and DANE turned on, then your server will refuse to deliver mail to mine unless it can negotiate a TLS encrypted connection, and the certificate used matches the cryptographically signed fingerprint I publish in the DNS.
One can obviously configure his/her own MTA to not send out mail unless encryption is being used (although one would certainly end up with undeliverable mail), but RFC2487 says that you may not refuse to accept mail (again, on 25/TCP) that is not encrypted.
As with DNSSEC and DANE, like you mentioned, one can also require his/her MTA to validate the server's certificate although this isn't typically enabled by default.
Proper validation can be enabled, of course, but it is typically not by default. Of course, connecting over a "plain text" connection and then "upgrading" to TLS has its own problems, as you pointed out. The most significant is that a man-in-the-middle can simply filter out the "250-STARTTLS" response from the server and the client will not attempt to use encryption.
Unfortunately, in order to be RFC-compliant, an MTA cannot refuse to transfer mail just because encryption (TLS) is not available.
I wholeheartedly agree that the e-mail protocols need updated -- or perhaps even completely overhauled -- but I think it will be a long time before we see that happen. Besides, even if new protocols were introduced tomorrow that fixed all of this, it would be years before there was 100% adoption meaning that we'd still have to support the current protocols until then.
I don't think you can say, fairly, that "this is incredibly stupid and short sighted", though. I've been working professionally in I.T. for nearly 20 years and SMTP was still around way way before that. The problems that we are currently trying to solve simply did not exist then and almost certainly could not have even been imagined that long ago (recall that RFC733 was authored in November 1977 and RFC822 in August 1982).
Overall, SMTP has proven to be a fairly robust protocol but, as with anything, it needs to adapt.