GNOME Bugzilla – Bug 645332
imapx cannot cope with broken Domino IMAP server
Last modified: 2014-11-19 13:13:26 UTC
The Lotus Domino IMAP server is broken; it lies to us about the size of a 'literal' in the IMAP protocol. A 'literal' tells us to suspend the IMAP protocol handling, and just suck up a certain number of bytes of data. But the Domino IMAP server actually sends fewer bytes than it claimed. So it switches back to talking IMAP and gives us the command completion, while we're still waiting for the appropriate amount of data to arrive. We don't see its command completion, because we're still just sucking bytes into the buffer. This server is completely broken, but it would be nice if we could cope with it a little better. The imapx back end fetches messages in 20KiB chunks instead of all-as-once, to improve responsiveness — it means we can insert other user-triggered requests 'between' the chunks being fetched, and it dramatically improves responsiveness by effectively download the message in the 'background' rather than blocking the connections. Simpler clients, including the old IMAP back end in Evolution, will just get the whole message in one go, and don't seem to trigger this bug in the Domino IMAP server. We need to: 1. Add a configuration option to disable the multi-part fetch. 2. Detect and handle the 'timeout' condition when the server has failed to send the amount of data it promised. 3. When the condition in #2 happens, we should ideally look at the end of the received data and see if it looks like an IMAP command completion. If it does, show the user an appropriate error message about their server being broken, and enable the option added by #1.
Created attachment 183868 [details] [review] Pach to make multipart fetch optional [PATCH] Bug 645332 (part 1): Make multipart fetch optional in imapx I'm not particularly happy about this being a 'disable multipart fetch' option, instead of 'enable multipart fetch'. But as far as I can tell, this is the only way to make it do the right thing for existing accounts when Evolution gets upgraded.
Created attachment 183875 [details] [review] Add error string for bogus FETCH response [PATCH] Bug 645332 (part 2): Add error message for bogus FETCH response I'm not brave enough to try to actually detect this at the 11th hour before the 3.0 code freeze. But put the translatable string in place, so we can do it in 3.0.1 without getting shot for changing strings *again*.
As implied by the patch in comment 2, items #2 and #3 in my original suggestions are too intrusive for me to want to do them late on a Sunday night, the day before the final code freeze. But perhaps it's worth putting the error string in place already, so that we can implement this at our leisure and get it in to 3.0.1? I still hate the wording of all the strings I've just added; suggestions welcome.
(In reply to comment #1) My opinion is that people will not understand much such option. I mean regular users. Let your mother setup all the strange options in IMAPx preferences. She'll get lost pretty quickly, unless she has an overview of IMAP protocol internals/features. Workarounding bug is usually done either by detecting "this is that bad server" or by an environment variable. It used to be done this way till now, at least. (In reply to comment #2) > Created an attachment (id=183875) [details] [review] > Add error string for bogus FETCH response Well, the new string, even not technically used, is not marked for translation, which is an opposite of the comment above it.
By the way, were domino server developers informed about bug in their code? If so, do you have a link to their bugzilla, mailing-list or anything? Just to have a reference for later, to check when the actual bug in someone else code was fixed.
Any idea if Lotus Domino servers are still broken in this way? If not, I'm not sure it's worth hacking around at this point.
I'm closing this for now, but feel free to reopen. There was done no code change on the IMAPx side.