3 ms·

STARTTLS is not an "optional upgrade command". Its support is routinely required and enforced by both clients and servers. Servers won't let clients do AUTH wi

STARTTLS is not an "optional upgrade command". Its support is routinely required and enforced by both clients and servers. Servers won't let clients do AUTH without STARTTLS first. Clients won't send emails if they are set to use it and it's not supported. One can certainly misconfigure the hell out of mail server, but then no "secure from start" will stand a chance against these leet skills either. Besides, STARTTLS dates back to 2002, so not sure what's up with your "?!?!" and "now we need to ..." comments. Looks like a basic rant to me :-/

jlgaddis 12y ago
With respect to the RFCs, it's not required to issue STARTTLS before AUTH so that's probably why billyhoffman said "optional". One is certainly free to use authentication without requiring encryption although, in practice, I'm not sure why you would want to do that (with an exception being when all MUA -> MTA traffic remains entirely within a private network, perhaps -- but even then, why not add encryption just for good measure?).
rwg 12y ago
I think you're underestimating the number of poorly configured/written SMTP clients and servers out there in the wild. As an example, here's smtp.comcast.net on tcp/587 (SMTP submission): Connection to smtp.comcast.net port 587 [tcp/submission] succeeded! 220 resomta-ch2-12v.sys.comcast.net comcast ESMTP server ready EHLO [2601:b:x:x:x:x:x:x] 250-resomta-ch2-12v.sys.comcast.net hello [2601:b:x:x:x:x:x:x], pleased to meet you 250-HELP 250-AUTH LOGIN PLAIN 250-SIZE 36700160 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-STARTTLS 250 OK AUTH LOGIN 334 VXNlcm5hbWU6 That's right, the customer-facing SMTP server for the largest ISP in North America will happily let clients authenticate via base64-encoded plaintext without doing STARTTLS first. At least with tcp/465 (SMTPS), the SMTP session (and the potential to send plaintext credentials) won't even start until the TLS session is up. That limits the attack surface to, "Does the client do something stupid with TLS, like not verify the peer's certificate or accept an aNULL/eNULL ciphersuite?" If the MUA has a "Use SSL?" checkbox in its SMTP settings and it's not checked, then the MUA will send its credentials in the clear on tcp/587 if the server advertises/accepts AUTH LOGIN/PLAIN/CRAM-MD5/etc. before/without SMARTTLS, like Comcast's SMTP servers do. This scenario can't happen with SMTPS.

jlgaddis 12y ago

With respect to the RFCs, it's not required to issue STARTTLS before AUTH so that's probably why billyhoffman said "optional". One is certainly free to use authentication without requiring encryption although, in practice, I'm not sure why you would want to do that (with an exception being when all MUA -> MTA traffic remains entirely within a private network, perhaps -- but even then, why not add encryption just for good measure?).

rwg 12y ago

I think you're underestimating the number of poorly configured/written SMTP clients and servers out there in the wild. As an example, here's smtp.comcast.net on tcp/587 (SMTP submission): Connection to smtp.comcast.net port 587 [tcp/submission] succeeded! 220 resomta-ch2-12v.sys.comcast.net comcast ESMTP server ready EHLO [2601:b:x:x:x:x:x:x] 250-resomta-ch2-12v.sys.comcast.net hello [2601:b:x:x:x:x:x:x], pleased to meet you 250-HELP 250-AUTH LOGIN PLAIN 250-SIZE 36700160 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-STARTTLS 250 OK AUTH LOGIN 334 VXNlcm5hbWU6 That's right, the customer-facing SMTP server for the largest ISP in North America will happily let clients authenticate via base64-encoded plaintext without doing STARTTLS first. At least with tcp/465 (SMTPS), the SMTP session (and the potential to send plaintext credentials) won't even start until the TLS session is up. That limits the attack surface to, "Does the client do something stupid with TLS, like not verify the peer's certificate or accept an aNULL/eNULL ciphersuite?" If the MUA has a "Use SSL?" checkbox in its SMTP settings and it's not checked, then the MUA will send its credentials in the clear on tcp/587 if the server advertises/accepts AUTH LOGIN/PLAIN/CRAM-MD5/etc. before/without SMARTTLS, like Comcast's SMTP servers do. This scenario can't happen with SMTPS.