fetchmail-users — User questions and discussion

[Fetchmail-users] UID lists

[Bob T. <rdt...@gm...>]

All I wanted was an explanation of what 

  fetchmail: Old UID list from innovate.cs.queensu.ca:
   <empty>

  fetchmail: Scratch list of UIDs:
   <empty>

means but you want a full bug report.  OK, here it is:


Operating system: Centos 7
compiler version: gcc 4.8.5
SMTP listener: innovate.cs.queensu.ca with proto IMAP

% fetchmail -V
This is fetchmail release 6.4.8+SSL-SSLv2-TLS1.3+HESIOD+NLS.
WARNING: Your SSL/TLS library does not support TLS v1.3.

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 - 2020 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 jimmy.tennent.ca 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Taking options from command line and /home/rdt/.fetchmailrc
Poll interval is 600 seconds
Idfile is /home/rdt/.fetchids
Fetchmail will forward misaddressed multidrop messages to rdt.
Options for retrieving from rd...@in...:
  True name of server is innovate.cs.queensu.ca.
  Protocol is IMAP.
  All available authentication methods will be tried.
  SSL server certificate checking enabled.
  Server nonresponse timeout is 300 seconds (default).
  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)
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
  Messages will be SMTP-forwarded to: localhost (default)
  Single-drop mode: 1 local name recognized.
  No UIDs saved from this host.

% fetchmail --nodetach -vvv --nosyslog
Old UID list from innovate.cs.queensu.ca:
 <empty>

Scratch list of UIDs:
 <empty>

fetchmail: starting fetchmail 6.4.8 daemon
fetchmail: 6.4.8 querying innovate.cs.queensu.ca (protocol IMAP) at Wed 12 Aug 2020 02:02:01 PM EDT: poll started
Trying to connect to 130.15.1.11/143...connected.
fetchmail: IMAP< * OK [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS] innovate IMAP4rev1 2007f.404 at Wed, 12 Aug 2020 14:02:06 -0400 (EDT)
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND SASL-IR LOGIN-REFERRALS STARTTLS
fetchmail: IMAP< A0001 OK CAPABILITY completed
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: IMAP> A0002 STARTTLS
fetchmail: IMAP< A0002 OK STARTTLS completed
fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: DigiCert Inc
fetchmail: Issuer CommonName: DigiCert Global Root CA
fetchmail: Subject CommonName: DigiCert Global Root CA
fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: DigiCert Inc
fetchmail: Issuer CommonName: DigiCert Global Root CA
fetchmail: Subject CommonName: RapidSSL RSA CA 2018
fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok
fetchmail: Server certificate:
fetchmail: Issuer Organization: DigiCert Inc
fetchmail: Issuer CommonName: RapidSSL RSA CA 2018
fetchmail: Subject CommonName: *.cs.queensu.ca
fetchmail: Subject Alternative Name: *.cs.queensu.ca
fetchmail: innovate.cs.queensu.ca key fingerprint: 19:ED:EA:E8:5D:8B:B9:A0:09:FE:85:FC:B6:BC:B6:DE
fetchmail: SSL/TLS: using protocol TLSv1, cipher AES256-SHA, 256/256 secret/processed bits
fetchmail: IMAP> A0003 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND SASL-IR LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN
fetchmail: IMAP< A0003 OK CAPABILITY completed
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: innovate.cs.queensu.ca: upgrade to TLS succeeded.
fetchmail: IMAP> A0004 LOGIN "rdt" *
fetchmail: IMAP< A0004 OK [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User rdt authenticated
fetchmail: selecting or re-polling default folder
fetchmail: IMAP> A0005 SELECT "INBOX"
fetchmail: IMAP< * 14 EXISTS
fetchmail: IMAP< * 1 RECENT
fetchmail: IMAP< * OK [UIDVALIDITY 1591704506] UID validity status
fetchmail: IMAP< * OK [UIDNEXT 7937] Predicted next UID
fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
fetchmail: IMAP< * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags
fetchmail: IMAP< * OK [UNSEEN 1] first unseen message in /var/mail/rdt
fetchmail: IMAP< A0005 OK [READ-WRITE] SELECT completed
fetchmail: 14 messages waiting after first poll
fetchmail: IMAP> A0006 EXPUNGE
fetchmail: IMAP< A0006 OK No messages deleted, so no update needed
fetchmail: 14 messages waiting after expunge
fetchmail: IMAP> A0007 SEARCH UNSEEN
fetchmail: IMAP< * SEARCH 1 2 3 4 5 6 7 8 9 10 11 12 13 14
fetchmail: 1 is unseen
fetchmail: 2 is unseen
fetchmail: 3 is unseen
fetchmail: 4 is unseen
fetchmail: 5 is unseen
fetchmail: 6 is unseen
fetchmail: 7 is unseen
fetchmail: 8 is unseen
fetchmail: 9 is unseen
fetchmail: 10 is unseen
fetchmail: 11 is unseen
fetchmail: 12 is unseen
fetchmail: 13 is unseen
fetchmail: 14 is unseen
fetchmail: IMAP< A0007 OK SEARCH completed
fetchmail: 1 is first unseen
14 messages for rdt at innovate.cs.queensu.ca.
fetchmail: IMAP> A0008 FETCH 1:14 RFC822.SIZE
^Cfetchmail: terminated with signal 2

Re: [Fetchmail-users] UID list?

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

Am 12.08.20 um 19:18 schrieb Bob Tennent:
> fetchmail isn't working and fetchmail -v -v is generating
>
>   fetchmail: Old UID list from innovate.cs.queensu.ca: <empty>
>   fetchmail: Scratch list of UIDs: <empty>
>
> What does this mean?
>
Bob,

Unfortunately my crystal ball has not been returned from repairs, and
that, and without configuration and logs, nobody is able to help you.

If you are using a halfway recent 6.4.x version, please provide the
information per <https://www.fetchmail.info/fetchmail-FAQ.html#G3>.

If you have an older version from a commercially supported distribution,
seek their customer support.

If you have an older version from an unsupported or community-supported
distribution, please update first.

HTH
Matthias

[Fetchmail-users] UID list?

[Bob T. <rdt...@gm...>]

fetchmail isn't working and fetchmail -v -v is generating

  fetchmail: Old UID list from innovate.cs.queensu.ca: <empty>
  fetchmail: Scratch list of UIDs: <empty>

What does this mean?

Re: [Fetchmail-users] Password length restriction

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

Am 16.07.20 um 10:50 schrieb Bjoern Voigt:
> Matthias Andree wrote:
>> Password buffers in 6.4.X are allocated dynamically, and there may be
>> undocumented limitations on your mail service provider's (MSP's) end. 30
>> certainly does not seem too long to me, but might be for your MSP.
> I still see a static maximum password length in the head branch of
> Fetchmail:
>
> #define PASSWORDLEN 256 /* max password length */
> (source https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/fetchmail.h#l117)

Yes, I figured my assessment yesterday was reaching too short; while it
is true that the password storage itself is allocated dynamically, some
of the ways of how the passwords are acquired are not.

I've marked an issue for that in Gitlab with milestone 7.0 so it's not
forgotten. => https://gitlab.com/fetchmail/fetchmail/-/issues/17

I am not sure if that's fixable for 6.5.x though.

Re: [Fetchmail-users] Password length restriction

[Bjoern V. <bj...@ar...>]

Matthias Andree wrote:
> Password buffers in 6.4.X are allocated dynamically, and there may be
> undocumented limitations on your mail service provider's (MSP's) end. 30
> certainly does not seem too long to me, but might be for your MSP.
I still see a static maximum password length in the head branch of
Fetchmail:

#define PASSWORDLEN 256 /* max password length */
(source https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/fetchmail.h#l117)

Greetings, Björn

Re: [Fetchmail-users] Password length restriction [getting slightly OT]

[Eike L. <zp...@gm...>]

On Wednesday, 15 July 2020 15:57:17 -04 Carlos E. R. wrote:
> On 15/07/2020 19.02, Eike Lantzsch wrote:
> > On Wednesday, 15 July 2020 12:32:49 -04 Matthias Andree wrote:
> >> Am 15.07.20 um 16:42 schrieb Zsolt Barat:
> >>> I'm using following fetchmail version:
> >>>
> >>> 6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5
> >>
> >> 6.3.X is a museum piece from 2013 and unsupported on this list, and
> >> I
> >> don't care to look back to what it might have done for such
> >> questions.
> >>
> >> Password buffers in 6.4.X are allocated dynamically, and there may
> >> be
> >> undocumented limitations on your mail service provider's (MSP's)
> >> end.
> >> 30 certainly does not seem too long to me, but might be for your
> >> MSP.
> >
> > If you don't mind my AOL-post ...
> > There are some distributions which are not including any recent
> > fetchmail version.
> > I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.
>
> That's intentional and documented policy.
>
> I guess you are talking of openSUSE Leap 15.x, which is an LTS, thus
> it simply can not change the versions of the core packages during the
> long term period (ie, when it goes to Leap 16), unless the commercial
> distribution from which it derives the core (SLE) switches version
> first.

Of course I was referring to the openSUSE distribution, which the OP
mentioned in his post.
Leap 15.1 dates 7 years back? No, there seems to be a gap of fetchmail
development upstream between 2013 and April 2020.
I had the impression that the SuSe-webpage adveritsed it as the latest?
Actually that would be 15.2.
It didn't really say LTS. That detail escaped me. Maybe I perused it
only too cursory.

Whoever might be to blame - putting blame on s/o does not help - users
need to be aware that distributions do not / cannot / don't want to
contain always the most recent upstream products.

OK, whatever, I'm not using SuSe (not anymore since 2001). I won't dive
into their release cycle any deeper. I already need to keep track of
"stable", "testing", "unstable", "experimental", "LTS" and "release",
"stable", "current" and snapshots - that's enough - oh and "rolling
release cycles". Is the release a ball or a steam roller? Not telling
any names SIMS[1]. So the OP may be forgiven to ask for support
on a s/w product of 2013.
Thanks for the clarification.
>
> However, there is the server:mail repository which has 6.4.1
>
> And there is openSUSE Tumbleweed which also has 6.4.1
Tumbleweed hints on a "rolling release cycle" SCNR or is it?
>
> > If mayor producers of Linux Distros are going on with this practice
> > questions like the one of the OP are bound to appear again and
> > again.
> > It seems to be a widely common assumption that the latest distro
> > comes with the latest ports - not at all, not at all.
>
> Of course.
>
> > Not good.
> > Not long ago OpenBsd e.g. was still with 6.3.xx when 6.4.xx was
> > already available upstream. Now OpenBSD 6.7 Release comes with
> > 6.4.3. At least on OpenBSD compiling the latest upstream version fo
> > fetchmail is straight forward and easy.
> > On Linux I don't know but would be worth a try.
> > Anyway, updating to the latest upstream version before asking for
> > help, is always good practice.
> >
> > Anyway I admire your patience giving a helpful answer despite the
> > OP's question based on outdated software.
> > All the best to y'all

Have a nice day

[1] snickering into my sleeve
--
Eike Lantzsch ZP6CGE

Re: [Fetchmail-users] Password length restriction

[Eike L. <zp...@gm...>]

On Wednesday, 15 July 2020 17:13:08 -04 Matthias Andree wrote:
> Am 15.07.20 um 19:02 schrieb Eike Lantzsch:
> > If you don't mind my AOL-post ...
> > There are some distributions which are not including any recent
> > fetchmail version.
> > I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.
> > If mayor producers of Linux Distros are going on with this practice
> > questions like the one of the OP are bound to appear again and
> > again.
> > It seems to be a widely common assumption that the latest distro
> > comes with the latest ports - not at all, not at all.
> > Not good.
>
> So be it, we'll politely tell people that the official support list is
> for officially supported releases (meaning the 6.4.X series at the
> time of writing), and what they (the users) make of that depends a
> bit on their skills and how much effort they want to spend.
>
> > Not long ago OpenBsd e.g. was still with 6.3.xx when 6.4.xx was
> > already available upstream. Now OpenBSD 6.7 Release comes with
> > 6.4.3.
> OpenBSD is a different story, their LibreSSL isn't up to speed with
> TLSv1.3. So it works with fetchmail 6.4.x, but not with 6.5.x (for
> instance beta1), as of OpenBSD 6.7. Their base system libressl isn't
> up to speed with TLS v1.3 which fetchmail 6.5 (a future release) will
> require, in the form of requiring the OpenSSL 1.1.1 API as well. I
> know the OpenBSD/LibreSSL are working on TLSv1.3, but it's not there
> yet.
That is good to know. Thank you for the enlightenment!
OpenBSD is working with manpower constraints and consequently they need
to decide wisely where to put their efforts in. TLSv1.3 is certainly
important.
>
> Otherwise someone else port fetchmail 6.5.x to OpenBSD's OpenSSL port,
> which is packaged so far differently from everything I've seen that I
> won't bother supporting it in fetchmail upstream with libecrypt
> libessl and whatnot.
> OpenBSD need to get their act together anyways. They forked OpenSSL
> into LibreSSL due to security issues, but don't deliver on up-to-date
> protocols. It's a bit of an inconsistent impression they are leaving
> with me.
>
> > At least on OpenBSD compiling the latest upstream version fo
> > fetchmail is straight forward and easy.
>
> Yes, for the recent OpenBSD versions and fetchmail 6.4.x (which
> tolerates OpenSSL 1.0.2 and compatible libraries).
>
> > On Linux I don't know but would be worth a try.
>
> I routinely test on recent Fedora and Ubuntu Linux and on FreeBSD, and
> occasionally on OpenBSD and I've tested with OpenIllumos Hipster
> which just crashed into a "disk full" condition in my virtual machine
> when trying to upgrade. No-one told me I'd need to keep 8 GB for
> updates. ;)
> > Anyway I admire your patience giving a helpful answer despite the
> > OP's question based on outdated software.
>
> I had to learn that part. ;)

Thank you and keep up the good work!

--
Eike Lantzsch ZP6CGE

Re: [Fetchmail-users] Password length restriction

[Carlos E. R. <rob...@te...>]

On 15/07/2020 23.19, Matthias Andree wrote:
> Am 15.07.20 um 21:57 schrieb Carlos E. R.:
>> On 15/07/2020 19.02, Eike Lantzsch wrote:
>>> If you don't mind my AOL-post ...
>>> There are some distributions which are not including any recent
>>> fetchmail version.
>>> I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.
>>
>> That's intentional and documented policy.
>>
>> I guess you are talking of openSUSE Leap 15.x, which is an LTS, thus
>> it simply can not change the versions of the core packages during the
>> long term period (ie, when it goes to Leap 16), unless the commercial
>> distribution from which it derives the core (SLE) switches version first.
>>
>> However, there is the server:mail repository which has 6.4.1
>>
>> And there is openSUSE Tumbleweed which also has 6.4.1
> 
> Which is outdated, too. 6.4.2 updated fetchmailconf, and 6.4.3 was a
> version to receive Linux-relevant bugfixes (6.4.5 for Solaris 10), and
> there have been translation updates since, so distros should really move
> forward. I believe I have paid sufficient attention that patchlevel
> updates within 6.4.x should be safe, with the exception that 6.4.2 also
> tightened up the Python requirement for fetchmailconf to >= 2.7.13. This
> may hurt LTS releases, but then again, if someone runs a LTS or
> commercial distro, that's also the place to go to for support.

And the OP got his support ;-)

-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.1 x86_64 at Telcontar)

Re: [Fetchmail-users] Password length restriction

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

Am 15.07.20 um 21:57 schrieb Carlos E. R.:
> On 15/07/2020 19.02, Eike Lantzsch wrote:
>> If you don't mind my AOL-post ...
>> There are some distributions which are not including any recent
>> fetchmail version.
>> I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.
>
> That's intentional and documented policy.
>
> I guess you are talking of openSUSE Leap 15.x, which is an LTS, thus
> it simply can not change the versions of the core packages during the
> long term period (ie, when it goes to Leap 16), unless the commercial
> distribution from which it derives the core (SLE) switches version first.
>
> However, there is the server:mail repository which has 6.4.1
>
> And there is openSUSE Tumbleweed which also has 6.4.1

Which is outdated, too. 6.4.2 updated fetchmailconf, and 6.4.3 was a
version to receive Linux-relevant bugfixes (6.4.5 for Solaris 10), and
there have been translation updates since, so distros should really move
forward. I believe I have paid sufficient attention that patchlevel
updates within 6.4.x should be safe, with the exception that 6.4.2 also
tightened up the Python requirement for fetchmailconf to >= 2.7.13. This
may hurt LTS releases, but then again, if someone runs a LTS or
commercial distro, that's also the place to go to for support.

Re: [Fetchmail-users] Password length restriction

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

Am 15.07.20 um 19:02 schrieb Eike Lantzsch:
> If you don't mind my AOL-post ...
> There are some distributions which are not including any recent
> fetchmail version.
> I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.
> If mayor producers of Linux Distros are going on with this practice
> questions like the one of the OP are bound to appear again and again.
> It seems to be a widely common assumption that the latest distro comes
> with the latest ports - not at all, not at all.
> Not good.

So be it, we'll politely tell people that the official support list is
for officially supported releases (meaning the 6.4.X series at the time
of writing), and what they (the users) make of that depends a bit on
their skills and how much effort they want to spend.

> Not long ago OpenBsd e.g. was still with 6.3.xx when 6.4.xx was already
> available upstream. Now OpenBSD 6.7 Release comes with 6.4.3.

OpenBSD is a different story, their LibreSSL isn't up to speed with
TLSv1.3. So it works with fetchmail 6.4.x, but not with 6.5.x (for
instance beta1), as of OpenBSD 6.7. Their base system libressl isn't up
to speed with TLS v1.3 which fetchmail 6.5 (a future release) will
require, in the form of requiring the OpenSSL 1.1.1 API as well. I know
the OpenBSD/LibreSSL are working on TLSv1.3, but it's not there yet.

Otherwise someone else port fetchmail 6.5.x to OpenBSD's OpenSSL port,
which is packaged so far differently from everything I've seen that I
won't bother supporting it in fetchmail upstream with libecrypt libessl
and whatnot.
OpenBSD need to get their act together anyways. They forked OpenSSL into
LibreSSL due to security issues, but don't deliver on up-to-date
protocols. It's a bit of an inconsistent impression they are leaving
with me.

> At least on OpenBSD compiling the latest upstream version fo fetchmail
> is straight forward and easy.
Yes, for the recent OpenBSD versions and fetchmail 6.4.x (which
tolerates OpenSSL 1.0.2 and compatible libraries).
> On Linux I don't know but would be worth a try.
I routinely test on recent Fedora and Ubuntu Linux and on FreeBSD, and
occasionally on OpenBSD and I've tested with OpenIllumos Hipster which
just crashed into a "disk full" condition in my virtual machine when
trying to upgrade. No-one told me I'd need to keep 8 GB for updates. ;)
> Anyway I admire your patience giving a helpful answer despite the OP's
> question based on outdated software.
I had to learn that part. ;)

Re: [Fetchmail-users] Password length restriction

[Carlos E. R. <rob...@te...>]

On 15/07/2020 19.02, Eike Lantzsch wrote:
> On Wednesday, 15 July 2020 12:32:49 -04 Matthias Andree wrote:
>> Am 15.07.20 um 16:42 schrieb Zsolt Barat:
>>> I'm using following fetchmail version:
>>>
>>> 6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5
>>
>> 6.3.X is a museum piece from 2013 and unsupported on this list, and I
>> don't care to look back to what it might have done for such questions.
>>
>> Password buffers in 6.4.X are allocated dynamically, and there may be
>> undocumented limitations on your mail service provider's (MSP's) end.
>> 30 certainly does not seem too long to me, but might be for your MSP.


> 
> If you don't mind my AOL-post ...
> There are some distributions which are not including any recent
> fetchmail version.
> I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.

That's intentional and documented policy.

I guess you are talking of openSUSE Leap 15.x, which is an LTS, thus it 
simply can not change the versions of the core packages during the long 
term period (ie, when it goes to Leap 16), unless the commercial 
distribution from which it derives the core (SLE) switches version first.

However, there is the server:mail repository which has 6.4.1

And there is openSUSE Tumbleweed which also has 6.4.1

> If mayor producers of Linux Distros are going on with this practice
> questions like the one of the OP are bound to appear again and again.
> It seems to be a widely common assumption that the latest distro comes
> with the latest ports - not at all, not at all.

Of course.

> Not good.
> Not long ago OpenBsd e.g. was still with 6.3.xx when 6.4.xx was already
> available upstream. Now OpenBSD 6.7 Release comes with 6.4.3.
> At least on OpenBSD compiling the latest upstream version fo fetchmail
> is straight forward and easy.
> On Linux I don't know but would be worth a try.
> Anyway, updating to the latest upstream version before asking for help,
> is always good practice.
> 
> Anyway I admire your patience giving a helpful answer despite the OP's
> question based on outdated software.
> All the best to y'all

-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.1 x86_64 at Telcontar)

Re: [Fetchmail-users] Password length restriction

[Bjoern V. <bj...@ar...>]

Zsolt Barat wrote:
> just wanted to ask if there is a known restriction of the password
> length for authenticating to a POP3 server.
>
> I recognized problems while using a password with more than 30
> characters, authenticating to gmx.net servers.
>
> I'm using following fetchmail version:
>
> 6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5
>
> On openSUSE Leap 15.1
Fetchmail 6.3.26 defines a maximum password length of 64 byte:

fetchmail.h*:*
#define             PASSWORDLEN     64      /* max password length */

Greetings,
Björn

Re: [Fetchmail-users] Password length restriction

[Gene H. <ghe...@sh...>]

On Wednesday 15 July 2020 13:02:26 Eike Lantzsch wrote:

> On Wednesday, 15 July 2020 12:32:49 -04 Matthias Andree wrote:
> > Am 15.07.20 um 16:42 schrieb Zsolt Barat:
> > > I'm using following fetchmail version:
> > >
> > > 6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5
> >
> > 6.3.X is a museum piece from 2013 and unsupported on this list, and
> > I don't care to look back to what it might have done for such
> > questions.
> >
> > Password buffers in 6.4.X are allocated dynamically, and there may
> > be undocumented limitations on your mail service provider's (MSP's)
> > end. 30 certainly does not seem too long to me, but might be for
> > your MSP.
> >
> > _______________________________________________
> > Fetchmail-users mailing list
> > Fet...@li...
> > https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>
> If you don't mind my AOL-post ...
> There are some distributions which are not including any recent
> fetchmail version.
> I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.
> If mayor producers of Linux Distros are going on with this practice
> questions like the one of the OP are bound to appear again and again.
> It seems to be a widely common assumption that the latest distro comes
> with the latest ports - not at all, not at all.
> Not good.
> Not long ago OpenBsd e.g. was still with 6.3.xx when 6.4.xx was
> already available upstream. Now OpenBSD 6.7 Release comes with 6.4.3.
> At least on OpenBSD compiling the latest upstream version fo fetchmail
> is straight forward and easy.
> On Linux I don't know but would be worth a try.

Piece of cake on stretch. SSL however has fallen way behind.  But the 
TLS/SSL I have on stretch is good enough for my providers server, which 
is running dovecot.

> Anyway, updating to the latest upstream version before asking for
> help, is always good practice.
>
> Anyway I admire your patience giving a helpful answer despite the OP's
> question based on outdated software.
> All the best to y'all
>
> --
> Eike Lantzsch ZP6CGE
> Asuncion / Paraguay
>
> I know what it feels like to be misunderstood. I know what it feels
> like to be misjudged because of prejudice. So, please would you stop
> to teach me that lesson?
> Or maybe by posting my 2 cents I asked for it ...
>
>
>
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: [Fetchmail-users] Password length restriction

[Eike L. <zp...@gm...>]

On Wednesday, 15 July 2020 12:32:49 -04 Matthias Andree wrote:
> Am 15.07.20 um 16:42 schrieb Zsolt Barat:
> > I'm using following fetchmail version:
> >
> > 6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5
>
> 6.3.X is a museum piece from 2013 and unsupported on this list, and I
> don't care to look back to what it might have done for such questions.
>
> Password buffers in 6.4.X are allocated dynamically, and there may be
> undocumented limitations on your mail service provider's (MSP's) end.
> 30 certainly does not seem too long to me, but might be for your MSP.
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

If you don't mind my AOL-post ...
There are some distributions which are not including any recent
fetchmail version.
I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.
If mayor producers of Linux Distros are going on with this practice
questions like the one of the OP are bound to appear again and again.
It seems to be a widely common assumption that the latest distro comes
with the latest ports - not at all, not at all.
Not good.
Not long ago OpenBsd e.g. was still with 6.3.xx when 6.4.xx was already
available upstream. Now OpenBSD 6.7 Release comes with 6.4.3.
At least on OpenBSD compiling the latest upstream version fo fetchmail
is straight forward and easy.
On Linux I don't know but would be worth a try.
Anyway, updating to the latest upstream version before asking for help,
is always good practice.

Anyway I admire your patience giving a helpful answer despite the OP's
question based on outdated software.
All the best to y'all

--
Eike Lantzsch ZP6CGE
Asuncion / Paraguay

I know what it feels like to be misunderstood. I know what it feels
like to be misjudged because of prejudice. So, please would you stop to
teach me that lesson?
Or maybe by posting my 2 cents I asked for it ...

Re: [Fetchmail-users] Password length restriction

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

Am 15.07.20 um 16:42 schrieb Zsolt Barat:
> I'm using following fetchmail version:
>
> 6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5

6.3.X is a museum piece from 2013 and unsupported on this list, and I
don't care to look back to what it might have done for such questions.

Password buffers in 6.4.X are allocated dynamically, and there may be
undocumented limitations on your mail service provider's (MSP's) end. 30
certainly does not seem too long to me, but might be for your MSP.

[Fetchmail-users] Password length restriction

[Zsolt B. <z....@he...>]

Hi there,

just wanted to ask if there is a known restriction of the password
length for authenticating to a POP3 server.

I recognized problems while using a password with more than 30
characters, authenticating to gmx.net servers.

I'm using following fetchmail version:

6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5

On openSUSE Leap 15.1


Best regards

Zsolt

-- 
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin
  
https://www.heinlein-support.de
 
Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19
  
Amtsgericht Berlin-Charlottenburg - HRB 93818 B
Geschäftsführer: Peer Heinlein - Sitz: Berlin

[Fetchmail-users] ANNOUNCE: The 6.5.0.beta1 snapshot of fetchmail is available (newer than the devel20200711)

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

The 6.5.0.beta1 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5//fetchmail-6.5.0.beta1.tar.lz>
And its GnuPG signature at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5//fetchmail-6.5.0.beta1.tar.lz.asc>

You will need lzip to decompress the tarballs, if your OS does not ship it,
get it from https://www.nongnu.org/lzip/ 

The earlier development snapshots released today messed up the TLS cipher list
(<= 1.2) or ciphersuite (TLS >= 1.3) setting a bit, and also the error
checking. Let's just move forward to a -beta1.

Please guide feedback to the fetchmail-devel@ mailing list.

Here are the release notes - note the EXPERIMENTAL CHANGES section, which
has the most recent updates throughout today.

--------------------------------------------------------------------------------
fetchmail-6.5.0 (not yet released):

## REMOVED FEATURES
* fetchmail no longer supports using an MDA as SMTP fallback. This is required 
  to make deliveries consistent.
  The --enable-fallback configure option is gone.
* fetchmail no longer supports SSLv3. --sslproto ssl3 and ssl3+ options have
  been removed and behave as though "--sslproto auto" had been given.

## INCOMPATIBLE CHANGES
* fetchmail by default only negotiates TLS v1.2 or higher. (RFC-7525)
* fetchmail can auto-negotiate TLS v1.1 through the --sslproto tls1.1+ option.
* fetchmail can auto-negotiate TLS v1.0 through the --sslproto tls1+ option.
* fetchmailconf now requires Python 3.7.0 or newer.
* fetchmail, with --logfile, now logs time stamps into the file, in localtime
  and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized through
  the environment variables LC_TIME (or LC_ALL) and TZ.
  Contributed by Holger Hoffstätte.
* fetchmail sets the OPENSSL security level to 2 by default. This can only
  be changed in socket.c, look for SSL_min_security_level = 2.

## CHANGED REQUIREMENTS
* fetchmail 6.5.0 is written in C99 and requires a SUSv3 (Single Unix
  Specification v3, a superset of POSIX.1-2001 aka. IEEE Std 1003.1-2001 with
  XSI extension) compliant system.

  In particular, older fetchmail versions had workarounds or replacement code
  for several functions standardized in the Single Unix Specification v3, these 
  have been removed. Hence:
  - The trio/ library has been removed from the distribution.
  - The libesmtp/getaddrinfo.? library has been removed from the distribution.
  - The KAME/getnameinfo.c file has been removed from the distribution.

* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL,
  at a minimum OpenSSL v1.1.1.

## BUG FIXES
* fetchmail can now report mailbox sizes of 2^31 octets and beyond.
  This required C99 support (for the long long type).
  Fixes Debian Bug#873668, reported by Andreas Schmidt.
* fetchmail now defines its OpenSSL API level (1.1.1, or 10101) so
  as to compile with OpenSSL 3.0.0. (fetchmail was requesting to hide
  deprecated APIs.)

## CHANGES
* When fetchmail attempts to log out from an IMAP4 server and the server messes
  up its responses (it is supposed to send an untagged * BYE and a tagged
  A4711 OK) and sends a tagged A4711 BYE response, tolerate that, rather than
  reporting a protocol error. We don't intend to chat any more so the protocol
  violation is harmless, and we know the server cannot send more untagged
  status responses.
  Analysis and fix courtesy of Maciej S. Szmigiero, GitLab merge request !20.
* The configure script now spends more effort for getting --with-ssl right, by 
  running pkg-config in the right environment, and using the AC_LIB_LINKFLAGS 
  macro to obtain run-time library path setting flags.

## EXPERIMENTAL CHANGES - these are not documented anywhere else, only here:
* fetchmail supports a FETCHMAIL_SSL_SECLEVEL environment variable that
  can be used to override the OpenSSL security level. Fetchmail by default
  raises the security level to 2 if lower. This variable can be used to lower it.
  Use with extreme caution. Note that levels 3 or higher will frequently cause
  incompabilities with servers because server-side data sizes are often too low.
  Valid range: 0 to 5 for OpenSSL 1.1.1 and 3.0.0-alpha4.
* fetchmail supports a FETCHMAIL_SSL_CIPHERS environment variable that
  sets the cipher string (through two different OpenSSL functions) for SSL and
  TLS versions up to TLSv1.2.
  If setting the ciphers fails, fetchmail will not connect.
  If not given, defaults to Postfix's "medium" list, 
  "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH".
* fetchmail supports a FETCHMAIL_TLS13_CIPHERSUITES environment variable
  that sets the ciphersuites (a colon-separated list, without + ! -) for
  TLSv1.3. If not given, defaults to OpenSSL's built-in list. If setting the 
  ciphersuites fails, fetchmail refuses to connect.
* NOTE the features above are simplistic. For instance, even though you 
  configure --sslproto tls1.3, a failure to set tls1.2 ciphers could cause
  a connection abort.

# KNOWN BUGS AND WORKAROUNDS
  (This section usually floats upwards through the NEWS file so it stays with 
  the current release information)
* Fetchmail does not handle messages without Message-ID header well
* Fetchmail currently uses 31-bit signed integers in several places
  where unsigned and/or wider types should have been used, for instance,
  for mailbox sizes, and misreports sizes of 2 GibiB and beyond. 
* BSMTP is mostly untested and errors can cause corrupt output.
* Fetchmail does not track pending deletes across crashes.
* The command line interface is sometimes a bit stubborn, for instance,
  fetchmail -s doesn't work with a daemon running.
* Linux systems may return duplicates of an IP address in some circumstances if
  no or no global IPv6 addresses are configured.
  (No workaround. Ubuntu Bug#582585, Novell Bug#606980.)
* Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error
  messages. This will not be fixed, because the maintainer has no Kerberos 5
  server to test against. Use GSSAPI.

--------------------------------------------------------------------------------

[Fetchmail-users] ANNOUNCE: The 6.5.0.dev20200711b (note trailing letter B!) snapshot of fetchmail is available

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

Note the final letter of the version: A vs. B.

The 6.5.0.dev20200711b release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>.

NOTE: replies with your findings should go to the fetchmail-devel@ mailing
list, not -users@.

I've made some configure changes that should assist with finding and linking
against OpenSSL outside the typical paths, and also set the run-time linker
path (rpath) properly. Let me know if/where this regresses and then provide
me details (config.log, config.h and make logs) if it fails.

It also tightens up OpenSSL to security level 2, so if you know your mail
server is pretty old, let me know if it still works for you.

This is supposed to become a 6.5.0 in several months' time.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.dev20200711b.tar.lz>
GnuPG signature file:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.dev20200711b.tar.lz.asc>

Here are the release notes:

--------------------------------------------------------------------------------
## EXPERIMENTAL CHANGES - these are not documented anywhere else, only here:
* fetchmail supports a FETCHMAIL_SSL_SECLEVEL environment variable that
  can be used to override the OpenSSL security level. Fetchmail by default
  raises the security level to 2 if lower. This variable can be used to lower it.
  Use with extreme caution. Note that levels 3 or higher will frequently cause
  incompabilities with servers because server-side data sizes are often too low.
  Valid range: 0 to 5 for OpenSSL 1.1.1 and 3.0.0-alpha4.
* fetchmail supports a FETCHMAIL_SSL_CIPHERS environment variable that
  sets the cipher string (through two different OpenSSL functions) for all TLS
  versions. If setting the ciphers fails, fetchmail will not connect.
  If not given, defaults to Postfix's "medium" list, 
  "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH".
--------------------------------------------------------------------------------

[Fetchmail-users] ANNOUNCE: The 6.5.0.dev20200711a snapshot of fetchmail is available

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

The 6.5.0.dev20200711a release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>.

NOTE: replies with your findings should go to the fetchmail-devel@ mailing
list, not -users@.

I've made some configure changes that should assist with finding and linking
against OpenSSL outside the typical paths, and also set the run-time linker
path (rpath) properly. Let me know if/where this regresses and then provide
me details (config.log, config.h and make logs) if it fails.

It also tightens up OpenSSL to security level 2, so if you know your mail
server is pretty old, let me know if it still works for you.

This is supposed to become a 6.5.0 in several months' time.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.dev20200711a.tar.lz>

There's also a GnuPG signature file (with .asc appended) available.

Here are the release notes:

--------------------------------------------------------------------------------
fetchmail-6.5.0 (not yet released):

## REMOVED FEATURES
* fetchmail no longer supports using an MDA as SMTP fallback. This is required 
  to make deliveries consistent.
  The --enable-fallback configure option is gone.
* fetchmail no longer supports SSLv3. --sslproto ssl3 and ssl3+ options have
  been removed and behave as though "--sslproto auto" had been given.

## INCOMPATIBLE CHANGES
* fetchmail by default only negotiates TLS v1.2 or higher. (RFC-7525)
* fetchmail can auto-negotiate TLS v1.1 through the --sslproto tls1.1+ option.
* fetchmail can auto-negotiate TLS v1.0 through the --sslproto tls1+ option.
* fetchmailconf now requires Python 3.7.0 or newer.
* fetchmail, with --logfile, now logs time stamps into the file, in localtime
  and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized through
  the environment variables LC_TIME (or LC_ALL) and TZ.
  Contributed by Holger Hoffstätte.
* fetchmail sets the OPENSSL security level to 2 by default. This can only
  be changed in socket.c, look for SSL_min_security_level = 2.

## CHANGED REQUIREMENTS
* fetchmail 6.5.0 is written in C99 and requires a SUSv3 (Single Unix
  Specification v3, a superset of POSIX.1-2001 aka. IEEE Std 1003.1-2001 with
  XSI extension) compliant system.

  In particular, older fetchmail versions had workarounds or replacement code
  for several functions standardized in the Single Unix Specification v3, these 
  have been removed. Hence:
  - The trio/ library has been removed from the distribution.
  - The libesmtp/getaddrinfo.? library has been removed from the distribution.
  - The KAME/getnameinfo.c file has been removed from the distribution.

* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL,
  at a minimum OpenSSL v1.1.1.

## BUG FIXES
* fetchmail can now report mailbox sizes of 2^31 octets and beyond.
  This required C99 support (for the long long type).
  Fixes Debian Bug#873668, reported by Andreas Schmidt.
* fetchmail now defines its OpenSSL API level (1.1.1, or 10101) so
  as to compile with OpenSSL 3.0.0. (fetchmail was requesting to hide
  deprecated APIs.)

## CHANGES
* When fetchmail attempts to log out from an IMAP4 server and the server messes
  up its responses (it is supposed to send an untagged * BYE and a tagged
  A4711 OK) and sends a tagged A4711 BYE response, tolerate that, rather than
  reporting a protocol error. We don't intend to chat any more so the protocol
  violation is harmless, and we know the server cannot send more untagged
  status responses.
  Analysis and fix courtesy of Maciej S. Szmigiero, GitLab merge request !20.
* The configure script now spends more effort for getting --with-ssl right, by 
  running pkg-config in the right environment, and using the AC_LIB_LINKFLAGS 
  macro to obtain run-time library path setting flags.

# KNOWN BUGS AND WORKAROUNDS
  (This section floats upwards through the NEWS file so it stays with the
  current release information)
* Fetchmail does not handle messages without Message-ID header well
  (See sourceforge.net bug #780933)
* Fetchmail currently uses 31-bit signed integers in several places
  where unsigned and/or wider types should have been used, for instance,
  for mailbox sizes, and misreports sizes of 2 GibiB and beyond. 
  Fixing this requires C89 compatibility to be relinquished.
* BSMTP is mostly untested and errors can cause corrupt output.
* Fetchmail does not track pending deletes across crashes.
* The command line interface is sometimes a bit stubborn, for instance,
  fetchmail -s doesn't work with a daemon running.
* Linux systems may return duplicates of an IP address in some circumstances if
  no or no global IPv6 addresses are configured.
  (No workaround. Ubuntu Bug#582585, Novell Bug#606980.)
* Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error
  messages. This will not be fixed, because the maintainer has no Kerberos 5
  server to test against. Use GSSAPI.
--------------------------------------------------------------------------------

Happy fetches,
Matthias

Re: [Fetchmail-users] fetchmail and ssl certificates

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

Am 07.07.20 um 14:00 schrieb Ranjan Maitra:
> On Thu, 2 Jul 2020 21:13:00 +0200 Matthias Andree <mat...@gm...> wrote:
>
>> Am 02.07.20 um 15:28 schrieb Ranjan Maitra:
>>> Hi,
>>>
>>> Here is my .fetchmailrc
>>>
>>> set daemon 301
>>> poll pop.gmx.com
>>>      protocol POP3
>>>      service 995
>>>      authenticate password
>>>      user "use...@gm..."
>>>      ssl
>>>      sslfingerprint "5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA"
>>> mda 'procmail -d %s'
>>> keep
>>>
>>> ...
>>> verify return:1
>>> SHA1 Fingerprint=5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA
>>>
>>> Any suggestions as to what I am doing wrong?
>>>
>>> I am on F32 (fully updated) which has fetchmail-6.4.1 and openssl-1:1.1.1g.
>>>
>>> Many thanks,
>>> Ranjan
>> Perhaps they have corrected the issue, because I currently get this with
>> -cvv and the subjectAltName seems to cover their usage.
>>
>> ...
>> fetchmail: pop.gmx.com key fingerprint:
>> A5:6D:6D:D4:2D:BE:4D:F5:0A:3A:DD:3E:A6:C2:D3:E8
>> fetchmail: SSL/TLS: using protocol TLSv1.3, cipher
>> TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
>> fetchmail: POP3< +OK POP server ready H migmx003 1M7L3e-1jjMxZ1u5E-007l8Y
>> ...
>>
> Thank you for this. I have changed my fingerprint to match what you write, and this seems to work. It is interesting why the other command
> gives an incorrect fingerprint.

Ranjan,

It is not incorrect, but calculated differently, with a different hash
function. The default fetchmail fingerprint in 6.3 and 6.4 is MD5 (which
IS specified in the manual page of 6.4.x in the prose describing
--sslcertck), while your OpenSSL command output shows an SHA1 hash and
was not obtained with the suggested openssl command line from the
manual. I found one place in the manual where I've added the MD5 name,
but that's not yet released. Should appear in 6.4.9 if one is needed or
else the next 6.5.x.

Fetchmail 6.X shall continue to use MD5 for compatibility reasons, but
we'll need to change that to a more secure hash in a future fetchmail
version, and also mention what hash is being used to avoid confusion.

Regards,
Matthias

Re: [Fetchmail-users] build errors for fetchmail-6.4.8

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

Am 07.07.20 um 23:08 schrieb Peter Scott:
> Dear Matthias,
>
> Thanks for your note, with its suggestion to try adding
> "--with-ssl=/opt/openssl" to the ./configure command.
>
> It turns out that did not help, so I will abandon my attempts to
> compile fetchmail-6.4.8 on my ancient Scientific Linux 6.10 OS,
> where by necessity there is the older openssl-1.0.1e-fips
> in addition to openssl-1.1.1g.
>
> I'm in the process of migrating to Fedora 32 on a new drive
> (where everything works much more smoothly), and arranging new
> email there, with sendmail, fetchmail, procmail, bogofilter and
> mutt, all quite speedy and working well.

Peter, I appreciate you may not want to sink indefinite amounts of time
when you can migrate to a modern platform instead, but two remarks:

1. I really would like to understand if that was a system issue on your
end, or if there are lingering bugs in fetchmail's configure[.ac] script
that I could fix.
Hence, your failing configure command line and environment and
corresponding config.log would still help so I can check the particular
code path it was using in your case.

2. I actively discourage using procmail. it has been rotting unmaintined
for shy of 20 years... I'll quote the fetchmail manual page for tech
reasons:

>               The well-known procmail(1) package is very hard to
> configure properly, it has a very nasty "fall  through  to  the
>               next rule" behavior on delivery errors (even temporary
> ones, such as out of disk space if another user's mail dae‐
>               mon copies the mailbox around to purge old messages), so
> your mail will end up in  the  wrong  mailbox  sooner  or
>               later.  The proper procmail configuration is outside the
> scope of this document. Using maildrop(1) is usually much
>               easier, and many users find the filter syntax used by
> maildrop easier to understand.

Re: [Fetchmail-users] build errors for fetchmail-6.4.8

[Peter S. <dr...@uc...>]

Dear Matthias,

Thanks for your note, with its suggestion to try adding
"--with-ssl=/opt/openssl" to the ./configure command.

It turns out that did not help, so I will abandon my attempts to
compile fetchmail-6.4.8 on my ancient Scientific Linux 6.10 OS,
where by necessity there is the older openssl-1.0.1e-fips
in addition to openssl-1.1.1g.

I'm in the process of migrating to Fedora 32 on a new drive
(where everything works much more smoothly), and arranging new
email there, with sendmail, fetchmail, procmail, bogofilter and
mutt, all quite speedy and working well.

Thanks so much,

     -- Peter

=================================================================
On Jul 03, 2020 at 11:04 pm, Matthias Andree <mat...@gm...> wrote:
| Am 03.07.20 um 22:32 schrieb Peter Scott:
| > Dear Matthias,
| >
| > Sure, feel free to quote anything you like on the list.  [...]
| 
| Peter,
| 
| Thanks for the permission to answer in public.
| 
| > On Fri, Jul 3, 2020 at 8:50 AM Matthias Andree <mat...@gm...
| > <mailto:mat...@gm...>> wrote:
| >
| >     Peter,
| >
| >     can I fullquote and answer on the mailing list, please?
| >     [...]
| >
| >     It might also help if you re-sent your previous mail to the list
| >     instead, so we get the solution into the archives.
| >
| >     Regards
| >     Matthias
| >
| >     Am 02.07.20 um 23:29 schrieb Peter Scott:
| >     > Matthias,
| >     >
| >     > Thanks for your comments.  I suspect my problem is that I have two
| >     > versions of openssl.
| >     > My OS is Scientific Linux-6.10 (like RHEL-6 or CentOS-6) for
| >     which the
| >     > openssl (shipped) version is OpenSSL 1.0.1e-fips 11 Feb 2013.
| >     > This is too old for fetchmail-6.4.8.
| >     > So I got the source for OpenSSL 1.1.1g  21 Apr 2020, which compiled
| >     > and installed in /opt/openssl with no glitches, and seems to work.
| >     >
| >     > Then to configure and build fetchmail-6.4.8, I first exported
| >     > LD_LIBRARY_PATH=/opt/openssl/lib and PATH=/opt/openssl/bin:$PATH.
| >     > Then for fetchmail-6.4.8, I did ./configure --prefix=$HOME.  This
| >     > completed, however there are these suspicious lines, especially
| >     > the WARNING line, and the first line below referring to a pkg-config
| >     > binary.
| >
| So the thing is if the system has multiple implementations, then it's in
| for a bit of a rough ride because I suppose you don't have a pkg-config
| in /opt/openssl/bin. So I think it's worth trying to add
| "--with-ssl=/opt/openssl" to the ./configure command line and retry from
| there. If it doesn't work, I'll need the full config.log to analyze
| whether configure is doing the right thing (given my other commitments
| over the next days, paste to https://paste.debian.net/ and please set
| expiry to 90 days so it's still there when I have time to look).
| 
| >     >
| >     > checking for pkg-config... /usr/bin/pkg-config
| >     > checking pkg-config is at least version 0.9.0... yes
| >     > checking for SSL... yes
| >     > configure: Enabling SSL support.
| >     > checking whether TLS1_3_VERSION is declared... no
| >     > configure: WARNING: Your OpenSSL version is too old and does not
| >     > support TLS v1.3. Upgrade.
| >
| This is a hint it picked up the older OpenSSL 1.0.x.
| 
| 
| >     >
| >     > So my question: Is there anything I can add to the ./configure that
| >     > will demand that the appropriate
| >     > openssl libraries will be consulted?  (I'm thinking that
| >     > /usr/bin/pkg-config finds the wrong libraries.)
| >
| Yes. ./configure --your --other --options --with-ssl=/opt/openssl might
| do the trick. If pkg-config picks up the wrong version again, you may
| need to temporarily deinstall it during ./configure, as a workaround -
| then I'll definitely need the full config.log as written above so I can
| try to find the bug and remove it.
| 
| 
| 
| 

Re: [Fetchmail-users] fetchmail and ssl certificates

[Ranjan M. <ma...@em...>]

On Thu, 2 Jul 2020 21:13:00 +0200 Matthias Andree <mat...@gm...> wrote:

> Am 02.07.20 um 15:28 schrieb Ranjan Maitra:
> > Hi,
> >
> > Here is my .fetchmailrc
> >
> > set daemon 301
> > poll pop.gmx.com
> >      protocol POP3
> >      service 995
> >      authenticate password
> >      user "use...@gm..."
> >      ssl
> >      sslfingerprint "5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA"
> > mda 'procmail -d %s'
> > keep
> >
> > So, it worked fine till last night, but since this morning, this has not been working. Here is what I get:
> >
> > $ fetchmail -c
> > fetchmail: pop.gmx.com fingerprints do not match!
> > fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
> > fetchmail: pop.gmx.com: SSL connection failed.
> > fetchmail: socket error while fetching from use...@gm...@pop.gmx.com
> >
> >
> > Here is how I verified my fingerprint:
> >
> > ~$ openssl s_client -servername gmx.com -connect pop.gmx.com:995 | openssl x509 -fingerprint -noout
> > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
> > verify return:1
> > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018
> > verify return:1
> > depth=0 C = DE, ST = Rheinland-Pfalz, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = mout.gmx.com
> > verify return:1
> > SHA1 Fingerprint=5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA
> >
> > Any suggestions as to what I am doing wrong?
> >
> > I am on F32 (fully updated) which has fetchmail-6.4.1 and openssl-1:1.1.1g.
> >
> > Many thanks,
> > Ranjan
>
> Perhaps they have corrected the issue, because I currently get this with
> -cvv and the subjectAltName seems to cover their usage.
>
> ...
> fetchmail: Server certificate:
> fetchmail: Issuer Organization: DigiCert Inc
> fetchmail: Issuer CommonName: GeoTrust RSA CA 2018
> fetchmail: Subject CommonName: mout.gmx.com
> fetchmail: Subject Alternative Name: mout.gmx.com
> fetchmail: Subject Alternative Name: mail.gmx.com
> fetchmail: Subject Alternative Name: mx00.gmx.com
> fetchmail: Subject Alternative Name: mx01.gmx.com
> fetchmail: Subject Alternative Name: pop.gmx.com
> fetchmail: Subject Alternative Name: imap.gmx.com
> fetchmail: Subject Alternative Name: smtp.gmx.com
> fetchmail: pop.gmx.com key fingerprint:
> A5:6D:6D:D4:2D:BE:4D:F5:0A:3A:DD:3E:A6:C2:D3:E8
> fetchmail: SSL/TLS: using protocol TLSv1.3, cipher
> TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
> fetchmail: POP3< +OK POP server ready H migmx003 1M7L3e-1jjMxZ1u5E-007l8Y
> ...
>

Thank you for this. I have changed my fingerprint to match what you write, and this seems to work. It is interesting why the other command
gives an incorrect fingerprint.

Thanks again and best wishes,
Ranjan
--
Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For
those needing to send personal or professional e-mail, please use appropriate addresses.

Re: [Fetchmail-users] build errors for fetchmail-6.4.8

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

Am 03.07.20 um 22:32 schrieb Peter Scott:
> Dear Matthias,
>
> Sure, feel free to quote anything you like on the list.  [...]

Peter,

Thanks for the permission to answer in public.

> On Fri, Jul 3, 2020 at 8:50 AM Matthias Andree <mat...@gm...
> <mailto:mat...@gm...>> wrote:
>
>     Peter,
>
>     can I fullquote and answer on the mailing list, please?
>     [...]
>
>     It might also help if you re-sent your previous mail to the list
>     instead, so we get the solution into the archives.
>
>     Regards
>     Matthias
>
>     Am 02.07.20 um 23:29 schrieb Peter Scott:
>     > Matthias,
>     >
>     > Thanks for your comments.  I suspect my problem is that I have two
>     > versions of openssl.
>     > My OS is Scientific Linux-6.10 (like RHEL-6 or CentOS-6) for
>     which the
>     > openssl (shipped) version is OpenSSL 1.0.1e-fips 11 Feb 2013.
>     > This is too old for fetchmail-6.4.8.
>     > So I got the source for OpenSSL 1.1.1g  21 Apr 2020, which compiled
>     > and installed in /opt/openssl with no glitches, and seems to work.
>     >
>     > Then to configure and build fetchmail-6.4.8, I first exported
>     > LD_LIBRARY_PATH=/opt/openssl/lib and PATH=/opt/openssl/bin:$PATH.
>     > Then for fetchmail-6.4.8, I did ./configure --prefix=$HOME.  This
>     > completed, however there are these suspicious lines, especially
>     > the WARNING line, and the first line below referring to a pkg-config
>     > binary.
>
So the thing is if the system has multiple implementations, then it's in
for a bit of a rough ride because I suppose you don't have a pkg-config
in /opt/openssl/bin. So I think it's worth trying to add
"--with-ssl=/opt/openssl" to the ./configure command line and retry from
there. If it doesn't work, I'll need the full config.log to analyze
whether configure is doing the right thing (given my other commitments
over the next days, paste to https://paste.debian.net/ and please set
expiry to 90 days so it's still there when I have time to look).

>     >
>     > checking for pkg-config... /usr/bin/pkg-config
>     > checking pkg-config is at least version 0.9.0... yes
>     > checking for SSL... yes
>     > configure: Enabling SSL support.
>     > checking whether TLS1_3_VERSION is declared... no
>     > configure: WARNING: Your OpenSSL version is too old and does not
>     > support TLS v1.3. Upgrade.
>
This is a hint it picked up the older OpenSSL 1.0.x.


>     >
>     > So my question: Is there anything I can add to the ./configure that
>     > will demand that the appropriate
>     > openssl libraries will be consulted?  (I'm thinking that
>     > /usr/bin/pkg-config finds the wrong libraries.)
>
Yes. ./configure --your --other --options --with-ssl=/opt/openssl might
do the trick. If pkg-config picks up the wrong version again, you may
need to temporarily deinstall it during ./configure, as a workaround -
then I'll definitely need the full config.log as written above so I can
try to find the bug and remove it.

Re: [Fetchmail-users] fetchmail and ssl certificates

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

Am 02.07.20 um 15:28 schrieb Ranjan Maitra:
> Hi,
>
> Here is my .fetchmailrc
>
> set daemon 301
> poll pop.gmx.com
>      protocol POP3
>      service 995
>      authenticate password
>      user "use...@gm..."
>      ssl
>      sslfingerprint "5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA"
> mda 'procmail -d %s'
> keep
>
> So, it worked fine till last night, but since this morning, this has not been working. Here is what I get:
>
> $ fetchmail -c
> fetchmail: pop.gmx.com fingerprints do not match!
> fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
> fetchmail: pop.gmx.com: SSL connection failed.
> fetchmail: socket error while fetching from use...@gm...@pop.gmx.com
>
>
> Here is how I verified my fingerprint:
>
> ~$ openssl s_client -servername gmx.com -connect pop.gmx.com:995 | openssl x509 -fingerprint -noout
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
> verify return:1
> depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018
> verify return:1
> depth=0 C = DE, ST = Rheinland-Pfalz, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = mout.gmx.com
> verify return:1
> SHA1 Fingerprint=5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA
>
> Any suggestions as to what I am doing wrong?
>
> I am on F32 (fully updated) which has fetchmail-6.4.1 and openssl-1:1.1.1g.
>
> Many thanks,
> Ranjan

Perhaps they have corrected the issue, because I currently get this with
-cvv and the subjectAltName seems to cover their usage.

...
fetchmail: Server certificate:
fetchmail: Issuer Organization: DigiCert Inc
fetchmail: Issuer CommonName: GeoTrust RSA CA 2018
fetchmail: Subject CommonName: mout.gmx.com
fetchmail: Subject Alternative Name: mout.gmx.com
fetchmail: Subject Alternative Name: mail.gmx.com
fetchmail: Subject Alternative Name: mx00.gmx.com
fetchmail: Subject Alternative Name: mx01.gmx.com
fetchmail: Subject Alternative Name: pop.gmx.com
fetchmail: Subject Alternative Name: imap.gmx.com
fetchmail: Subject Alternative Name: smtp.gmx.com
fetchmail: pop.gmx.com key fingerprint:
A5:6D:6D:D4:2D:BE:4D:F5:0A:3A:DD:3E:A6:C2:D3:E8
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher
TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
fetchmail: POP3< +OK POP server ready H migmx003 1M7L3e-1jjMxZ1u5E-007l8Y
...