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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Ulrich Mueller <ulm@gentoo.org> writes:

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

Well that was lucky.

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

Okay, I'll work something up in the next week that goes halfway with
this.

Glad it's partially fixed.

Eric