Re: IMAP confusion on unexpected EXPUNGE

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