fetchmail-users — User questions and discussion

[Fetchmail-users] 6.4.24

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

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.

Thanks Mathias.

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.24 is available (manual & translation updates, OpenSSL 1.0.2 workaround for Let's Encrypt sites)

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

Greetings,

The 6.4.24 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.

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

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

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.24.tar.lz)= 10018eaf3930cdc3162304f507bbd063233a0dde1febb82795c910c4c2f54b64
SHA256(fetchmail-6.4.24.tar.xz)= 9c961df25cd922f539218b0b56a77e7a47778e49ed907edaa5b4941ad3b253cf

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.24 (released 2021-11-20, 30218 LoC):

# OPENSSL AND LICENSING NOTE:
> see fetchmail-6.4.22, and the file COPYING.

  Note that distribution of packages linked with LibreSSL is not feasible
  due to a missing GPLv2 clause 2(b) exception.

# COMPATIBILITY:
* Bison 3.8 dropped yytoknum altogether, breaking compilation due to a
  warning workaround. Remove the cast of yytoknum to void.  This may cause
  a compiler warning to reappear with older Bison versions.
* OpenSSL 1.0.2: Workaround for systems that keep the expired DST Root CA X3 
  certificate in its trust store because OpenSSL by default prefers the 
  untrusted certificate and fails.  Fetchmail now sets the 
  X509_V_FLAG_TRUSTED_FIRST flag (on OpenSSL 1.0.2 only).
  This is workaround #2 from the OpenSSL Blog.  For details, see both:
  https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/
  https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

  NOTE: OpenSSL 1.0.2 is end of life, it is assumed that the OpenSSL library
  is kept up to date by a distributor or via OpenSSL support contract.
  Where this is not the case, please upgrade to a supported OpenSSL version.

# DOCUMENTATION:
* The manual page was revised after re-checking with mandoc -Tlint, aspell,
  igor. Some more revisions were made for clarity.

# TRANSLATIONS: language translations were updated by these fine people:
* sv:    Göran Uddeborg [Swedish]
* pl:    Jakub Bogusz [Polish]
* fr:    Frédéric Marchal [French]
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* ja:    Takeshi Hamasaki [Japanese]

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

Happy fetches,
Matthias

Re: [Fetchmail-users] Before arguing with my pop3 folks, are my fm setting what I think they are.

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

Am 10.11.21 um 00:10 schrieb hput via Fetchmail-users:
> Note: some munging done to the following .fetchmailrc
>
> ,----
> | set logfile /home/reader/t/var/log/fetchmail.log
> |
> | poll pop.zoho.com  proto POP3 user US...@zo...  password MANGLED
> |
> | ssl
> | fetchall
> | no keep
> | no rewrite
> | mda "/usr/bin/procmail -f %F -d %T";
> `----
>
> I hope my settings above will retrieve both read and unread, and ask
> the server to delete after I've downloaded them..  Delivering with
> procmail shouldn't have any baring on pop3 server end, I hope.
>
>
> There is no problem with connecting or the handshake but I notice the
> zohomail.com server when I connect using a web browser shows some 26
> unread messages in the inbox. And I notice some of them are messages I
> pulled down 24 hrs or more ago.
>
> I also notice that a few messages I thought I should have gotten by
> now are setting in something called `Notifications'.  One of them
> being the reply to my request for subscription to this list.
>
> So can anyone verify my .fetchmailrc is worded correctly to
> 1) download both unread and read and 2) have the messages I download
> deleted.
>
> Any other input would be very welcome as well.
Depending on server capabilities and idiosyncrasies and fetchmail
version, you may want to add uidl, and you should not need fetchall in
normal operation when uidl is in effect.
procmail should be phased out and be replaced by something that works
and is maintained, for instance, maildrop. Other than that, looks
reasonable.

Re: [Fetchmail-users] Before arguing with my pop3 folks, are my fm setting what I think they are.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



El 2021-11-09 a las 18:10 -0500, hput via Fetchmail-users escribió:

> So can anyone verify my .fetchmailrc is worded correctly to
> 1) download both unread and read and 2) have the messages I download
> deleted.

Maybe no empty line in the middle?


- -- 
Cheers
        Carlos E. R.

        (from openSUSE Leap 15.2 x86_64 (Minas Tirith))

-----BEGIN PGP SIGNATURE-----

iJIEAREIADoWIQQt/vKEw5659AgM/X2NrxRtxRYzXAUCYYsBzxwccm9iaW4ubGlz
dGFzQHRlbGVmb25pY2EubmV0AAoJEI2vFG3FFjNcH20BAIyQSP27juWft9gG5xvW
DSLmhUzbOVI7fltMWKVFXGAPAP9nulAgs9+8sNbZSn7mfaAzcqE4JFqqWu5w1Jdi
qMptoA==
=WleW
-----END PGP SIGNATURE-----

[Fetchmail-users] Before arguing with my pop3 folks, are my fm setting what I think they are.

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

Note: some munging done to the following .fetchmailrc

,----
| set logfile /home/reader/t/var/log/fetchmail.log
| 
| poll pop.zoho.com  proto POP3 user US...@zo...  password MANGLED
| 
| ssl
| fetchall
| no keep
| no rewrite
| mda "/usr/bin/procmail -f %F -d %T";
`----

I hope my settings above will retrieve both read and unread, and ask
the server to delete after I've downloaded them..  Delivering with
procmail shouldn't have any baring on pop3 server end, I hope.


There is no problem with connecting or the handshake but I notice the
zohomail.com server when I connect using a web browser shows some 26
unread messages in the inbox. And I notice some of them are messages I
pulled down 24 hrs or more ago.

I also notice that a few messages I thought I should have gotten by
now are setting in something called `Notifications'.  One of them
being the reply to my request for subscription to this list.

So can anyone verify my .fetchmailrc is worded correctly to
1) download both unread and read and 2) have the messages I download
deleted.

Any other input would be very welcome as well.

Re: [Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

On Sunday 07 November 2021 16:00:33 Matthias Andree wrote:

> Am 06.11.21 um 18:45 schrieb Gene Heskett:
> > On Saturday 06 November 2021 12:44:47 Matthias Andree wrote:
> >> Am 06.11.21 um 03:22 schrieb Gene Heskett:
> >>> On Friday 05 November 2021 17:22:48 Gene Heskett wrote:
> >>>> On Friday 05 November 2021 17:05:16 Matthias Andree wrote:
> >>>>> Am 05.11.21 um 21:57 schrieb Gene Heskett:
> >>>>>> On Friday 05 November 2021 14:14:32 Matthias Andree wrote:
> >>>>>>> Am 05.11.21 um 17:52 schrieb Gene Heskett:
> >>>>>>>> Greetings Mathias;
> >>>>>>>>
> >>>>>>>> The bump was a msg that landed in the inbox at
> >>>>>>>> imap.shentel.net. no subject, no body, no from address, from
> >>>>>>>> the debian listmail server. at about 6:53 EDT.
> >>>>>>>>
> >>>>>>>> That convinced fetchmail it had an error 7, and exited that
> >>>>>>>> invocation without fetching any more msgs.  Wash, rinse and
> >>>>>>>> repeat at 2 minute intervals till shentel and I figured it
> >>>>>>>> out a few seconds after the log entry below.
> >>>>>>>>
> >>>>>>>> log looked like this:
> >>>>>>>>
> >>>>>>>> ov 05 11:42:32 fetchmail: 54 messages for
> >>>>>>>> ghe...@sh... at imap.shentel.net. Nov 05 11:42:33
> >>>>>>>> fetchmail: reading message
> >>>>>>>> ghe...@sh...@imap.shentel.mail2world.com:1 of 54
> >>>>>>>> (2182 header octets) (log message incomplete)
> >>>>>>>> Nov 05 11:42:33 fetchmail: client/server synchronization
> >>>>>>>> error while fetching from
> >>>>>>>> ghe...@sh...@imap.shentel.net Nov 05 11:42:33
> >>>>>>>> fetchmail: Query status=7 (ERROR)
> >>>>>>>>
> >>>>>>>> I finally logged into the webmail, saw that funky msg and
> >>>>>>>> deleted it, which unplugged the drain  and it fetched the
> >>>>>>>> other 53 msgs ok.
> >>>>>>>>
> >>>>>>>> Unforch the log is all I could salvage. Is this helpfull?
> >>>>>>>
> >>>>>>> Hi Gene,
> >>>>>>>
> >>>>>>> thanks for the report. Unfortunately, this log does not
> >>>>>>> suffice to check where fetchmail failed - I would need to see
> >>>>>>> a verbose log with at least one -v (or possibly -vv if you can
> >>>>>>> spare the disk logging space).
> >>>>>>
> >>>>>> That -vv I assume goes in my user .fetchmailrc?
> >>>>>
> >>>>> On the command line, you can't use it from .fetchmailrc.
> >>>
> >>> And it didn't take long to get a replay.
> >>>
> >>> This is the message in its entirety from a kmail v entry:
> >>> =====================
> >>> ...
> >>> =====================
> >>> And this is the corresponding log:
> >>> But its not, with the -vv, its not reporting a Query status=7,
> >>> just a 1 now,=no mail but mail has stopped again. I'll log into
> >>> webmail and see. Humm, no mail. None of those ipv4 addresses above
> >>> are me. I should be that from the web link in the sig.
> >>
> >> Hi Gene,
> >>
> >> Well, the more interesting part is really the IMAP dialogue from
> >> the -v or -vv verbose log in such cases to figure where the
> >> conversation goes out of synch and if it's the server messing up or
> >> fetchmail. Reason is that there may be subtle differences on the
> >> server-side how the server presents messages with missing parts.
> >>
> >> Either the message got marked read and not downloaded a 2nd time by
> >> fetchmail (in that case, you can download again with fetchmail -q
> >> followed by: fetchmail -Nvvd0 -a 2>&1 | tee fetchmail.log), or
> >> deleted after fetch (in that case we need to wait for the next
> >> occasion, possibly you want to run fetchmail output to a log).
> >
> > I see, but looking at the log again just now, it has lost the -vv,
> > then it reminded me that another script had been run since I
> > restarted fetchmail and it, sa-train-bayes was restarting fetchmail
> > w/o the -vv. so thats fixed now. And fetchmail is blabbering like an
> > idiot, 20+ lines of output per new mail scan 120 seconds after the
> > last one.  So now we wait.  Since the last such instance was 4 or so
> > months back, it may be a while, but it will be easier to find since
> > its now logging times again.
> >
> > Thanks for the update Mathias.  Take care & stay well now.
>
> Gene,
>
> If the logging seems excessive, we may also get away with just -v
> instead of -vv for this case. That would also contain the IMAP or POP3
> dialogues.
>
> You may also want to rotate and compress logs more often.

No worries Mathias, its a 2T drive. and those logs are located in ~/log, 
I got tired of something changing the perms in /var/log about weekly, so 
I moved them into my user domain and fixed logrotate to service them 
there, probably 3 years ago. Life is soooo much simpler when my logs 
belong to me. ;o)

> Cheers,
> 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] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

Am 06.11.21 um 18:45 schrieb Gene Heskett:
> On Saturday 06 November 2021 12:44:47 Matthias Andree wrote:
>
>> Am 06.11.21 um 03:22 schrieb Gene Heskett:
>>> On Friday 05 November 2021 17:22:48 Gene Heskett wrote:
>>>> On Friday 05 November 2021 17:05:16 Matthias Andree wrote:
>>>>> Am 05.11.21 um 21:57 schrieb Gene Heskett:
>>>>>> On Friday 05 November 2021 14:14:32 Matthias Andree wrote:
>>>>>>> Am 05.11.21 um 17:52 schrieb Gene Heskett:
>>>>>>>> Greetings Mathias;
>>>>>>>>
>>>>>>>> The bump was a msg that landed in the inbox at
>>>>>>>> imap.shentel.net. no subject, no body, no from address, from
>>>>>>>> the debian listmail server. at about 6:53 EDT.
>>>>>>>>
>>>>>>>> That convinced fetchmail it had an error 7, and exited that
>>>>>>>> invocation without fetching any more msgs.  Wash, rinse and
>>>>>>>> repeat at 2 minute intervals till shentel and I figured it out
>>>>>>>> a few seconds after the log entry below.
>>>>>>>>
>>>>>>>> log looked like this:
>>>>>>>>
>>>>>>>> ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh...
>>>>>>>> at imap.shentel.net. Nov 05 11:42:33 fetchmail: reading message
>>>>>>>> ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182
>>>>>>>> header octets) (log message incomplete)
>>>>>>>> Nov 05 11:42:33 fetchmail: client/server synchronization error
>>>>>>>> while fetching from ghe...@sh...@imap.shentel.net Nov
>>>>>>>> 05 11:42:33 fetchmail: Query status=7 (ERROR)
>>>>>>>>
>>>>>>>> I finally logged into the webmail, saw that funky msg and
>>>>>>>> deleted it, which unplugged the drain  and it fetched the other
>>>>>>>> 53 msgs ok.
>>>>>>>>
>>>>>>>> Unforch the log is all I could salvage. Is this helpfull?
>>>>>>> Hi Gene,
>>>>>>>
>>>>>>> thanks for the report. Unfortunately, this log does not suffice
>>>>>>> to check where fetchmail failed - I would need to see a verbose
>>>>>>> log with at least one -v (or possibly -vv if you can spare the
>>>>>>> disk logging space).
>>>>>> That -vv I assume goes in my user .fetchmailrc?
>>>>> On the command line, you can't use it from .fetchmailrc.
>>> And it didn't take long to get a replay.
>>>
>>> This is the message in its entirety from a kmail v entry:
>>> =====================
>>> ...
>>> =====================
>>> And this is the corresponding log:
>>> But its not, with the -vv, its not reporting a Query status=7, just
>>> a 1 now,=no mail but mail has stopped again. I'll log into webmail
>>> and see. Humm, no mail. None of those ipv4 addresses above are me. I
>>> should be that from the web link in the sig.
>> Hi Gene,
>>
>> Well, the more interesting part is really the IMAP dialogue from the
>> -v or -vv verbose log in such cases to figure where the conversation
>> goes out of synch and if it's the server messing up or fetchmail.
>> Reason is that there may be subtle differences on the server-side how
>> the server presents messages with missing parts.
>>
>> Either the message got marked read and not downloaded a 2nd time by
>> fetchmail (in that case, you can download again with fetchmail -q
>> followed by: fetchmail -Nvvd0 -a 2>&1 | tee fetchmail.log), or deleted
>> after fetch (in that case we need to wait for the next occasion,
>> possibly you want to run fetchmail output to a log).
> I see, but looking at the log again just now, it has lost the -vv, then
> it reminded me that another script had been run since I restarted
> fetchmail and it, sa-train-bayes was restarting fetchmail w/o the -vv.
> so thats fixed now. And fetchmail is blabbering like an idiot, 20+ lines
> of output per new mail scan 120 seconds after the last one.  So now we
> wait.  Since the last such instance was 4 or so months back, it may be a
> while, but it will be easier to find since its now logging times again.
>
> Thanks for the update Mathias.  Take care & stay well now.

Gene,

If the logging seems excessive, we may also get away with just -v
instead of -vv for this case. That would also contain the IMAP or POP3
dialogues.

You may also want to rotate and compress logs more often.

Cheers,
Matthias

Re: [Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

On Saturday 06 November 2021 12:44:47 Matthias Andree wrote:

> Am 06.11.21 um 03:22 schrieb Gene Heskett:
> > On Friday 05 November 2021 17:22:48 Gene Heskett wrote:
> >> On Friday 05 November 2021 17:05:16 Matthias Andree wrote:
> >>> Am 05.11.21 um 21:57 schrieb Gene Heskett:
> >>>> On Friday 05 November 2021 14:14:32 Matthias Andree wrote:
> >>>>> Am 05.11.21 um 17:52 schrieb Gene Heskett:
> >>>>>> Greetings Mathias;
> >>>>>>
> >>>>>> The bump was a msg that landed in the inbox at
> >>>>>> imap.shentel.net. no subject, no body, no from address, from
> >>>>>> the debian listmail server. at about 6:53 EDT.
> >>>>>>
> >>>>>> That convinced fetchmail it had an error 7, and exited that
> >>>>>> invocation without fetching any more msgs.  Wash, rinse and
> >>>>>> repeat at 2 minute intervals till shentel and I figured it out
> >>>>>> a few seconds after the log entry below.
> >>>>>>
> >>>>>> log looked like this:
> >>>>>>
> >>>>>> ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh...
> >>>>>> at imap.shentel.net. Nov 05 11:42:33 fetchmail: reading message
> >>>>>> ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182
> >>>>>> header octets) (log message incomplete)
> >>>>>> Nov 05 11:42:33 fetchmail: client/server synchronization error
> >>>>>> while fetching from ghe...@sh...@imap.shentel.net Nov
> >>>>>> 05 11:42:33 fetchmail: Query status=7 (ERROR)
> >>>>>>
> >>>>>> I finally logged into the webmail, saw that funky msg and
> >>>>>> deleted it, which unplugged the drain  and it fetched the other
> >>>>>> 53 msgs ok.
> >>>>>>
> >>>>>> Unforch the log is all I could salvage. Is this helpfull?
> >>>>>
> >>>>> Hi Gene,
> >>>>>
> >>>>> thanks for the report. Unfortunately, this log does not suffice
> >>>>> to check where fetchmail failed - I would need to see a verbose
> >>>>> log with at least one -v (or possibly -vv if you can spare the
> >>>>> disk logging space).
> >>>>
> >>>> That -vv I assume goes in my user .fetchmailrc?
> >>>
> >>> On the command line, you can't use it from .fetchmailrc.
> >
> > And it didn't take long to get a replay.
> >
> > This is the message in its entirety from a kmail v entry:
> > =====================
> > ...
> > =====================
> > And this is the corresponding log:
> > But its not, with the -vv, its not reporting a Query status=7, just
> > a 1 now,=no mail but mail has stopped again. I'll log into webmail
> > and see. Humm, no mail. None of those ipv4 addresses above are me. I
> > should be that from the web link in the sig.
>
> Hi Gene,
>
> Well, the more interesting part is really the IMAP dialogue from the
> -v or -vv verbose log in such cases to figure where the conversation
> goes out of synch and if it's the server messing up or fetchmail.
> Reason is that there may be subtle differences on the server-side how
> the server presents messages with missing parts.
>
> Either the message got marked read and not downloaded a 2nd time by
> fetchmail (in that case, you can download again with fetchmail -q
> followed by: fetchmail -Nvvd0 -a 2>&1 | tee fetchmail.log), or deleted
> after fetch (in that case we need to wait for the next occasion,
> possibly you want to run fetchmail output to a log).

I see, but looking at the log again just now, it has lost the -vv, then 
it reminded me that another script had been run since I restarted 
fetchmail and it, sa-train-bayes was restarting fetchmail w/o the -vv.
so thats fixed now. And fetchmail is blabbering like an idiot, 20+ lines 
of output per new mail scan 120 seconds after the last one.  So now we 
wait.  Since the last such instance was 4 or so months back, it may be a 
while, but it will be easier to find since its now logging times again.

Thanks for the update Mathias.  Take care & stay well now.

> Cheers,
> 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] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

Am 06.11.21 um 03:22 schrieb Gene Heskett:
> On Friday 05 November 2021 17:22:48 Gene Heskett wrote:
>
>> On Friday 05 November 2021 17:05:16 Matthias Andree wrote:
>>> Am 05.11.21 um 21:57 schrieb Gene Heskett:
>>>> On Friday 05 November 2021 14:14:32 Matthias Andree wrote:
>>>>> Am 05.11.21 um 17:52 schrieb Gene Heskett:
>>>>>> Greetings Mathias;
>>>>>>
>>>>>> The bump was a msg that landed in the inbox at imap.shentel.net.
>>>>>> no subject, no body, no from address, from the debian listmail
>>>>>> server. at about 6:53 EDT.
>>>>>>
>>>>>> That convinced fetchmail it had an error 7, and exited that
>>>>>> invocation without fetching any more msgs.  Wash, rinse and
>>>>>> repeat at 2 minute intervals till shentel and I figured it out a
>>>>>> few seconds after the log entry below.
>>>>>>
>>>>>> log looked like this:
>>>>>>
>>>>>> ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh...
>>>>>> at imap.shentel.net. Nov 05 11:42:33 fetchmail: reading message
>>>>>> ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182
>>>>>> header octets) (log message incomplete)
>>>>>> Nov 05 11:42:33 fetchmail: client/server synchronization error
>>>>>> while fetching from ghe...@sh...@imap.shentel.net Nov 05
>>>>>> 11:42:33 fetchmail: Query status=7 (ERROR)
>>>>>>
>>>>>> I finally logged into the webmail, saw that funky msg and
>>>>>> deleted it, which unplugged the drain  and it fetched the other
>>>>>> 53 msgs ok.
>>>>>>
>>>>>> Unforch the log is all I could salvage. Is this helpfull?
>>>>> Hi Gene,
>>>>>
>>>>> thanks for the report. Unfortunately, this log does not suffice
>>>>> to check where fetchmail failed - I would need to see a verbose
>>>>> log with at least one -v (or possibly -vv if you can spare the
>>>>> disk logging space).
>>>> That -vv I assume goes in my user .fetchmailrc?
>>> On the command line, you can't use it from .fetchmailrc.
> And it didn't take long to get a replay.
>
> This is the message in its entirety from a kmail v entry:
> =====================
> ...
> =====================
> And this is the corresponding log:
> But its not, with the -vv, its not reporting a Query status=7, just a 1
> now,=no mail but mail has stopped again. I'll log into webmail and see.
> Humm, no mail. None of those ipv4 addresses above are me. I should be
> that from the web link in the sig.
Hi Gene,

Well, the more interesting part is really the IMAP dialogue from the -v
or -vv verbose log in such cases to figure where the conversation goes
out of synch and if it's the server messing up or fetchmail. Reason is
that there may be subtle differences on the server-side how the server
presents messages with missing parts.

Either the message got marked read and not downloaded a 2nd time by
fetchmail (in that case, you can download again with fetchmail -q
followed by: fetchmail -Nvvd0 -a 2>&1 | tee fetchmail.log), or deleted
after fetch (in that case we need to wait for the next occasion,
possibly you want to run fetchmail output to a log).

Cheers,
Matthias

Re: [Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

On Friday 05 November 2021 17:22:48 Gene Heskett wrote:

> On Friday 05 November 2021 17:05:16 Matthias Andree wrote:
> > Am 05.11.21 um 21:57 schrieb Gene Heskett:
> > > On Friday 05 November 2021 14:14:32 Matthias Andree wrote:
> > >> Am 05.11.21 um 17:52 schrieb Gene Heskett:
> > >>> Greetings Mathias;
> > >>>
> > >>> The bump was a msg that landed in the inbox at imap.shentel.net.
> > >>> no subject, no body, no from address, from the debian listmail
> > >>> server. at about 6:53 EDT.
> > >>>
> > >>> That convinced fetchmail it had an error 7, and exited that
> > >>> invocation without fetching any more msgs.  Wash, rinse and
> > >>> repeat at 2 minute intervals till shentel and I figured it out a
> > >>> few seconds after the log entry below.
> > >>>
> > >>> log looked like this:
> > >>>
> > >>> ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh...
> > >>> at imap.shentel.net. Nov 05 11:42:33 fetchmail: reading message
> > >>> ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182
> > >>> header octets) (log message incomplete)
> > >>> Nov 05 11:42:33 fetchmail: client/server synchronization error
> > >>> while fetching from ghe...@sh...@imap.shentel.net Nov 05
> > >>> 11:42:33 fetchmail: Query status=7 (ERROR)
> > >>>
> > >>> I finally logged into the webmail, saw that funky msg and
> > >>> deleted it, which unplugged the drain  and it fetched the other
> > >>> 53 msgs ok.
> > >>>
> > >>> Unforch the log is all I could salvage. Is this helpfull?
> > >>
> > >> Hi Gene,
> > >>
> > >> thanks for the report. Unfortunately, this log does not suffice
> > >> to check where fetchmail failed - I would need to see a verbose
> > >> log with at least one -v (or possibly -vv if you can spare the
> > >> disk logging space).
> > >
> > > That -vv I assume goes in my user .fetchmailrc?
> >
> > On the command line, you can't use it from .fetchmailrc.
And it didn't take long to get a replay.

This is the message in its entirety from a kmail v entry:
=====================
From gene  Fri Nov  5 11:40:31 2021
Return-Path: <bounce-debian-user=gheskett=she...@li...>
Received: from imap.shentel.mail2world.com [209.67.128.65]
	by coyote.coyote.den with IMAP (fetchmail-6.5.0.beta6)
	for <gene@localhost> (single-drop); Fri, 05 Nov 2021 11:40:31 -0400 
(EDT)
Received: from 216.163.176.191 unverified ([216.163.176.191]) by 
mwpop05oc.mail2world.com with Mail2World SMTP Server; 
	Fri, 05 Nov 2021 03:54:12 -0700
Received: from [82.195.75.100] (port=39482 helo=bendel.debian.org)
	by prd-mail2world-inbound-ash1-025.ash1.cynet with esmtps  (TLS1.2) tls 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94)
	(envelope-from 
<bounce-debian-user=gheskett=she...@li...>)
	id 1miwpT-000Xrv-1k
	for ghe...@sh...; Fri, 05 Nov 2021 10:52:15 +0000
Received: from localhost (localhost [127.0.0.1])
	by bendel.debian.org (Postfix) with QMQP
	id A661820757; Fri,  5 Nov 2021 10:52:08 +0000 (UTC)
X-Mailbox-Line: From deb...@li...  Fri Nov  5 
10:52:08 2021
Message-ID: <DxZSuwzvpZG.A.lW.YzQhhB@bendel>
Resent-Message-ID: <DxZSuwzvpZG.B.lW.YzQhhB@bendel>
To: deb...@li...
Resent-From: deb...@li...
Subject: Unidentified subject!
X-Mailing-List: <deb...@li...> archive/latest/782632
X-Loop: deb...@li...
List-Id: <debian-user.lists.debian.org>
List-URL: <https://lists.debian.org/debian-user/>
List-Post: <mailto:deb...@li...>
List-Help: <mailto:deb...@li...?subject=help>
List-Subscribe: 
<mailto:deb...@li...?subject=subscribe>
List-Unsubscribe: 
<mailto:deb...@li...?subject=unsubscribe>
Precedence: list
Resent-Sender: deb...@li...
List-Archive: 
https://lists.debian.org/msgid-search/CAG...@ma...
Resent-Date: Fri,  5 Nov 2021 10:52:08 +0000 (UTC)
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
x-ctasd: uncategorized
x-ctasd-vod: uncategorized
X-CTCH-Flags: 1024
X-CTCH-RefID: 
str=0001.0A742F19.61850CDF.000A:SCGSTAT2751311,ss=1,re=-4.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=1024
X-CTASD-IP: 82.195.75.100
X-CTASD-Sender: deb...@li...
X-OpenTrafficX: bulk
X-OpenTrafficX-type: bulk
X-OpenTrafficX-ID: 155810::1636109535-00015DF1-334107C9/9/2797
X-procmail: user=gene
=====================
And this is the corresponding log:
But its not, with the -vv, its not reporting a Query status=7, just a 1 
now,=no mail but mail has stopped again. I'll log into webmail and see. 
Humm, no mail. None of those ipv4 addresses above are me. I should be 
that from the web link in the sig.

So the above copy/paste from a kmail v, must have arrived while I was 
checking this at about 11 something local time this morning. 2 of them 
before I killed the original at imap.shentel.net.

I must be confused. Or oldtimers has set in.  Since I'm now 87, I suppose 
its a possibility.

> Done, is positively a blabbermouth now. Now we wait for the next
> screwup. Might be a year...

Thanks Mathias.

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] 6.4.23 interesting feature

[isdtor <is...@gm...>]

 
> Surprise: This is documented in the manual page:
> 
> >        --pidfile <pathname>
> >               (Keyword: pidfile; since fetchmail v6.3.4)
> >               Override the default location of the PID file that is
> > used as a lock file.  Default: see "ENVIRONMENT" below. Note
> >               that many places in the code and documentation, the term
> > "lock file" is used.  This file contains the process  ID
> >               of the running fetchmail on the first line and
> > potentially the daemon interval on a second line.
 
Wow. I missed that.

I rest my case.

Re: [Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

On Friday 05 November 2021 17:05:16 Matthias Andree wrote:

> Am 05.11.21 um 21:57 schrieb Gene Heskett:
> > On Friday 05 November 2021 14:14:32 Matthias Andree wrote:
> >> Am 05.11.21 um 17:52 schrieb Gene Heskett:
> >>> Greetings Mathias;
> >>>
> >>> The bump was a msg that landed in the inbox at imap.shentel.net.
> >>> no subject, no body, no from address, from the debian listmail
> >>> server. at about 6:53 EDT.
> >>>
> >>> That convinced fetchmail it had an error 7, and exited that
> >>> invocation without fetching any more msgs.  Wash, rinse and repeat
> >>> at 2 minute intervals till shentel and I figured it out a few
> >>> seconds after the log entry below.
> >>>
> >>> log looked like this:
> >>>
> >>> ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh... at
> >>> imap.shentel.net. Nov 05 11:42:33 fetchmail: reading message
> >>> ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182
> >>> header octets) (log message incomplete)
> >>> Nov 05 11:42:33 fetchmail: client/server synchronization error
> >>> while fetching from ghe...@sh...@imap.shentel.net Nov 05
> >>> 11:42:33 fetchmail: Query status=7 (ERROR)
> >>>
> >>> I finally logged into the webmail, saw that funky msg and deleted
> >>> it, which unplugged the drain  and it fetched the other 53 msgs
> >>> ok.
> >>>
> >>> Unforch the log is all I could salvage. Is this helpfull?
> >>
> >> Hi Gene,
> >>
> >> thanks for the report. Unfortunately, this log does not suffice to
> >> check where fetchmail failed - I would need to see a verbose log
> >> with at least one -v (or possibly -vv if you can spare the disk
> >> logging space).
> >
> > That -vv I assume goes in my user .fetchmailrc?
>
> On the command line, you can't use it from .fetchmailrc.
>
Done, is positively a blabbermouth now. Now we wait for the next screwup. 
Might be a year...

Thanks Mathias.

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] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

Am 05.11.21 um 21:57 schrieb Gene Heskett:
> On Friday 05 November 2021 14:14:32 Matthias Andree wrote:
>
>> Am 05.11.21 um 17:52 schrieb Gene Heskett:
>>> Greetings Mathias;
>>>
>>> The bump was a msg that landed in the inbox at imap.shentel.net. no
>>> subject, no body, no from address, from the debian listmail server.
>>> at about 6:53 EDT.
>>>
>>> That convinced fetchmail it had an error 7, and exited that
>>> invocation without fetching any more msgs.  Wash, rinse and repeat
>>> at 2 minute intervals till shentel and I figured it out a few
>>> seconds after the log entry below.
>>>
>>> log looked like this:
>>>
>>> ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh... at
>>> imap.shentel.net. Nov 05 11:42:33 fetchmail: reading message
>>> ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182
>>> header octets) (log message incomplete)
>>> Nov 05 11:42:33 fetchmail: client/server synchronization error while
>>> fetching from ghe...@sh...@imap.shentel.net Nov 05 11:42:33
>>> fetchmail: Query status=7 (ERROR)
>>>
>>> I finally logged into the webmail, saw that funky msg and deleted
>>> it, which unplugged the drain  and it fetched the other 53 msgs ok.
>>>
>>> Unforch the log is all I could salvage. Is this helpfull?
>> Hi Gene,
>>
>> thanks for the report. Unfortunately, this log does not suffice to
>> check where fetchmail failed - I would need to see a verbose log with
>> at least one -v (or possibly -vv if you can spare the disk logging
>> space).
>>
> That -vv I assume goes in my user .fetchmailrc?

On the command line, you can't use it from .fetchmailrc.

Re: [Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

On Friday 05 November 2021 14:14:32 Matthias Andree wrote:

> Am 05.11.21 um 17:52 schrieb Gene Heskett:
> > Greetings Mathias;
> >
> > The bump was a msg that landed in the inbox at imap.shentel.net. no
> > subject, no body, no from address, from the debian listmail server.
> > at about 6:53 EDT.
> >
> > That convinced fetchmail it had an error 7, and exited that
> > invocation without fetching any more msgs.  Wash, rinse and repeat
> > at 2 minute intervals till shentel and I figured it out a few
> > seconds after the log entry below.
> >
> > log looked like this:
> >
> > ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh... at
> > imap.shentel.net. Nov 05 11:42:33 fetchmail: reading message
> > ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182
> > header octets) (log message incomplete)
> > Nov 05 11:42:33 fetchmail: client/server synchronization error while
> > fetching from ghe...@sh...@imap.shentel.net Nov 05 11:42:33
> > fetchmail: Query status=7 (ERROR)
> >
> > I finally logged into the webmail, saw that funky msg and deleted
> > it, which unplugged the drain  and it fetched the other 53 msgs ok.
> >
> > Unforch the log is all I could salvage. Is this helpfull?
>
> Hi Gene,
>
> thanks for the report. Unfortunately, this log does not suffice to
> check where fetchmail failed - I would need to see a verbose log with
> at least one -v (or possibly -vv if you can spare the disk logging
> space).
>
That -vv I assume goes in my user .fetchmailrc?

> I know fetchmail lacks some parser support for edge cases like yours.
>
> Cheers,
> 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] sometime in the night, fetchmail 6.5.0beta6 heard a bump

[grarpamp <gra...@gm...>]

> https://github.com/marlam/msmtp-mirror

That's on the submission side.

The relay side can be done by just as easily
with netcat or openssl s_client, provided the shentel
lets you connect, etc.

Tests with local imap server bypass the smtp issue.

Re: [Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

[grarpamp <gra...@gm...>]

Antispam makes it harder these days to send without
a body-from (which could perhaps have had non-printables
in it, or been otherwise mangled). Sending without envelope-from
is even harder. Regardless, you note there was one sitting
at shentel waiting for you, but that it was deleted.

So can test by using 'msmtp' program to inject such a piece
of by memory crafted mail into shentel for further testing.

https://github.com/marlam/msmtp-mirror

Or use any imap server to serve such a test
message file locally to fetchmail.

Re: [Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

Am 05.11.21 um 17:52 schrieb Gene Heskett:
> Greetings Mathias;
>
> The bump was a msg that landed in the inbox at imap.shentel.net. no
> subject, no body, no from address, from the debian listmail server.
> at about 6:53 EDT.
>
> That convinced fetchmail it had an error 7, and exited that invocation
> without fetching any more msgs.  Wash, rinse and repeat at 2 minute
> intervals till shentel and I figured it out a few seconds after the
> log entry below.
>
> log looked like this:
>
> ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh... at imap.shentel.net.
> Nov 05 11:42:33 fetchmail: reading message ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182 header octets) (log message
> incomplete)
> Nov 05 11:42:33 fetchmail: client/server synchronization error while fetching from ghe...@sh...@imap.shentel.net
> Nov 05 11:42:33 fetchmail: Query status=7 (ERROR)
>
> I finally logged into the webmail, saw that funky msg and deleted it,
> which unplugged the drain  and it fetched the other 53 msgs ok.
>
> Unforch the log is all I could salvage. Is this helpfull?

Hi Gene,

thanks for the report. Unfortunately, this log does not suffice to check
where fetchmail failed - I would need to see a verbose log with at least
one -v (or possibly -vv if you can spare the disk logging space).

I know fetchmail lacks some parser support for edge cases like yours.

Cheers,
Matthias

Re: [Fetchmail-users] 6.4.23 interesting feature

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

Am 05.11.21 um 15:21 schrieb isdtor:
> G'day all,
>
> After updating to release 6.4.23, I noticed that the .pid file had an unusual size here, 9 bytes instead of 6.
>
> $ cat ~/.fetchmail.pid
> 12345
> 42
> $
>
> The first line certainly corresponds to the running pid, and fetchmail -q continues to work fine. The second line represents the daemon interval, and the entry is created regardless whether I use -d on the command line or set daemon xx in the .rc file.
>
> I did a very quick diff of the 6.4.22 and 6.4.23 sources and found no reference to pidfile, which makes me think this is not a change introduced by 6.4.23. Obviously, in my opinion, the daemon interval should not be recorded in the pid file.

Surprise: This is documented in the manual page:

>        --pidfile <pathname>
>               (Keyword: pidfile; since fetchmail v6.3.4)
>               Override the default location of the PID file that is
> used as a lock file.  Default: see "ENVIRONMENT" below. Note
>               that many places in the code and documentation, the term
> "lock file" is used.  This file contains the process  ID
>               of the running fetchmail on the first line and
> potentially the daemon interval on a second line.

Bigger surprise: It is in line with the Linux Filesystem Hierarchy
Standard 3.0, section 3.15.2 in
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

It is also in line with what FreeBSD's rc.subr expects.

All pidfile stuff I know expects the PID on the first line only and is
to ignore what's on subsequent lines.

History lesson (it's all in Git, all public): Code to log the daemon's
poll interval was added to fetchmail 25 years ago, into fetchmail.c at
the time, later refactored into lock.c (see below for the commit banner).
Released in fetchmail-1.9.0 (Fri Oct 25 23:02:26 EDT 1996). See OLDNEWS
for the release note...

Now what?

>> commit 7c01a0bb7d66715319fa94626a963e8389375858
>> Author: Eric S. Raymond <es...@th...>
>> Date:   Sun Oct 13 15:46:55 1996 +0000
>>
>>     Added wakeup feature.
>>
>>     svn path=/trunk/; revision=323
>>
>>  NEWS          |  4 ++++
>>  fetchmail.c   | 59
>> ++++++++++++++++++++++++++++++++++++++++++++++++++---------
>>  fetchmail.man |  4 +++-
>>  3 files changed, 57 insertions(+), 10 deletions(-)

[Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

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

Greetings Mathias;

The bump was a msg that landed in the inbox at imap.shentel.net. no 
subject, no body, no from address, from the debian listmail server. 
at about 6:53 EDT.

That convinced fetchmail it had an error 7, and exited that invocation 
without fetching any more msgs.  Wash, rinse and repeat at 2 minute
intervals till shentel and I figured it out a few seconds after the
log entry below.

log looked like this:

ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh... at imap.shentel.net.
Nov 05 11:42:33 fetchmail: reading message ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182 header octets) (log message 
incomplete)
Nov 05 11:42:33 fetchmail: client/server synchronization error while fetching from ghe...@sh...@imap.shentel.net
Nov 05 11:42:33 fetchmail: Query status=7 (ERROR)

I finally logged into the webmail, saw that funky msg and deleted it, 
which unplugged the drain  and it fetched the other 53 msgs ok.

Unforch the log is all I could salvage. Is this helpfull?

Thanks.

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] 6.4.23 interesting feature

[isdtor <is...@gm...>]

G'day all,

After updating to release 6.4.23, I noticed that the .pid file had an unusual size here, 9 bytes instead of 6.

$ cat ~/.fetchmail.pid
12345
42
$ 

The first line certainly corresponds to the running pid, and fetchmail -q continues to work fine. The second line represents the daemon interval, and the entry is created regardless whether I use -d on the command line or set daemon xx in the .rc file.

I did a very quick diff of the 6.4.22 and 6.4.23 sources and found no reference to pidfile, which makes me think this is not a change introduced by 6.4.23. Obviously, in my opinion, the daemon interval should not be recorded in the pid file.

Re: [Fetchmail-users] ANNOUNCE: The 6.4.23 release of fetchmail is available (usability fix for IMAP plugin + auth ssh, translation updates)

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

Am 31.10.21 um 15:02 schrieb Gene Heskett:
> On Sunday 31 October 2021 08:14:20 Matthias Andree wrote:
>
>> Greetings,
>>
>> The 6.4.23 release of fetchmail is now available at
>> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.
>>
> Sourceforge is still serving up 6.4.22 as the latest.
>

Hi Gene,

Right, I forgot to mark 6.4.23 as the one. Fixed now.

Thanks, Gene!


Additional Note to packagers and developers, if you are trying to
rebuild the parser files with a newer bison 3.8.x, from Git, or due to a
rebuild-everything policy, you may need to patch out one line (void)
from rcfile_y.y to avoid compilation failures.

Fixed in Git but not yet in 6.4.23
https://gitlab.com/fetchmail/fetchmail/-/commit/595d6b354aeef9db4f106e37fe5cccc4b80ec087
(I saw the CI pipe on GitLab failing after I'd merged things forward to
6.5.x, and apparently Debian testing updated Bison.)

Basically, this line #464 of rcfile_y.y needs to go (and may cause a
compiler warning about unused...)

    |(void)yytoknum; /* work around compiler warning */ |

Regards,
Matthias

Re: [Fetchmail-users] ANNOUNCE: The 6.4.23 release of fetchmail is available (usability fix for IMAP plugin + auth ssh, translation updates)

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

On Sunday 31 October 2021 08:14:20 Matthias Andree wrote:

> Greetings,
>
> The 6.4.23 release of fetchmail is now available at
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.
>
Sourceforge is still serving up 6.4.22 as the latest.
 
> It updates the Japanese and Serbian translations and improves an error
> message around STARTTLS with IMAP --auth ssh and --plugin.
>
> Note the tarball was re-rolled to include the German translation
> update, missed in the first upload.
>
> DISTRIBUTORS please note OpenSSL's licensing change for OpenSSL 3,
> and you may want to review COPYING.
>
> The source archive is available at:
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail
>-6.4.23.tar.xz/download>
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail
>-6.4.23.tar.lz/download>
>
> Detached GnuPG signatures for the respective tarballs are at:
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail
>-6.4.23.tar.xz.asc/download>
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail
>-6.4.23.tar.lz.asc/download>
>
> SHA256 hash values for the tarballs:
> SHA256(fetchmail-6.4.23.tar.lz)=
> 0fa3b57f05ec38b3ecb58d2221223b6a4da6e30dd857af37b49798c3e84a71e5
> SHA256(fetchmail-6.4.23.tar.xz)=
> 5f7a5e13731431134a2ca535bbced7adc666d3aeb93169a0830945d91f492300
>
> Here are the release notes:
>
> ----------------------------------------------------------------------
>----------- fetchmail-6.4.23 (released 2021-10-31, 30206 LoC):
>
> # USABILITY:
> * For common ssh-based IMAP PREAUTH setups (i. e. those that use a
> plugin - no matter its contents - and that set auth ssh), change the
> STARTTLS error message to suggest sslproto '' instead.
>   This is a commonly reported issue after the CVE-2021-39272 fix in
> 6.4.22. Fixes Redhat Bugzilla 2008160. Fixes GitLab #39.
>
> # TRANSLATIONS: language translations were updated by these fine
> people: * ja:    Takeshi Hamasaki [Japanese]
> * sr:	 Мирослав Николић (Miroslav Nikolić) [Serbian]
>
> ----------------------------------------------------------------------
>----------
>
> Happy fetches,
> Matthias


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: The 6.5.0.beta5 snapshot of fetchmail is available

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

Greetings,

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

The source archive has been uploaded and will shortly be available from:
<https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta5.tar.xz/download>

This is a deep link to the GnuPG signature:
<https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta5.tar.xz.asc/download>

This brings the 6.5.0 beta in line with the recent 6.4 developments.

This is the change history from Git:
================================================================================
* b26f8b3b 2021-10-31 | po/: record state (HEAD -> legacy_6x, tag: SNAPSHOT_6-5-0-beta6, tag: 6.5.0.beta6)
*   a3407a04 2021-10-31 | Merge branch 'legacy_64' into legacy_6x (sourceforge/legacy_6x, origin/legacy_6x)
|\  
| * 86533e67 2021-10-31 | website: announce 6.4.23 release. (sourceforge/legacy_64, origin/legacy_64, legacy_64)
| * ce6c06dc 2021-10-31 | po/: Update German translation and record ja/sr updates. (tag: RELEASE_6-4-23)
| * 7183296d 2021-10-31 | Get ready for 6.4.23.
| * 56e8f9b6 2021-10-31 | IMAP: improve STARTTLS error message for ssh-plugin case
| * b93af8e8 2021-10-31 | NEWS: mention Мирослав Николић/Miroslav Nikolić as translator.
| * 0b90c974 2021-10-10 | Update <sr> Serbian translation to fetchmail-6.4.22.rc1 [Мирослав Николић]
| * 06113cae 2021-09-20 | NEWS: Mention Takeshi Hamasaki as translator.
* | fcb4ce6e 2021-09-20 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 47a2e9a0 2021-09-18 | Update <ja> Japanese translation to fetchmail 6.4.22.rc1 [Takeshi Hamasaki]
* | 298e7b79 2021-09-13 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 84f2d310 2021-09-13 | Get ready for 6.4.22. (tag: RELEASE_6-4-22)
| * 8eed56c2 2021-09-13 | Note OpenSSL 3.0.0 support and licensing change.
| * fded2be1 2021-09-01 | de.po: Fix typo in German translation
* | de625bd3 2021-09-13 | save
* | 53976bfd 2021-09-01 | CMake: check for vsyslog sym -> define HAVE_VSYSLOG
* | 647a75c5 2021-09-01 | Fix compilation in !HAVE_VSYSLOG path,
* | e433536a 2021-09-01 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 02693b4b 2021-09-01 | NEWS: fix spelink of Stefan Eßer's last name
| * 28490560 2021-09-01 | NEWS: Credit Petr Pisar for Czech translation.
| * 34656a01 2021-08-31 | IMAP: fix error code when LOGIN fails
| * 431ccf32 2021-08-30 | Update <sv> Swedish translation to fetchmail 6.4.22.rc1 [Göran Uddeborg]
| * 1a86e2c9 2021-08-29 | Update <cs> Czech translation to fetchmail 6.4.22.rc1 [Petr Pisar]
* | 921ecd0c 2021-08-30 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 4601caf3 2021-08-30 | website: announce 6.4.22.rc3
| * c863e9db 2021-08-29 | update SA-2021-02
| * 5b31e6e3 2021-08-29 | Get ready for 6.4.22.rc3. (tag: SNAPSHOT_6-4-22-rc3)
| * 5606d737 2021-08-29 | NEWS: Credit RC testers.
| * bdedbbd7 2021-08-29 | NEWS: credit translators.
| * 87af2407 2021-08-28 | Update <sq> Albanian translation to fetchmail-6.4.22.rc1 [Besnik Bleta]
| * 5d83eb47 2021-08-28 | Update <pl> Polish translation to fetchmail 6.4.22.rc1 [Jakub Bogusz]
| * d33bc06d 2021-08-29 | Fix IMAP protocol confusion on 2nd and subsequent polls.
| * a5a961e7 2021-08-28 | socket.c: invalid sslproto no longer abort()s
| * 79956228 2021-08-28 | Convert to UTF-8.
| * 8ca5b306 2021-08-28 | declare .txt to be UTF-8
| * 83341013 2021-08-28 | upload .htaccess
| * 36b4c0bb 2021-08-27 | Update <sv> Swedish translation to fetchmail 6.4.22.rc1 [Göran Uddeborg]
* | 358d2b0b 2021-08-28 | bump version to -beta6
* | 17853d32 2021-08-28 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 5f976705 2021-08-27 | Get ready for 6.4.22.rc2. (tag: SNAPSHOT_6-4-22-rc2)
| * c7c6055b 2021-08-27 | Credit fr/eo translators.
| * 521bcb6b 2021-08-27 | Update <fr> French translation to fetchmail-6.4.22.rc1 [Frédéric Marchal]
| * 1a293bb7 2021-08-27 | Update <eo> Esperanto translation to fetchmail 6.4.22.rc1 [Keith Bowes]
| * 616e8c70 2021-08-27 | imap.c, pop3.c: fix protocol regression of 6.4.22.rc1
| * 2a2150f4 2021-08-27 | etrn.c, odmr.c, pop2.c: declare NULL con-/destructors
| * 74771392 2021-08-27 | struct method: introduce con-/destructors
| * ec8e9e35 2021-08-27 | NEWS: fix typo.
| * 452d2c59 2021-08-27 | README.SSL-SERVER: require TLS 1.2/1.3
| * 44431fed 2021-08-27 | get ready for 6.4.22.rc1. (tag: SNAPSHOT_6-4-22-rc1)
| * 4b736f0a 2021-08-26 | Doxyfile: updates
| * 8363b7b7 2021-08-26 | Add CVE ID; revise TLS docs & fetchmail-SA-2021-02
| * 5cca5d1e 2021-08-26 | fetchmail.c: Fix SIGSEGV optmerge()ing "no envelope"
| * 27e6d102 2021-08-26 | po/de.po: Update German translation.
| * e12677b1 2021-08-26 | Misc POP3 cleanups.
| * 3837f0e2 2021-08-26 | SECURITY: imap.c, pop3.c: STARTTLS drops state
| * bb220dc1 2021-08-26 | NEWS: reword 6.4.21 regression fix to include --syslog
| * 4df94d59 2021-08-26 | fetchmail.c: reword port/--ssl checks to nudge user towards --ssl
| * 5b22b38d 2021-08-26 | sanity check well-known POP3/IMAP ports vs. SSL
| * 9ef9cd28 2021-08-26 | lock.c: fix unused-value warning in unlockit().
| * f5644ba2 2021-08-26 | POP3: make CAPA parser caseblind.
| * a0b9f2fb 2021-08-26 | xmalloc.h: Add GCC malloc attribute to xmalloc().
| * 46a82e13 2021-08-26 | imap.c, report.c: remove or comment dead stores.
| * 8517491d 2021-08-26 | SECURITY: POP3: changes for --auth ssh and RPA
| * b11d834a 2021-08-26 | NEWS: Deprecate RPA and other nonstandard auth' schemes.
| * 77b3f56c 2021-08-26 | socket.c: plugin/plugout SIGSEGV and memleak fixes
| * 8fae5227 2021-08-26 | IMAP: record server's CAPABILITY data in pre-auth state.
| * 1b20ea02 2021-08-26 | IMAP: report 'upgrade to TLS succeeded' before CAPA probe
| * c78cc2fc 2021-08-26 | SECURITY: IMAP: no longer permit LOGIN with LOGINDISABLED.
| * 39818023 2021-08-26 | fetchmail.c: fix typo in comment.
| * 0bd7f01f 2021-08-26 | IMAP: log error if --auth external requested but server does not advertise it.
| * 771a80b7 2021-08-26 | imap.c: one FIXME for command continuation requests
| * a2fcf70b 2021-08-26 | IMAP: two more AUTHENTICATE EXTERNAL fixes
| * 8001d09a 2021-08-26 | IMAP: fix base64 length calc. for AUTH=EXTERNAL
| * 84580ab8 2021-08-26 | IMAP: don't send * after failed AUTHENTICATE EXTERNAL
| * 7f0acc8f 2021-08-26 | IMAP: rename misnamed function and variable
| * 5e9e3c86 2021-08-26 | Bump version to 6.4.22.rc1
| * 7ed2377c 2021-08-26 | manpage: Fix indentation under --sslproto
| * e7199006 2021-08-26 | SECURITY: IMAP: --auth ssh no longer prevents STARTTLS
| * b82c3ccb 2021-08-26 | SECURITY: IMAP: PREAUTH->abort if STARTTLS needed
* | 9a617868 2021-08-09 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 3aad706d 2021-08-09 | 6.5.0.beta5: mention regression fix and idle timeout.
* | cf4bc0c5 2021-08-09 | Merge branch 'legacy_64' into legacy_6x
|/  
* f8377e3c 2021-08-09 | Announce 6.4.21 and 6.5.0.beta5.
================================================================================

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

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

Greetings,

Sorry - first announcement slipped with the wrong version tag (beta5 
instead of beta6).

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

The source archive has been uploaded and will shortly be available from:
<https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta6.tar.xz/download>

This is a deep link to the GnuPG signature:
<https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta6.tar.xz.asc/download>

This brings the 6.5.0 beta in line with the recent 6.4 developments.

This is the change history from Git:
================================================================================
* b26f8b3b 2021-10-31 | po/: record state (HEAD -> legacy_6x, tag: SNAPSHOT_6-5-0-beta6, tag: 6.5.0.beta6)
*   a3407a04 2021-10-31 | Merge branch 'legacy_64' into legacy_6x (sourceforge/legacy_6x, origin/legacy_6x)
|\  
| * 86533e67 2021-10-31 | website: announce 6.4.23 release. (sourceforge/legacy_64, origin/legacy_64, legacy_64)
| * ce6c06dc 2021-10-31 | po/: Update German translation and record ja/sr updates. (tag: RELEASE_6-4-23)
| * 7183296d 2021-10-31 | Get ready for 6.4.23.
| * 56e8f9b6 2021-10-31 | IMAP: improve STARTTLS error message for ssh-plugin case
| * b93af8e8 2021-10-31 | NEWS: mention Мирослав Николић/Miroslav Nikolić as translator.
| * 0b90c974 2021-10-10 | Update <sr> Serbian translation to fetchmail-6.4.22.rc1 [Мирослав Николић]
| * 06113cae 2021-09-20 | NEWS: Mention Takeshi Hamasaki as translator.
* | fcb4ce6e 2021-09-20 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 47a2e9a0 2021-09-18 | Update <ja> Japanese translation to fetchmail 6.4.22.rc1 [Takeshi Hamasaki]
* | 298e7b79 2021-09-13 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 84f2d310 2021-09-13 | Get ready for 6.4.22. (tag: RELEASE_6-4-22)
| * 8eed56c2 2021-09-13 | Note OpenSSL 3.0.0 support and licensing change.
| * fded2be1 2021-09-01 | de.po: Fix typo in German translation
* | de625bd3 2021-09-13 | save
* | 53976bfd 2021-09-01 | CMake: check for vsyslog sym -> define HAVE_VSYSLOG
* | 647a75c5 2021-09-01 | Fix compilation in !HAVE_VSYSLOG path,
* | e433536a 2021-09-01 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 02693b4b 2021-09-01 | NEWS: fix spelink of Stefan Eßer's last name
| * 28490560 2021-09-01 | NEWS: Credit Petr Pisar for Czech translation.
| * 34656a01 2021-08-31 | IMAP: fix error code when LOGIN fails
| * 431ccf32 2021-08-30 | Update <sv> Swedish translation to fetchmail 6.4.22.rc1 [Göran Uddeborg]
| * 1a86e2c9 2021-08-29 | Update <cs> Czech translation to fetchmail 6.4.22.rc1 [Petr Pisar]
* | 921ecd0c 2021-08-30 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 4601caf3 2021-08-30 | website: announce 6.4.22.rc3
| * c863e9db 2021-08-29 | update SA-2021-02
| * 5b31e6e3 2021-08-29 | Get ready for 6.4.22.rc3. (tag: SNAPSHOT_6-4-22-rc3)
| * 5606d737 2021-08-29 | NEWS: Credit RC testers.
| * bdedbbd7 2021-08-29 | NEWS: credit translators.
| * 87af2407 2021-08-28 | Update <sq> Albanian translation to fetchmail-6.4.22.rc1 [Besnik Bleta]
| * 5d83eb47 2021-08-28 | Update <pl> Polish translation to fetchmail 6.4.22.rc1 [Jakub Bogusz]
| * d33bc06d 2021-08-29 | Fix IMAP protocol confusion on 2nd and subsequent polls.
| * a5a961e7 2021-08-28 | socket.c: invalid sslproto no longer abort()s
| * 79956228 2021-08-28 | Convert to UTF-8.
| * 8ca5b306 2021-08-28 | declare .txt to be UTF-8
| * 83341013 2021-08-28 | upload .htaccess
| * 36b4c0bb 2021-08-27 | Update <sv> Swedish translation to fetchmail 6.4.22.rc1 [Göran Uddeborg]
* | 358d2b0b 2021-08-28 | bump version to -beta6
* | 17853d32 2021-08-28 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 5f976705 2021-08-27 | Get ready for 6.4.22.rc2. (tag: SNAPSHOT_6-4-22-rc2)
| * c7c6055b 2021-08-27 | Credit fr/eo translators.
| * 521bcb6b 2021-08-27 | Update <fr> French translation to fetchmail-6.4.22.rc1 [Frédéric Marchal]
| * 1a293bb7 2021-08-27 | Update <eo> Esperanto translation to fetchmail 6.4.22.rc1 [Keith Bowes]
| * 616e8c70 2021-08-27 | imap.c, pop3.c: fix protocol regression of 6.4.22.rc1
| * 2a2150f4 2021-08-27 | etrn.c, odmr.c, pop2.c: declare NULL con-/destructors
| * 74771392 2021-08-27 | struct method: introduce con-/destructors
| * ec8e9e35 2021-08-27 | NEWS: fix typo.
| * 452d2c59 2021-08-27 | README.SSL-SERVER: require TLS 1.2/1.3
| * 44431fed 2021-08-27 | get ready for 6.4.22.rc1. (tag: SNAPSHOT_6-4-22-rc1)
| * 4b736f0a 2021-08-26 | Doxyfile: updates
| * 8363b7b7 2021-08-26 | Add CVE ID; revise TLS docs & fetchmail-SA-2021-02
| * 5cca5d1e 2021-08-26 | fetchmail.c: Fix SIGSEGV optmerge()ing "no envelope"
| * 27e6d102 2021-08-26 | po/de.po: Update German translation.
| * e12677b1 2021-08-26 | Misc POP3 cleanups.
| * 3837f0e2 2021-08-26 | SECURITY: imap.c, pop3.c: STARTTLS drops state
| * bb220dc1 2021-08-26 | NEWS: reword 6.4.21 regression fix to include --syslog
| * 4df94d59 2021-08-26 | fetchmail.c: reword port/--ssl checks to nudge user towards --ssl
| * 5b22b38d 2021-08-26 | sanity check well-known POP3/IMAP ports vs. SSL
| * 9ef9cd28 2021-08-26 | lock.c: fix unused-value warning in unlockit().
| * f5644ba2 2021-08-26 | POP3: make CAPA parser caseblind.
| * a0b9f2fb 2021-08-26 | xmalloc.h: Add GCC malloc attribute to xmalloc().
| * 46a82e13 2021-08-26 | imap.c, report.c: remove or comment dead stores.
| * 8517491d 2021-08-26 | SECURITY: POP3: changes for --auth ssh and RPA
| * b11d834a 2021-08-26 | NEWS: Deprecate RPA and other nonstandard auth' schemes.
| * 77b3f56c 2021-08-26 | socket.c: plugin/plugout SIGSEGV and memleak fixes
| * 8fae5227 2021-08-26 | IMAP: record server's CAPABILITY data in pre-auth state.
| * 1b20ea02 2021-08-26 | IMAP: report 'upgrade to TLS succeeded' before CAPA probe
| * c78cc2fc 2021-08-26 | SECURITY: IMAP: no longer permit LOGIN with LOGINDISABLED.
| * 39818023 2021-08-26 | fetchmail.c: fix typo in comment.
| * 0bd7f01f 2021-08-26 | IMAP: log error if --auth external requested but server does not advertise it.
| * 771a80b7 2021-08-26 | imap.c: one FIXME for command continuation requests
| * a2fcf70b 2021-08-26 | IMAP: two more AUTHENTICATE EXTERNAL fixes
| * 8001d09a 2021-08-26 | IMAP: fix base64 length calc. for AUTH=EXTERNAL
| * 84580ab8 2021-08-26 | IMAP: don't send * after failed AUTHENTICATE EXTERNAL
| * 7f0acc8f 2021-08-26 | IMAP: rename misnamed function and variable
| * 5e9e3c86 2021-08-26 | Bump version to 6.4.22.rc1
| * 7ed2377c 2021-08-26 | manpage: Fix indentation under --sslproto
| * e7199006 2021-08-26 | SECURITY: IMAP: --auth ssh no longer prevents STARTTLS
| * b82c3ccb 2021-08-26 | SECURITY: IMAP: PREAUTH->abort if STARTTLS needed
* | 9a617868 2021-08-09 | Merge branch 'legacy_64' into legacy_6x
|\| 
| * 3aad706d 2021-08-09 | 6.5.0.beta5: mention regression fix and idle timeout.
* | cf4bc0c5 2021-08-09 | Merge branch 'legacy_64' into legacy_6x
|/  
* f8377e3c 2021-08-09 | Announce 6.4.21 and 6.5.0.beta5.
================================================================================

[Fetchmail-users] ANNOUNCE: The 6.4.23 release of fetchmail is available (usability fix for IMAP plugin + auth ssh, translation updates)

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

Greetings,

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

It updates the Japanese and Serbian translations and improves an error 
message around STARTTLS with IMAP --auth ssh and --plugin.

Note the tarball was re-rolled to include the German translation update,
missed in the first upload.

DISTRIBUTORS please note OpenSSL's licensing change for OpenSSL 3,
and you may want to review COPYING.

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

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

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.23.tar.lz)= 0fa3b57f05ec38b3ecb58d2221223b6a4da6e30dd857af37b49798c3e84a71e5
SHA256(fetchmail-6.4.23.tar.xz)= 5f7a5e13731431134a2ca535bbced7adc666d3aeb93169a0830945d91f492300

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.23 (released 2021-10-31, 30206 LoC):

# USABILITY:
* For common ssh-based IMAP PREAUTH setups (i. e. those that use a plugin
  - no matter its contents - and that set auth ssh), change the STARTTLS 
  error message to suggest sslproto '' instead.
  This is a commonly reported issue after the CVE-2021-39272 fix in 6.4.22.
  Fixes Redhat Bugzilla 2008160. Fixes GitLab #39.

# TRANSLATIONS: language translations were updated by these fine people:
* ja:    Takeshi Hamasaki [Japanese]
* sr:	 Мирослав Николић (Miroslav Nikolić) [Serbian]

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

Happy fetches,
Matthias