bug#35443: 27.0.50; Gnus (nnimap) shows "ghost" messages in summary buffer

[Ulrich Mueller <ulm@gentoo.org>]

>>>>> On Thu, 09 May 2019, Eric Abrahamsen wrote:

> Okay, here's what I was told on irc:

> <tss> looks like it's the new feature that adds $HasAttachment or
>       $HasNoAttachment flags to mails. they're actually supposed to be added
>       only during mail delivery, and there's a setting needed to enable them:
>       mail_attachment_detection_options = add-flags-on-save
> <tss> but .. there's an "unintentional feature" :) that they also get added
>       during some FETCH commands if they're not already there
> <tss> but even without this, imap protocol allows sending FETCH FLAGS updates
>       (or any updates really) as a response to any command. and with
>       concurrent imap access dovecot does this.
> <tss> for example if another client adds a \Seen flag, that same thing could
>       happen
> <jkt> either way, a client should really be able to process these
>       "unexpeceted" FETCH updates, that's what the standard is about
> --8<---------------cut here---------------end--------------->8---

> Ultimately, the "real" fix would be to teach Gnus to handle all possible
> responses from IMAP servers, probably using a proper parser.

> But if you have access to the dovecot config in your case, you might try
> removing the mail_attachment_detection_options setting above, if it's
> set. If it's not set, then you might be getting the "unintentional
> feature".

Thank you very much for your help. Indeed the add-flags-on-save option
was enabled in the config file. Gentoo's infrastructure team has agreed
to disable it for now, which made the problem go away.

> I suppose in the interim I could mess with `nnimap-transform-headers'
> and try to add some bookkeeping so that multiple FETCH responses for
> the same article UID get merged together. On the other hand, this
> feature only seems to relate to has/hasnoattachment flags, which Gnus
> doesn't handle anyway -- we could safely drop those lines altogether.

> (Though it sure would be nice to handle hasattachment flags, that's
> something that users have requested in the past...)

Maybe drop the extra FETCH responses for now, and add proper bookkeeping
later when implementing the requested feature?