[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35443: 27.0.50; Gnus (nnimap) shows "ghost" messages in summary buff
From: |
Eric Abrahamsen |
Subject: |
bug#35443: 27.0.50; Gnus (nnimap) shows "ghost" messages in summary buffer |
Date: |
Thu, 09 May 2019 13:15:00 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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