Re: [Fetchmail-users] fetchmail: puts no messages, quits

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

Am 08.08.2018 um 20:08 schrieb lothar via Fetchmail-users:
> i have spent hours and days building and rebuilding fetchmail, studying documents and user reports, and fiddling with configuration and settings.
>
> 1. why is fetchmail not working?

To give a short answer up front, because the kind person who has been
packaging fetchmail for Cygwin used to have a different opinion than I
on when a fetchmail package update was warranted, and I have given up
trying to persuade him to package newer versions, or make the Cygwin
project find another maintainer for the fetchmail package. Personally, I
am not using Cygwin in production or for hacking, and grarpamp's
suggestion to try and build legacy_64 is probably the best one. You will
need to install a few more packages than for building a tarball, and
bootstrap, see README.git - or else fetch the 6.4.0.beta4 tarball from
sourceforge.net here:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/> - be sure
to install the xz package so you can unpack it.

Newer fetchmail versions print messages that are a bit more helpful when
certificate verification fails.

> fetchmail runs silently for maybe 30 seconds, then puts the message shown below and quits.
> also there is nothing in the logfile.

It's either console messages or logfile, not both.

> 2. why do i see no progress messages, when i have put to give them?
> there is nothing like:
>   fetchmail: 6.3.22 querying someisp.net (protocol POP3) at Tue 31 Jul 2018 02:00:00 UCT: poll started
>   Trying to connect to 178.47.11.211/995...connected.
>
> 3. i can communicate with the mail provider with openssl to the point where openssl sends
>   +OK POP3 ready

But you haven't showed OpenSSL's s_client the way to the certificate
directory (openssl s_client -CApath ..., or openssl s_client -CAfile...,
respectively), so you have been running OpenSSL in a less strict
configuration than fetchmail, and that is the reason why it works and
fetchmail does not: you are not performing equivalent tests.

> 8. aside from the fact that there are no messages but one, that one complains about certificate verification.

...and that leads to an early abort, so there is no progress to show
(answering #2 and #8 at the same time).

> i have changed sslcertpath in ~/.fetchmailrc to:
>   /etc/ssl/certs
>   /usr/ssl/certs
>   /var/lib/fetchmail/certs
> all equally in vain.

These would have to be directories with individual PEM files, and also
symlinks that the c_rehash script shipping with OpenSSL would produce,
and are named like 1234abcd.0 (or perhaps .1).
I don't know if Cygwin's openssl packages and the ca-certificates
package match and configure the right default paths, so that *omitting*
the sslcertpath option might have helped. I assume these do, these days.

> $ uname -a
> CYGWIN_NT-10.0 hooha 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin

This, too, appears to be dated, Cygwin used to release quite often. Be
sure to keep things updated.

>
> ## in /var/lib/fetchmail/certs:
> $ ls -lgGt "--time-style=$TIMESTYLE"
> -rw-r--r-- 1 6148 2018.07.31 02:00 mail.someisp.net.pem
> lrwxrwxrwx 1   49 2018.07.31 02:00 tls-ca-bundle.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

As grarpamp has mentioned, you need to use sslcertfile if you use one
big certificate bundle, not sslcertpath. Mind the last four letters. If
Cygwin's OpenSSL is matched to the ca-certificates package, omitting
sslcertfile/sslcertpath should work out of the box. It does with some
popular Linux distributions, and FreeBSD.

> ## mail.userservices.net.pem was created with:
> $ openssl s_client -connect mail.someisp.net:995 -showcerts > mail.someisp.net.pem

This is not recommended nor necessary.

Hope that clarifies some of your trouble.

Best regards,
Matthias