Red Hat Bugzilla – Bug 167574
enable/disable imap4 back end
Last modified: 2007-11-30 17:11:13 EST
I used to complain about the fact that Evolution's IMAP back end would sometimes
go off into the weeds for minutes at a time, checking for new mail in all
folders. And that it would insist on fetching headers for new mail in all new
folders after you disconnect and reconnect it.
Having updated to rawhide and tried the new back end, however, I long for the
old one. Upon starting it up, it seems to be fetching all headers for all mails
in _all_ folders. After half an hour, I gave up and killed it. It's difficult to
tell precisely what it was doing, however, because the output with
CAMEL_VERBOSE_DEBUG is no longer very informative. It _used_ to be the only
thing which let me know what Evo was doing when the GUI was failing to respond.
The new back end also seems to ask for an IMAP password even though the server
Are these problem still occurring in the latest rawhide pckages?
If so, any idea which version brought about the regression? Were you updating
daily to rawhide?
Will try again shortly.
The misnamed 'IMAP4rev1' mailstore type still seems to be behaving the same way.
I clicked on a mail in my INBOX, and it hasn't showed it to me yet; it seems to
be fetching _all_ headers in _all_ folders before it fetches the mail I wanted.
It did eventually show me the mail, and then went on trawling through other
folders. Then it segfaulted.
I'd recommend either disabling the 'IMAP4rev1' back end, or at least renaming it
to something more appropriate, like 'Experimental new IMAP client code'.
I disagree with disabling it, which appears to have occurred in FC5.
The "normal" IMAP code makes evolution accessing my GroupWise 6.5 (and it is NOT
I had very few issues with the same setup with the IMAP4rev1 code in Fedora Core
4. This is a regression to not at least provide the option of selecting the old
I am rebuilding eds with imap4 enabled, and will test. If it works for me, I
will file a bug requesting reenabling of it.
Rebuilt, enabled it, and tested. Works.
Evolution, with the "normal" IMAP in my setup, will segfault on one out of
approx. every fifty messages.
I understand that this backend is not as fast, or as tested as the older one. At
least it works for me, which is more than I can say for the only one enabled in
Amusingly, the 'imap' back end has developed exactly the same problem which
caused us to disable 'imap4' as totally broken -- that's bug #183219.
However, the advice from upstream (from Karsten BrÃ¤ckelmann) is that we probably
shouldn't re-enable this. There are other bugs, and people would like to disable
it upstream too. See these GNOME bugs...
The alternate IMAP backends were disabled long ago, so I'm closing this.