> I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext

Where is this? Why would bad encryption be better than plaintext? I can't imagine a scenario where this is the case.

Email is a great example of this. There's a bunch of complications like the 'to address' not matching the MX record, the MX record being served without DNSSEC, and a history of self-signed certificates. Unless you do something special you're likely transmitting email using TLS without validating the certificate.

This is strictly better than plaintext as a passive eavesdropper cannot listen in; an active attack is needed.

I wrote much more here: https://alexsci.com/blog/is-email-confidential-in-transit-ye...

	▲	rainsford 4 days ago \| parent [-]
		I definitely agree it's strictly better than plaintext. But the counter argument is that introducing bad encryption makes it less likely you'll ever end up with good encryption because the perceived delta between good and bad encryption isn't enough to make people invest the effort compared to fixing the more obviously bad situation of just plaintext. I honestly don't know if I fully buy that argument, but there's something to be said for the idea that the problem with "better than nothing" is that it presupposes "nothing" is what you'd otherwise end up with and the crummy solution is the best you're going to get. I think your blog post highlights this point. Encrypting email even without validating certificates is better than not doing the encryption at all, but is giving people the security blanket of "at least we're doing something" slowing down the process of taking that last step?