> For most people, "better compatibility" sounds like a pretty convincing excuse.

Security has always been a compromise between protection and convenience. The most secure computer is one that is turned off and stored in a safe, but it's difficult to write a letter to your boss explaining why you weren't able to complete your assignment on time in that state.

With the not-surprising revelations about the NSAs spying programs and state sanctioned hacking and malware distribution, I think we're starting to see that we need computers to be a little less convenient and users to be a bit more literate on how to secure their communications, but to call a "If Available" encryption option stupid doesn't take in account the state of the world 14ish years ago. We, HN readers, can be on the forefront of deprecating the option of maybe and forcing an all or nothing approach, but it will still take time to get our users to accept it.

I once had a career in an entirely different field repairing mechanical technology hundreds of years old. At my technical school, my instructor was constantly telling us that we weren't in the field of mechanical watch repair, but in education. Whenever a customer would come to us and complain that their multi-thousand dollar watch was running ~30 seconds slow a week (compounded to a noticeable couple minutes per month), it was our job to educate them on the physical limits of the timepiece. Some watches are only so accurate. Now that I'm in Software Development, I see that the premise has not changed. Even though I'm paid to write software and enable business users to make loads of money using magical things, my daily job consists of educating those users on the capabilities of that system and showing them that there isn't some magical switch that I keep hidden that makes everything run fast and without issue just to piss them off. If you start to educate your users on what is good and what is impossible, then you can start to change how they use it and what they expect from it.

The reason I call STARTTLS "stupid" is because it superceded a perfectly good, fully encrypted, transport layer protocol: SMTP over SSL/TLS on port 465.

That was 16 years ago. Even back then, plenty of people seem to have been on the right track when it comes to how to encrypt a stream. People back then were also aware of the difference between the needs of mail transport and the needs of mail submission; the distinction was codified in RFC 2476 in 1998. Despite all of this, some people went ahead and implemented an "if available" encrypted protocol in the name of compatibility, deprecated the fully encrypted and widely supported alternative, and even went so far as to revoke port 465.

Two years ago, it may have sounded crazy to suggest that some three-letter agency was behind this. Now, I'm not so sure.

People who configure their clients to use encryption optionally, will find that their clients, use encryption optionally.

This is not evidence that 465 is more secure than 587. This is evidence that some clients come with strange options.

Fair point. It is, however, evidence that strange protocols beget strange clients.

Had the protocol not permitted optional encryption in the first place, no client would have implemented optional encryption, because any attempt to access mail using optional encryption would reliably fail.