@gcupc this is only true if the second set of conditions fails: (($obj->command('STARTTLS')->response() == CMD_OK)
and $obj->ssl_start(\%ssl_args)
and $obj->hello($arg{Hello} || ""))

But what if this fails: $obj->supports('STARTTLS')

This is not a hypothetical, due to a weird dependency issue my Net::SMTP (which Net::SMTPS uses) was an ancient one without SSL support. So, $obj->supports('STARTTLS') was false. Credentials got sent in cleartext.

@rysiek Huh. I see that.

@gcupc yeah.

Basically, if any of these three is false, nothing inside the curly brackets gets executed:

(defined($ssl) && $ssl =~ /starttls/i && $obj->supports('STARTTLS') )

So you can have a config requiring the use of STARTTLS, but $obj not supporting STARTTLS - the effect being that the code continues to line 132 without bailing out.

@rysiek Traditionally, STARTTLS was optional/opportunistic, and falling back to unencrypted was expected. But expectations have changed, and RFC 2595 requires rejecting unencrypted connections if auth is used, which is more common today than formerly.

@lnxw48a1 this is not checking if the server supports STARTTLS and downgrading in case it doesn't. It doesn't get that far.

It's trying to load the libraries responsible for providing TLS/STARTTLS, and if that fails, just goes ahead in plaintext.

Funnily enough, if it successfully loads the libraries, it *then* checks if the server supports STARTTLS, and... bails out if it doesn't!

So, kinda the exact opposite what you're saying. ;)

@Wolf480pl yeah, I suspected something like this, but it took a while and a lot of help from people from #perl at irc.freenode.net to figure out what exactly the issue was.