fetchmail-users — User questions and discussion

Re: [Fetchmail-users] logrotate options?

[gene h. <ghe...@sh...>]

On Wednesday, January 19, 2022 4:35:35 PM EST Joe Acquisto-j4 wrote:
> This is fetchmail release 6.4.21+SSL-SSLv2-SSLv3+NLS
> 
> Looking for examples I can follow to implement log rotation with
> fetchmail.   Links, examples, tutorials kindly accepted.
> 
> 
Log rotation I thought was part of the install. But I've not used that 
canned script in years, because I long ago edited it, to rotate the logs 
in $user/logs, doing away forever with perms problems if it was logging 
to /var/log/fetchmail.log. Logrotate doing its thing in /var/log, always 
restoring root perms is a pita, but here I'm the only user, why can't I 
put a tail on it? logging to /home/me/log puts a stop to all that 
baloney. 

> 
> _______________________________________________
> 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, 1940)
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] logrotate options?

[Peter P. <ro...@ri...>]

On Wed, Jan 19, 2022 at 04:35:35PM -0500, Joe Acquisto-j4 wrote:
> This is fetchmail release 6.4.21+SSL-SSLv2-SSLv3+NLS
> 
> Looking for examples I can follow to implement log rotation with
> fetchmail.   Links, examples, tutorials kindly accepted.

If you have the logrotate tool installed on your system, the fetchmail
source contains a sample fetchmail.logrotate file:

  https://gitlab.com/fetchmail/fetchmail/-/blob/next/contrib/fetchmail.logrotate

Of course, you can customize it however you wish - specify different
rotation criteria, point to a different fetchmail logfile - but, most
importantly, you will most probably need to modify the command to be
executed after the logfile has been rotated - the contents of
the logrotate configuration file's "postrotate" section.
In the sample file, the command in the postrotate section is a POSIX
shell "if" statement that examines the server that it is running on and
figures out the appropriate command to run to make the fetchmail
instance that is running as a system service reopen its logfiles.

If you run fetchmail as root, something like that will probably work for
you. If you run fetchmail from a normal user account, there might be
a slight problem here, since the logrotate tool will need to restart
fetchmail. So if your fetchmail instance is run under some kind of
service manager (supervise, runsv, a systemd user service, etc), then
the postrotate section is where you place the appropriate command to
restart that particular service.

Of course, if you run fetchmail under some kind of service manager, then
there may be no need for a separate logfile at all, since most of
the service managers can already handle a program that sends messages to
its standard output stream, as fetchmail does by default in daemon mode.
So that service manager's functionality may already provide some kind of
log storage and rotation, and you don't need the logrotate tool.

Hope that helps! In short, it all depends on how you run fetchmail.

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[Fetchmail-users] logrotate options?

[Joe Acquisto-j. <jo...@j4...>]

This is fetchmail release 6.4.21+SSL-SSLv2-SSLv3+NLS

Looking for examples I can follow to implement log rotation with fetchmail.   Links, examples, tutorials kindly accepted.

Re: [Fetchmail-users] Is it possible to have fetchmail chk /var/spool/mail/

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

Am 15.01.22 um 17:15 schrieb Peter Pentchev:
> On Sat, Jan 15, 2022 at 04:26:11PM +0100, Matthias Andree wrote:
>> Am 15.01.22 um 16:21 schrieb hput via Fetchmail-users:
>>> If it is possible to have fetchmail check for mail at
>>> /var/spool/mail/MY-USER
>>>
>>> Can anyone give me a few clues as to how that would be entered into
>>> ~/.fetchmailrc along with the polls of pop3 servers.
>> Harry,
>>
>> Why would anyone need that?
> It is possible that their setup is the same as mine here - fetchmail
> handling a couple of remote accounts and delivering to a Maildir in
> my home directory, and me wondering what to do with the messages that
> my local system is sending to me - cron reports, apt-listchanges after
> updates, sbuild logs, etc. For the present I've made a symlink making
> it easier to point Mutt at it every now and then, and that's enough
> for me personally.
>> /var/spool/mail/$USER is traditionally where fetchmail would *PLACE*
>> downloaded mail by means of a mail delivery agent or mail transport
>> agent, not *FIND* it.
>>
>> Consequently, fetchmail cannot do that, and it is unlikely it ever will,
>> because that would be reversing the purpose. It is way out of scope.
> Of course, one *could* run a local POP3/IMAP server with a simple
> configuration that only provides access to this one account and
> this one mailbox... It might be a bit of overkill, but it would allow
> fetchmail to query it and move the mail somewhere else.

Guys,

after reading through Russell's and Peter's replies,

sorry for not making clear that my "why" question was a rhetorical and
suggestive question.
My implication was "nobody should need that", on the assumption that one
should not use third-party software (= fetchmail) to patch around what I
perceive as local configuration inconsistencies. I surely would NOT want
my system to generally, excuse me, litter my mail around to various piles.

Thanks for imagining some creative approaches on how *not* to configure
a system.

Further thoughts on why my "no" isn't just a simple brush-off:

* it takes quite a bit of hoop-jumping (meaning more effort than just
using default settings) to make fetchmail deliver to *different* place
from where the system would send locally-originating email.
   Default is to talk SMTP to localhost and ship to the user invoking
fetchmail, and I do not see how that would then differ from delivery of
locally-originated mail, unless someone deliberately set it up for some
purpose.
   Alternatively, fetchmail could use the same MDA as the rest of the
system.

* for locally-originated mail, my expectation is that the mail delivery
mechanism (or local mail server) allows for configuring where your mail
goes.
If it does not allow that, swap it out and install software that serves
the purpose. That serves both (1) unifying where mail goes no matter if
fetchmail fetches it or the local system generates it, and (2) the
purpose of forwarding somewhere else. Consistently.
Traditionally, we have used ~/.forward files, which also supported
pipe-syntax to feed the messages into configurable software, for
instance, maildrop.

* if your distribution only ships a dumbed-down local delivery agent,
complain there.

* if you have multiple mail servers competing for the various inbound
mail paths, then either fix that by removing one and transferring some
equivalent configuration to another, or align their configurations.


Does that leave any reasonably valid use cases outside laziness to "get
my system configured consistently and properly", and that would fall
within fetchmail's scope "fetch mail from a remote system via some
network protocol"?
Note I am sking "reasonably valid", not "freakingly astonishingly
strangely imaginable" purpose.

Regards,
Matthias

Re: [Fetchmail-users] Is it possible to have fetchmail chk /var/spool/mail/

[Peter P. <ro...@ri...>]

On Sat, Jan 15, 2022 at 04:26:11PM +0100, Matthias Andree wrote:
> Am 15.01.22 um 16:21 schrieb hput via Fetchmail-users:
> > If it is possible to have fetchmail check for mail at
> > /var/spool/mail/MY-USER
> > 
> > Can anyone give me a few clues as to how that would be entered into
> > ~/.fetchmailrc along with the polls of pop3 servers.
> 
> Harry,
> 
> Why would anyone need that?

It is possible that their setup is the same as mine here - fetchmail
handling a couple of remote accounts and delivering to a Maildir in
my home directory, and me wondering what to do with the messages that
my local system is sending to me - cron reports, apt-listchanges after
updates, sbuild logs, etc. For the present I've made a symlink making
it easier to point Mutt at it every now and then, and that's enough
for me personally.

> /var/spool/mail/$USER is traditionally where fetchmail would *PLACE*
> downloaded mail by means of a mail delivery agent or mail transport
> agent, not *FIND* it.
> 
> Consequently, fetchmail cannot do that, and it is unlikely it ever will,
> because that would be reversing the purpose. It is way out of scope.

Of course, one *could* run a local POP3/IMAP server with a simple
configuration that only provides access to this one account and
this one mailbox... It might be a bit of overkill, but it would allow
fetchmail to query it and move the mail somewhere else.

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: [Fetchmail-users] Is it possible to have fetchmail chk /var/spool/mail/

[<rus...@gm...>]

	Fragt hput via Fetchmail-users:
	'If it is possible to have fetchmail check for mail at /var/spool/mail/MY-USER'

	schrieb Matthias, 'Why would anyone need that?'

	Quoth I, 'Because, when I fetch mail, if there is any, I want
to read it.'
	Thus I use a script that runs fetchmail, then checks
/var/spool/mail/MY-USER for non-zeroness, runs mail if non-zero.

russell bell

Re: [Fetchmail-users] Is it possible to have fetchmail chk /var/spool/mail/

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

Am 15.01.22 um 16:21 schrieb hput via Fetchmail-users:
> If it is possible to have fetchmail check for mail at
> /var/spool/mail/MY-USER
>
> Can anyone give me a few clues as to how that would be entered into
> ~/.fetchmailrc along with the polls of pop3 servers.

Harry,

Why would anyone need that?

/var/spool/mail/$USER is traditionally where fetchmail would *PLACE*
downloaded mail by means of a mail delivery agent or mail transport
agent, not *FIND* it.

Consequently, fetchmail cannot do that, and it is unlikely it ever will,
because that would be reversing the purpose. It is way out of scope.

Regards,
Matthias

[Fetchmail-users] Is it possible to have fetchmail chk /var/spool/mail/

[hput <hp...@zo...>]

If it is possible to have fetchmail check for mail at
/var/spool/mail/MY-USER

Can anyone give me a few clues as to how that would be entered into
~/.fetchmailrc along with the polls of pop3 servers.

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.26 is available (Serbian translation updates, workaround added for some servers when wolfSSL 5.0.0 is used)

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

The 6.4.26 release of fetchmail is now available at the usual locations,
including <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

DISTRIBUTORS please note OpenSSL's licensing change for OpenSSL 3,
and you may want to review COPYING. NOTE that LibreSSL licensing
is incompatible with fetchmail's, as there is no GPL clause 2(b) 
exception for LibreSSL, so LibreSSL can only be used where it is
part of the operating system (one of the very few examples is OpenBSD).

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.26.tar.xz/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.26.tar.lz/download>

The detached GnuPG signature is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.26.tar.xz.asc/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.26.tar.lz.asc/download>

The SHA256 hashes for the tarballs are:
SHA256(fetchmail-6.4.26.tar.xz)= 2cc8a94bfaaf794687b2b2147786508f30da598d1ab035c345d731928ac40c9a
SHA256(fetchmail-6.4.26.tar.lz)= 18060c9a3aa4b0eb31fdf3543503313a136aac5b979d5a8fcba8e886fbd188ab

Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.4.26 (released 2021-12-26, 31661 LoC):

# FIXES:
* When using wolfSSL 5.0.0, work around a bug that appears to hit wolfSSL when
  receiving handshake records while still in SSL_peek(). Workaround is to read
  1 byte and cache it, then call SSL_peek() again.
  This affects only some servers. https://github.com/wolfSSL/wolfssl/issues/4593

# TRANSLATIONS: language translations were updated by this fine person:
* sr:    Мирослав Николић (Miroslav Nikolić) [Serbian]
--------------------------------------------------------------------------------

Happy fetches,
Matthias

Re: [Fetchmail-users] google oauth2 refresh token expiration

[Nerijus B. <ne...@us...>]

2021-12-22 15:02, Andrew C Aitchison wrote:

>> Yes, it seems it was because of OAuth consent screen had Publishing status: 
>> Testing.
>> I changed it to Production and refresh token does not expire for 2 weeks 
>> already.
> 
> Which version of fetchmail is this: 6.4, 6.5 or 7 ?

7.0.0-alpha9.

Re: [Fetchmail-users] google oauth2 refresh token expiration

[Nerijus B. <ne...@us...>]

Hello,

Yes, it seems it was because of OAuth consent screen had Publishing status: 
Testing.
I changed it to Production and refresh token does not expire for 2 weeks 
already.

2021-11-25 11:13, Nerijus Baliunas via Fetchmail-users wrote:
> Hello,
> 
> I setup fetchmail to get email from gmail according to README.OAUTH2. It 
> works for exactly a week
> and then stops:
> 
> $ ./fetchmail-oauth2.py -c ... --refresh
> Traceback (most recent call last):
>   File "/home/user/./fetchmail-oauth2.py", line 567, in <module>
>     main(sys.argv)
>   File "/home/user/./fetchmail-oauth2.py", line 479, in main
>     response = RefreshToken(cfg['client_id'],cfg['client_secret'],reftok,
>   File "/home/user/./fetchmail-oauth2.py", line 368, in RefreshToken
>     response = urlopen.urlopen(token_url,
>   File "/usr/lib64/python3.10/urllib/request.py", line 216, in urlopen
>     return opener.open(url, data, timeout)
>   File "/usr/lib64/python3.10/urllib/request.py", line 525, in open
>     response = meth(req, response)
>   File "/usr/lib64/python3.10/urllib/request.py", line 634, in http_response
>     response = self.parent.error(
>   File "/usr/lib64/python3.10/urllib/request.py", line 563, in error
>     return self._call_chain(*args)
>   File "/usr/lib64/python3.10/urllib/request.py", line 496, in _call_chain
>     result = func(*args)
>   File "/usr/lib64/python3.10/urllib/request.py", line 643, in 
> http_error_default
>     raise HTTPError(req.full_url, code, msg, hdrs, fp)
> urllib.error.HTTPError: HTTP Error 400: Bad Request
> 
> It starts to work again for a week after I use fetchmail-oauth2.py 
> --obtain_refresh_token_file.
> Could it be because my Google app in OAuth consent screen has Publishing 
> status: Testing?
> 
> Regards,
> Nerijus

Re: [Fetchmail-users] wrong message length on every message

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

Am 17.12.21 um 02:38 schrieb hput via Fetchmail-users:
> 0S: ubuntu-21.10
> fetchmail release 6.4.22+SSL-SSLv2-SSLv3+NLS
> -------       -------       ---=---       -------       -------
>
> At one of the  pop3 servers I use I get messages like the one below for every
> message (wrapped for mail):
>
> ,----
> | fetchmail: message bl...@zo...@pop.zoho.com:12 was not the
> | expected length (1513 actual != 856 expected)
> `----
>
> At another  pop3 server I use, nothing like that ever happens.
>
> So suspicious it may be on the server side.  As you see that is:
> zohomail.com
>
> Can any of you here tell me what to make of the messages and whether
> it is likely a server problem or not.

Harry,

As you suspect, it is a server problem. Some servers compress their
storage and report the compressed size, and some miscount line endings.

As long as it does not causes issues on the mailserver (SMTP server)
your fetchmail forwards to, you can ignore this, and of course you can
tell the server operator to fix their POP3 server... and recommend RFC-1939.

HTH

Regards,
Matthias

[Fetchmail-users] wrong message length on every message

[hput <hp...@zo...>]

0S: ubuntu-21.10
fetchmail release 6.4.22+SSL-SSLv2-SSLv3+NLS
-------       -------       ---=---       -------       -------

At one of the  pop3 servers I use I get messages like the one below for every
message (wrapped for mail):

,----
| fetchmail: message bl...@zo...@pop.zoho.com:12 was not the
| expected length (1513 actual != 856 expected)
`----

At another  pop3 server I use, nothing like that ever happens.

So suspicious it may be on the server side.  As you see that is:
zohomail.com

Can any of you here tell me what to make of the messages and whether
it is likely a server problem or not.

Re: [Fetchmail-users] ANNOUNCE: fetchmail 6.4.25 is available (documentation & translation updates, wolfSSL 5.0, fix to OpenSSL 1.0.2 support for Let's Encrypt Sites, configure updates)

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

Am 10.12.21 um 20:59 schrieb Gene Heskett:
> This reminds me of the compuserve debacle over gif, so we invented png.
> Its about time a new ssl was written?

Gene,

that was quick...

Several years ago I was exploring alternatives, because OpenSSL at the
time was massively lacking in instructive and reference documentation,
but alternative libraries would have meant rewriting fetchmail's code
massively.
However, many other libraries were slow to adopt new protocol standards
(some still do not offer TLS 1.3), or were big-footprint and likewise
difficult with documentation at the time.

Then, in the wake of the heartbleed bug[1][2], LibreSSL was forked off
of OpenSSL, and OpenSSL extended their development resources, and has
shaped up nicely. About 1.1.0 I have largely forgotten, yet OpenSSL
1.1.1 to me from the client application programmer's perspective seems
more mature, and OpenSSL 3.0 appears likewise mature, there were only
few minute changes required to make fetchmail play nice with OpenSSL 3.0.

LibreSSL is a different story. It makes a mess of the version numbers,
does not fully render the OpenSSL API, and it has its quicks.
For fetchmail it is by and large a no-go license-wise anyways, unless
the operating system ships it (I only know of OpenBSD that does - a
separate package that gets installed later does not fit the bill), it is
infeasible.

wolfSSL 5.0.0 was an experiment - it was a library proposing an
OpenSSL-compatible API wrapper and GNU General Public License; it was
one Saturday to get the adaptations done, issues reported, and a few
more evening hours of polishing the configure.ac file. There is one
quirk we are working out and that fetchmail is working around already,
but I do not know how robust it would be for future wolfSSL versions.

So, with OpenSSL 3.0 out, and 1.1.1 also a quite reasonable
implementation, I do not feel a strong urge to switch. 3.0 no longer
requires the advertising, and its Apache license is compatible with the
GNU GPL v3, so with OpenSSL having matured and wolfSSL as an alternative
also under alternative license.

[1] https://heartbleed.com/
[2] https://en.wikipedia.org/wiki/Heartbleed

Re: [Fetchmail-users] ANNOUNCE: fetchmail 6.4.25 is available (documentation & translation updates, wolfSSL 5.0, fix to OpenSSL 1.0.2 support for Let's Encrypt Sites, configure updates)

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

On Fri, 10 Dec, 2021 at 2:25 PM, Matthias Andree <mat...@gm...> wrote:
 

To: fet...@li...; fet...@li...; fet...@li...
Greetings,

The 6.4.25 release of fetchmail is now available at 
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.>

DISTRIBUTORS please note OpenSSL's licensing change for OpenSSL 3,
and you may want to review COPYING. NOTE that LibreSSL licensing
is incompatible with fetchmail's, as there is no GPL clause 2(b) 
exception for LibreSSL, so LibreSSL can only be used where it is
part of the operating system (one of the very few examples is OpenBSD).

There have been several tweaks to improve the stability of the
configure script and build again.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.xz/download><https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.xz/download>>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.lz/download><https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.lz/download>>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.xz.asc/download><https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.xz.asc/download>>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.lz.asc/download><https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.lz.asc/download>>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.25.tar.lz)= ba94f3d9ea3e9dd55e59b7a08ca71edfdbc3e3ca1413a285aa8b08aaac923b05
SHA256(fetchmail-6.4.25.tar.xz)= 7ebefbe89172fd59f0fd8317d8743a8436f375ccdcab3900e4c3ec06a8fbf27f

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.25 (released 2021-12-10, 31653 LoC):

# BREAKING CHANGES:
* Since distributions continue patching for LibreSSL use, which cannot be
 linked legally, block out LibreSSL in configure.ac<http://configure.ac> and socket.c, and
 refer to COPYING, unless on OpenBSD (which ships it in the base system).
 OpenSSL and wolfSSL 5 can be used.  SSL-related documentation was updated, do 
 re-read COPYING, INSTALL, README, README.packaging, README.SSL.
* Bump OpenSSL version requirement to 1.0.2f in order to safely remove
 the obsolete OpenSSL flag SSL_OP_SINGLE_DH_USE. This blocks out 1.0.2e and 
 older 1.0.2 versions. 1.0.2f was a security fix release, and 1.0.2u is 
 publicly available from https://www.openssl.org/source/old/1.0.2/
* Some of the configure.ac<http://configure.ac> fiddling MIGHT have broken cross-compilation
 again. The maintainer does not test cross-compiling fetchmail; if you
 have difficulties, try setting PKG_CONFIG_LIBDIR to the pkg-config path
 containing your target/host libraries, or see if --with-ssl-prefix or 
 --with-wolfssl-prefix, or overriding LDFLAGS/LIBS/CPPFLAGS, can help.
 Feedback solicited on compliant systems that are before end-of-life.

# BUG FIXES:
* 6.4.24's workaround for OpenSSL 1.0.2's X509_V_FLAG_TRUSTED_FIRST flag
 contained a typo and would not kick in properly.
* Library and/or rpath setting from configure.ac<http://configure.ac> was fixed.

# ADDITIONS:
* Added an example systemd unit file and instructions to contrib/systemd/
 which runs fetchmail as a daemon with 5-minute poll intervals.
 Courteously contributed by Barak A. Pearlmutter, Debian Bug#981464.
* fetchmail can now be used with wolfSSL 5's OpenSSL compatibility layer,
 see INSTALL and README.SSL. This is considered experimental.
 Feedback solicited.

# CHANGES:
* The getstats.py<http://getstats.py> dist-tool now counts lines of .ac and .am files.
* ./configure --with-ssl now supports pkg-config module names, too. See INSTALL.

# TRANSLATIONS: language translations were updated by these fine people:
(in reverse alphabetical order of language codes so as not to prefer people):
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* pl:    Jakub Bogusz [Polish]
* ja:    Takeshi Hamasaki [Japanese]
* fr:    Frédéric Marchal [French]
* eo:    Keith Bowes [Esperanto]
* cs:    Petr Pisar [Czech]

# CREDITS:
* Thanks to Corey Halpin for testing release candidates.
--------------------------------------------------------------------------------

Happy fetches,
Matthias


This reminds me of the compuserve debacle over gif, so we invented png.
Its about time a new ssl was written?


Take care and stay well Matthias 
Gene

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.25 is available (documentation & translation updates, wolfSSL 5.0, fix to OpenSSL 1.0.2 support for Let's Encrypt Sites, configure updates)

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

Greetings,

The 6.4.25 release of fetchmail is now available at 
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

DISTRIBUTORS please note OpenSSL's licensing change for OpenSSL 3,
and you may want to review COPYING. NOTE that LibreSSL licensing
is incompatible with fetchmail's, as there is no GPL clause 2(b) 
exception for LibreSSL, so LibreSSL can only be used where it is
part of the operating system (one of the very few examples is OpenBSD).

There have been several tweaks to improve the stability of the
configure script and build again.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.xz/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.lz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.xz.asc/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.tar.lz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.25.tar.lz)= ba94f3d9ea3e9dd55e59b7a08ca71edfdbc3e3ca1413a285aa8b08aaac923b05
SHA256(fetchmail-6.4.25.tar.xz)= 7ebefbe89172fd59f0fd8317d8743a8436f375ccdcab3900e4c3ec06a8fbf27f

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.25 (released 2021-12-10, 31653 LoC):

# BREAKING CHANGES:
* Since distributions continue patching for LibreSSL use, which cannot be
  linked legally, block out LibreSSL in configure.ac and socket.c, and
  refer to COPYING, unless on OpenBSD (which ships it in the base system).
  OpenSSL and wolfSSL 5 can be used.  SSL-related documentation was updated, do 
  re-read COPYING, INSTALL, README, README.packaging, README.SSL.
* Bump OpenSSL version requirement to 1.0.2f in order to safely remove
  the obsolete OpenSSL flag SSL_OP_SINGLE_DH_USE. This blocks out 1.0.2e and 
  older 1.0.2 versions. 1.0.2f was a security fix release, and 1.0.2u is 
  publicly available from https://www.openssl.org/source/old/1.0.2/
* Some of the configure.ac fiddling MIGHT have broken cross-compilation
  again. The maintainer does not test cross-compiling fetchmail; if you
  have difficulties, try setting PKG_CONFIG_LIBDIR to the pkg-config path
  containing your target/host libraries, or see if --with-ssl-prefix or 
  --with-wolfssl-prefix, or overriding LDFLAGS/LIBS/CPPFLAGS, can help.
  Feedback solicited on compliant systems that are before end-of-life.

# BUG FIXES:
* 6.4.24's workaround for OpenSSL 1.0.2's X509_V_FLAG_TRUSTED_FIRST flag
  contained a typo and would not kick in properly.
* Library and/or rpath setting from configure.ac was fixed.

# ADDITIONS:
* Added an example systemd unit file and instructions to contrib/systemd/
  which runs fetchmail as a daemon with 5-minute poll intervals.
  Courteously contributed by Barak A. Pearlmutter, Debian Bug#981464.
* fetchmail can now be used with wolfSSL 5's OpenSSL compatibility layer,
  see INSTALL and README.SSL. This is considered experimental.
  Feedback solicited.

# CHANGES:
* The getstats.py dist-tool now counts lines of .ac and .am files.
* ./configure --with-ssl now supports pkg-config module names, too. See INSTALL.

# TRANSLATIONS: language translations were updated by these fine people:
(in reverse alphabetical order of language codes so as not to prefer people):
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* pl:    Jakub Bogusz [Polish]
* ja:    Takeshi Hamasaki [Japanese]
* fr:    Frédéric Marchal [French]
* eo:    Keith Bowes [Esperanto]
* cs:    Petr Pisar [Czech]

# CREDITS:
* Thanks to Corey Halpin for testing release candidates.
--------------------------------------------------------------------------------

Happy fetches,
Matthias

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.25 release candidate #4 available (wolfSSL support also on 32-bit FreeBSD, fixup Encrypt fix, configure.ac, add systemd example)

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

Greetings,

The 6.4.25 release CANDIDATE #4 of fetchmail is now available at
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

It fixes up the OpenSSL 1.0.2 workaround for Let's Encrypt Sites.
It contains support for wolfSSL 5.0, blocks out LibreSSL due to
licensing issues, and overhauls the configure script for OpenSSL.

release candidate #2 adds contrib/systemd (which see)
and makes some fixes to configure.ac. It updated some translations.

release candidate #3 makes more fixes to configure.ac and
updates some translations.

release candidate #4 fixes compilation with wolfSSL on 32-bit systems,
for instance, FreeBSD i386, and mentions that wolfSSL support requires
a C99 compiler.

See COPYING, INSTALL, README.SSL, README.packaging for more details on 
the news.

Please test this thoroughly and report your findings so we can be sure that
6.4.25 will be a good release.

It has been mailed out to the translation project to solicit translation updates.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.rc4.tar.xz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.rc4.tar.xz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.25.rc4.tar.xz)= d1ea78ea27245631908cf8fe4e821a9a534cb97e9ce68a4afd4302903df054d5

Thanks to Corey Halpin for the suggestion about license clarification
with gnu.org links (submitted through FreeBSD's Bugzilla).

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.25.rc4 (release candidate issued 2021-12-03, 31641 LoC):

# BREAKING CHANGES:
* Since distributions continue patching for LibreSSL use, which cannot be
  linked legally, block out LibreSSL in configure.ac and socket.c, and
  refer to COPYING.  OpenSSL and wolfSSL 5 can be used.
  SSL-related documentation was updated, do re-read
  COPYING, INSTALL, README, README.packaging, README.SSL.
* Bump OpenSSL version requirement to 1.0.2f in order to safely remove
  the obsolete OpenSSL flag SSL_OP_SINGLE_DH_USE. This blocks out 1.0.2e and 
  older 1.0.2 versions. 1.0.2f was a security fix release, and 1.0.2u is 
  publicly available from https://www.openssl.org/source/old/1.0.2/
* Some of the configure.ac fiddling MIGHT have broken cross-compilation
  again. The maintainer does not test cross-compiling fetchmail; if you
  have difficulties, try setting PKG_CONFIG_LIBDIR to the pkg-config path
  containing your target/host libraries, or see if --with-ssl-prefix or 
  --with-wolfssl-prefix, or overriding LDFLAGS/LIBS/CPPFLAGS, can help.
  Feedback solicited on compliant systems that are before end-of-life.

# BUG FIXES:
* 6.4.24's workaround for OpenSSL 1.0.2's X509_V_FLAG_TRUSTED_FIRST flag
  contained a typo and would not kick in properly.
* Library and/or rpath setting from configure.ac was fixed.

# ADDITIONS:
* Added an example systemd unit file and instructions to contrib/systemd/
  which runs fetchmail as a daemon with 5-minute poll intervals.
  Courteously contributed by Barak A. Pearlmutter, Debian Bug#981464.

# CHANGES:
* fetchmail can now be used with wolfSSL 5's OpenSSL compatibility layer,
  see INSTALL and README.SSL. This is considered experimental.
  Feedback solicited.
* The getstats.py dist-tool now counts lines of .ac and .am files.
* ./configure --with-ssl now supports pkg-config module names, too. See INSTALL.

# TRANSLATIONS: language translations were updated by these fine people:
(in reverse alphabetical order of language codes so as not to prefer people):
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* pl:    Jakub Bogusz [Polish]
* ja:    Takeshi Hamasaki [Japanese]
* fr:    Frédéric Marchal [French]
* eo:    Keith Bowes [Esperanto]
* cs:    Petr Pisar [Czech]

# CREDITS:
* Thanks to Corey Halpin for testing release candidates.

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

Happy fetches,
Matthias

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.25 release candidate #3 available (wolfSSL support, fixup Encrypt fix, fixup configure.ac, add systemd example)

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

Greetings,

The 6.4.25 release CANDIDATE #3 of fetchmail is now available at
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

It fixes up the OpenSSL 1.0.2 workaround for Let's Encrypt Sites.
It contains support for wolfSSL 5.0, blocks out LibreSSL due to
licensing issues, and overhauls the configure script for OpenSSL.

release candidate #2 adds contrib/systemd (which see)
and makes some fixes to configure.ac. It updated some translations.

release candidate #3 makes more fixes to configure.ac and
updates some translations.

See COPYING, INSTALL, README.SSL, README.packaging for more details on 
the news.

Please test this thoroughly and report your findings so we can be sure that
6.4.25 will be a good release.

It has been mailed out to the translation project to solicit translation updates.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.rc3.tar.xz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.rc3.tar.xz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.25.rc3.tar.xz)= d40995068ff7c18682ef0dcae051a44ec89b6a54df4dd2e50a25d32becfb15b2

Thanks to Corey Halpin for the suggestion about license clarification
with gnu.org links (submitted through FreeBSD's Bugzilla).

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.25.rc3 (release candidate issued 2021-11-28, 31636 LoC):

# BREAKING CHANGES:
* Since distributions continue patching for LibreSSL use, which cannot be
  linked legally, block out LibreSSL in configure.ac and socket.c, and
  refer to COPYING.  OpenSSL and wolfSSL 5 can be used.
  SSL-related documentation was updated, do re-read
  COPYING, INSTALL, README, README.packaging, README.SSL.
* Bump OpenSSL version requirement to 1.0.2f in order to safely remove
  the obsolete OpenSSL flag SSL_OP_SINGLE_DH_USE. This blocks out 1.0.2e and 
  older 1.0.2 versions. 1.0.2f was a security fix release, and 1.0.2u is 
  publicly available from https://www.openssl.org/source/old/1.0.2/
* Some of the configure.ac fiddling MIGHT have broken cross-compilation
  again. The maintainer does not test cross-compiling fetchmail; if you
  have difficulties, try setting PKG_CONFIG_LIBDIR to the pkg-config path
  containing your target/host libraries, or see if --with-ssl-prefix or 
  --with-wolfssl-prefix, or overriding LDFLAGS/LIBS/CPPFLAGS, can help.
  Feedback solicited on compliant systems that are before end-of-life.

# BUG FIXES:
* 6.4.24's workaround for OpenSSL 1.0.2's X509_V_FLAG_TRUSTED_FIRST flag
  contained a typo and would not kick in properly.
* Library and/or rpath setting from configure.ac was fixed.

# ADDITIONS:
* Added an example systemd unit file and instructions to contrib/systemd/
  which runs fetchmail as a daemon with 5-minute poll intervals.
  Courteously contributed by Barak A. Pearlmutter, Debian Bug#981464.

# CHANGES:
* fetchmail can now be used with wolfSSL 5's OpenSSL compatibility layer,
  see INSTALL and README.SSL. This is considered experimental.
  Feedback solicited.
* The getstats.py dist-tool now counts lines of .ac and .am files.
* ./configure --with-ssl now supports pkg-config module names, too. See INSTALL.

# TRANSLATIONS: language translations were updated by these fine people:
(in reverse alphabetical order of language codes so as not to prefer people):
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* pl:    Jakub Bogusz [Polish]
* ja:    Takeshi Hamasaki [Japanese]
* fr:    Frédéric Marchal [French]
* eo:    Keith Bowes [Esperanto]
* cs:    Petr Pisar [Czech]
--------------------------------------------------------------------------------

Happy fetches,
Matthias

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.25 release candidate #2 available (wolfSSL support, fixup Encrypt fix, fixup configure.ac, add systemd example)

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

Greetings,

The 6.4.25 release CANDIDATE #2 of fetchmail is now available at
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

It fixes up the OpenSSL 1.0.2 workaround for Let's Encrypt Sites.
It contains support for wolfSSL 5.0, blocks out LibreSSL due to
licensing issues, and overhauls the configure script for OpenSSL.

release candidate #2 adds contrib/systemd (which see)
and makes some fixes to configure.ac.

See COPYING, INSTALL, README.SSL, README.packaging for more details on 
the news.

Please test this thoroughly and report your findings so we can be sure that
6.4.25 will be a good release.

It has been mailed out to the translation project to solicit translation updates.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.rc2.tar.xz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.rc2.tar.xz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.25.rc2.tar.xz)= dd5aae3ae1061640a273482ae44583be70052a4fb6be257b90803cefd849410f

Thanks to Corey Halpin for the suggestion about license clarification
with gnu.org links (submitted through FreeBSD's Bugzilla).

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.25.rc2 (release candidate 2021-11-27, 31633 LoC):

# BREAKING CHANGES:
* Since distributions continue patching for LibreSSL use, which cannot be
  linked legally, block out LibreSSL in configure.ac and socket.c, and
  refer to COPYING.  OpenSSL and wolfSSL 5 can be used.
  SSL-related documentation was updated, do re-read
  COPYING, INSTALL, README, README.packaging, README.SSL.
* Bump OpenSSL version requirement to 1.0.2f in order to safely remove
  the obsolete OpenSSL flag SSL_OP_SINGLE_DH_USE. This blocks out 1.0.2e and 
  older 1.0.2 versions. 1.0.2f was a security fix release, and 1.0.2u is 
  publicly available from https://www.openssl.org/source/old/1.0.2/

# BUG FIXES:
* 6.4.24's workaround for OpenSSL 1.0.2's X509_V_FLAG_TRUSTED_FIRST flag
  contained a typo and would not kick in properly.
* Library and/or rpath setting from configure.ac was fixed.

# ADDITIONS:
* Added an example systemd unit file and instructions to contrib/systemd/
  which runs fetchmail as a daemon with 5-minute poll intervals.
  Courteously contributed by Barak A. Pearlmutter, Debian Bug#981464.

# CHANGES:
* fetchmail can now be used with wolfSSL 5's OpenSSL compatibility layer,
  see INSTALL and README.SSL. This is considered experimental.
  Feedback solicited.
* The getstats.py dist-tool now counts lines of .ac and .am files.
* ./configure --with-ssl now supports pkg-config module names, too. See INSTALL.

# TRANSLATIONS: language translations were updated by these fine people:
(in reverse alphabetical order of language codes so as not to prefer people):
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* pl:    Jakub Bogusz [Polish]
* ja:    Takeshi Hamasaki [Japanese]
* fr:    Frédéric Marchal [French]
* eo:    Keith Bowes [Esperanto]

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

Happy fetches,
Matthias

[Fetchmail-users] google oauth2 refresh token expiration

[Nerijus B. <ne...@us...>]

Hello,

I setup fetchmail to get email from gmail according to README.OAUTH2. It works for exactly a week and then stops:

$ ./fetchmail-oauth2.py -c ... --refresh
Traceback (most recent call last):
  File "/home/user/./fetchmail-oauth2.py", line 567, in <module>
    main(sys.argv)
  File "/home/user/./fetchmail-oauth2.py", line 479, in main
    response = RefreshToken(cfg['client_id'],cfg['client_secret'],reftok,
  File "/home/user/./fetchmail-oauth2.py", line 368, in RefreshToken
    response = urlopen.urlopen(token_url,
  File "/usr/lib64/python3.10/urllib/request.py", line 216, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib64/python3.10/urllib/request.py", line 525, in open
    response = meth(req, response)
  File "/usr/lib64/python3.10/urllib/request.py", line 634, in http_response
    response = self.parent.error(
  File "/usr/lib64/python3.10/urllib/request.py", line 563, in error
    return self._call_chain(*args)
  File "/usr/lib64/python3.10/urllib/request.py", line 496, in _call_chain
    result = func(*args)
  File "/usr/lib64/python3.10/urllib/request.py", line 643, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 400: Bad Request

It starts to work again for a week after I use fetchmail-oauth2.py --obtain_refresh_token_file.
Could it be because my Google app in OAuth consent screen has Publishing status: Testing?

Regards,
Nerijus

Re: [Fetchmail-users] how to fetch the dovecot spam folder contents with fetchmail?

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

On Monday 22 November 2021 15:56:18 Matthias Andree wrote:

> Am 22.11.21 um 21:51 schrieb Gene Heskett:
> > Greetings; The spam battles continue.
> >
> > I'm having trouble with fp's that originate from some of the more
> > popular mailing lists. I've been using a browser to move them back
> > to the inbox but when the spam folder gets hit with 20 msgs in a
> > week, none of which are real spam, its time to address the problem
> > with a bigger hammer.
> >
> > So, how to I make fm pull the spam that isn't spam from that folder
> > too, while its cleaning out the inbox?
> >
> > Cheers, Gene Heskett.
>
> Gene,
>
> if you are using IMAP, you can use the "folder foo" rcfile argument
> (or --folder foo) on the command line, and you can specify several of
> them per account.
>
> Depending on the server's namespaces, you may need to use a prefix for
> the spam folder. On some servers, it might be called Spam, on other
> servers, it might be INBOX.Spam. Check the server operator's
> instructions.
>
> Hope that helps.
>
> Cheers,
> Matthias
>
I will.  Thank you Matthias.
>
>
> _______________________________________________
> 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, 1940)
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] how to fetch the dovecot spam folder contents with fetchmail?

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

Am 22.11.21 um 21:51 schrieb Gene Heskett:
> Greetings; The spam battles continue.
>
> I'm having trouble with fp's that originate from some of the more popular
> mailing lists. I've been using a browser to move them back to the inbox
> but when the spam folder gets hit with 20 msgs in a week, none of which
> are real spam, its time to address the problem with a bigger hammer.
>
> So, how to I make fm pull the spam that isn't spam from that folder too,
> while its cleaning out the inbox?
>
> Cheers, Gene Heskett.

Gene,

if you are using IMAP, you can use the "folder foo" rcfile argument (or
--folder foo) on the command line, and you can specify several of them
per account.

Depending on the server's namespaces, you may need to use a prefix for
the spam folder. On some servers, it might be called Spam, on other
servers, it might be INBOX.Spam. Check the server operator's instructions.

Hope that helps.

Cheers,
Matthias

[Fetchmail-users] how to fetch the dovecot spam folder contents with fetchmail?

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

Greetings; The spam battles continue.

I'm having trouble with fp's that originate from some of the more popular 
mailing lists. I've been using a browser to move them back to the inbox 
but when the spam folder gets hit with 20 msgs in a week, none of which 
are real spam, its time to address the problem with a bigger hammer.

So, how to I make fm pull the spam that isn't spam from that folder too, 
while its cleaning out the inbox?

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, 1940)
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>

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.25 release candidate #1 available (wolfSSL support, OpenSSL 1.0.2 workaround for Let's Encrypt fixed)

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

Greetings,

The 6.4.25 release CANDIDATE #1 of fetchmail is now available at
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

It fixes up the OpenSSL 1.0.2 workaround for Let's Encrypt Sites.
It contains support for wolfSSL 5.0, blocks out LibreSSL due to
licensing issues, and overhauls the configure script for OpenSSL.

See COPYING, INSTALL, README.SSL for more details on the news.

Please test this thoroughly and report your findings so we can be sure that
6.4.25 will be a good release.

It has been mailed out to the translation project to solicit translation updates.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.rc1.tar.xz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.25.rc1.tar.xz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.25.rc1.tar.xz)= 300787d19c31490fba2e8842b5f9ac13750c4db30def3222eec88b530b305161

Thanks to Corey Halpin for the suggestion about license clarification
with gnu.org links (submitted through FreeBSD's Bugzilla).

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.25.rc1 (released 2021-11-20, 31632 LoC):

# BREAKING CHANGES
* Since distributions continue patching for LibreSSL use, which cannot be
  linked legally, block out LibreSSL in configure.ac and socket.c, and
  refer to COPYING.  OpenSSL and wolfSSL 5 can be used.
* Bump OpenSSL version requirement to 1.0.2f in order to safely remove
  the obsolete OpenSSL flag SSL_OP_SINGLE_DH_USE. 1.0.2f was a security fix
  release, and 1.0.2u is publicly available from
  https://www.openssl.org/source/old/1.0.2/

# BUG FIXES
* 6.4.24's workaround for OpenSSL 1.0.2's X509_V_FLAG_TRUSTED_FIRST flag
  contained a typo and would not kick in properly.
* Library and/or rpath setting from configure.ac was fixed.

# CHANGES
* fetchmail can now be used with wolfSSL 5's OpenSSL compatibility layer,
  see INSTALL and README.SSL. This is considered experimental.
  Feedback solicited.
* The getstats.py dist-tool now counts lines of .ac and .am files.
* ./configure --with-ssl now supports pkg-config module names, too. See INSTALL.

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

Happy fetches,
Matthias

Re: [Fetchmail-users] 6.4.24

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

Am 20.11.21 um 11:47 schrieb Gene Heskett:
> Greetings Mathias;
>
> Is there a reason to switch back to 6.4.24? 6.5.0beta6 is running well
> here, and OPENssl is 1.1.0 something. Using TLSv1.2 ack the log.
>
Dear Gene,


If 6.5.0beta6 works for you, compiled from source, no worries for end
users who compiled from tarballs.

Since 6.5 rejects OpenSSL 1.0.2, the workaround is irrelevant.


Cheers,
Matthias