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

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

I am top-posting a response to my own message because I have resolved my 
problem. My fetchmail daemon is successfully collecting queued mail via 
TLS1.2 and POP3.

I resolved my problem by installing and running fetchmailconf in novice 
mode (not a pleasant program, but useful in my case) on my ubuntu 16.04 
development system:-

1. I then hacked "keep" into the generated ~/.fetchmailrc file to make 
sure it didn't lose any queued emails during my tests.

2. I then used fetchmailconf to run in debug mode. It seemed to hang 
again, but when I came back with a coffee to collect the entire timeout 
log, I was amazed to discover it had fetched all the mail (good job I 
used "keep", because nothing could be delivered!)

3. I tidied this .fetchmailrc and moved it to my server as /etc/fetchmailrc.

4. I then hacked my multi-drop configuration into this fetchmailrc and 
ran it through "-V" repeatedly until there were no syntax errors (there 
were quite a few!).

5. When I started the daemon it immediately connected and started 
transferring queued mail - and delivering it to my users. I had a 
tcpdump running, which showed the empty client hello was sent quickly by 
fetchmail and the server certificate was accepted. The session was 
conducted under TLS1.2.

It looks like I suffered from a bug associated with an "apparently 
valid" fetchmailrc configuration which contained unreported errors. The 
fetchmail bug was exposed when my mail provider did the server 
certificate upgrade.

I will analyse the difference between the two fetchmailrc files and 
report my findings once I have a proper explanation.

Brian

On 29/07/16 18:35, fet...@li... wrote:
> Date: Fri, 29 Jul 2016 17:59:57 +1000
> From: Brian Burch <br...@pi...>
> Subject: [Fetchmail-users] Fetchmail TLS POP connection timeout after
> 	Mail	Service upgrade
> To: Fetchmail Users <fet...@li...>
> Message-ID: <da2...@pi...>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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