fetchmail-users — User questions and discussion

Re: [Fetchmail-users] Warning users about authentication failures

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

Am 21.06.25 um 14:45 schrieb Andrea Venturoli:
> On 6/21/25 12:48, Matthias Andree via Fetchmail-users wrote:
>
> Hello.
>
> Thanks for your answer.
>
>
>
>> these warnings work only in daemon mode
>
> That's my case.
>
>
>
>> fetchmail runs for a sufficiently long time
>
> It's usually weeks, if not months before I restart it.
>
>
>
>> fetchmail didn't authenticate successfully, it should send the 
>> warning after 3 failed attempts;
>
> It did (in the past); only it doesn't anymore :(
>
>
>
>> If fetchmail is triggered purely by cron or systemd timer or similar, 
>
> Not my case.
>
>
>
>> Changes to configuration files also trigger fetchmail to discard 
>> state and re-execute itself.
>
> These are very rare.
>
>
>
>> Oh, one more thing, this only happens on authentication failures and 
>> timeouts BUT NOT on other errors,
>
> That's fine; that's what I'm trying to get.
>
>
>
> I thought some option was added to enable/disable this, but if you 
> confirm it hasn't, I guess I'll need to try and debug this. 


I would probably start by checking what actual error code is passed 
through this code in driver.c (near line 1150) as return from the 
->getauth(...) method:

> /* accept greeting message from mail server */
>        err = 
> (ctl->server.base_protocol->parse_response)(mailserver_socket, buf);
> if(err != 0)
> gotocleanUp;
>
> /* try to get authorized to fetch mail */
> if(ctl->server.base_protocol->getauth)
>        {
>            set_timeout(mytimeout);
>            err = 
> (ctl->server.base_protocol->getauth)(mailserver_socket, ctl, buf);
>            set_timeout(0);
>
> if(err != 0)
>            {
> if(err == PS_LOCKBUSY)
>                    report(stderr, GT_("Lock-busy error on %s@%s\n"),
>                          ctl->remotename,
>                          ctl->server.truename);
> elseif(err == PS_SERVBUSY)
>                    report(stderr, GT_("Server busy error on %s@%s\n"),
>                          ctl->remotename,
>                          ctl->server.truename);
> elseif(err == PS_AUTHFAIL)
>                {
>                    report(stderr, GT_("Authorization failure on 
> %s@%s%s\n"),
>                           ctl->remotename,
>                           ctl->server.truename,
>                           (ctl->wehaveauthed ? GT_(" (previously 
> authorized)") : "")
>                        );
> if(ctl->server.authenticate == A_ANY && !ctl->wehaveauthed) {
>                        report(stderr, GT_("For help, see 
> http://www.fetchmail.info/fetchmail-FAQ.html#R15\n"));
>                    }
>

Re: [Fetchmail-users] Warning users about authentication failures

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

On 6/21/25 12:48, Matthias Andree via Fetchmail-users wrote:

Hello.

Thanks for your answer.



> these warnings work only in daemon mode

That's my case.



> fetchmail runs for a sufficiently long time

It's usually weeks, if not months before I restart it.



> fetchmail didn't authenticate successfully, it should send the warning 
> after 3 failed attempts;

It did (in the past); only it doesn't anymore :(



> If fetchmail is triggered purely by cron or systemd timer or similar, 

Not my case.



> Changes to configuration files also trigger fetchmail 
> to discard state and re-execute itself.

These are very rare.



> Oh, one more thing, this only happens on authentication failures and timeouts BUT NOT on other errors,

That's fine; that's what I'm trying to get.



I thought some option was added to enable/disable this, but if you 
confirm it hasn't, I guess I'll need to try and debug this.

  bye & Thanks
	av.

Re: [Fetchmail-users] Warning users about authentication failures

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

Am 21.06.25 um 12:48 schrieb Matthias Andree via Fetchmail-users:
> Am 20.06.25 um 14:30 schrieb Andrea Venturoli:
>> Hello.
>>
>> Suppose you set up fetchmail to get messages fro a service (POP or 
>> IMAP) and it works; then something happens (e.g. the password 
>> expires) and it stops working.
>> While I (as the sysadmin) can see this in the logs, I wish the user 
>> who reads the emails was informed.
>> In the past this worked: he received a mail from fetchmail itself 
>> saying auth was failing and another mail when everything was solved.
>> However, this hasn't been working for me for some time (after some 
>> upgrade, I think, but without any change to configuration).
>>
>> What are the requirements to have these informational messages?
>> Some setting? Some prerequisite?
>> Has anything purposedly changed? (I don't know since when, however... 
>> possibly several months). 
>
>
> Hi Andrea,
>
> these warnings work only in daemon mode (run.poll_interval) and if 
> fetchmail runs for a sufficiently long time, counting in intervals. If 
> fetchmail didn't authenticate successfully, it should send the warning 
> after 3 failed attempts; if it did authenticate ever before, after 10 
> (both hardcoded). See below. I quick test with fetchmail 6.5.4 and 
> arguments
>
>  --mda "cat >/dev/null ; exit 75" and --proto imap --auth external 
> --user -d 1 --nodetach on one of my servers complained "MDA returned 
> nonzero status 75" and when using --mda "cat >/tmp/debug.txt || exit 
> 75" put the warning message into the file -- so it seems to be working 
> still.
>
> If fetchmail is triggered purely by cron or systemd timer or similar, 
> they won't work. Changes to configuration files also trigger fetchmail 
> to discard state and re-execute itself.
>
>
> This is from the 6.5.X code (the "in background" comment is 
> inaccurate, --nodetach won't impact this):
>
>> /*
>>                     * If we're running in background, try to mail the
>>                     * calling user a heads-up about the authentication
>>                     * failure once it looks like this isn't a fluke
>>                     * due to the server being temporarily inaccessible.
>>                     * When we get third succesive failure, we notify 
>> the user
>>                     * but only if we haven't already managed to get
>>                     * authorization.  After that, once we get 
>> authorization
>>                     * we let the user know service is restored.
>>                     */
>> if(run.poll_interval
>>                        && !ctl->wehavesentauthnote
>>                        && ((ctl->wehaveauthed && ++ctl->authfailcount 
>> >= 10)
>>                            || (!ctl->wehaveauthed && 
>> ++ctl->authfailcount >= 3))
>>                        && !open_warning_by_mail(ctl))
>>                    {
>>
> The thing is that fetchmail doesn't store these 
> authfailcount/wehaveauthed/wehavesentauthnote variables to disk.
>
> HTH & feel free to ask further questions 


Oh, one more thing, this only happens on authentication failures and 
timeouts BUT NOT on other errors, for instance, server/client 
synchronization errors, for instance, if the user deletes an IMAP folder 
(mailbox) and it can no longer be selected when using the --folder option.

Re: [Fetchmail-users] Warning users about authentication failures

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

Am 20.06.25 um 14:30 schrieb Andrea Venturoli:
> Hello.
>
> Suppose you set up fetchmail to get messages fro a service (POP or 
> IMAP) and it works; then something happens (e.g. the password expires) 
> and it stops working.
> While I (as the sysadmin) can see this in the logs, I wish the user 
> who reads the emails was informed.
> In the past this worked: he received a mail from fetchmail itself 
> saying auth was failing and another mail when everything was solved.
> However, this hasn't been working for me for some time (after some 
> upgrade, I think, but without any change to configuration).
>
> What are the requirements to have these informational messages?
> Some setting? Some prerequisite?
> Has anything purposedly changed? (I don't know since when, however... 
> possibly several months). 


Hi Andrea,

these warnings work only in daemon mode (run.poll_interval) and if 
fetchmail runs for a sufficiently long time, counting in intervals. If 
fetchmail didn't authenticate successfully, it should send the warning 
after 3 failed attempts; if it did authenticate ever before, after 10 
(both hardcoded). See below. I quick test with fetchmail 6.5.4 and arguments

  --mda "cat >/dev/null ; exit 75" and --proto imap --auth external 
--user -d 1 --nodetach on one of my servers complained "MDA returned 
nonzero status 75" and when using --mda "cat >/tmp/debug.txt || exit 75" 
put the warning message into the file -- so it seems to be working still.

If fetchmail is triggered purely by cron or systemd timer or similar, 
they won't work. Changes to configuration files also trigger fetchmail 
to discard state and re-execute itself.


This is from the 6.5.X code (the "in background" comment is inaccurate, 
--nodetach won't impact this):

> /*
>                     * If we're running in background, try to mail the
>                     * calling user a heads-up about the authentication
>                     * failure once it looks like this isn't a fluke
>                     * due to the server being temporarily inaccessible.
>                     * When we get third succesive failure, we notify 
> the user
>                     * but only if we haven't already managed to get
>                     * authorization.  After that, once we get 
> authorization
>                     * we let the user know service is restored.
>                     */
> if(run.poll_interval
>                        && !ctl->wehavesentauthnote
>                        && ((ctl->wehaveauthed && ++ctl->authfailcount 
> >= 10)
>                            || (!ctl->wehaveauthed && 
> ++ctl->authfailcount >= 3))
>                        && !open_warning_by_mail(ctl))
>                    {
>
The thing is that fetchmail doesn't store these 
authfailcount/wehaveauthed/wehavesentauthnote variables to disk.

HTH & feel free to ask further questions

Regards,
Matthias

[Fetchmail-users] Warning users about authentication failures

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

Hello.

Suppose you set up fetchmail to get messages fro a service (POP or IMAP) 
and it works; then something happens (e.g. the password expires) and it 
stops working.
While I (as the sysadmin) can see this in the logs, I wish the user who 
reads the emails was informed.
In the past this worked: he received a mail from fetchmail itself saying 
auth was failing and another mail when everything was solved.
However, this hasn't been working for me for some time (after some 
upgrade, I think, but without any change to configuration).

What are the requirements to have these informational messages?
Some setting? Some prerequisite?
Has anything purposedly changed? (I don't know since when, however... 
possibly several months).

  bye & Thanks
	av.

[Fetchmail-users] ANNOUNCE: fetchmail 6.5.4 is available (crash fix for unencrypted socket write error, wolfSSL compilation fix)

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

The 6.5.4 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.4.tar.xz/download>

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

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


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.4 (released 2025-06-17, 31208 LoC):

## BUGFIXES:
* socket: avoid crash when writing to a socket without SSL/TLS fails.
  Reported by Andrea Venturoli via mailing list, fixes #71.
* wolfSSL support: avoid fetchmail.c compilation failure in certain
  configurations of wolfSSL (for instance, on FreeBSD's wolfssl-5.8.0_1
  package), OpenSSL_version enables a newer 1.1.x compat API that passes its
  argument to a wolfSSL API, with OPENSSL_DIR and OPENSSL_ENGINES_DIR, causing
  related compiler failures.
  See <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287435>.

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

Re: [Fetchmail-users] fetchmail crashing

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

On 6/16/25 18:40, Matthias Andree via Fetchmail-users wrote:

> mille grazie for the report and debugging.

You are welcome.



> Would you also know a quick way to reproduce it?

Not really.
An idea might be:
_ set up fetchmail to retrieve from somewhere *without SSL*;
_ put a huge message on the server (so to have time for the next steps);
_ start fetchmail;
_ while it's fetching, unplug the network cable/drop the connection 
somehow/introduce a firewall block/...

However I didn]'t try this.



  bye & Thanks
	av.

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...X 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...X 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