[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: |
Ulrich Mueller |
Subject: |
bug#35443: 27.0.50; Gnus (nnimap) shows "ghost" messages in summary buffer |
Date: |
Thu, 09 May 2019 21:03:38 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>>>>> 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?