Re: [Evolution] Error fetching message info: unknown body response

[Milan Crha <mcrha redhat com>]

        Hi,

On Mon, 2018-11-05 at 23:19 -0500, Josh wrote:
> 1. Retrieve emails from IMAP server to the best extend possible, for
> the 
> maximum user's benefits.
> or
> 2. Report bugs in IMAP server and completely discard user needs if a
> bug 
> is found.

well, maybe if you can answer me this simple question:

What are RFCs and (Internet) standards good for?

And one more question:

If the software claims to conform to certain RFC, but in reality it
doesn't, is it better to left the software broken and ask every single
piece of software which can talk to the broken software to add a
workaround just for that single issue?

Yes, camel library has workarounds for some servers. Workarounds, which
are maintainable. Add code complexity or increase bandwidth usage just
because one server misbehaves on certain message for whatever reason
doesn't sound like something from which would all users benefit.

It seems you do not understand the underlying problem. I'll try to make
it simpler, because the IMAP protocol is a complex thing. It's like
this:

Client: give me headers and flags for message 1 to 3
Server: message 1: flags () headers {10}
        1234567890
        message 2: flags () headers {100}
        message 3: flags () headers {10}
        1234567890
        OK that's all

The number in {} means how many following bytes is the value for the
headers. The first message says it's 10 bytes, which follow on the next
line. The second message says it's 100 bytes, but nothing follows. The
third message says it's 10 bytes, which follow on the next line. The
thing is those 100 bytes cannot be interpreted by the IMAP response
parser. Those are just raw bytes returned by the server. That means the
IMAP parser attempts to read those 100 bytes and it expects to have
them followed according to the IMAP RFC. As the server failed to follow
the RFC, the response is broken. Those 100 bytes can end in the middle
of an unrelated response. Or even worse, just at the end of the next
headers, which would look like it's perfectly valid response and you'd
miss some messages.

There are failures which can be handled and there are failures which
cannot. This particular one, as simplified above, is one of those which
cannot be recovered from. There can be used other methods how to get to
the information about the messages, but as said above, it has side
effects, like higher bandwidth usage, like in case if it would always
download  whole message. It might not look like a problem for you, but
imagine a message with 10MB attachment, which you'd filter to a
different folder on the client side and you download it completely just
to trash it with the move operation (move can be done on the server,
when it supports the extension, or it can be copied&deleted, both
without having downloaded whole message completely). That's not what
all users want for sure.

Again, either you fix a problem at the place where the problem is, or
you add workarounds everywhere else. What is better? What is better for
everyone, not only for certain part of the affected group?

        Bye,
        Milan