Bug 167574 - enable/disable imap4 back end
enable/disable imap4 back end
Product: Fedora
Classification: Fedora
Component: evolution-data-server (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
Depends On:
  Show dependency treegraph
Reported: 2005-09-05 15:39 EDT by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: Fedora 7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-02 16:04:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 324118 None None None Never

  None (edit)
Description David Woodhouse 2005-09-05 15:39:16 EDT
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
preauthenticated us.
Comment 1 Dave Malcolm 2005-11-08 19:11:06 EST
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?
Comment 2 David Woodhouse 2005-11-08 19:23:32 EST
Will try again shortly.
Comment 3 David Woodhouse 2005-11-20 16:33:02 EST
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. 
Comment 4 David Woodhouse 2005-11-20 16:40:09 EST
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'. 
Comment 6 Andrew Gilmore 2006-03-27 16:09:03 EST
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
upgradable) unusable.
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.
Comment 7 Andrew Gilmore 2006-03-27 17:01:03 EST
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
Comment 8 David Woodhouse 2006-03-27 18:10:48 EST
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...

Comment 10 Matthew Barnes 2007-10-02 16:04:28 EDT
The alternate IMAP backends were disabled long ago, so I'm closing this.

Note You need to log in before you can comment on or make changes to this bug.