fetchmail-users — User questions and discussion

Re: [Fetchmail-users] The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

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

Am 14.07.26 um 20:44 schrieb Norman Ramsey:
>   > On Mon, 13 Jul 2026, Norman Ramsey wrote:
>   >
>   > > Building on Debian stable, I'm running into this build issue...
>   > >
>   > > Please advise me how to proceed.
>   >
>   > I think
>   >          rm Makefile ; configure
>   > should be sufficient. Add whatever configure options you usually use.
>
> This was sufficient; thank you.
>
> (And in the event, the system clock is fine, and the filesystem is ext4.)

Norman,

Glad you've got that solved with Andrew's help;
if you have another few minutes: would you happen to have any idea or 
even remote hunch how the situation came to pass then so I could try to 
avoid that from the packaging end?

How did you unpack the tarball? Was that "tar" on the command line or 
some graphical utility? Which, in which version?

Did you unpack source tarballs of different versions over one another 
and/or mix with Git checkouts, or mix meson and autotools builds?

In attempting to understand your situation, I found a few edge cases in 
the packaging that I want to iron out for 6.6.7.rc2/release later.

The files were created in CEST time zone (2 hours ahead/east of 
UTC/"GMT") somewhen on 2026-06-27, with a forged date back to midnight 
of beginning that same day, and in UTC display that makes it 
2026-06-26T22:00:00 sharp; I've packaged from btrfs with GNU tar 1.35. 
Anything you would have unpacked would be newer. The tarball contains 
the files with the same timestamp in lexicographical order.

> $ TZ=UTC tar -tJvf ~/Downloads/fetchmail-6.6.7.rc1.tar.xz --full-time 
> | grep -E Makefile\|config\|m4
> -rw-r--r-- root/root      8785 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/Makefile.am
> -rw-r--r-- root/root    110915 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/Makefile.in
> -rw-r--r-- root/root     79584 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/aclocal.m4
> -rwxr-xr-x root/root     50853 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/config.guess
> -rw-r--r-- root/root     11143 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/config.h.in
> -rwxr-xr-x root/root     20196 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/config.rpath
> -rwxr-xr-x root/root     39946 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/config.sub
> -rwxr-xr-x root/root    500912 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/configure
> -rw-r--r-- root/root     29698 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/configure.ac
> drwxr-xr-x root/root         0 2026-06-26 22:00:00 fetchmail-6.6.7.rc1/m4/
> -rw-r--r-- root/root      9242 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/build-to-host.m4
> -rw-r--r-- root/root     14990 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/gettext.m4
> -rw-r--r-- root/root     17194 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/host-cpu-c-abi.m4
> -rw-r--r-- root/root     11052 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/iconv.m4
> -rw-r--r-- root/root      3560 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/intlmacosx.m4
> -rw-r--r-- root/root      5440 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/lib-ld.m4
> -rw-r--r-- root/root     35796 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/lib-link.m4
> -rw-r--r-- root/root     12582 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/lib-prefix.m4
> -rw-r--r-- root/root      1236 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/nls.m4
> -rw-r--r-- root/root     19013 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/po.m4
> -rw-r--r-- root/root      3091 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4/progtest.m4
> drwxr-xr-x root/root         0 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4-local/
> -rw-rw-r-- root/root      2968 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4-local/ac-archive-license.txt
> -rw-r--r-- root/root      3207 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/m4-local/ac_ma_search_package.m4
> -rw-r--r-- root/root     20250 2026-06-26 22:00:00 
> fetchmail-6.6.7.rc1/po/Makefile.in.in
> [...]

Re: [Fetchmail-users] The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

[Norman R. <nr...@cs...>]

 > On Mon, 13 Jul 2026, Norman Ramsey wrote:
 > 
 > > Building on Debian stable, I'm running into this build issue...
 > >
 > > Please advise me how to proceed.
 > 
 > I think
 >          rm Makefile ; configure
 > should be sufficient. Add whatever configure options you usually use.

This was sufficient; thank you.

(And in the event, the system clock is fine, and the filesystem is ext4.)


Norman

Re: [Fetchmail-users] The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

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

Am 13.07.26 um 21:49 schrieb Andrew C Aitchison:
> On Mon, 13 Jul 2026, Norman Ramsey wrote:
>
>> > The 6.6.7.rc1 release candidate of fetchmail tightens code
>> > around a security vulnerability in the NTLM code.
>> > It is now available at the usual locations, including
>> > <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.
>>
>> Building on Debian stable, I'm running into this build issue, which is
>> not addressed in the FAQ:
>>
>>    nr@homedog ~/n/fetchmail> make check
>>    CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
>> /home/nr/net/fetchmail/missing aclocal-1.14 -I m4 -I m4-local
>>    /home/nr/net/fetchmail/missing: 81: aclocal-1.14: not found
>>    WARNING: 'aclocal-1.14' is missing on your system.
>>             You should only need it if you modified 'acinclude.m4' or
>>             'configure.ac' or m4 files included by 'configure.ac'.
>>             The 'aclocal' program is part of the GNU Automake package:
>>             <http://www.gnu.org/software/automake>
>>             It also requires GNU Autoconf, GNU m4 and Perl in order 
>> to run:
>>             <http://www.gnu.org/software/autoconf>
>>             <http://www.gnu.org/software/m4/>
>>             <http://www.perl.org/>
>>    make: *** [Makefile:893: aclocal.m4] Error 127
>>    nr@homedog ~/n/fetchmail [2]> l /usr/bin/aclocal*
>>    /usr/bin/aclocal@  /usr/bin/aclocal-1.15* /usr/bin/aclocal-1.17*
>>
>> I did not modify the files that are mentioned.
>>
>> Running `make install` is also blocked by this error.
>>
>> I can globally replace aclocal-1.14 with aclocal 1.15, but if the
>> Makefile is looking for such a specific version, perhaps I should not
>> tinker with things I don't understand.
>>
>> Please advise me how to proceed.
>
> I think
>         rm Makefile ; configure
> should be sufficient. Add whatever configure options you usually use.
>
> If not, you may need to run
>         rm Makefile.in ; automake
> and then then above
>         rm Makefile ; configure
> again.
>
> It looks like your automake has been updated since you last built 
> fetchmail,
> so removing config.status and/or or autom4te.cache/
> *might* be appropriate too.

Norman reported NOT having done so.  I have test built the freshly 
downloaded and unpackged tarball in a freshly pulled debian:stable 
container where I installed build-essential make libssl-dev, no such 
observation.

The usual cause that the autoconf/automake/gettext stuff wants to update 
its files is that timestamps got messed up, or that the computer time is 
way behind.
This might happen on tiny computers without real-time clock if they fail 
to synchronize upon boot.

If the computer slept for long enough in suspend mode so the clock is 
behind, or a computer without or with broken/unset/wrongly set RTC boots 
up and can't get the time from the network during boot, it can happen 
that the tarball is "in the future" from the perspective of the computer 
that built the tarball (mine), confusion ensues.

Now, as a result of an oversight in the build scripts, I export 
TAR_OPTIONS with an empty --mtime= argument which means all files get 
"start of today" date (midnight in the local timezone). This does work 
in my testing on Debian stable without forcing rebuilds of automake etc.

HTH

Re: [Fetchmail-users] The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

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

On Mon, 13 Jul 2026, Norman Ramsey wrote:

> > The 6.6.7.rc1 release candidate of fetchmail tightens code
> > around a security vulnerability in the NTLM code.
> > It is now available at the usual locations, including
> > <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.
>
> Building on Debian stable, I'm running into this build issue, which is
> not addressed in the FAQ:
>
>    nr@homedog ~/n/fetchmail> make check
>    CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/nr/net/fetchmail/missing aclocal-1.14 -I m4 -I m4-local
>    /home/nr/net/fetchmail/missing: 81: aclocal-1.14: not found
>    WARNING: 'aclocal-1.14' is missing on your system.
>             You should only need it if you modified 'acinclude.m4' or
>             'configure.ac' or m4 files included by 'configure.ac'.
>             The 'aclocal' program is part of the GNU Automake package:
>             <http://www.gnu.org/software/automake>
>             It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>             <http://www.gnu.org/software/autoconf>
>             <http://www.gnu.org/software/m4/>
>             <http://www.perl.org/>
>    make: *** [Makefile:893: aclocal.m4] Error 127
>    nr@homedog ~/n/fetchmail [2]> l /usr/bin/aclocal*
>    /usr/bin/aclocal@  /usr/bin/aclocal-1.15*  /usr/bin/aclocal-1.17*
>
> I did not modify the files that are mentioned.
>
> Running `make install` is also blocked by this error.
>
> I can globally replace aclocal-1.14 with aclocal 1.15, but if the
> Makefile is looking for such a specific version, perhaps I should not
> tinker with things I don't understand.
>
> Please advise me how to proceed.

I think
         rm Makefile ; configure
should be sufficient. Add whatever configure options you usually use.

If not, you may need to run
         rm Makefile.in ; automake
and then then above
         rm Makefile ; configure
again.

It looks like your automake has been updated since you last built 
fetchmail,
so removing config.status and/or or autom4te.cache/
*might* be appropriate too.

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

Re: [Fetchmail-users] The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

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

Norman, 

Please check if your clock is set correctly (also on your file server if using some networked file system for your home) and that you are not building on some file system with low resolution timestamps such as FAT. 

If you needed to adjust the clock, best remove the build directory and unpack freshly, preserving time stamps.

HTH, if not, we'll try something else.

Best regards, 
Matthias

Am 13. Juli 2026 14:38:20 UTC schrieb Norman Ramsey:
> > The 6.6.7.rc1 release candidate of fetchmail tightens code
> > around a security vulnerability in the NTLM code.
> > It is now available at the usual locations, including 
> > <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.
>
>Building on Debian stable, I'm running into this build issue, which is
>not addressed in the FAQ:
>
>    nr@homedog ~/n/fetchmail> make check
>    CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/nr/net/fetchmail/missing aclocal-1.14 -I m4 -I m4-local
>    /home/nr/net/fetchmail/missing: 81: aclocal-1.14: not found
>    WARNING: 'aclocal-1.14' is missing on your system.
>             You should only need it if you modified 'acinclude.m4' or
>             'configure.ac' or m4 files included by 'configure.ac'.
>             The 'aclocal' program is part of the GNU Automake package:
>             <http://www.gnu.org/software/automake>
>             It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>             <http://www.gnu.org/software/autoconf>
>             <http://www.gnu.org/software/m4/>
>             <http://www.perl.org/>
>    make: *** [Makefile:893: aclocal.m4] Error 127
>    nr@homedog ~/n/fetchmail [2]> l /usr/bin/aclocal*
>    /usr/bin/aclocal@  /usr/bin/aclocal-1.15*  /usr/bin/aclocal-1.17*
>
>I did not modify the files that are mentioned.
>
>Running `make install` is also blocked by this error.
>
>I can globally replace aclocal-1.14 with aclocal 1.15, but if the
>Makefile is looking for such a specific version, perhaps I should not
>tinker with things I don't understand.
>
>Please advise me how to proceed.
>
>
>Norman Ramsey

Re: [Fetchmail-users] The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

[Norman R. <nr...@cs...>]

 > The 6.6.7.rc1 release candidate of fetchmail tightens code
 > around a security vulnerability in the NTLM code.
 > It is now available at the usual locations, including 
 > <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.

Building on Debian stable, I'm running into this build issue, which is
not addressed in the FAQ:

    nr@homedog ~/n/fetchmail> make check
    CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/nr/net/fetchmail/missing aclocal-1.14 -I m4 -I m4-local
    /home/nr/net/fetchmail/missing: 81: aclocal-1.14: not found
    WARNING: 'aclocal-1.14' is missing on your system.
             You should only need it if you modified 'acinclude.m4' or
             'configure.ac' or m4 files included by 'configure.ac'.
             The 'aclocal' program is part of the GNU Automake package:
             <http://www.gnu.org/software/automake>
             It also requires GNU Autoconf, GNU m4 and Perl in order to run:
             <http://www.gnu.org/software/autoconf>
             <http://www.gnu.org/software/m4/>
             <http://www.perl.org/>
    make: *** [Makefile:893: aclocal.m4] Error 127
    nr@homedog ~/n/fetchmail [2]> l /usr/bin/aclocal*
    /usr/bin/aclocal@  /usr/bin/aclocal-1.15*  /usr/bin/aclocal-1.17*

I did not modify the files that are mentioned.

Running `make install` is also blocked by this error.

I can globally replace aclocal-1.14 with aclocal 1.15, but if the
Makefile is looking for such a specific version, perhaps I should not
tinker with things I don't understand.

Please advise me how to proceed.


Norman Ramsey

[Fetchmail-users] The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

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

The 6.6.7.rc1 release candidate of fetchmail tightens code
around a security vulnerability in the NTLM code.
It is now available at the usual locations, including 
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.

Depending on compilation options around --enable-NTLM and protective 
features such as stack smashing protection, fortification and other 
means, around 52 bytes might be overwritten on the stack, and we
cannot rule out that remote code execution be mounted.

Fetchmail builds that did not enable NTLM at compile time are 
unaffected.  fetchmail -V | head -1 will show "+NTLM" if NTLM was 
enabled, for instance (note the presence of +NTLM):

This is fetchmail release 6.6.2+GSS+RPA+NTLM+SDPS+TLS+NLS+KRB5.

A version in French locale that is not vulnerable to this NTLM
bug might reporto (note the absense of +NTLM):
Ceci est fetchmail, version 6.6.7.rc1+TLS+NLS.


The security announcement will be provided at a later date, it is
important to get the fix out; inaccuracies in the report might hint
at AI being used in the generation of the report, so holding back 
anything whilst a simple fix is available is a disservice to users.

Workaround: use the --auth PARAM option, where PARAM is another
mechanism (not NTLM) supported by fetchmail and by the IMAP or POP3 
server.  This may not be viable on shared multi-user systems.

Workaround for distributors and system operators:
Recompile fetchmail with --disable-NTLM option and reinstall it.
To confirm, look at the fetchmail -V | head -1 output, it should NOT 
mention +NTLM.

The immediate minimal fix can be cherry-picked from
https://gitlab.com/fetchmail/fetchmail/-/commit/cb5be5c38471eec19e519ace0bc569176317ea92
with a compiler warning fix in
https://gitlab.com/fetchmail/fetchmail/-/commit/ddf19ffab973bf6a424f878faa8ff6753ddf6246

Note though that 6.6.7.rc1's NTLM authentication fixed other bugs that 
are believed to not be exploitable beyond slowing down fetchmail while 
waiting for server I/O, which usually would not be a high risk.
Fetchmail usually applies timeouts to network reads.

The .pot file has been provided to the translation project, we have 
a few new messages that need translation.

Please report any regressions to the fetchmail-user mailing list,
or if security-sensitive observations are made, directly to me.


Note on AI assisted bugfinding and -fixing:
* Tell your AI to reply tersely and any assurances that are not
verifiably proven and that you have not proved to be true.
Some AIs guess and then are very assertive, like a lying child,
that it really is what it is, but does not provide the proof.
I am not interested in reading such AI slop. That time is
wasted and not available for other development work.
* Provide a proof of concept, or a unit test or similar, as code,
and prove that it practically compiles on a recent release version of 
Fedora Linux, FreeBSD, OpenBSD or Debian Linux.  I won't follow manual 
instructions.  It must compile out of the box within the folder of the
latest release package of fetchmail or build directory.
* Be careful with what AIs believe to be root causes or suggest as 
fixes.  Before providing an AI fix suggestion, prove that it fixes
not only one particular situation, but apply experience-based testing
or fuzzing to prove similar situations are also implied in the fix.


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

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

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.6.7.rc1.tar.xz)= d03b9abee39c64333703dc1d2512f0259698a5e130d344c375e1b42d1d2056e4


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.6.7 (not yet released):

## SECURITY BUGFIX FOR --enable-NTLM builds:
* Safeguard internal NTLM buffer handling to avoid overrun if server
  sends extremely long fields in the challenge, to avoid stack corruption.
  Reported by "Tristan".

  The code will report the buffer sizing issue and abort the NTLM authentication
  flow properly so that it's clear that message sizes are the issue.
  Fetchmail 6.6.7 currently supports 1 kByte of NTLM payload for each of the
  three messages, plus header.

  NOTE: NTLM is based on obsolete cryptographic mechanisms
  and should not be used without TLS or SSL security for the transport.

  NOTE: fetchmail 7 will remove support for NTLM and MSN authentication.
  Microsoft (who own the specification) generally advises that applications
  should not use NTLM, and is replacing with with Kerberos, see
  [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol,
  https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/
  See Introduction and Security Considerations for Implements
  (In Version 37.0 of the spec, sections 1 and 5.1 on page 84)

## BUGFIXES:
* The IMAP protocol exchange was made stricter, (1) it will validate tagged
  responses that we received the right response to make sure fetchmail
  and the IMAP server are still in synch, (2) it will no longer accept
  the response words OK, NO, BAD, BYE if there is trailing garbage,
  such as OKAY or NONE.
* For NTLM: Made protocol exchange more robust and make it track errors
  and SASL cancellation better to avoid hangs if NTLM does not work but other
  authentication schemes do or NTLM gets rejected by the server.

-------------------------------------------------------------------------------
fetchmail-6.6.6 (released 2026-06-24, 32443 LoC):

## CRITICAL BUGFIX FOR IMAP:
* The IMAP client, which has always used message indexes for the selected
  mailbox, did not abort when receiving an EXPUNGE response - which changes
  message numbers inside the mailbox.  Unlike UIDs, the message numbers are
  not stable and fetchmail does not have internal interfaces to track which
  messages are deleted, and adding those to a 6.6.X release would be too
  risky, and switching to UID is also too big a change, so we have no
  choice but to abort the session when seeing an EXPUNGE response without
  our own EXPUNGE request, to avoid marking the wrong message as seen/deleted
  or skip the wrong one, or assume the wrong message size.
  Earl Chew reported this versus Yahoo Mail via Gitlab Work Item #91, which
  automatically expunges messages that are marked with the \Deleted flag.

  This has one new message for which we do not have translations yet,
  it is urgent to get the fix in the field.

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

Re: [Fetchmail-users] IMAP confusion on unexpected EXPUNGE

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

Am 25.06.26 um 02:35 schrieb Hans Carlson via Fetchmail-users:
> Matthias,
>
> Could you explain this fix a bit more... or rather could you explain 
> how this differs from the previous behavior.  I ask because the 
> behavior I see with fetchmail-6.5.7 (latest available on Fedora 43) 
> seems to be basically the same except for the message.

Hans,

sure. The crucial change is that fetchmail 6.6.6 will now abort on *ANY* 
EXPUNGE that's received unless we're in an active "EXPUNGE" request -- 
the check to count EXPUNGE replies versus the "\Deleted" tags we dole 
out in the same session remains in place, but happens too late - 
including on Yahoo, depending on EXPUNGE interval.


Let's look at examples.


Example #1

Assume you have messages A, B, C.  Message numbers (not UIDs) in IMAP 
are dynamic in a session.  The server will always number them 1 2 3 if 
they are three messages.  Assume we have a longer EXPUNGE interval and 
only expunge every 10 messages because we're on a slow line and want 
fewer round trips. Satellite link, mobile link in the outskirts, your 
imagination defines why.

mailbox 1A 2B 3C

fetch and delete "1". This obtains message A and marks it deleted. So 
far, so good.

Yahoo expunges without our telling them to, and tells us "* 1 EXPUNGE". 
Meaning message 1 expunged, and messages 2...N now renumbered to 
1...N-1. Fetchmail 6.6.5 and older DISREGARDED this * 1 EXPUNGE. <- Bug! 
6.6.6 will see the * 1 EXPUNGE and abort the session because something 
outside our control messed with the mailbox and renumbered messages. Our 
internal state no longer matches the mailbox state. (Footnote [FN1]).

mailbox now has 1B 2C.    If fetchmail itself expunges after downloading 
that message 1A, we've trapped the bug because we request an.

fetchmail now downloads message "2" and marks it deleted. But instead of 
retrieving "B" it obtains C. OK.

Yahoo expunges without our telling them to.

mailbox now has 1B.

fetchmail attempts downloading message "3" and the server complains 
about a client bug. (Yes, it's right, that's fetchmail's fault.)


That's your use case. If we delete messages right away we're skipping 
every other message and at the end of the session the server complains. 
Not pretty, but not harmful.


Example #2

Other situation, we have messages A, B, C, D, E. Assume C is marked 
seen. Read in the web interface, read with another client, whatever.

mailbox 1A, 2B, 3C (Seen), 4D, 5E.

Assume that while fetchmail is downloading 1A, and before that 
completes, another client or the web interface deletes 1A and expunges 
it, or it gets auto-expunged through the server. Doesn't matter.

Mailbox now is 1B, 2C (Seen), 3D, 4E. fetchmail 6.6.5 and older ignore 
the * 1 EXPUNGE that arrives here.

Now, what might happen is this: In that moment, fetchmail marks message 
#1 seen and deleted in the assumption it will mark message A. Instead it 
marks B for deletion. The server auto-expunges.

Oops. We've just destroyed message B!   The fix in fetchmail 6.6.6 is 
that in this situation there is an EXPUNGE that we didn't request, so we 
drop the receiver on the hook immediately, so we don't accidentally lose B.

Mailbox now is 1C (Seen), 2D, 3E.

Remainder more or less as above.


The actual bug is that fetchmail wasn't (and still isn't) counting 
EXPUNGE replies properly except when we EXPUNGE ourselves because we 
don't have robust code in place to match our internal state to the 
mailbox by looking at EXISTS, EXPUNGE, RECENT and thereabouts.

I chose not to fix that because I don't believe this would be 
bullet-proof, ever. I've seen too many servers doing strange and 
possibly nonconforming things that wouldn't dare take that risk.

The proper fix will be accessing messages by UID instead of message 
numbers, and UIDVALIDITY: the UID numbers must be stable in a session 
whatever happens. If they change from one session to the next, the 
server must change the UIDVALIDITY. UIDVALIDITY and UID combined must be 
globally stable forever. No other message B is ever allowed to have the 
same UIDVALIDITY:UID combination than another message A. You delete A 
expunge, new message B arrives, new UID.


The other advantage of that future UID change (it's not in 6.6.6 nor any 
7.0.0-alpha yet) will be that we need not rely on a \Seen flag that can 
be changed outside fetchmail.  Fetchmail will reliably know "I've had 
message 61782312:4543" irrespective of any flags. EXPUNGE won't renumber 
the UIDs so we just need to track if a message we want to download gets 
expunged so we know to skip it.


> With 6.5.7 if I fetch email from yahoo I see this:
>
>   3 messages for XXXXX at XXXXX.
>   reading message XXXXX:1 of 3 (6568 header octets) (8 body octets) 
> flushed
>   mail expunge mismatch (0 actual != 1 expected)
>   client/server synchronization error while fetching from XXXXX
>   Query status=7 (ERROR)
>
> and then the connection closes.
>
> With 6.6.6 I see this:
>
>   3 messages for XXXXX at XXXXX.
>   reading message XXXXX:1 of 3 (6568 header octets) (8 body octets) 
> flushed
>   Unexpected EXPUNGE response from IMAP server: "* 1 EXPUNGE". 
> fetchmail must abort the session because message numbers are 
> desynchronized now.
>   client/server protocol error while fetching from XXXXX
>   Query status=4 (PROTOCOL)
>
> and then the connection closes.
>
> It's definitely a better message, but other than that the behavior 
> seems to be the same (to me).  I'm guessing the unexpected EXPUNGE is 
> caught at a different stage during the connection?


Yes - might be SEARCH, STORE, FETCH, whatever in addition to the EXPUNGE 
we check now.


>
> I've lived with this behavior from Yahoo because it's very low volume 
> (1-3/day if that) and if it takes a bit longer to get the 1-2 other 
> messages that's fine. But the warning below suggests the wrong message 
> could be deleted?


Not if fetchmail really is the only client accessing the mailbox at the 
same time.  But I won't guarantee what happens if another client access 
the mailbox as in Example #2, hence my alarming wording.


>
> In my case, there's only one instance of fetchmail that accesses this 
> account and it's the only thing that accesses it, so maybe that 
> minimizes/eliminates the chance of an incorrect deletion?


Likely. If you don't fetch from multiple mailboxes, switch to POP3. For 
Yahoo that means you change from imap.mail.yahoo.com to 
pop.mail.yahoo.com and add "protocol POP3" somewhere between the "poll 
pop.mail.yahoo.com" and the "user".

HTH.

Happy fetching,
Matthias


>
>
> On Wed, 24 Jun 2026, Matthias Andree via Fetchmail-users wrote:
>
>> The 6.6.6 critical bug fix release of fetchmail is now available at the
>> usual locations, including 
>> <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.
>>
>> People who cannot update but use IMAP should set "keep" or use "--keep"
>> on the command line immediately to avoid accidentally deleting the wrong
>> message in case your upstream IMAP server sees multiple clients on the
>> same mailbox OR expunge automatically when a \Deleted flag is STOREd on
>> a message.  A proper fix for this would be too large and/or risky and/or
>> introduce breaking changes, so is unsuitable for 6.6.x.
>>
>> The source archive is available at:
>> <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.6.tar.xz/download> 
>>
>>
>> The detached GnuPG signature is available at:
>> <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.6.tar.xz.asc/download> 
>>
>>
>> The SHA256 hashes for the tarballs are:
>> SHA2-256(fetchmail-6.6.6.tar.xz)= 
>> da99f8c573c4d9e63f493c7e24447126aea25b53b4c076ec79266874e29b1975
>>
>>
>> Here are the release notes:
>> -------------------------------------------------------------------------------- 
>>
>> fetchmail-6.6.6 (released 2026-06-24, 32443 LoC):
>>
>> ## CRITICAL BUGFIX FOR IMAP:
>> * The IMAP client, which has always used message indexes for the 
>> selected
>>  mailbox, did not abort when receiving an EXPUNGE response - which 
>> changes
>>  message numbers inside the mailbox.  Unlike UIDs, the message 
>> numbers are
>>  not stable and fetchmail does not have internal interfaces to track 
>> which
>>  messages are deleted, and adding those to a 6.6.X release would be too
>>  risky, and switching to UID is also too big a change, so we have no
>>  choice but to abort the session when seeing an EXPUNGE response without
>>  our own EXPUNGE request, to avoid marking the wrong message as 
>> seen/deleted
>>  or skip the wrong one, or assume the wrong message size.
>>  Earl Chew reported this versus Yahoo Mail via Gitlab Work Item #91, 
>> which
>>  automatically expunges messages that are marked with the \Deleted flag.
>>
>>  This has one new message for which we do not have translations yet,
>>  it is urgent to get the fix in the field.
>>
>> ------------------------------------------------------------------------------- 
>>
>>
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] IMAP confusion on unexpected EXPUNGE

[Hans C. <fo...@gm...>]

Matthias,

Could you explain this fix a bit more... or rather could you explain how 
this differs from the previous behavior.  I ask because the behavior I see 
with fetchmail-6.5.7 (latest available on Fedora 43) seems to be basically 
the same except for the message.

With 6.5.7 if I fetch email from yahoo I see this:

   3 messages for XXXXX at XXXXX.
   reading message XXXXX:1 of 3 (6568 header octets) (8 body octets) flushed
   mail expunge mismatch (0 actual != 1 expected)
   client/server synchronization error while fetching from XXXXX
   Query status=7 (ERROR)

and then the connection closes.

With 6.6.6 I see this:

   3 messages for XXXXX at XXXXX.
   reading message XXXXX:1 of 3 (6568 header octets) (8 body octets) flushed
   Unexpected EXPUNGE response from IMAP server: "* 1 EXPUNGE". fetchmail must abort the session because message numbers are desynchronized now.
   client/server protocol error while fetching from XXXXX
   Query status=4 (PROTOCOL)

and then the connection closes.

It's definitely a better message, but other than that the behavior seems 
to be the same (to me).  I'm guessing the unexpected EXPUNGE is caught at 
a different stage during the connection?

I've lived with this behavior from Yahoo because it's very low volume 
(1-3/day if that) and if it takes a bit longer to get the 1-2 other 
messages that's fine. But the warning below suggests the wrong message 
could be deleted?

In my case, there's only one instance of fetchmail that accesses this 
account and it's the only thing that accesses it, so maybe that 
minimizes/eliminates the chance of an incorrect deletion?


On Wed, 24 Jun 2026, Matthias Andree via Fetchmail-users wrote:

> The 6.6.6 critical bug fix release of fetchmail is now available at the
> usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.
>
> People who cannot update but use IMAP should set "keep" or use "--keep"
> on the command line immediately to avoid accidentally deleting the wrong
> message in case your upstream IMAP server sees multiple clients on the
> same mailbox OR expunge automatically when a \Deleted flag is STOREd on
> a message.  A proper fix for this would be too large and/or risky and/or
> introduce breaking changes, so is unsuitable for 6.6.x.
>
> The source archive is available at:
> <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.6.tar.xz/download>
>
> The detached GnuPG signature is available at:
> <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.6.tar.xz.asc/download>
>
> The SHA256 hashes for the tarballs are:
> SHA2-256(fetchmail-6.6.6.tar.xz)= da99f8c573c4d9e63f493c7e24447126aea25b53b4c076ec79266874e29b1975
>
>
> Here are the release notes:
> --------------------------------------------------------------------------------
> fetchmail-6.6.6 (released 2026-06-24, 32443 LoC):
>
> ## CRITICAL BUGFIX FOR IMAP:
> * The IMAP client, which has always used message indexes for the selected
>  mailbox, did not abort when receiving an EXPUNGE response - which changes
>  message numbers inside the mailbox.  Unlike UIDs, the message numbers are
>  not stable and fetchmail does not have internal interfaces to track which
>  messages are deleted, and adding those to a 6.6.X release would be too
>  risky, and switching to UID is also too big a change, so we have no
>  choice but to abort the session when seeing an EXPUNGE response without
>  our own EXPUNGE request, to avoid marking the wrong message as seen/deleted
>  or skip the wrong one, or assume the wrong message size.
>  Earl Chew reported this versus Yahoo Mail via Gitlab Work Item #91, which
>  automatically expunges messages that are marked with the \Deleted flag.
>
>  This has one new message for which we do not have translations yet,
>  it is urgent to get the fix in the field.
>
> -------------------------------------------------------------------------------
>

[Fetchmail-users] The 6.6.6 critical bug fix release of fetchmail is available (fixes IMAP confusion on unexpected EXPUNGE)

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

The 6.6.6 critical bug fix release of fetchmail is now available at the 
usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.

People who cannot update but use IMAP should set "keep" or use "--keep" 
on the command line immediately to avoid accidentally deleting the wrong 
message in case your upstream IMAP server sees multiple clients on the 
same mailbox OR expunge automatically when a \Deleted flag is STOREd on 
a message.  A proper fix for this would be too large and/or risky and/or
introduce breaking changes, so is unsuitable for 6.6.x.

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

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

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


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.6.6 (released 2026-06-24, 32443 LoC):

## CRITICAL BUGFIX FOR IMAP:
* The IMAP client, which has always used message indexes for the selected
  mailbox, did not abort when receiving an EXPUNGE response - which changes
  message numbers inside the mailbox.  Unlike UIDs, the message numbers are
  not stable and fetchmail does not have internal interfaces to track which
  messages are deleted, and adding those to a 6.6.X release would be too
  risky, and switching to UID is also too big a change, so we have no
  choice but to abort the session when seeing an EXPUNGE response without
  our own EXPUNGE request, to avoid marking the wrong message as seen/deleted
  or skip the wrong one, or assume the wrong message size.
  Earl Chew reported this versus Yahoo Mail via Gitlab Work Item #91, which
  automatically expunges messages that are marked with the \Deleted flag.

  This has one new message for which we do not have translations yet,
  it is urgent to get the fix in the field.

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

[Fetchmail-users] The 6.6.5 security fix release of fetchmail is available (fixes RPA buffer sizing)

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

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

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

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

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


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.6.5 (released 2026-06-17, 32433 LoC):

## SECURITY BUGFIX
* POP3 with RPA: fix calculation of buffer sizes to avoid buffer overflow
  on long service challenges with long user IDs, which would smash our stack.
    Triggering this requires that 1. RPA is enabled at compile time
  (non-default, which is discouraged in autotools, and possible but not
  documented nor supported in meson), and the username (--user option, or user
  in the rcfile) contains @compuserve.com anywhere, and the server supports an
  AUTH command without arguments (which is a non-standard local extension), and
  that it offers RPA authentication in response to that command.

  This was reported based on an incomplete semi-wrong AI report with an
  incomplete fix "recommendation" by zha...@ou... via
  fetchmail-devel@.  The fix suggested in that AI report was wrong, and
  would happily crash a few lines later again.  The fix deployed calculates
  the buffer size of "workarea" variables based on the sizeof() of constituent
  components.

## BUGFIX
* Robustness: If RPA is enabled at compile time and POP3 is in use,
  do not barf if @compuserve.com is in the remote site's username (what you'd
  pass as --user, or user in the rcfile) and the remote site either does not
  support an "AUTH" command without parameters (normally, one is required, but
  some servers such as jpop and Cyrus allow AUTH to request the list of
  supported authentication types as an extension; the standard way would be
  a "CAPA" request instead), but try other authentication methods.
  Found by code auditing in response to a bug report against rpa.c.
  Note that enabling RPA is discouraged because it is based on the weak
  MD5 crypto algorithm.

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

[Fetchmail-users] The 6.6.4 release of fetchmail is available (fixes --moveto, improves build, also with AWS-LC or wolfSSL)

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

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

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

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

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


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.6.4 (released 2026-05-08, 32432 LoC):

## BUGFIX
* The IMAP client will now properly quote the folder name given with the
  moveto rcfile option, or --moveto command-line option.
  Report and bugfix contributed by Corben Dallas.

## BUILD IMPROVEMENTS
* meson-based builds with wolfSSL should now also work when meson finds
  the wolfssl package through cmake, instead of pkgconfig. This is unsupported
  and depends on internal set(_wolfssl_includedir "...") in wolfSSL's
  lib/cmake/*.cmake files, and works as of wolfSSL 5.9.1.
  The supported way to build fetchmail with wolfSSL with meson is
  to make sure that wolfSSL is found with pkgconfig, as in (change /path/to!)
  meson setup --pkg-config-path /path/to/wolfssl/lib/pkgconfig

## EXPERIMENTAL CHANGES - these are not documented anywhere else, only here:
* fetchmail supports AWS-LC 1.71 or newer, since its relicensing to
  the Apache license v2.0.  Note this requires you to distribute fetchmail
  under terms of the GPLv3 because the GPLv2 is claimed incompatible
  with Apache license (this is no different for OpenSSL 3 or newer,
  or the one wolfSSL version that was GPLv3 licensed).
* fetchmail supports a FETCHMAIL_SSL_SECLEVEL environment variable
  (since 6.5.0, except when using AWS-LC where it is silently ignored),
  which 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
  (since 6.5.0) 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 "HIGH:MEDIUM:+RC4:@STRENGTH:!aNULL" - note
  that +RC4 is supposed to move the RC4 to the end of the list, not add it.
* fetchmail supports a FETCHMAIL_TLS13_CIPHERSUITES environment variable
  (since 6.5.0) that sets the ciphersuites (a colon-separated list,
  without + ! -) for TLSv1.3. If not given, defaults to the SSL library'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-users] The 6.6.3 release of fetchmail is available (fixes compilation with OpenSSL 4.0.0-beta1)

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

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

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

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

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.6.3.tar.xz)= 246e5fc0e35c93dde1a3fb66778e3ab700e16809232e4959c508b91214374bb2


Here are the release notes (and no, there is no April prank implied):

--------------------------------------------------------------------------------
fetchmail-6.6.3 (released 2026-04-01, 32388 LoC):

## COMPATIBILITY:
* fetchmail can now be built with OpenSSL 4.0.0 (tested as of -beta1).

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

Re: [Fetchmail-users] Fetchmail not working and putting errors in maillog

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

Am 06.01.26 um 03:17 schrieb Al:
> Hi,
>
> I hope that I someone can help me. I am trying to use fetchmail with 
> fetchmail.pl. I am running as the vmail user and this is the errors I 
> see in my mail log:
>
> fetchmail-all[19497]: fetch me...@ya... for me...@my...
> fetchmail[19498]: 9955 messages for me...@ya... at pop.mail.yahoo.com 
> (1982615899 octets).
> fetchmail[19498]: reading message 
> me...@ya...@any-jpop.mail.gm0.yahoodns.net:1 of 9955 (34082 octets) 
> (log message incomplete)
> fetchmail[19498]: Cannot switch effective user id to 2001: Operation 
> not permitted
> fetchmail[19498]: MDA error while fetching from 
> jea...@ya...@pop.mail.yahoo.com
> fetchmail[19498]: Query status=6 (IOERR)
>
> I have tried to find a solution, but I am unable to solve this error. 
> Dovecot does deliver email that are received from postfix after I 
> added virtualmail to the dovecot group.


Your MDA cannot switch to user ID 2001 what- or whoever that is. No 
configuration shown, so we can't help you yet.


>
> Please let me know if other information is needed.

Yes, please... but that's a FAQ with a FGA... 
<https://www.fetchmail.info/fetchmail-FAQ.html#G3>

[Fetchmail-users] Fetchmail not working and putting errors in maillog

[Al <al...@da...>]

Hi,

I hope that I someone can help me. I am trying to use fetchmail with 
fetchmail.pl. I am running as the vmail user and this is the errors I 
see in my mail log:

fetchmail-all[19497]: fetch me...@ya... for me...@my...
fetchmail[19498]: 9955 messages for me...@ya... at pop.mail.yahoo.com 
(1982615899 octets).
fetchmail[19498]: reading message 
me...@ya...@any-jpop.mail.gm0.yahoodns.net:1 of 9955 (34082 octets) 
(log message incomplete)
fetchmail[19498]: Cannot switch effective user id to 2001: Operation not 
permitted
fetchmail[19498]: MDA error while fetching from 
jea...@ya...@pop.mail.yahoo.com
fetchmail[19498]: Query status=6 (IOERR)

I have tried to find a solution, but I am unable to solve this error. 
Dovecot does deliver email that are received from postfix after I added 
virtualmail to the dovecot group.

Please let me know if other information is needed.

Kind Regards,
Al

Re: [Fetchmail-users] Problems with downloads from hotmail

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

Am 01.01.26 um 16:22 schrieb Ian Neal:
> Hi,
>
> Attaching gzip'd so it the file doesn't get mangled in transit.
>
Thanks.

It's not the BOM that is the issue, but that the header ends prematurely 
after the From: line, unless that's an artifact introduced by redacting 
the header. Between the From and next Received headers, there are two 0a 
characters (line feed, see offset/line 260, below), meaning a blank 
line, technically the header ends there. I don't see either of those two 
should have been created by fetchmail. Fetchmail itself does not add 
byte order marks.

Does this happen for @updates.westmidlandsrailway.co.uk only or all 
messages?

Can I see a fetchmail -vv log trying to obtain one of these failing 
messages, too?


00000230: 4d54 290a 4672 6f6d 3a20 7a7a 7a7a 7a40  MT).From: zzzzz@
00000240: 7570 6461 7465 732e 7765 7374 6d69 646c updates.westmidl
00000250: 616e 6473 7261 696c 7761 792e 636f 2e75 andsrailway.co.u
00000260: 6b0a 0aef bbbf 5265 6365 6976 6564 3a20 k.....Received:
00000270: 6672 6f6d 2044 5532 5031 3932 4d42 3231  from DU2P192MB21
00000280: 3639 2e45 5552 5031 3932 2e50 524f 442e 69.EURP192.PROD.



> Regards,
>
> Ian
>
> On 01/01/2026 1:10 pm, Matthias Andree wrote:
>> Hi Ian,
>>
>> where exactly is the BOM? Can you show an example? Feel free to 
>> replace any printable character by x to mask private information.
>>
>> POP3 and IMAP headers clearly are not UTF-8 or UTF-16 according to 
>> standards, so a provider's inserting 0xFF or 0xFE characters is a 
>> blatant violation of the protocol and I guess not just fetchmail will 
>> have trouble with that.
>>
>>
>> Am 31. Dezember 2025 18:09:15 UTC schrieb Ian Neal 
>> <ian...@gm...>:
>>
>>     Hi, I currently use fetchmail 7.0.0-alpha13 running on Fedora 42
>>     to pull emails down from hotmail with OAuth2 and delivery to my
>>     local dovecot email server. Up until the last few weeks I've not
>>     had any issues with downloading emails, but now I've started
>>     having an issue where an <feff> character gets inserted just
>>     before the start of the main header (so after the local part
>>     inserted by fetchmail). My fetchmailrc file is along the lines
>>     of: poll pop-mail.outlook.com proto POP3 port 995 auth
>>     oauthbearer username "use...@ho..." passwordfile
>>     "fetchmail-token" is "user" here nokeep fetchall sslmode wrapped
>>     sslcertck Anyone got any ideas/suggestions? Thanks, Ian
>>     ------------------------------------------------------------------------
>>     Fetchmail-users mailing list
>>     Fet...@li...
>>     https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>>
>

-- 
Matthias Andree

Re: [Fetchmail-users] Problems with downloads from hotmail

[Ian N. <ian...@gm...>]

Hi,

Attaching gzip'd so it the file doesn't get mangled in transit.

Regards,

Ian

On 01/01/2026 1:10 pm, Matthias Andree wrote:
> Hi Ian,
>
> where exactly is the BOM? Can you show an example? Feel free to 
> replace any printable character by x to mask private information.
>
> POP3 and IMAP headers clearly are not UTF-8 or UTF-16 according to 
> standards, so a provider's inserting 0xFF or 0xFE characters is a 
> blatant violation of the protocol and I guess not just fetchmail will 
> have trouble with that.
>
>
> Am 31. Dezember 2025 18:09:15 UTC schrieb Ian Neal 
> <ian...@gm...>:
>
>     Hi, I currently use fetchmail 7.0.0-alpha13 running on Fedora 42
>     to pull emails down from hotmail with OAuth2 and delivery to my
>     local dovecot email server. Up until the last few weeks I've not
>     had any issues with downloading emails, but now I've started
>     having an issue where an <feff> character gets inserted just
>     before the start of the main header (so after the local part
>     inserted by fetchmail). My fetchmailrc file is along the lines of:
>     poll pop-mail.outlook.com proto POP3 port 995 auth oauthbearer
>     username "use...@ho..." passwordfile "fetchmail-token" is
>     "user" here nokeep fetchall sslmode wrapped sslcertck Anyone got
>     any ideas/suggestions? Thanks, Ian
>     ------------------------------------------------------------------------
>     Fetchmail-users mailing list Fet...@li...
>     https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>

Re: [Fetchmail-users] Problems with downloads from hotmail

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

On 2026-01-01 15:00, Ian Neal wrote:
> Hi,
> 
> I've attached a trimmed down redacted version of one such email. 
> Hopefully you can see it is at the top of the original message with the 
> fetchmail rewrite above it.
> 

I think you have to attach as binary (for instance, as a gzipped file). If you send it as text, it can be interpreted in transit.


00000000 52 65 74 75 │ 72 6E 2D 50 │ 61 74 68 3A │ 20 3C 7A 7A │ 7A 7A 7A 40 │ 75 70 64 61 │ 74 65 73 2E  Return-Path: <zzzzz@updates.
0000001C 77 65 73 74 │ 6D 69 64 6C │ 61 6E 64 73 │ 72 61 69 6C │ 77 61 79 2E │ 63 6F 2E 75 │ 6B 3E 0A 58  westmidlandsrailway.co.uk>.X
00000038 2D 4F 72 69 │ 67 69 6E 61 │ 6C 2D 54 6F │ 3A 20 75 73 │ 65 72 40 6C │ 6F 63 61 6C │ 68 6F 73 74  -Original-To: user@localhost
00000054 0A 44 65 6C │ 69 76 65 72 │ 65 64 2D 54 │ 6F 3A 20 75 │ 73 65 72 40 │ 6C 6F 63 61 │ 6C 68 6F 73  .Delivered-To: user@localhos
00000070 74 0A 52 65 │ 63 65 69 76 │ 65 64 3A 20 │ 66 72 6F 6D │ 20 78 78 78 │ 2E 79 79 79 │ 2E 6C 6F 63  t.Received: from xxx.yyy.loc
0000008C 61 6C 20 28 │ 6C 6F 63 61 │ 6C 68 6F 73 │ 74 20 5B 31 │ 32 37 2E 30 │ 2E 30 2E 31 │ 5D 29 0A 09  al (localhost [127.0.0.1])..
000000A8 62 79 20 78 │ 78 78 2E 79 │ 79 79 2E 63 │ 6F 2E 75 6B │ 20 28 50 6F │ 73 74 66 69 │ 78 29 20 77  by xxx.yyy.co.uk (Postfix) w
000000C4 69 74 68 20 │ 45 53 4D 54 │ 50 20 69 64 │ 20 35 46 34 │ 33 31 31 33 │ 30 43 42 44 │ 0A 09 66 6F  ith ESMTP id 5F431130CBD..fo
000000E0 72 20 3C 75 │ 73 65 72 40 │ 6C 6F 63 61 │ 6C 68 6F 73 │ 74 3E 3B 20 │ 54 68 75 2C │ 20 30 31 20  r <user@localhost>; Thu, 01
000000FC 4A 61 6E 20 │ 32 30 32 36 │ 20 31 31 3A │ 31 31 3A 30 │ 32 20 2B 30 │ 30 30 30 20 │ 28 47 4D 54  Jan 2026 11:11:02 +0000 (GMT
00000118 29 0A 52 65 │ 63 65 69 76 │ 65 64 3A 20 │ 66 72 6F 6D │ 20 6F 6F 63 │ 2D 67 32 2E │ 74 6D 2D 34  ).Received: from ooc-g2.tm-4
00000134 2E 6F 66 66 │ 69 63 65 2E │ 63 6F 6D 20 │ 5B 34 30 2E │ 39 39 2E 31 │ 35 31 2E 31 │ 36 32 5D 0A  .office.com [40.99.151.162].
00000150 09 62 79 20 │ 78 78 78 2E │ 79 79 79 2E │ 6C 6F 63 61 │ 6C 20 77 69 │ 74 68 20 50 │ 4F 50 33 20  .by xxx.yyy.local with POP3
0000016C 28 66 65 74 │ 63 68 6D 61 │ 69 6C 2D 37 │ 2E 30 2E 30 │ 2D 61 6C 70 │ 68 61 31 33 │ 29 0A 09 66  (fetchmail-7.0.0-alpha13)..f
00000188 6F 72 20 3C │ 75 73 65 72 │ 40 6C 6F 63 │ 61 6C 68 6F │ 73 74 3E 20 │ 28 73 69 6E │ 67 6C 65 2D  or <user@localhost> (single-
000001A4 64 72 6F 70 │ 29 3B 20 54 │ 68 75 2C 20 │ 30 31 20 4A │ 61 6E 20 32 │ 30 32 36 20 │ 31 31 3A 31  drop); Thu, 01 Jan 2026 11:1
000001C0 31 3A 30 32 │ 20 2B 30 30 │ 30 30 20 28 │ 47 4D 54 29 │ 0A 4D 65 73 │ 73 61 67 65 │ 2D 49 64 3A  1:02 +0000 (GMT).Message-Id:
000001DC 20 3C 32 30 │ 32 36 30 31 │ 30 31 31 31 │ 31 31 30 32 │ 2E 35 46 34 │ 33 31 31 33 │ 30 43 42 44   <20260101111102.5F431130CBD
000001F8 40 78 78 78 │ 2E 79 79 79 │ 2E 63 6F 2E │ 75 6B 3E 0A │ 44 61 74 65 │ 3A 20 54 68 │ 75 2C 20 30  @xxx.yyy.co.uk>.Date: Thu, 0
00000214 31 20 4A 61 │ 6E 20 32 30 │ 32 36 20 31 │ 31 3A 31 31 │ 3A 30 32 20 │ 2B 30 30 30 │ 30 20 28 47  1 Jan 2026 11:11:02 +0000 (G



-- 
Cheers / Saludos,

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

Re: [Fetchmail-users] Problems with downloads from hotmail

[Ian N. <ian...@gm...>]

Hi,

I've attached a trimmed down redacted version of one such email. 
Hopefully you can see it is at the top of the original message with the 
fetchmail rewrite above it.

Regards,

Ian

On 01/01/2026 1:10 pm, Matthias Andree wrote:
> Hi Ian,
>
> where exactly is the BOM? Can you show an example? Feel free to 
> replace any printable character by x to mask private information.
>
> POP3 and IMAP headers clearly are not UTF-8 or UTF-16 according to 
> standards, so a provider's inserting 0xFF or 0xFE characters is a 
> blatant violation of the protocol and I guess not just fetchmail will 
> have trouble with that.
>
>
> Am 31. Dezember 2025 18:09:15 UTC schrieb Ian Neal 
> <ian...@gm...>:
>
>     Hi, I currently use fetchmail 7.0.0-alpha13 running on Fedora 42
>     to pull emails down from hotmail with OAuth2 and delivery to my
>     local dovecot email server. Up until the last few weeks I've not
>     had any issues with downloading emails, but now I've started
>     having an issue where an <feff> character gets inserted just
>     before the start of the main header (so after the local part
>     inserted by fetchmail). My fetchmailrc file is along the lines of:
>     poll pop-mail.outlook.com proto POP3 port 995 auth oauthbearer
>     username "use...@ho..." passwordfile "fetchmail-token" is
>     "user" here nokeep fetchall sslmode wrapped sslcertck Anyone got
>     any ideas/suggestions? Thanks, Ian
>     ------------------------------------------------------------------------
>     Fetchmail-users mailing list Fet...@li...
>     https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>

Re: [Fetchmail-users] Problems with downloads from hotmail

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

Hi Ian, 

where exactly is the BOM? Can you show an example? Feel free to replace any printable character by x to mask private information. 

POP3 and IMAP headers clearly are not UTF-8 or UTF-16 according to standards, so a provider's inserting 0xFF or 0xFE characters is a blatant violation of the protocol and I guess not just fetchmail will have trouble with that.

Am 31. Dezember 2025 18:09:15 UTC schrieb Ian Neal <ian...@gm...>:
>Hi,
>
>I currently use fetchmail 7.0.0-alpha13 running on Fedora 42 to pull emails down from hotmail with OAuth2 and delivery to my local dovecot email server.
>
>Up until the last few weeks I've not had any issues with downloading emails, but now I've started having an issue where an <feff> character gets inserted just before the start of the main header (so after the local part inserted by fetchmail).
>
>My fetchmailrc file is along the lines of:
>poll pop-mail.outlook.com proto POP3 port 995 auth oauthbearer username "use...@ho..." passwordfile "fetchmail-token" is "user" here nokeep fetchall sslmode wrapped sslcertck
>
>Anyone got any ideas/suggestions?
>
>Thanks,
>
>Ian
>
>
>_______________________________________________
>Fetchmail-users mailing list
>Fet...@li...
>https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] Problems with downloads from hotmail

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

On Wed, 31 Dec 2025, Ian Neal wrote:

> Hi,
>
> I currently use fetchmail 7.0.0-alpha13 running on Fedora 42 to pull emails down from
> hotmail with OAuth2 and delivery to my local dovecot email server.

(I haven't been keeping up with fetchmail 7 as I believed that
  current development was on version 6 and frustration wth GMail
  made it likely that OAuth2 support might not continue.
   For fetchmail 6 I use Matthew Ogilvie's OAuth2 patches:
  https://sourceforge.net/u/mmogilvi/fetchmail/ci/master/tree/ )

> Up until the last few weeks I've not had any issues with downloading emails, but now
> I've started having an issue where an <feff> character gets inserted just before the
> start of the main header (so after the local part inserted by fetchmail).
>
> My fetchmailrc file is along the lines of:
> poll pop-mail.outlook.com proto POP3 port 995 auth oauthbearer username
> "use...@ho..." passwordfile "fetchmail-token" is "user" here nokeep fetchall
> sslmode wrapped sslcertck
>
> Anyone got any ideas/suggestions?

Apologies if this is not new. <feff> is an invisible UTF16 character, 
mostly used to indicate big- or litle-endian data.
I'm not actually sure what an application is supposed to do with it when
coverting from UTF16 to UTF8 (which I *assume* your dovecot is using).

I would start by finding out whether Hotmail is delivering email as UTF16
(whether deliberately or just by not converting what it is given).

Sorry I cannot be more help.

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

[Fetchmail-users] Problems with downloads from hotmail

[Ian N. <ian...@gm...>]

Hi,

I currently use fetchmail 7.0.0-alpha13 running on Fedora 42 to pull 
emails down from hotmail with OAuth2 and delivery to my local dovecot 
email server.

Up until the last few weeks I've not had any issues with downloading 
emails, but now I've started having an issue where an <feff> character 
gets inserted just before the start of the main header (so after the 
local part inserted by fetchmail).

My fetchmailrc file is along the lines of:
poll pop-mail.outlook.com proto POP3 port 995 auth oauthbearer username 
"use...@ho..." passwordfile "fetchmail-token" is "user" here 
nokeep fetchall sslmode wrapped sslcertck

Anyone got any ideas/suggestions?

Thanks,

Ian

[Fetchmail-users] The 6.6.2 release of fetchmail is available (fixes compilation without TLS/SSL)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.2.tar.xz/download>
<https://gitlab.com/-/project/188557/uploads/ab974ed004f98526e82ba90bbcb791b4/fetchmail-6.6.2.tar.xz>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.2.tar.xz.asc/download>
<https://gitlab.com/-/project/188557/uploads/1bf347357294eb10e05f903d50b8dc35/fetchmail-6.6.2.tar.xz.asc>

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


Here are the release notes:
- --------------------------------------------------------------------------------
fetchmail-6.6.2 (released 2025-12-09, 32386 LoC):

## BUGFIX:
* fetchmail 6.6.0 and 6.6.1 could not be configured without SSL, it would break
  compiling sink.c.  Fix compilation.  Report by Toralf Förster, analysis and
  different patch suggested by Holger Hoffstätte, fixes #86.
  https://bugs.gentoo.org/967258 and
  https://gitlab.com/fetchmail/fetchmail/-/issues/86

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

iQIzBAEBCgAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAmk4bXsACgkQ5BKxVu/z
hVpX5hAAvYfSfvpoS9pxDLzrqixg1DLSeXMO5zeAnpOtEvXZgwetY7O0W0IUjrAv
A6Y7U7nss2apQD/c0c/6TjBPy7Pwdb6ytdRKQOJJ8qi5WVoWDpBvh5bbyLpA/tIt
1hgCo1hHqY6A8eXxMU4rsX2FxspbK3K3m6kiGHlKfycY9Wl1WPKUvpiQFxjEoqso
bRA1wZdAjdM6zAch4hIPfwvrKO1reqJuWkbzBvKPQaNVNN+0lLrov5SwGZ1S+LtW
60B9keiZtPrEm6MEZlYS9gL01jOh/vHAMEvTF1BL1OkADofV+abp7eT9+xk6m2DC
NpPb7Jjk+c1VDgl8VPpLIQqDI02Yfk6VQTsHoF2HoxxLvDYZLQ6orCiL0VN6pdKj
27z+TtKrgZkc+qMs93VFUMYUKIgzFIfJqGc4ZbEctjbPSsWD9LFYxZi0jKBdm/eg
gAMbIClL3kkG56WvaBFsWZux0l1WucjedmUUdfPGAal29A9LCkQa/aSCTPnMwyXP
hyojSSiMrWPGcAOmOZ7zFoRdEIcaDDYoiS4R4tHah+LGv8XvHPHwJIAwJPN8aAQH
6MYydukkofJuFJJ0BhiO3PgPvSzLrpLLHojaMFNhzZ/oDo9W3GJ3I0NzOyTCeo92
yzTFj6vGemjYxg1ALOo+oXm1JDn3IOP0fOnqlwjSMUXeMCkD4C0=
=REcb
-----END PGP SIGNATURE-----

Re: [Fetchmail-users] poll server failover with multiple DNS entries

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

Am 19.11.25 um 21:24 schrieb Matthias Andree via Fetchmail-users:
> Am 19.11.25 um 14:32 schrieb BASSAGET Cédric:
>> Hello,
>>
>> I'm trying to poll a pop3 server resolving on different IP addresses :
>> # dig pop.dom.tld +short
>> 1.2.3.4
>> 1.2.3.5
>>
>> when running fetchmail, it tries to reach one of the two servers, and at
>> the end of the (-t) timeout, fetchmail exits without trying to poll the
>> other server.
>
> Salut Cédric,
>
> Uh. That would be a logic bug. I won't have time immediately, so I'd 
> better file an issue in Gitlab so I don't forget.
> -> https://gitlab.com/fetchmail/fetchmail/-/issues/85 


This cannot be fixed without rewriting several functions and changing 
their meaning and would not be exactly compatible, and bears risks to 
introduce new bugs.
This is therefore unsuitable for a patch-level fix in 6.6.X and needs to 
be part of a major revision, so will only appear in 7.0 later. The Issue 
on Gitlab (URL in previous message, quoted above) has been moved to the 
7.0.0 milestone.

Re: [Fetchmail-users] Local delivery - smtp or sendmail

[Hans C. <fo...@gm...>]

On Wed, 19 Nov 2025, Matthias Andree via Fetchmail-users wrote:

> Am 11.11.25 um 21:24 schrieb Hans Carlson via Fetchmail-users:
>>
>>  Sooo... if I don't actually want any restrictions on fetchmail, then is
>>  there any reason NOT to use sendmail for delivery instead of SMTP?
>
> The concerns are
>
> - you're breaking up the tight coupling between the SMTP server (Postfix) and 
> the client (fetchmail), so...
>
> - that you won't notice from fetchmail's end if the Postfix service goes down 
> (which it doesn't ever do for me, Postfix is one of the nicer things in 
> software) because the sendmail command should always be able to enqueue the 
> message, even after "postfix stop", but they won't get delivered

Thanks for the clarification.  In that case, I'll setup postfix to listen 
on port 25 for fetchmail and port 587 for alpine.  That way I should be 
able to configure different restrictions based on the port.