fetchmail-users — User questions and discussion

Re: [Fetchmail-users] fetchmail crashing

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

Am 16.06.25 um 17:45 schrieb Andrea Venturoli:
> Hello.
>
> Recently fetchmail has started crashing on a couple of servers of mine.


Hi Andrea,


mille grazie for the report and debugging. I've put this up as issue #71 
<https://gitlab.com/fetchmail/fetchmail/-/issues/71>.

Would you also know a quick way to reproduce it?


>
> The problem seems to be in socket.c:
>
>> int SockWrite(int sock, const char *buf, int len)
>> {
>>         /* WARNING: This is messy - we use an int pointer, so does 
>> SSL_write, but fm_write/write would use ssize_t instead.
>>         Assume that write() won't ever return something that wouldn't 
>> fit an int. */
>>     int n;
>>     int wrlen = 0;
>> #ifdef  SSL_ENABLE
>>     SSL *ssl = SSLGetContext(sock);
>> #endif
>>
>>     while (len)
>>     {
>> #ifdef SSL_ENABLE
>>         if (ssl) {
>>             ERR_clear_error();
>>             n = SSL_write(ssl, buf, len);
>>         } else
>> #endif /* SSL_ENABLE */
>>             n = fm_write(sock, buf, len);
>> #ifdef SSL_ENABLE
>>         if (n <= 0) {
>>             int ssle = SSL_get_error(ssl, n); // do this before 
>> flushing the error queue!
>>             // map error code to n = 0 -> retryable or n = -1 -> true 
>> error
>>             switch(ssle) {
>>                 case SSL_ERROR_ZERO_RETURN:
>>                 case SSL_ERROR_SYSCALL:
>>                 case SSL_ERROR_SSL:
>>                         n = -1; break;
>>                 default:
>>                         /* assume retryable */
>>                         n = 0; break;
>>             }
>>             if (n)
>>                     ERR_print_errors_fp(stderr); // do this after 
>> SSL_get_error - and only on fatal errors
>>         }
>> #endif
>>         if (n < 0)
>>             return -1;
>>         len -= n;
>>         wrlen += n;
>>         buf += n;
>>     }
>>     return wrlen;
>> }
>
> Here ssl is first checked in order to decide if SSL_write or fm_write 
> should be called.
> Then, regardless of the choice, in case of error, SSL_get_error is 
> called (even when ssl is NULL) and that's where the program crashes.

Plausible. I could issue 6.5.4 once I understand or reproduce this with 
a fix.

>
>
>
> Maybe I'm wrong, but I think the lines:
>>>         if (n <= 0) {
>>>             int ssle = SSL_get_error(ssl, n); // do this before 
>>> flushing the error queue!
>
> should be changed to:
>
>>>         if (ssl && n <= 0) {
>>>             int ssle = SSL_get_error(ssl, n); // do this before 
>>> flushing the error queue!
>
>
> (Or the whole "if {...}" could be moved inside the first "if (ssl)").
>
>
>
>
> In any case, thanks a lot for providing this software!

Thanks a lot for your report!

Cheers,
Matthias

[Fetchmail-users] fetchmail crashing

[Andrea V. <ml...@ne...>]

Hello.

Recently fetchmail has started crashing on a couple of servers of mine.

The problem seems to be in socket.c:

> int SockWrite(int sock, const char *buf, int len)
> {
>         /* WARNING: This is messy - we use an int pointer, so does SSL_write, but fm_write/write would use ssize_t instead.
>         Assume that write() won't ever return something that wouldn't fit an int. */
>     int n;
>     int wrlen = 0;
> #ifdef  SSL_ENABLE
>     SSL *ssl = SSLGetContext(sock);
> #endif
> 
>     while (len)
>     {
> #ifdef SSL_ENABLE
>         if (ssl) {
>             ERR_clear_error();
>             n = SSL_write(ssl, buf, len);
>         } else
> #endif /* SSL_ENABLE */
>             n = fm_write(sock, buf, len);
> #ifdef SSL_ENABLE
>         if (n <= 0) {
>             int ssle = SSL_get_error(ssl, n); // do this before flushing the error queue!
>             // map error code to n = 0 -> retryable or n = -1 -> true error
>             switch(ssle) {
>                 case SSL_ERROR_ZERO_RETURN:
>                 case SSL_ERROR_SYSCALL:
>                 case SSL_ERROR_SSL:
>                         n = -1; break;
>                 default:
>                         /* assume retryable */
>                         n = 0; break;
>             }
>             if (n)
>                     ERR_print_errors_fp(stderr); // do this after SSL_get_error - and only on fatal errors
>         }
> #endif
>         if (n < 0)
>             return -1;
>         len -= n;
>         wrlen += n;
>         buf += n;
>     }
>     return wrlen;
> }

Here ssl is first checked in order to decide if SSL_write or fm_write 
should be called.
Then, regardless of the choice, in case of error, SSL_get_error is 
called (even when ssl is NULL) and that's where the program crashes.



Maybe I'm wrong, but I think the lines:
>>         if (n <= 0) {
>>             int ssle = SSL_get_error(ssl, n); // do this before flushing the error queue!

should be changed to:

>>         if (ssl && n <= 0) {
>>             int ssle = SSL_get_error(ssl, n); // do this before flushing the error queue!


(Or the whole "if {...}" could be moved inside the first "if (ssl)").




In any case, thanks a lot for providing this software!

  bye
	av.

[Fetchmail-users] ANNOUNCE: fetchmail 6.5.3 is available (reinstate IDLE workaround & translation update for Spanish (Castellano))

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

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

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.3.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.3.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.3.tar.xz)= d74e893b78ef29ebef375ab7e726d2977140f8f1208f5905569395cbdae4c23d


Note that I have re-rolled the tarball and moved the tag and forced 
committed between 19:15 UTC and 19:30 UTC today because the 
documentation, manual page, NEWS file, commit logs accidentally 
referenced Gitlab issue #68 when they should have referenced Gitlab 
issue #69.  Now fixed.


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.3 (released 2025-06-10, 31204 LoC):

## BUGFIXES:
* IMAP: Reinstate workaround for missing IDLE support if --idle is requested.
  This had been a long-standing feature but got broken in fetchmail 6.4.22
  (commit 616e8c70).  Thanks to Lukáš Tesař for the detailed report including
  a Git bisect that identified this faulty commit.  Fixes Gitlab issue #69.
* IMAP: Only print 'will idle after poll' if --idle is enabled
  and either offered by the server, or forced through --forceidle.
  This fixes a regression introduced in fetchmail 6.4.22 (commit 616e8c70).

## TRANSLATIONS: fetchmail's translation was updated, courtesy of:
* es:    Cristian Othón Martínez Vera [Spanish]

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

Re: [Fetchmail-users] Any way to remove timestamps from fetchmail output?

[Spencer C. <sp...@sp...>]

> Hello Spencer,
> 
> Thanks for the question and feedback. The log format is hardcoded, so
> you have not missed anything like a switch, there is none.
> 
> I'll see if I can change something for 6.5.3 to fix the double
> timestamp though,
> <https://gitlab.com/fetchmail/fetchmail/-/issues/66>.
> 
> In the interim, for cron, the first timestamp - can be stripped off by
> piping the output through sed, say,
> 
> fetchmail --your-options-here 2>&1 | sed -Ee
> 's/^(Jan|Feb|Mar|Apr|May|Ju[nl]|Aug|Sep|Oct|Nov|Dev) [0-9]{1,2}  
> [0-9]{1,2}:[0-9]{2}:[0-9]{2} //'
> 
> HTH
> 
> Matthias

Thanks Matthias. I'll try the 'sed' trick to get rid of the first one and would appreciate it if the double timestamp could be fixed.

Regards,

Spencer

Re: [Fetchmail-users] Any way to remove timestamps from fetchmail output?

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

Am 14.04.25 um 10:36 schrieb Spencer Collyer:
> Hi,
>
> After a recent update of my Arch Linux system my fetchmail is now at release 6.5.2+TLS+NLS.
>
> Since updating to this release, I'm seeing timestamps appearing in the fetchmail output, where they didn't appear before.
>
> For instance, sample output used to be:
>
> -----------------------------------------------
> 2 messages for spencercollyer at mail.plus.net (89359 octets).
> reading message spe...@ma...:1 of 2 (47364 octets) flushed
> reading message spe...@ma...:2 of 2 (41995 octets) flushed
> -----------------------------------------------
>
> But now I'm getting:
> -----------------------------------------------
> Apr 04 09:00:00 fetchmail: 3 messages for spencercollyer at mail.plus.net (82284 octets).
> Apr 04 09:00:00 fetchmail: reading message spe...@ma...:1 of 3Apr 04 09:00:00 fetchmail:  (31026 octets) flushed
> Apr 04 09:00:00 fetchmail: reading message spe...@ma...:2 of 3Apr 04 09:00:00 fetchmail:  (31715 octets) flushed
> Apr 04 09:00:01 fetchmail: reading message spe...@ma...:3 of 3Apr 04 09:00:01 fetchmail:  (19543 octets) flushed
> -----------------------------------------------
>
> I'd like to go back to the old style format, as I don't really need the timestamp - I always call fetchmail in a cron job so don't need the timestamp as the mail from cron tells me when it iwas run.
>
> Failing that, is it possible to at least get rid of the second timestamp on each line? That is just noise which makes the message harder to read.
>
> I've looked over the help that's printed if you use `fetchmail -h` but don't see anything on there.
>
> Thanks,
>
> Spencer

Hello Spencer,

Thanks for the question and feedback. The log format is hardcoded, so
you have not missed anything like a switch, there is none.

I'll see if I can change something for 6.5.3 to fix the double timestamp
though, <https://gitlab.com/fetchmail/fetchmail/-/issues/66>.

In the interim, for cron, the first timestamp - can be stripped off by
piping the output through sed, say,

fetchmail --your-options-here 2>&1 | sed -Ee
's/^(Jan|Feb|Mar|Apr|May|Ju[nl]|Aug|Sep|Oct|Nov|Dev) [0-9]{1,2}
[0-9]{1,2}:[0-9]{2}:[0-9]{2} //'

HTH

Matthias

[Fetchmail-users] Any way to remove timestamps from fetchmail output?

[Spencer C. <sp...@sp...>]

Hi,

After a recent update of my Arch Linux system my fetchmail is now at release 6.5.2+TLS+NLS.

Since updating to this release, I'm seeing timestamps appearing in the fetchmail output, where they didn't appear before.

For instance, sample output used to be:

-----------------------------------------------
2 messages for spencercollyer at mail.plus.net (89359 octets).
reading message spe...@ma...:1 of 2 (47364 octets) flushed
reading message spe...@ma...:2 of 2 (41995 octets) flushed
-----------------------------------------------

But now I'm getting:
-----------------------------------------------
Apr 04 09:00:00 fetchmail: 3 messages for spencercollyer at mail.plus.net (82284 octets).
Apr 04 09:00:00 fetchmail: reading message spe...@ma...:1 of 3Apr 04 09:00:00 fetchmail:  (31026 octets) flushed
Apr 04 09:00:00 fetchmail: reading message spe...@ma...:2 of 3Apr 04 09:00:00 fetchmail:  (31715 octets) flushed
Apr 04 09:00:01 fetchmail: reading message spe...@ma...:3 of 3Apr 04 09:00:01 fetchmail:  (19543 octets) flushed
-----------------------------------------------

I'd like to go back to the old style format, as I don't really need the timestamp - I always call fetchmail in a cron job so don't need the timestamp as the mail from cron tells me when it iwas run.

Failing that, is it possible to at least get rid of the second timestamp on each line? That is just noise which makes the message harder to read.

I've looked over the help that's printed if you use `fetchmail -h` but don't see anything on there.

Thanks,

Spencer

Re: [Fetchmail-users] New draft rfc: OAuth Profile for Open Public Clients

[Lucio C. <lu...@la...>]

On Sun, 12 Jan 2025, Matthias Andree wrote:

> How can I NOT have the impression that this is all going in the wrong 
> direction? If you see fetchmail as a set-up-and-forget piece of embedded 
> software, that entire OAuth 2 thing is nothing but reinventing wheels so 
> heavy that you need corporations to handle them.

I agree that, as users. we should do what we can to stay away of 
OAuth-based providers, either: (a) using other mechanisms like "app 
passwords" if available (may work both with fetchmail and mail clients); 
(b) rerouting mail from OAuth-based providers to fetchmail-friendly IMAP 
providers (or abandoning OAuth-based providers); (c) running one's owm 
e-mail host on a VPS (I haven't yet tried that).


-- 
Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
A middle rank researcher at end career is not rich but is in the top 5%
of the Italian income tax taxpayers. Does it not sound strange ?

Re: [Fetchmail-users] fetchmail + oauth2 + outlook

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

Am 12.01.25 um 17:56 schrieb Gerard E. Seibert:
> poll outlook.office365.com with protocol imap timeout 30 and options bad-header accept
>      auth oauthbearer <User Email Address>
>      passwordfile "/home/john/.fetchmail-token" is <John_Smith> here
>      options flush forcecr dropdelivered smtpname 'john_smith@mydomain,com' ssl sslproto 'auto' sslcertfile /usr/local/share/certs/ca-root-nss.crt sslcertck sslcertpath /usr/local/etc/
>
> This is fetchmails response.
>
> fetchmail:/usr/local/etc/fetchmailrc:46: syntax error, unexpected STRING, expecting AUTHTYPE at oauthbearer
> fetchmail:/usr/local/etc/fetchmailrc:46: syntax error, unexpected STRING, expecting AUTHTYPE at oauthbearer
> Stopping fetchmail.
> Waiting for PIDS: 52729.
> Starting fetchmail.
> fetchmail:/usr/local/etc/fetchmailrc:46: syntax error, unexpected STRING, expecting AUTHTYPE at oauthbearer
> /usr/local/etc/rc.d/fetchmail: WARNING: failed to start fetchmail
>
> I found nothing in the Fetchmail FAQ or manual for configuring oauth2 with outlook.
>
> Fetchmail's version:
>
> This is fetchmail release 6.5.1+RPA+SDPS+TLS+NLS.

Gerard,

fetchmail releases (such as 6.5.x in FreeBSD or other operating systems)
do not support OAuth2. In fact, fetchmail does not formally support
OAuth2 at all. There is some contributed code in the Git repository on
the "next" branch, which requires some more development tools and user
proficiency installed to use. It is not a turnkey solution.

I would be helpful to lobby providers away from the massive burden of
OAuth2 towards existing solutions, such as GSSAPI-based Kerberos.

Regards
Matthias

[Fetchmail-users] fetchmail + oauth2 + outlook

[Gerard E. S. <ger...@gm...>]

This is from a FreeBSD 14.2-RELEASE OS

I have been trying for the first time to get fetchmail to work with outlook.com and oauth2. It has been a colossal failure.

I tried Googling for an answer and discovered a virtual cornucopia of different and sometimes conflicting scenarios.

The last one I tried was this one.

This is from a FreeBSD 14.2-RELEASE OS

I have been trying for the first time to get fetchmail to work with outlook.com and oauth2. It has been a colossal failure.

I tried Googling for an answer and discovered a virtual cornucopia of different and sometimes conflicting scenarios.

The last one I tried was this one.

poll outlook.office365.com with protocol imap timeout 30 and options bad-header accept
    auth oauthbearer <User Email Address>
    passwordfile "/home/john/.fetchmail-token" is <John_Smith> here
    options flush forcecr dropdelivered smtpname 'john_smith@mydomain,com' ssl sslproto 'auto' sslcertfile /usr/local/share/certs/ca-root-nss.crt sslcertck sslcertpath /usr/local/etc/

This is fetchmails response.

fetchmail:/usr/local/etc/fetchmailrc:46: syntax error, unexpected STRING, expecting AUTHTYPE at oauthbearer
fetchmail:/usr/local/etc/fetchmailrc:46: syntax error, unexpected STRING, expecting AUTHTYPE at oauthbearer
Stopping fetchmail.
Waiting for PIDS: 52729.
Starting fetchmail.
fetchmail:/usr/local/etc/fetchmailrc:46: syntax error, unexpected STRING, expecting AUTHTYPE at oauthbearer
/usr/local/etc/rc.d/fetchmail: WARNING: failed to start fetchmail

I found nothing in the Fetchmail FAQ or manual for configuring oauth2 with outlook.

Fetchmail's version:

This is fetchmail release 6.5.1+RPA+SDPS+TLS+NLS.
Compiled with SSL library 0x30300020 "OpenSSL 3.3.2 3 Sep 2024"
Run-time uses SSL library 0x30300020 "OpenSSL 3.3.2 3 Sep 2024"
OpenSSL: OPENSSLDIR: "/usr/local/openssl"
Engines: ENGINESDIR: "/usr/local/lib/engines-15"

I am hoping someone could assist me.
-- 

Thanks!

Gerard

Re: [Fetchmail-users] New draft rfc: OAuth Profile for Open Public Clients

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

Am 11.01.25 um 09:11 schrieb Andrew C Aitchison:
>
> New draft rfc: OAuth Profile for Open Public Clients
>
> https://www.ietf.org/archive/id/draft-ietf-mailmaint-oauth-public-00.html
>
> I am not sure how useful this will be for GMail and Microsoft,
> but this may make it simpler to support OAUTH with many other email
> services.
>
Hi Andrew,

thank you for the pointer.

In the end, what the Intro says is this 20-page IETF draft is pulling
together existing standards, apparently there is at least one more to be
written, but the bottom line is we're adding 20 more pages of text to
the 423 pages of existing OAuth related ones (I've discounted three that
aren't relevant to client implementors), not factoring in the W3C's Web
Authentication spec, which is very long, too.

RFC8252 specifically states

>                         OAuth 2.0 for Native Apps
>
> Abstract
>
>     OAuth 2.0 authorization requests from native apps should only be made
>     through external user-agents, primarily the user's browser.  This
>     specification details the security and usability reasons why this is
>     the case and how native apps and authorization servers can implement
>     this best practice.
So basically cementing "you must use an external browser for OAuth", or
there must be an additional fetchmail-oauth2-authorizer application that
doesn't store much to disk to complete that. Which is more or less
another browser.
Or whatever separate user-agent needs to be maintained AND SECURE (lest
we endanger client systems). Uh.

Also, the client app must implement considerable amounts of browsing and
parsing client code, all of which fetchmail has never needed.

It would specifically need a HTTPS client (meaning HTTP generator and
parser, including TLS and the necessary security bits), JSON generator
and parser (more or less REST API client-side support), JW* support for
signatures and whatnot, all the OAuth profile knowledge, for what? Just
Authentication for Mail?

How can I NOT have the impression that this is all going in the wrong
direction? If you see fetchmail as a set-up-and-forget piece of embedded
software, that entire OAuth 2 thing is nothing but reinventing wheels so
heavy that you need corporations to handle them. Looks to me that OAuth2
is wonderful because it opens so many new problems that you ever and
ever need more standards to solve problems you would not have had
without OAuth2 and design and implementation flaws in existing
OAuth2-enabled software.


Anyone who wands to help with OAuth2 nonetheless, please see
<https://gitlab.com/fetchmail/fetchmail/-/blob/next/CONTRIBUTING.txt?ref_type=heads>
(if that file doesn't exist in the future, and you read this from an
archive, see if it became a .md or a .rst file).


Best regards,
Matthias

[Fetchmail-users] New draft rfc: OAuth Profile for Open Public Clients

[Andrew C A. <fet...@ai...>]

New draft rfc: OAuth Profile for Open Public Clients

https://www.ietf.org/archive/id/draft-ietf-mailmaint-oauth-public-00.html

I am not sure how useful this will be for GMail and Microsoft,
but this may make it simpler to support OAUTH with many other email
services.

-- 
Andrew C. Aitchison                      Kendal, UK
                    an...@ai...

Re: [Fetchmail-users] Fetchmail vs outlook - missing emails

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

Am 06.01.25 um 11:28 schrieb sup...@gm...:
> I wonder if anyone can shed some light on a peculiar problem I have:
>
> I use fetchmail to grab my email off an outlook server and recently we've had a new accounting system added which issues notifications via outlook for things that need to be done.
>
> These notifications end up in my outlook inbox but it appears that fetchmail won't get them.
>
> Looking at the logs I have messages like this:
>
> Jan 06 10:11:19 fetchmail: SMTP error: 553 5.1.8 <XXXX>... Domain of sender address don...@XX... does not exist
> Jan 06 10:11:19 fetchmail: can't even send to XXXX!
> Jan 06 10:11:19 fetchmail:  not flushed
>
> Is there any simple way to fix this?

fetchmail is stating that your local SMTP server (usually localhost)
rejected the sender's domain. fetchmail can't fix that.


Quite simply fix your receving end's configuration.

1. make sure your DNS works properly and can resolve legit sender domains

2. make your local SMTP server that fetchmail forwards to accept all
mail injected locally from fetchmail. Whatever software that is, you
would not mention, but likely you also need to seek its support
channels, not fetchmail's.


If you need further help, see
<https://www.fetchmail.info/fetchmail-FAQ.html#G3> for more information
as to what's required to assist. Do not elide domains, we can't help you
otherwise. Replace local parts systematically.

[Fetchmail-users] Fetchmail vs outlook - missing emails

[<sup...@gm...>]

I wonder if anyone can shed some light on a peculiar problem I have:

I use fetchmail to grab my email off an outlook server and recently we've had a new accounting system added which issues notifications via outlook for things that need to be done.

These notifications end up in my outlook inbox but it appears that fetchmail won't get them.

Looking at the logs I have messages like this:

Jan 06 10:11:19 fetchmail: SMTP error: 553 5.1.8 <XXXX>... Domain of sender address don...@XX... does not exist
Jan 06 10:11:19 fetchmail: can't even send to XXXX!
Jan 06 10:11:19 fetchmail:  not flushed

Is there any simple way to fix this?

[Fetchmail-users] ANNOUNCE: fetchmail 6.5.2 is available (translation updates for Czech and Serbian)

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

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

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.2.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.2.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.2.tar.xz)= 8fd0477408620ae382c1d0ef83d8946a95e5be0c2e582dd4ebe55cba513a45fe


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.2 (released 2024-12-30, 31200 LoC):

## TRANSLATIONS: fetchmail's translations were updated, courtesy of:
* cs:    Petr Pisar [Czech]
* sr:    Мирослав Николић (Miroslav Nikolić) [Serbian]

## CHANGES:
* Minor documentation consistency fixes (versions, dates).

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

[Fetchmail-users] ANNOUNCE: fetchmail 6.5.1 is available (minor polishing)

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

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

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.1.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.1.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.1.tar.xz)= ca3fdb95141c277aca109be77f4d45b47e03ee010043058dd90bc182db518d4a


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.1 (released 2024-11-13):

## BUG AND PORTABILITY FIXES:
* Drop two wolfSSL compile-time checks that were for older 6.4 or for future
  7.0 releases and broke compilation with wolfSSL 5.7.4. 
  Fixes https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282413#c4
* Use %p instead of non-portable %#p for one wolfSSL-related diagnostic message
  (FreeBSD defines %#p to be %p, on many other platforms it's undefined 
  behavior).
* Add regex_helper.c to list of files that contain translatable strings,
  which contains two strings we missed to translate.

## CHANGES:
* Simplify EVP_MD_fetch API detection ("like OpenSSL 3" vs. "like OpenSSL 1") 
  for version switch and base it on the claimed OpenSSL version of the crypto 
  SSL, which works for LibreSSL (claims OpenSSL 2) and wolfSSL alike.

## TRANSLATIONS: fetchmail's messages were translated by these fine people:
* sq:    Besnik Bleta [Albanian]
* es:    Cristian Othón Martínez Vera [Spanish]
* ro:    Remus-Gabriel Chelu [Romanian]
* fr:    Frédéric Marchal [French]
* pl:    Jakub Bogusz [Polish]
* sv:    Göran Uddeborg [Swedish]
* ja:    Takeshi Hamasaki [Japanese]
* eo:    Keith Bowes [Esperanto]

-------------------------------------------------------------------------------
fetchmail-6.5.0 (released 2024-10-29, 31200 LoC):

## SECURITY FIX:
* .netrc now may not have more than 0700 permission if it contains passwords,
  else fetchmail will warn and ignore the file.

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

## INCOMPATIBLE CHANGES
* fetchmail by default only negotiates TLS v1.2 or higher. (RFC-7525)
* fetchmail can auto-negotiate TLS v1.1 through the --sslproto tls1.1+ option.
* fetchmail can auto-negotiate TLS v1.0 through the --sslproto tls1+ option.
* fetchmailconf now requires Python 3.7.0 or newer.
* fetchmail, with --logfile, now logs time stamps into the file, in localtime
  and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized through
  the environment variables LC_TIME (or LC_ALL) and TZ.
  Contributed by Holger Hoffstätte.
* fetchmail sets the OPENSSL security level to 2 by default.
  Override is possible from an environment variable,
  see EXPERIMENTAL CHANGES below.
* The ca, da, en_GB, id, it, nl, ru, zh_CN translations have been disabled,
  they are too far behind.

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

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

* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL or wolfSSL,
  at a minimum OpenSSL v3.0.9 or wolfSSL v5.7.2.

## TRANSLATIONS: fetchmail's messages were translated by these fine people:
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* es:    Cristian Othón Martínez Vera [Spanish]
* fr:    Frédéric Marchal [French]
* ja:    Takeshi Hamasaki [Japanese]
* ro:    Remus-Gabriel Chelu [Romanian]
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* pl:    Jakub Bogusz [Polish]

## BUG FIXES
* fetchmail can now report mailbox sizes of 2^31 octets and beyond (2 GibiB).
  This required C99 support (for the long long type).
  Fixes Debian Bug#873668, reported by Andreas Schmidt.
* fetchmail now defines its OpenSSL API level to 3.0.0 so as to expose the
  3.0.0 APIs from OpenSSL.
* The .netrc parser no longer permits "machine" after "default".
* Add manpage info on the .netrc syntax, as ftp(1) is not standardized and
  may not be installed. Fixes Launchpad Bug #1976361 reported by Bill Yikes.
* Received: lines now return GMT time if the tzoffset cannot be represented
  as whole minutes. Reported by @rriddicc via Gitlab #49.
* If fetchmail was running localized, generated an error e-mail message locally,
  and if the selected translation would require the Subject: line to wrap
  inside an RFC-2047 encoded word (=?UTF-8?Q?...?=), the wrapped encoded-word
  was not indented, thus not marked as a continuation line.
* SSL error handling was improved, fetchmail now consistently clears the
  thread/SSL error queue before SSL I/O operations and checks SSL_get_error
  afterwards.  The SSL_connect() error handling has been revised to log more
  consistently.

## CHANGES
* When fetchmail attempts to log out from an IMAP4 server and the server messes
  up its responses (it is supposed to send an untagged * BYE and a tagged
  A4711 OK) and sends a tagged A4711 BYE response, tolerate that, rather than
  reporting a protocol error. We don't intend to chat any more so the protocol
  violation is harmless, and we know the server cannot send more untagged
  status responses.
  Analysis and fix courtesy of Maciej S. Szmigiero, GitLab merge request !20.
* The configure script now spends more effort for getting --with-ssl right, by
  running pkg-config in the right environment, and using the AC_LIB_LINKFLAGS
  macro to obtain run-time library path setting flags.
* For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option
  do not match, emit a warning and continue. Closes Gitlab #31.
* There is now a --idletimeout feature contributed by Eric Durand, to
  permit setting a shorter timeout for the --idle option, because many
  servers violate the protocol (requiring 30 minutes) and hang up sooner than
  the 28 minutes fetchmail waits before refreshing IDLE.
  GitLab merge request !35.
* There is now a --forceidle feature to force idle mode even if not advertised
  in the server capabilities. This is a dangerous option, use it carefully.
  Courtesy of Eric Durand, GitLab merge request !39.
* There is now a --moveto feature (only feasible in IMAP) that, instead of
  flushing mail, moves it to a user-specified folder. This is to assist with
  archiving, or when providers (G...) break the IMAP model.
  Courteously provided by Damjan Jovanovic.
* rcfile parsing errors are now reported in more detail, and with -vv mode,
  also lead to a non-importable Python dump of what was obtained, for debugging.
* fetchmail's --auth option ssh was renamed to implicit, to make clear that it
  does *NOT* imply any particular type or features of the --plugin.  --auth ssh
  will be understood for a while for compatibility but fetchmail will report it
  as implicit.
* fetchmail no longer warns about port/service mismatches with/without ssl
  option when a "plugin" is in use because fetchmail cannot know whether the
  plugin talks SSL or STARTTLS/STLS. Fixes Debian Bug#1076604.
* fetchmail re-executes itself if the .netrc file's modification change
  is found to be newer at the beginning of a new run.
* fetchmail can now use other digest algorithms than MD5 for the
  --sslfingerprint option. To use, specify the algorithm's name in
  curly braces as prefix in the finger print, say,
  --sslfingerprint '{SHA256}00:01:[...]:1F'. This will also switch the
  algorithm for printing. All algorithms supported by the TLS/SSL library
  can be specified. Fixes Gitlab issue #19, Debian Bug#700266.

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

================================================================================

Re: [Fetchmail-users] Generate Bouncemail from nonzero exit code returned by procmail

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

Am 30.10.24 um 21:10 schrieb Marvin Dickhaus via Fetchmail-users:
> Hey all,
>
> I have the following setup:
> local mailbox --> fetchmail --> procmail --> another local mailbox
>
> My .procmailrc is configured to reject certain mails with exitcode 67

Procmail should not be used. Transition to something that hasn't got a
flawed design or been in disrepair for 30 years.

> My .fetchmailrc is configured not to keep mails and fetch all.
>
> My expectation would be, that mails "rejected" by procmail would be
> bounced by fetchmail.
> However that is not the case. Instead fetchmail fetches the mails on
> every call and doesn't generate any bouncemails for them.
> Is there anything I'm doing wrong, or is it just not possible to
> generate a bouncemail in this scenario?
> I've also tried setting "antispam 067" in .fetchmailrc but that did
> not change anything.

You should not bounce mail after you've downloaded ever. Either you can
reject it in the SMTP conversation before you accept it, or if you have
accepted it you delete or discard it, but you don't bounce because you
have no proof that the sender address in the e-mail is correct.

Fetchmail has a "softbounce" option that is ON by default to avoid mail
loss because too many new users used to shoot holes in their feet.

If you want to delete mail, then the recourse is adding these two lines
atop your .fetchmailrc:

set no bouncemail
set no softbounce

> Note: I did also install featchmail on Archlinux (version 6.4.39) but
> experienced the same behavior here.

Thanks for that attempt because I was almost tempted to tell you that
fetchmail 6.3.x has been unsupported for the past five years.

fetchmail 6.5.0 has been released yesterday and I don't want to spend
time on 6.4.x either any more, but I won't blame a distro that takes a
few days to adopt it, and 6.4.39 qualified because 6.5.0 is the same.

FreeBSD's "latest" ports tree has just updated.

Re: [Fetchmail-users] fetchmail-6.5.0 questions

[Ken M. <zar...@nt...>]

On Wed, Oct 30, 2024 at 08:35:41PM +0100, Matthias Andree via Fetchmail-users wrote:
> Am 30.10.24 um 17:06 schrieb Ken Moffat via Fetchmail-users:
> > Hi,
> 
> Hi Ken,
> 
> thanks for reaching out.
> 
> > 
> > I see that fetchmail no longer supports using an MDA as SMTP
> > fallback.
> 
> Yes. That only means there is no fallback from SMTP to MDA if the former
> fails. The plan is to always behave consistently and not try to do A
> today and in adverse situations we try B and you have to start looking
> where/how your mail ended up, because B wasn't equivalent to A (and
> fetchmail cannot prove or disprove that). I don't like such surprises.
> So I threw the fallout behavior out without removing MDA or SMTP.
> 
> Assume you use Postfix. What if you had procmail as a fallback but
> Postfix uses its own local(8) without procmail? Then procmail would
> behave differently from Postfix's local... or some messages would be
> logged by Postfix, others would not.
> 
> You configure an mda or use --mda on the command line, fetchmail uses MDA,
> you don't use mda or --mda then fetchmail uses SMTP (default) or LMTP or
> whatever else you configured.
> 
> > Sending mail to lists, and getting the incoming, for a home user has
> > become increasingly complex and I try not to change my setup. As
> > best I can understand (several years since I had to change it apart
> > from a password), I'm doing the following: (one human user on my
> > systems).
> > 
> > 1. postfix on home server, running as servername.mydomain.
> > 
> > 2. outgoing: postfix connects to my ISP's server using Cyrus-SASL.
> > 
> > 3. incoming: a cron job to run fetchmail authenticating to my ISP
> > and retrieving POP3.
> > 
> > I have always specified --enable-fallback=procmail, but I see that
> > my fetchmailrc has a comented-out invocation of procmail with a
> > comment that procmail is not needed for that if the mail server is
> > correctly setup.
> > 
> > Am I worrying unnecessarily ?
> 
> Maybe. As long as you notice in some - for you, anyways - reasonable
> timeframe that your Postfix is down, this should be good. I found that
> on reasonable distros (I have used Fedora Linux and FreeBSD in the past
> years and have been quite content) there aren't Postfix surprises for me.
> 
> ...but fetchmail should notice that it has not succeeded in retrieving
> those messages and will therefore not delete them and retry them later
> (except maybe if it uses LAST on your POP3 server, in that case you
> could specify --uidl or uidl).
> 
> > I see that procmail was originally specified so that if the mail
> > server was not responding, mail would be processed by procmail. I
> > assume (if I do not need to change anything) that if my local server
> > does not respond then the mail will just be queued ?
> 
> If your default is to talk to SMTP, it's re-fetch the same message
> later, do not delete it.
> 
> > 
> > En passant (testing configure on a desktop without kerberos):
> >   CFLAGS:   -g -O2 -I/usr/kerberos/include
> > looks a bit odd : /usr/kerberos ?
> 
> Yeah, we've had such stuff needed in various circumstances, ./configure
> adds it, either because it's one of the search paths you have for a
> ./configure --with-kerberos like option, or as a leftover workaround
> from Red Hat Linux 9 (must have been in the early 2000's) I forgot to
> remove.  At that time, some SSL implementations needed such an option to
> find krb5.h. This shouldn't be in use today, but also in
> /usr/kerberos/include there shouldn't be stuff that disturbs us. Too
> late for 6.5.0 now, should've known during the betas then I could have
> done something...
> 
> We'd need to look at your config.log and/or console output, together
> with configure.ac, to see what's there, but if fetchmail behaves
> normally and fetchmail -V doesn't emit strange things, you're probably good.
> 
> HTH
> Matthias
> 
Hi, Matthias.

Thanks for that. I'll give it a try when I've got time (with luck,
in a day or two).

I must admit I hadn't looked at past fetchmail build logs, it
turns out /usr/kerberos has been mentioned since at least
fetchmail-6.3.26.  Sorry for the noise about that.

ĸen
-- 
  I saw an eagle fly once.
  Fortunately, I had my eagle fly swatter handy.

[Fetchmail-users] Generate Bouncemail from nonzero exit code returned by procmail

[Marvin D. <acc...@ma...>]

Hey all,

I have the following setup:
local mailbox --> fetchmail --> procmail --> another local mailbox

My .procmailrc is configured to reject certain mails with exitcode 67

My .fetchmailrc is configured not to keep mails and fetch all.

My expectation would be, that mails "rejected" by procmail would be bounced by fetchmail.
However that is not the case. Instead fetchmail fetches the mails on every call and doesn't generate any bouncemails for them.
Is there anything I'm doing wrong, or is it just not possible to generate a bouncemail in this scenario?
I've also tried setting "antispam 067" in .fetchmailrc but that did not change anything.

Note: I did also install featchmail on Archlinux (version 6.4.39) but experienced the same behavior here.

$ LC_ALL=C fetchmail -V
This is fetchmail release 6.3.24+GSS+RPA+NTLM+SDPS+SSL+HESIOD+NLS+KRB5.

Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond,
                    Robert M. Funk, Graham Wilson
Copyright (C) 2005 - 2006, 2010 - 2012 Sunil Shetye
Copyright (C) 2005 - 2012 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)

Fallback MDA: (none)
Linux corvus.uberspace.de 3.10.0-1160.119.1.el7.tuxcare.els2.x86_64 #1 SMP Mon Jul 15 12:09:18 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Taking options from command line and /home/whtmp/.fetchmailrc
Idfile is /home/whtmp/.fetchids
Fetchmail will forward misaddressed multidrop messages to whtmp.
Fetchmail will treat permanent errors as permanent (drop messages).
Options for retrieving fro...@wh...@localhost:
   True name of server is localhost.
   Protocol is IMAP.
   All available authentication methods will be tried.
   Server nonresponse timeout is 300 seconds (default).
   Default mailbox selected.
   All messages will be retrieved (--all on).
   Fetched messages will not be kept on the server (--keep off).
   Old messages will not be flushed before message retrieval (--flush off).
   Oversized messages will not be flushed before message retrieval (--limitflush off).
   Rewrite of server-local addresses is enabled (--norewrite off).
   Carriage-return stripping is enabled (stripcr on).
   Carriage-return forcing is disabled (forcecr off).
   Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
   MIME decoding is disabled (mimedecode off).
   Idle after poll is disabled (idle off).
   Nonempty Status lines will be kept (dropstatus off)
   Delivered-To lines will be kept (dropdelivered off)
   Fetch message size limit is 100 (--fetchsizelimit 100).
   Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
   Messages will be delivered with "/usr/bin/procmail".
   Recognized listener spam block responses are: 67
   Single-drop mode: 1 local name recognized.
   No UIDs saved from this host.

$ LC_ALL=C fetchmail --nodetach -v --nosyslog
fetchmail: 6.3.24 querying localhost (protocol IMAP) at Tue Oct 29 21:25:32 2024: poll started
Trying to connect to ::1/143...connected.
fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SPECIAL-USE LITERAL+ STARTTLS LOGINDISABLED] Dovecot ready.
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SPECIAL-USE LITERAL+ STARTTLS LOGINDISABLED
fetchmail: IMAP< A0001 OK Pre-login capabilities listed, post-login capabilities have more.
fetchmail: IMAP> A0002 STARTTLS
fetchmail: IMAP< A0002 OK Begin TLS negotiation now.
fetchmail: Server certificate:
fetchmail: Issuer Organization: GlobalSign nv-sa
fetchmail: Issuer CommonName: GlobalSign GCC R6 AlphaSSL CA 2023
fetchmail: Subject CommonName: *.uberspace.de
fetchmail: Subject Alternative Name: *.uberspace.de
fetchmail: Subject Alternative Name: uberspace.de
fetchmail: Server CommonName mismatch: *.uberspace.de != localhost
fetchmail: localhost key fingerprint: 92:76:D1:DB:4B:EB:7B:50:CD:48:D1:34:66:2C:6D:9D
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits
fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)
fetchmail: IMAP> A0003 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SPECIAL-USE LITERAL+ AUTH=PLAIN
fetchmail: IMAP< A0003 OK Pre-login capabilities listed, post-login capabilities have more.
fetchmail: localhost: upgrade to TLS succeeded.
fetchmail: IMAP> A0004 LOGIN"te...@wh..." *
fetchmail: IMAP< * CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW STATUS=SIZE SAVEDATE SPECIAL-USE LITERAL+ NOTIFY SPECIAL-USE
fetchmail: IMAP< A0004 OK Logged in
fetchmail: IMAP> A0005 SELECT "INBOX"
fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
fetchmail: IMAP< * 2 EXISTS
fetchmail: IMAP< * 0 RECENT
fetchmail: IMAP< * OK [UNSEEN 1] First unseen.
fetchmail: IMAP< * OK [UIDVALIDITY 1729362238] UIDs valid
fetchmail: IMAP< * OK [UIDNEXT 4] Predicted next UID
fetchmail: IMAP< A0005 OK [READ-WRITE] Select completed (0.002 + 0.000 + 0.001 secs).
fetchmail: IMAP> A0006 EXPUNGE
fetchmail: IMAP< A0006 OK Expunge completed (0.001 + 0.000 secs).
2 messages fo...@wh... at localhost.
fetchmail: IMAP> A0007 FETCH 1:2 RFC822.SIZE
fetchmail: IMAP< * 1 FETCH (RFC822.SIZE 5598)
fetchmail: IMAP< * 2 FETCH (RFC822.SIZE 5632)
fetchmail: IMAP< A0007 OK Fetch completed (0.001 + 0.000 secs).
fetchmail: IMAP> A0008 FETCH 1 RFC822.HEADER
fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {5586}
reading mes...@wh...@localhost:1 of 2 (5586 header octets) #
fetchmail: IMAP< )
fetchmail: IMAP< A0008 OK Fetch completed (0.005 + 0.000 + 0.004 secs).
fetchmail: IMAP> A0009 FETCH 1 BODY.PEEK[TEXT]
fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {12}
  (12 body octets) **
fetchmail: IMAP< )
fetchmail: IMAP< A0009 OK Fetch completed (0.001 + 0.000 secs).
procmail: [16702] Tue Oct 29 21:25:33 2024
procmail: Assigning "LOGFILE=/home/whtmp/procmail.log"
procmail: Opening "/home/whtmp/procmail.log"
fetchmail: MDA returned nonzero status 67
  not flushed
fetchmail: IMAP> A0010 FETCH 2 RFC822.HEADER
fetchmail: IMAP< * 2 FETCH (RFC822.HEADER {5611}
reading mes...@wh...@localhost:2 of 2 (5611 header octets) #
fetchmail: IMAP< )
fetchmail: IMAP< A0010 OK Fetch completed (0.002 + 0.000 + 0.001 secs).
fetchmail: IMAP> A0011 FETCH 2 BODY.PEEK[TEXT]
fetchmail: IMAP< * 2 FETCH (BODY[TEXT] {21}
  (21 body octets) *
fetchmail: IMAP< )
fetchmail: IMAP< A0011 OK Fetch completed (0.001 + 0.000 secs).
procmail: [16706] Tue Oct 29 21:25:33 2024
procmail: Assigning "LOGFILE=/home/whtmp/procmail.log"
procmail: Opening "/home/whtmp/procmail.log"
fetchmail: MDA returned nonzero status 67
  not flushed
fetchmail: IMAP> A0012 LOGOUT
fetchmail: IMAP< * BYE Logging out
fetchmail: IMAP< A0012 OK Logout completed (0.001 + 0.000 secs).
fetchmail: 6.3.24 querying localhost (protocol IMAP) at Tue Oct 29 21:25:33 2024: poll completed
fetchmail: normal termination, status 0

Re: [Fetchmail-users] fetchmail-6.5.0 questions

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

Am 30.10.24 um 17:06 schrieb Ken Moffat via Fetchmail-users:
> Hi,

Hi Ken,

thanks for reaching out.

>
> I see that fetchmail no longer supports using an MDA as SMTP
> fallback.

Yes. That only means there is no fallback from SMTP to MDA if the former
fails. The plan is to always behave consistently and not try to do A
today and in adverse situations we try B and you have to start looking
where/how your mail ended up, because B wasn't equivalent to A (and
fetchmail cannot prove or disprove that). I don't like such surprises.
So I threw the fallout behavior out without removing MDA or SMTP.

Assume you use Postfix. What if you had procmail as a fallback but
Postfix uses its own local(8) without procmail? Then procmail would
behave differently from Postfix's local... or some messages would be
logged by Postfix, others would not.

You configure an mda or use --mda on the command line, fetchmail uses MDA,
you don't use mda or --mda then fetchmail uses SMTP (default) or LMTP or
whatever else you configured.

> Sending mail to lists, and getting the incoming, for a home user has
> become increasingly complex and I try not to change my setup. As
> best I can understand (several years since I had to change it apart
> from a password), I'm doing the following: (one human user on my
> systems).
>
> 1. postfix on home server, running as servername.mydomain.
>
> 2. outgoing: postfix connects to my ISP's server using Cyrus-SASL.
>
> 3. incoming: a cron job to run fetchmail authenticating to my ISP
> and retrieving POP3.
>
> I have always specified --enable-fallback=procmail, but I see that
> my fetchmailrc has a comented-out invocation of procmail with a
> comment that procmail is not needed for that if the mail server is
> correctly setup.
>
> Am I worrying unnecessarily ?

Maybe. As long as you notice in some - for you, anyways - reasonable
timeframe that your Postfix is down, this should be good. I found that
on reasonable distros (I have used Fedora Linux and FreeBSD in the past
years and have been quite content) there aren't Postfix surprises for me.

...but fetchmail should notice that it has not succeeded in retrieving
those messages and will therefore not delete them and retry them later
(except maybe if it uses LAST on your POP3 server, in that case you
could specify --uidl or uidl).

> I see that procmail was originally specified so that if the mail
> server was not responding, mail would be processed by procmail. I
> assume (if I do not need to change anything) that if my local server
> does not respond then the mail will just be queued ?

If your default is to talk to SMTP, it's re-fetch the same message
later, do not delete it.

>
> En passant (testing configure on a desktop without kerberos):
>   CFLAGS:   -g -O2 -I/usr/kerberos/include
> looks a bit odd : /usr/kerberos ?

Yeah, we've had such stuff needed in various circumstances, ./configure
adds it, either because it's one of the search paths you have for a
./configure --with-kerberos like option, or as a leftover workaround
from Red Hat Linux 9 (must have been in the early 2000's) I forgot to
remove.  At that time, some SSL implementations needed such an option to
find krb5.h. This shouldn't be in use today, but also in
/usr/kerberos/include there shouldn't be stuff that disturbs us. Too
late for 6.5.0 now, should've known during the betas then I could have
done something...

We'd need to look at your config.log and/or console output, together
with configure.ac, to see what's there, but if fetchmail behaves
normally and fetchmail -V doesn't emit strange things, you're probably good.

HTH
Matthias

[Fetchmail-users] fetchmail-6.5.0 questions

[Ken M. <zar...@nt...>]

Hi,

I see that fetchmail no longer supports using an MDA as SMTP
fallback.

Sending mail to lists, and getting the incoming, for a home user has
become increasingly complex and I try not to change my setup. As
best I can understand (several years since I had to change it apart
from a password), I'm doing the following: (one human user on my
systems).

1. postfix on home server, running as servername.mydomain.

2. outgoing: postfix connects to my ISP's server using Cyrus-SASL.

3. incoming: a cron job to run fetchmail authenticating to my ISP
and retrieving POP3.

I have always specified --enable-fallback=procmail, but I see that
my fetchmailrc has a comented-out invocation of procmail with a
comment that procmail is not needed for that if the mail server is
correctly setup.

Am I worrying unnecessarily ?

I see that procmail was originally specified so that if the mail
server was not responding, mail would be processed by procmail. I
assume (if I do not need to change anything) that if my local server
does not respond then the mail will just be queued ?

En passant (testing configure on a desktop without kerberos):
 CFLAGS:   -g -O2 -I/usr/kerberos/include
looks a bit odd : /usr/kerberos ?

ĸen
-- 
  I saw an eagle fly once.
  Fortunately, I had my eagle fly swatter handy.

[Fetchmail-users] ANNOUNCE: fetchmail 6.5.0 is available (modernization)

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

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

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

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.0.tar.xz)= 42611aea4861a5311e5116843f01c203dceadf440bf2eb1b4a43a445f2977668

Note that the Sourceforge Git view is quirky,
the preferred Git repository is at 
https://gitlab.com/fetchmail/fetchmail
and mirrored at  
https://sourceforge.net/p/fetchmail/git/ci/legacy_6x/tree/

But it seems that SourceForge's Git web interface isn't fully 
recognizing the latest changes on the "legacy_6x" branch that the 6.5.0 
release was made from, you need to click the 6.5.0 tag on the left to 
see the update version.

Fetchmail 6.4.X and older releases are now unsupported.


DISTRIBUTORS BEWARE: OpenSSL changed license, so you may need to change
your license tags and possibly the license which you invoke to 
redistribute fetchmail.  As an alternative, wolfSSL could be used
to maintain GPL v2 compatibility, but it lacks some features OpenSSL 
offers.


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.0 (released 2024-10-29, 31200 LoC):

## SECURITY FIX:
* .netrc now may not have more than 0700 permission if it contains passwords,
  else fetchmail will warn and ignore the file.

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

## INCOMPATIBLE CHANGES
* fetchmail by default only negotiates TLS v1.2 or higher. (RFC-7525)
* fetchmail can auto-negotiate TLS v1.1 through the --sslproto tls1.1+ option.
* fetchmail can auto-negotiate TLS v1.0 through the --sslproto tls1+ option.
* fetchmailconf now requires Python 3.7.0 or newer.
* fetchmail, with --logfile, now logs time stamps into the file, in localtime
  and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized through
  the environment variables LC_TIME (or LC_ALL) and TZ.
  Contributed by Holger Hoffstätte.
* fetchmail sets the OPENSSL security level to 2 by default.
  Override is possible from an environment variable,
  see EXPERIMENTAL CHANGES below.
* The ca, da, en_GB, id, it, nl, ru, zh_CN translations have been disabled,
  they are too far behind.

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

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

* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL or wolfSSL,
  at a minimum OpenSSL v3.0.9 or wolfSSL v5.7.2.

## TRANSLATIONS: fetchmail's messages were translated by these fine people:
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* es:    Cristian Othón Martínez Vera [Spanish]
* fr:    Frédéric Marchal [French]
* ja:    Takeshi Hamasaki [Japanese]
* ro:    Remus-Gabriel Chelu [Romanian]
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* pl:    Jakub Bogusz [Polish]

## BUG FIXES
* fetchmail can now report mailbox sizes of 2^31 octets and beyond (2 GibiB).
  This required C99 support (for the long long type).
  Fixes Debian Bug#873668, reported by Andreas Schmidt.
* fetchmail now defines its OpenSSL API level to 3.0.0 so as to expose the
  3.0.0 APIs from OpenSSL.
* The .netrc parser no longer permits "machine" after "default".
* Add manpage info on the .netrc syntax, as ftp(1) is not standardized and
  may not be installed. Fixes Launchpad Bug #1976361 reported by Bill Yikes.
* Received: lines now return GMT time if the tzoffset cannot be represented
  as whole minutes. Reported by @rriddicc via Gitlab #49.
* If fetchmail was running localized, generated an error e-mail message locally,
  and if the selected translation would require the Subject: line to wrap
  inside an RFC-2047 encoded word (=?UTF-8?Q?...?=), the wrapped encoded-word
  was not indented, thus not marked as a continuation line.
* SSL error handling was improved, fetchmail now consistently clears the
  thread/SSL error queue before SSL I/O operations and checks SSL_get_error
  afterwards.  The SSL_connect() error handling has been revised to log more
  consistently.

## CHANGES
* When fetchmail attempts to log out from an IMAP4 server and the server messes
  up its responses (it is supposed to send an untagged * BYE and a tagged
  A4711 OK) and sends a tagged A4711 BYE response, tolerate that, rather than
  reporting a protocol error. We don't intend to chat any more so the protocol
  violation is harmless, and we know the server cannot send more untagged
  status responses.
  Analysis and fix courtesy of Maciej S. Szmigiero, GitLab merge request !20.
* The configure script now spends more effort for getting --with-ssl right, by
  running pkg-config in the right environment, and using the AC_LIB_LINKFLAGS
  macro to obtain run-time library path setting flags.
* For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option
  do not match, emit a warning and continue. Closes Gitlab #31.
* There is now a --idletimeout feature contributed by Eric Durand, to
  permit setting a shorter timeout for the --idle option, because many
  servers violate the protocol (requiring 30 minutes) and hang up sooner than
  the 28 minutes fetchmail waits before refreshing IDLE.
  GitLab merge request !35.
* There is now a --forceidle feature to force idle mode even if not advertised
  in the server capabilities. This is a dangerous option, use it carefully.
  Courtesy of Eric Durand, GitLab merge request !39.
* There is now a --moveto feature (only feasible in IMAP) that, instead of
  flushing mail, moves it to a user-specified folder. This is to assist with
  archiving, or when providers (G...) break the IMAP model.
  Courteously provided by Damjan Jovanovic.
* rcfile parsing errors are now reported in more detail, and with -vv mode,
  also lead to a non-importable Python dump of what was obtained, for debugging.
* fetchmail's --auth option ssh was renamed to implicit, to make clear that it
  does *NOT* imply any particular type or features of the --plugin.  --auth ssh
  will be understood for a while for compatibility but fetchmail will report it
  as implicit.
* fetchmail no longer warns about port/service mismatches with/without ssl
  option when a "plugin" is in use because fetchmail cannot know whether the
  plugin talks SSL or STARTTLS/STLS. Fixes Debian Bug#1076604.
* fetchmail re-executes itself if the .netrc file's modification change
  is found to be newer at the beginning of a new run.
* fetchmail can now use other digest algorithms than MD5 for the
  --sslfingerprint option. To use, specify the algorithm's name in
  curly braces as prefix in the finger print, say,
  --sslfingerprint '{SHA256}00:01:[...]:1F'. This will also switch the
  algorithm for printing. All algorithms supported by the TLS/SSL library
  can be specified. Fixes Gitlab issue #19, Debian Bug#700266.

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

================================================================================

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

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

On 2024-10-03 06:30, Ian! D. Allen wrote:
> Yes, but forwarding from hotmail has Spamassassin SPF problems:
> 
>      4.0 SPF_FAIL SPF: sender does not match SPF record (fail)

Perhaps you can add your own rule to add 4 good points to emails coming 
from the hotmail account, to nullify that SPF rule.


-- 
Cheers / Saludos,

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

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

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

Am 03.10.24 um 06:30 schrieb Ian! D. Allen:
> On Wed, Sep 25, 2024 at 06:27:27AM -0400, Matthias Andree wrote:
>> App passwords are the sidestep or workaround while they last.
> Yes, app passwords are still working with gmail (October 2 2024):
> -https://support.google.com/accounts/answer/185833
>
> As of September 16, app passwords don't work with hotmail:
> -https://support.microsoft.com/en-us/office/modern-authentication-methods-now-needed-to-continue-syncing-outlook-email-in-non-microsoft-email-apps-c5d65390-9676-4763-b41f-d7986499a90d
> -https://techcommunity.microsoft.com/t5/outlook-blog/keeping-our-outlook-personal-email-users-safe-reinforcing-our/ba-p/4164184
>    "App passwords or Application passwords will be deprecated as part of the Basic Auth deprecation.  You will need to use Modern Auth for all cases."

Hm. App-specific passwords still seem to be advertised under the
condition that 2-factor authentication is enabled and it references
"mail apps on some smartphones" or devices ("f.i., xbox 360") that seem
unable to use "regular security codes" (this is all translated back from
German from the page about 2FA for the account).

I haven't tested this but unless they stop requiring application reviews
for OAuth2 application tokens, if they really turned off application
passwords, then we're done with Microsoft.

fetchmail 7 (currently in development) has rudimentary support for
OAUTH2 but has no application token so that's of limited use.

> I can generate an "app password" for my Microsoft account, but using
> that password in my .fetchmailrc does not work:
>
>      fetchmail: POP3< -ERR Logon failure: unknown user name or bad password.
>      fetchmail: Logon failure: unknown user name or bad password.

Does it have to be a specific application-specific password *for mail*?
I presume these passwords would be limited to one particular service.

> On Tue, Sep 24, 2024 at 03:43:06PM -0400, Lucio Chiappetti wrote:
>> Can you instruct your "legacy proprietaruy service" to FORWARD all mail to
>> another fetchmail-firendly provider?
> Yes, but forwarding from hotmail has Spamassassin SPF problems:
>
>      4.0 SPF_FAIL SPF: sender does not match SPF record (fail)

That's self-inflicted by how SpamAssassin is configured. It doesn't have
to punish SPF forwardings like that. I know SPF is being promoted for
spam defense, but it's broken by design and for many people causes more
trouble than it's worth.


> Also, fetching email via POP kept my hotmail account alive without me
> having to access it in a browser, because POP was treated as a "login".
>
> I've set up hotmail forwarding and have a cron job to remind me to
> use a web browser to log in to hotmail every now and then to keep the
> account alive.
>

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

[Ian! D. A. <id...@id...>]

On Wed, Sep 25, 2024 at 06:27:27AM -0400, Matthias Andree wrote:
> App passwords are the sidestep or workaround while they last.

Yes, app passwords are still working with gmail (October 2 2024):
- https://support.google.com/accounts/answer/185833

As of September 16, app passwords don't work with hotmail:
- https://support.microsoft.com/en-us/office/modern-authentication-methods-now-needed-to-continue-syncing-outlook-email-in-non-microsoft-email-apps-c5d65390-9676-4763-b41f-d7986499a90d
- https://techcommunity.microsoft.com/t5/outlook-blog/keeping-our-outlook-personal-email-users-safe-reinforcing-our/ba-p/4164184
  "App passwords or Application passwords will be deprecated as part of the Basic Auth deprecation.  You will need to use Modern Auth for all cases."

I can generate an "app password" for my Microsoft account, but using
that password in my .fetchmailrc does not work:

    fetchmail: POP3< -ERR Logon failure: unknown user name or bad password.
    fetchmail: Logon failure: unknown user name or bad password.

---

On Tue, Sep 24, 2024 at 03:43:06PM -0400, Lucio Chiappetti wrote:
> Can you instruct your "legacy proprietaruy service" to FORWARD all mail to
> another fetchmail-firendly provider?

Yes, but forwarding from hotmail has Spamassassin SPF problems:

    4.0 SPF_FAIL SPF: sender does not match SPF record (fail)

Also, fetching email via POP kept my hotmail account alive without me
having to access it in a browser, because POP was treated as a "login".

I've set up hotmail forwarding and have a cron job to remind me to
use a web browser to log in to hotmail every now and then to keep the
account alive.

-- 
| Ian! D. Allen, BA-Psych, MMath-CompSci  id...@id... Ottawa CANADA
| Home: www.idallen.com  Contact Improvisation Dance: www.contactimprov.ca
| Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com
| Improve democracy www.fairvote.ca and defend digital freedom www.eff.org

[Fetchmail-users] ANNOUNCE: The 6.5.0.rc2 release candidate of fetchmail is available

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

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

It adds seven new translations and fixes a PATH_MAX related mis-merge 
that might break compilation on arcane operating systems.

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

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.rc2.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.0.rc2.tar.xz)= 577b4f32b81be2c5ccd4a2ea18131a758f159497b13aba71d8e3a490952914ac


Here are the release notes changes since rc1:
--------------------------------------------------------------------------------
* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL or wolfSSL,
  at a minimum OpenSSL v3.0.9 or wolfSSL v5.7.2.

## TRANSLATIONS: fetchmail's messages were translated by these fine people:
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* es:    Cristian Othón Martínez Vera [Spanish]
* fr:    Frédéric Marchal [French]
* ja:    Takeshi Hamasaki [Japanese]
* ro:    Remus-Gabriel Chelu [Romanian]
* sv:    Göran Uddeborg [Swedish]

* fetchmail now defines its OpenSSL API level to 3.0.0 so as to expose the
  3.0.0 APIs from OpenSSL.
* SSL error handling was improved, fetchmail now consistently clears the
  thread/SSL error queue before SSL I/O operations and checks SSL_get_error
  afterwards.  The SSL_connect() error handling has been revised to log more
  consistently.

* fetchmail can be built with meson 1.30 or newer <https://mesonbuild.com/>.
  fetchmail is not currently written in a way that supports unity
  (amalgamated) builds.
================================================================================