Comment 5 for bug 1934155

Bill,

I can sense quite a deal of frustration on your end, and am sorry for that. I should have mentioned to also look into the NEWS file, which at least would have told you that sslcertck is now the default. Fetchmail's -vv verbose mode might also try to log more details on the decisions along the way...

Your feedback as to how you find documentation confusing or incomplete or incompletely referenced is helpful, thank you for that - although it will take a while before improvements will make it into Ubuntu, this is due to how software ends up for Ubuntu.

On the other hand, I must say that nobody promised that fetchmail 6.4 would be bug-for-bug-compatible with 6.3, and fetchmail has indeed changed in the years between the 6.3.26 and 6.4.1X releases. In particular, I was making fetchmail 6.4 protect users' credentials more thoroughly, and this is why fetchmail finally defaults to certificate validation, and that makes "opportunistic" encryption quite a bit more mandatory, and the failing STARTTLS after the server hadn't offered it was/is not helpful: In order to validate certificates, fetchmail will try to obtain one - and on a non-SSL connection this means starttls, and fetchmail tries it blind.

I see that it is less transparent to users than I would have hoped, so thanks for mirroring that - the certificate validation makes TLS (or STARTTLS in-band negotiation for that matter) less opportunistic and more mandatory than parts of the documentation suggest.

So, "no sslcertck" is currently required to make "opportunistic" TLS really opportunistic (your "config 2" - and not in an obscure way mandatory), and "sslproto ''" indeed defeats TLS negotiation at all (your config 3).

I need to think a bit more about which changes could go into 6.5, and which will have to wait for 7.0, where the version is more of a flag to users that reads "beware of incompatibilities".