Just FYI, I have STLS working with the one suitable client I have (fetchmail-6.1.0), by adding '--sslproto tls1' to the fetchmail command line.

This had me confused for a while, since my pop3d-ssl config file has

TLS_PROTOCOL=SSL3

until I realised that it also has

TLS_STARTTLS_PROTOCOL=TLS1

fetchmail appears to choose ssl2 as its default, which fails badly, and also doesn't interwork if you select ssl3. I know very little about SSL/TLS, so I don't know whether there's supposed to be any backwards compatibility between these protocols.

Regards,

Brian.

P.S. This is what you get with fetchmail -v -v --sslproto ssl3:

fetchmail: POP3< IMPLEMENTATION Courier Mail Server fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK Begin SSL/TLS negotiation now. 7316:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/s3_pkt.c:284: fetchmail: SSL connection failed. fetchmail: Authorization failure on bri...@test.example.com@192.168.0.1 fetchmail: Server CommonName mismatch: localhost != 192.168.0.1 fetchmail: 192.168.0.1 key fingerprint:
51:2F:8A:FD:52:4A:BD:7C:E0:D1:94:0C:99:09:3D:BB fetchmail: Server CommonName mismatch: localhost != 192.168.0.1 fetchmail: POP3> QUIT fetchmail: 6.1.0 querying 192.168.0.1 (protocol POP3) at Mon Oct 14 15:51:34
2002: poll completed fetchmail: Query status=3 (AUTHFAIL) fetchmail: Writing fetchids file. fetchmail: normal termination, status 3 fetchmail: Writing fetchids file.

[7316 is the pid of the fetchmail process]

At the server end you get:

Oct 14 15:51:36 mk-testbox-1 pop3d: couriertls: accept: error:14094410:SSL
routines:SSL3_READ_BYTES:sslv3 alert handshake failure Oct 14 15:51:36 mk-testbox-1 pop3d: Unexpected SSL connection shutdown.

This is almost working, because clearly the handshake has been successful enough to get the server key fingerprint, and detect the name mismatch in its self-signed certificate, but it's not happy enough to be able to complete the connection.

The environment is FreeBSD-4.7 (openssl 0.9.6g) at the client end, and FreeBSD-4.6 at the server. This had openssl 0.9.6a, which is pretty old, so I replaced it with openssl 0.9.6g and rebuilt courier-imap, but I get the same behaviour.