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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 06/23/19 14:23 PM, Lars Ingebrigtsen wrote:
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>>> Did you get any further in fixing this nnimap parsing bug?
>>>
>>> Here's a whack at it. I tried to make sure that it would handle unwanted
>>> FETCH responses whether they came before or after (or in the middle of)
>>> the wanted FETCH responses, but I'm not in love with checking the header
>>> regexp this way.
>>
>> Well, I think it's OK...
>>
>>> Because this IMAP server feature is very closely focused on adding a
>>> flag in case of attachment (and because Gnus never explicitly requests
>>> this flag, though I'd sure like to in the future), another more targeted
>>> approach would be to simply delete any lines containing
>>> $Has\(No\)?Attachment, assuming that these FETCH responses will only
>>> take up one line.
>>
>> That sounds a bit brittle -- I'm sure there'll be other extensions like
>> this in the future to the IMAP protocol.
>>
>>> I've configured my local Dovecot with the offending setting, and will
>>> test it out for a bit.
>>
>> Great!
>
> (NB This patch is very broken and no one should use it; I'm still
> working on it. I want a proper parser!)

Turns out the dumb thing was simple: I was testing if the FETCH line was
followed by mail headers by looking for:

"\\(From\\|To\\|Subject\\|Date\\|Message-ID\\)"

Which is obviously insufficient. I've since changed it to:

"\\([A-Z][[:ascii:]-]+: \\)"

Which works better, but also seems susceptible to breakage due to
ignorance. A quick scan doesn't turn up any `mail-header-regexp'
variables or `this-is-a-mail-header-p' functions -- does the above
regexp seem reasonable?