GNOME Bugzilla – Bug 317830
Explain "POP extensions" and possibly add warning
Last modified: 2011-08-24 13:42:09 UTC
Please describe the problem: After upgrading from Evolution 1.0.2(?) to 2.0.2 as distributed in Red Hat Enterprise release 4, I found that the program hung after downloading always exactly two emails from my POP account. It would continue after clicking CANCEL and then hitting F9 or the SEND/RECEIVE button again, which could be repeated until all the mail was downloaded. Clearing out the .gconf entries, reconfiguring from a fresh start, etc. did not help. WORKAROUND: With a friend, I discovered by accident that clicking the item "Disable support for all POP3 extensions" in the "Receiving Options" dialog in the account editor made the problem go away. I consider this is a bug because there is no documentation what a POP3 extension is or why it is enabled by default, or why it would make the program hang instead of producing an error message when left on. Steps to reproduce: 1. Set up POP account as usual, accepting default POP3 extensions. 2. Try to download multiple emails from a POP2 account. Actual results: Program hangs forever with the download progress bar showing. Exactly two emails are downloaded. No error messages are produced. Expected results: Download all emails. Does this happen every time? Yes--but see workaround described above. Other information:
Does this happen even with the latest versions of evolution, ie, evolution-2.4.x?
hi reeke, Thanks for the bug report. This is actually not a bug though. Since the 'WORKAROUND' you suggested itself is the way you can resolve it. Some POP mail servers do not support all POP extensions. And thats the reason for the option (in Receiving options). Ofcourse, i agree though it should not hang. But there is no way really to know if the server supports all POP extensions or not. Thanks.
(1) Re: does it happen with 2.4.x? I am using the RedHat Enterprise up2date mechanism and they have not yet provided 2.4.x. I will try to find time to download this independently and try it, but I can't promise. (2) OK on "not really a bug". So maybe we could convert this into a request for a little more documentation: (a) what is a POP3 extension? what features you stand to lose when turning them off, (b) warning that leaving them on may cause evolution to hang with some servers, and (c) if that happens, how to turn it off. This would have saved me several weeks of very slow downloads.
reopening as there is an answer :-)
so this bug is about the documentation.
*** Bug 389147 has been marked as a duplicate of this bug. ***
Hello, I too have been hit with this problem. I happened upon this page by accident. I did not know what POP3 extensions were at the start of troubleshooting this problem. After a complete update then an upgrade distro, on one of the boxes. The error was still occurring. I clicked on the disable pop3 extensions and poof all the mail comes in. That’s how I got here, now here is what I found out on the way. I have 5 ubuntu machines that all got the error after a mail server upgrade. I see the statement in comment 2, "Some POP mail servers do not support all POP extensions." I too thought it was a server problem. But I have no other machines having this problem and I cannot duplicate this on any other machine. I even did the fetch mail process by hand on the problem machines, the error did not occur. After running evolution with debug information and digging in the source code. I find the following. (Attached example log - CAMEL_DEBUG=all evolution >& evo.log) On line 298, in camel-pop3-engine.c there is a switch statement, that starts a check for [+] or [-] and a default with an error. For reference, [code] switch (p[0]) { case '+': dd(printf("Got + response\n")); if (pc->flags & CAMEL_POP3_COMMAND_MULTI) { pc->state = CAMEL_POP3_COMMAND_DATA; camel_pop3_stream_set_mode(pe->stream, CAMEL_POP3_STREAM_DATA); if (pc->func) pc->func(pe, pe->stream, pc->func_data); /* Make sure we get all data before going back to command mode */ while (camel_pop3_stream_getd(pe->stream, &p, &len) > 0) ; camel_pop3_stream_set_mode(pe->stream, CAMEL_POP3_STREAM_LINE); } else { pc->state = CAMEL_POP3_COMMAND_OK; } break; case '-': pc->state = CAMEL_POP3_COMMAND_ERR; break; default: /* what do we do now? f'knows! */ g_warning("Bad server response: %s\n", p); pc->state = CAMEL_POP3_COMMAND_ERR; break; } [/code] In this hang problem it is being caught at "default", eventually timing out with an error similar to: (evolution:4627): camel-pop3-provider-WARNING **: Bad server response: n MIME format.+OK Message 1 marked In the debug, we find something like this, POP3_STREAM_LINE(29): 'E format.+OK Message 1 marked' I see the code looking for the first letter of the server response to be a [+] or [-] for some reason the last server response (or variable/object p) contains extra data. This 'E format.+OK Message 1 marked' should really be 'E format.' and '+OK Message 1 marked'. Where the 'E format.'part came from is the big question. I don’t know enough about the source know where to look to see how [p] gets the data and what determines its size. This is as far as I have gotten, as I do not have a machine set up to compile and since the error is being machine picky, I would have to run it on the problem machine. I am looking in to maybe trying to clone one of the machines, but not sure if that would work either. I have tried dumping the package list and then installing all packages to match but that also did not reproduce the problem. I also tried setting up a new user, that user also inherited the problem, so that eliminated a per user settings issue. Since the problem can be prevented by disabling the POP3 extensions, I’ve mostly stopped looking at network, switches and the like. Anyone have other ideas? For the moment the machines are working so this problem is not as big as it once was, but for support of the pop3 extensions and the advantages of using it. A better solution could be useful. If there is more information I could possibly provide please ask away. Thanks for your time. Terre Attached: machine_info.txt and evolog_snip.txt
Created attachment 83410 [details] evolutions log snip
Created attachment 83411 [details] machine info helpful maybe?
Bumping version to a stable release.
I am lazy, hence I committed this: http://git.gnome.org/browse/evolution/commit/?id=d8999c79baa0385e1234eaa114b384cfef1d745f Okay to close?
Looks OK by me, thanks. George Reeke
I have also fixed this in the new topic-based, Mallard formatted user docs for Evolution version 3.1.90: http://git.gnome.org/browse/evolution/commit/?id=f67ba3c152d5d396c005adfc1576e8392d4033e3 Closing as FIXED.