Re: ProtonMail Bridge Patch

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Jakub Ječmínek <kuba@kubajecminek.cz> writes:

> Hello,
> I'm not sure if this is the correct place to post this but I wish there
> was this information somewhere like a week ago.
>
> I recently switched my mail provider to ProtonMail which lets you use
> IMAP/SMTP protocol only if you run something called ProtonMail Bridge on
> your machine. This software basically acts as a local IMAP/SMTP server
> and communicates with the upstream servers in a secured fashion (or at
> least this is the rationale).
>
> The problem is that Gnus and Gluon - IMAP server embedded inside
> ProtonMail Bridge - doesn't work well together. Gnus (nnimap back end)
> was acting like a lunatic and it took me a while before I found the real
> reason for its behaviour.
>
> Gnus expects that the messages are returned from a FETCH request in a
> ascending (predictable?) order but Gluon responds each time
> differently. Example communication might look like this:
>
> Gnus: FETCH 1:3 ...
> Gluon: * 3 RESPONSE ...
> Gluon: * 1 RESPONSE ...
> Gluon: * 2 RESPONSE ...

> This is apparently a valid response according to RFC 3501.

Thanks a lot for this note! I'm glad you found a solution, but if
out-of-order FETCH UIDs are valid according to the RFC, Gnus should also
handle that.

I assume the problem is in `nnimap-transform-headers'? Nothing in there
jumps out at me immediately. Or maybe the problem is that the function
doesn't sort the parsed headers, and Gnus' next step expects the headers
to be in sorted order?

Thanks
Eric