From: Matthias A. <mat...@gm...> - 2019-03-12 22:52:58
|
Am 12.03.19 um 16:26 schrieb Ralph Corderoy: > Hi, > > I've just added another host and user to my .fetchmailrc. > > poll foo via mail.foo.example proto pop3 > user "ralph@foo.example" is ralph password "letmein" > ssl sslcertck sslproto "TLS1" sslcommonname "bar.foo.example" > > `fetchmail -c foo' successfully establishes a TLS1.2 connection, but > after a flurry of encrypted application data, `Encrypted Alert' packets > are exchanged and the connection closed. Dropping the -c gives the same > behaviour. If I keep -c and change "TLS1" to "SSL23" then it doesn't > happen Ralph, The thing is "TLS1" means "TLS v1.0 and v1.0 only" and will fail if the server refuses TLSv1.0. TLS1 triggers a call through the tls1_client_method() constructor to set up internal TLS structures, whereas SSL23 uses whatever OpenSSL would auto-negotiate (SSLv23_client_method() - and is a misnomer), with restrictions (such as forbidding SSLv2 and possibly SSLv3, depending on version). I suspect that's that. If not, can you share details on your setup? Fetchmail version or Git commit hash, SSL library provider and version? Note that I neither try nor trust LibreSSL, so if you're using that, see if the issue reproduces with OpenSSL. I'd think code and TLS-support-quality wise, the tip of the legacy_64 branch from Git should be the best choice if you would bother with installing the autotools/gettext and other stuff such as flex and GNU bison. (You wouldn't need these when installing from a formal tarball. Auto-generated tarballs from the Git repo don't count, only those I get from "make distcheck"). > Using s_client(1), I see the server is Dovecot. Will s_client work if you restrict it to the same server and -tls1? HTH Matthias |