[Fetchmail-users] Fetchmail TLS POP connection timeout after Mail Service upgrade

[Brian B. <br...@pi...>]

I have been using fetchmail successfully for many years and haven't 
needed to change /etc/fetchmainrc for a very long time.

My mail service provider implemented new SHA-256 certificates this week 
and (except for one "lucky" poll cycle) my fetchmail daemon has timed 
out after the successful 3-way handshake - because it never sends a 
client hello.

My server runs ubuntu 32-bit 14.04 LTS and the ubuntu distribution of 
fetchmail 6.3.26. It also has both openssl 0.9.8 and 1.0.0 installed, 
but an strace of fetchmail shows it is loading libssl.so.1.0.0, which I 
believe is "a good thing". (I have set up an ubuntu 16.04 64-bit system 
on another machine with only openssl 1.0.2, but it behaves the same way.)

I have tinkered with the sslproto, sslcertck and service options, but 
here is the output for the configuration which seems best to me:

brian@shiraz:/etc$ sudo fetchmail -V -vvv --nodetach --nosyslog 
--fetchmailrc /etc/fetchmailrc | tee 
~/scratch/shiraz-fetchmail-tls-configcheck
fetchmail: WARNING: Running as root is discouraged.
This is fetchmail release 6.3.26+GSS+NTLM+SDPS+SSL+NLS+KRB5.

Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond,
                    Robert M. Funk, Graham Wilson
Copyright (C) 2005 - 2012 Sunil Shetye
Copyright (C) 2005 - 2013 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)

Fallback MDA: (none)
Linux shiraz 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:32 UTC 
2016 i686 i686 i686 GNU/Linux
Old UID list from yali.mythic-beasts.com: <empty>
Scratch list of UIDs: <empty>
Taking options from command line and /etc/fetchmailrc
Poll interval is 480 seconds
Idfile is /home/brian/.fetchids
Fetchmail will forward misaddressed multidrop messages to postmaster.
Fetchmail will direct error mail to the postmaster.
Fetchmail will treat permanent errors as temporary (keep messages).
Options for retrieving from pi...@pi...@yali.mythic-beasts.com:
   True name of server is yali.mythic-beasts.com.
   This host will be queried when no host is specified.
   Password = "xxxxxxxx".
   Protocol is POP3 (using service pop3s).
   All available authentication methods will be tried.
   SSL protocol: TLS1.2+.
   Server nonresponse timeout is 600 seconds.
   Default mailbox selected.
   Only new messages will be retrieved (--all off).
   Fetched messages will not be kept on the server (--keep off).
   Old messages will not be flushed before message retrieval (--flush off).
   Oversized messages will not be flushed before message retrieval 
(--limitflush off).
   Rewrite of server-local addresses is enabled (--norewrite off).
   Carriage-return stripping is disabled (stripcr off).
   Carriage-return forcing is disabled (forcecr off).
   Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
   MIME decoding is disabled (mimedecode off).
   Idle after poll is disabled (idle off).
   Nonempty Status lines will be kept (dropstatus off)
   Delivered-To lines will be kept (dropdelivered off)
   Message size limit is 16777216 octets (--limit 16777216).
   Message size warning interval is 864000 seconds (--warnings 864000).
   Received-message limit is 15 (--fetchlimit 15).
   Fetch message size limit is 100 (--fetchsizelimit 100).
   Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
   No SMTP message batch limit (--batchlimit 0).
   Deletion interval between expunges forced to 15 (--expunge 15).
   Messages will be SMTP-forwarded to: mail-untrusted
   Host part of MAIL FROM line will be pingtoo.com
   Spam-blocking disabled
   No pre-connection command.
   No post-connection command.
   Multi-drop mode: 1 local name recognized.
	root
	*
   DNS lookup for multidrop addresses is enabled.
   Server aliases will be compared with multidrop addresses by name.
   Envelope header is assumed to be: X-BlackCat-To
   Number of envelope headers to be skipped over: 0
   Prefix toopin0296- will be removed from user id
   Predeclared mailserver aliases: pingtoo.com
   No interface requirement specified.
   No monitor interface specified.
   No plugin command specified.
   No plugout command specified.
   No UIDs saved from this host.
   No poll trace information will be added to the Received header.
   Messages with bad headers will be rejected.


When I run it from a command prompt, the output is very short:

brian@shiraz:/etc$ sudo env LC_ALL=C fetchmail -vvv --nodetach 
--nosyslog --fetchmailrc /etc/fetchmailrc | tee 
~/scratch/shiraz-fetchmail-tls-test
fetchmail: WARNING: Running as root is discouraged.
Old UID list from yali.mythic-beasts.com: <empty>
Scratch list of UIDs: <empty>
fetchmail: starting fetchmail 6.3.26 daemon
fetchmail: 6.3.26 querying yali.mythic-beasts.com (protocol POP3) at Fri 
Jul 29 17:42:56 2016: poll started
Trying to connect to 93.93.131.127/995...connected.
fetchmail: timeout after 600 seconds waiting for server 
yali.mythic-beasts.com.
fetchmail: socket error while fetching from 
pi...@pi...@yali.mythic-beasts.com
fetchmail: 6.3.26 querying yali.mythic-beasts.com (protocol POP3) at Fri 
Jul 29 17:53:00 2016: poll completed
Merged UID list from yali.mythic-beasts.com: <empty>
fetchmail: Query status=2 (SOCKET)
fetchmail: sleeping at Fri Jul 29 17:53:00 2016 for 480 seconds


Wireshark shows me that my fetchmail simply does not send a client 
hello! (Just once, inexplicably, it DID send a hello and then the 
session worked perfectly. However, when it tried the next poll, that 
hung until it timed out.)

Nothing seems to kick it into sending an "empty" client hello... which 
has been redefined from "should" to "must" in RFC5246 (TLS Version 1.2). 
I don't have a client certificate for my server to send, but that 
shouldn't inhibit an "empty" client hello.

To baffle me further, when I run openssl s_client against the server, an 
empty client hello is sent within a few milliseconds. The TLS 1.2 
handshake completes successfully and I can manually connect to the POP3 
server!

I do not believe this problem is related to the server certificate 
change, because until client hello is sent by fetchmail, the server 
certificate is legitimately unknown.

Do you have any words of wisdom for me? I'm feeling pretty lonely at the 
moment!

Thanks,

Brian