I hit this bug/feature too.

After upgrading fetchmail to 6.3.26-3, some inboxes were silently ignored.
The usual error emails from fetchmail were not sent. I only discovered
this several weeks later :(

Debugging shows:

$ apt-cache policy fetchmail
fetchmail:
  Installed: 6.3.26-3
  Candidate: 6.3.26-3
  Version table:
 *** 6.3.26-3 500
        500 http://ftp.de.debian.org/debian stretch/main amd64 Packages
        500 http://ftp.de.debian.org/debian sid/main amd64 Packages
        100 /var/lib/dpkg/status
     6.3.26-1+b1 500
        500 http://ftp.de.debian.org/debian jessie/main amd64 Packages
$ fetchmail -c -v -v -v
Old UID list from email-server: <empty>
Old UID list from localhost: <empty>
Scratch list of UIDs: <empty>
fetchmail: --check mode enabled, not fetching mail
fetchmail: 6.3.26 querying email-server (protocol IMAP) at Tue 10 Oct 2017 
10:33:30 AM CEST: poll started
Trying to connect to 10.0.0.1/993...connected.
fetchmail: OpenSSL reported: error:1417118C:SSL 
routines:tls_process_server_hello:version too low
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from user@email-server
fetchmail: 6.3.26 querying email-server (protocol IMAP) at Tue 10 Oct 2017 
10:33:30 AM CEST: poll completed
Merged UID list from email-server: <empty>
fetchmail: 6.3.26 querying localhost (protocol IMAP) at Tue 10 Oct 2017 
10:33:30 AM CEST: poll started

OpenSSL shows that the server is using TLSv1:

$ openssl s_client -host 10.0.0.1 -port 993
<snip>
CONNECTED(00000003)
<snip>
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1286 bytes and written 310 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 6E1A0000980314FC8F72FAE53500BA7018F4FDE74E04C428AD573A1CF5259CA8
    Session-ID-ctx: 
    Master-Key: 
9532468A10452BCCB3812E8219DA407B01FC5303D5FFB4D934D6D7A9B1BC929D4A846D233EAB779C01367D6511CB7C01
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1507625022
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---
* OK The Microsoft Exchange IMAP4 service is ready.

Downgrading to fetchmail to 6.3.26-1+b1 is a workaround, as is adding
--sslproto TLS1 command line parameter.

fetchmail should really fail more loudly when there are ssl problems.

-Mikko

Reply via email to