Re: [Fetchmail-users] Unable to fetch mail from "outlook"

[Matthias A. <mat...@gm...>]

Am 10.04.2015 um 16:18 schrieb Jerry:
> On Thu, 09 Apr 2015 22:00:38 +0200, Matthias Andree stated:
> 
>> Do remove openssl and then rebuild things.  This should use the OpenSSL
>> version from the base system.  OpenSSL-from-Ports only ever caused
>> trouble for me.
> 
> Unfortunately, that is not really an option. The "ports" version is tightly
> integrated to several other applications that I use. Reverting to the "base
> system" version is a step backwards and not one that I feel is advantageous.
> 
> What I am confused about is why MUA's like "Claws-Mail" that utilize
> "openssl" from ports is not encountering the same problem that "fetchmail"
> is. In any case, at some point, the base system will be updated to the latest
> version of "openssl". Therefore it becomes crucial that this problem is
> corrected.

Jerry,

I concur that such a problem needs to be corrected.

However, having seen the network traces, I'd say this needs to be fixed
on the server's end.

Is claws also connecting to pop3.live.com in your situation?  What does
it do in a different way, compared to fetchmail?

The pop3.live.com server in your case just sees the first package of TLS
negotiation and directly hangs up, without any more TLS packets. That
seems like a protocol violation, thus, a malfunction on the server's
end, to me.  My interpretation is that pop3.live.com's service (or some
preceding application-level firewall) does not support TLS v1.2 and gets
scared to death when a client offers TLS v1.2.

If the negotiation fails, one normally expects to see something along
the lines of

> fetchmail: OpenSSL reported: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
(when forcing TLS v1.1 on pop3.live.com, which it rejects)

or:

> fetchmail: OpenSSL reported: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
(when only offering ciphers that aren't acceptable to the server)

but instead you're getting a rude plain disconnect which I also see when
/forcing/ TLS v1.2 (I am using the Git master branch for experimenting
which allows a bit more control over TLS protocols and ciphers than
RELEASE-6-3-26 aka fetchmail-6.3.26 does).


Now, retracing your previous setup and workaround experiments:
When I suggested to use --sslproto tls1 for a workaround,
you got longish delays before the failure.

I should mention that you need to be sure to specify --ssl in that case
to avoid STARTTLS that is implied by fetchmail 6.3.x versions if you
give --sslproto tls1.

HTH
Matthias