After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 324118 - Remove IMAP4rev1 from stable releases.
Remove IMAP4rev1 from stable releases.
Product: evolution
Classification: Applications
Component: Mailer
2.8.x (obsolete)
Other All
: High major
: ---
Assigned To: Harish Krishnaswamy
Evolution QA team
Depends on:
Blocks: 327508 327510
Reported: 2005-12-14 20:56 UTC by Alexander “weej” Jones
Modified: 2013-09-13 00:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12

Description Alexander “weej” Jones 2005-12-14 20:56:19 UTC
Difference? Some elaboration would be nice when creating/editing a mail account.

Maybe call the second "IMAP 4 rev. 1" and the first "IMAP X" where X is whatever
version it's supposed to be.

I don't know which one is the more modern/better/recommended and personally I am

As far as I can tell, IMAP4rev1 support is rubbish. It doesn't mark any emails
as "read" which drives me up the wall - but that's another bug maybe.

Other information:
*** This bug report was brought to you by my "Getting Linux un-fucked"
bug-filing rampage. Sorry if it seems stupid or offends. ***
Comment 1 André Klapper 2005-12-15 13:20:52 UTC
no, you're right. IMAP4rev1 should not have become part of the stable release.
it's experimental.
Comment 2 André Klapper 2005-12-15 14:00:29 UTC
good evening harish, good evening partha.
i'd like to see this discussed. now.

when will IMAP4rev1 be removed from the "normal" build?

both of you can imagine how many times i have written "do not use imap4rev1,
it's experimental" at bugzilla now?
it just sucks currently, i could spend that time on more useful things if it
would simply be removed. i'm spending too much time on stuff that just has no
development at all - answering imap4rev1 crashes in bugzilla is one of them.

if it's experimental, then it's experimental.
if evolution does not support some stuff, it does not support some stuff.
that's we way it goes. we can't have everything.

leave it optional with a configure flag for people compiling on their own, but
please don't waste my time anymore with answering IMAP4rev1 questions.
thanks in advance.

(i'm ranting too often within the last days, damn.)

PS: alex: sorry for kidnapping your bug report. :-)
Comment 3 Alexander “weej” Jones 2005-12-15 14:13:34 UTC
Any time :P

At least I know for myself now not to use it!
Comment 4 Karsten Bräckelmann 2005-12-15 14:32:21 UTC

The experimental and pretty-much unssupported/unmaintained IMAP4rev1 Account
Type needs to be *removed* from the default build. Make it optional again, like
it used to be.

Note: As this one went live before, Evo *must* provide some way to either
automatically or (easily) maually migrate from IMAP4rev1 to the stable IMAP

See e-h for a dead discussion about this, some months ago.
Comment 5 Karsten Bräckelmann 2005-12-15 14:35:43 UTC
Alex, since you asked:

Both Mail Account Types IMAP and IMAP4rev1 basically use the IMAP4rev1
*protocol*, IIRC. At least, both are definitely IMAP4.

IMAP (as in the account type) is stable and should be preferred. The account
type IMAP4rev1 should never have been enabled by default in stable releases, IMHO.
Comment 6 Karsten Bräckelmann 2005-12-15 14:39:20 UTC
FWIW, this is the thread I was talking about:

(Please note, there are a few more responses than obvious in the month view by a
quick glimpse. That's what you get for using shitty clients that break proper
In-Reply-To and References headers. GAR)
Comment 7 Karsten Bräckelmann 2005-12-15 15:07:17 UTC
Additional note:

Coincidentally I just came across a user on IRC, who couldn't switch from
IMAP4rev1 to IMAP providers. Evo kept sitting in the "Loading" state, even after
restarting Evo.

I don't remember, if anyone successfully just *switched* account types.

To solve this, creating a new "IMAP" account was necessary. Dunno, if there are
some issues in the backends that effectively prohib switching. This needs to be
addressed, too.
Comment 8 parthasarathi susarla 2005-12-16 06:25:53 UTC
Hey Alex, Andre, Guenther,
IMAP4 rev 1 is going, soon. We have not removed it altogether since moving the
users is not quite straight forward. And thats the reason for the problem
mentioned by Guenther on Comment #7 

The IMAP is IMAP4 compliant currently. So theoritically there is not much a
differnce between both the implementations in Evolution today. The only major
difference is the support for namspaces whcih 'IMAP 4 rev 1' has complete
support. And the IMAP implementation (in Evo) does not support it fully, as per
the RFC. Shreyas is actually adding the support for namspaces in the IMAP
provider. So the only hitch which remains is the migration from IMAP 4 rev1 to IMAP.
Comment 9 Shreyas Srinivasan 2005-12-16 07:40:35 UTC
Hmmm.. Maybe its worthwhile to write migration support first and then implement
Namespaces. We dont want people using it <peroid>

Partha have you looked at how hard it is to write migration code from 'imap 4
rev1' (evo protocol) to imap. 
Comment 10 Karsten Bräckelmann 2006-01-18 01:00:38 UTC
*poke* :)
Comment 11 Srinivasa Ragavan 2006-01-26 19:05:44 UTC
Im not sure how this came under UI. It has to do with mailer and backends.

removing the keyword.
Comment 12 Karsten Bräckelmann 2006-03-27 23:52:45 UTC
OK, so we missed this Milestone. Punting.

This still is a serious issue, and should be corrected ASAP.
Comment 13 Harish Krishnaswamy 2006-04-21 08:19:37 UTC
The issue of an existing amorphous user base for IMAP4rev1, the necessity of providing a migration path or the likelihood of renewed hacking love for the provider have all been in limbo all these months.  I would like to propose for one more time (hopefully, final) - 
* to take IMAP4rev1 off the builds.
* not make the migration code a blocker, since it was 'experimental' all the while anyway
* add/test the support for namespaces in IMAP to address the need why some people opt to use IMAP4rev1. Get this in our roadmap but not wait on this to  remove the provider.

partha/sankar/fejj : thoughts ?
Comment 14 Jeffrey Stedfast 2006-04-21 14:00:28 UTC
sounds good to me, sad to see imap4 go but it's not worth trying to maintaining 2 imap providers.
Comment 15 Alexander “weej” Jones 2006-06-04 23:40:08 UTC
Unmarking NEEDINFO... I don't have any more info to provide!
Comment 16 André Klapper 2006-07-11 15:25:36 UTC
what's up, guys?
Comment 17 André Klapper 2006-07-11 21:47:31 UTC
what's up, guys?
Comment 18 Constantine Evans 2006-08-12 14:12:31 UTC
Sorry for the additional spam, but is anyone working on this?
Comment 19 André Klapper 2006-08-22 21:44:39 UTC
seems the answer is "no".

harish, srini: this sucks.
Comment 20 Alexander “weej” Jones 2006-08-22 21:58:49 UTC
Crap, wish I never reported this. Seems the emails just keep on coming in about it. :P

What's the holdup?
Comment 21 André Klapper 2006-08-23 00:04:08 UTC
alex: hehehe :-)
guess the problem is that we also need to provide a well-tested fallback migration so people can easily migrate from imap4rev1 back to plain imap, which could be a tricky task.
Comment 22 Alexander “weej” Jones 2006-08-23 00:09:19 UTC
Why do you even need to migrate an account type?

Isn't the whole point of IMAP that the mail remains on a remote server? What exactly do you need to "migrate"?
Comment 23 André Klapper 2006-08-23 07:34:44 UTC
we need to migrate the account settings, e.g. imap4rev1 supports multiple namespaces while imap does not, if i remember correctly.
Comment 24 Jeffrey Stedfast 2006-08-23 15:09:41 UTC
I'm not sure really how badly things really need to be "migrated", how many people really use imap4rev1 now? I doubt many.

the longer we keep imap4 available, the more people will start using it/depending on it which means the more needed migration will be. if this had been dropped asap, we probably could have gotten away without migrating at all.

I kinda think the best approach to this is to remove imap4 now and see how many people really need migration. if we find it's a problem, then we can write migration code, but seeing as how no one is actively writing it now anyway and we keep telling users who mention they are using imap4 to switch back to imap, we aren't going to be causing any additional harm by simply removing it.
Comment 25 Constantine Evans 2006-08-24 11:24:10 UTC
For the time being, since nothing seems to be happening to resolve this, can we at least get IMAP4rev1 removed from the new account creation options, and something added to the documentation about the situation? It is rather hard to explain to users why a supposedly mature product has an experimental and broken option like this with *no warning anywhere in the documentation*.
Comment 26 Harish Krishnaswamy 2006-08-29 11:40:43 UTC
Reassigning this to myself to get this removed in time for the release.
Mailer guys - I am requesting a freeze break approval for the removal unless I hear an objection from you.
Comment 27 Veerapuram Varadhan 2006-08-30 09:26:32 UTC
I have no objection to remove it from the build and lets evaluate how many users really want a *migration* fix.
Comment 28 Harish Krishnaswamy 2006-09-04 08:13:10 UTC
Patch committed to the CVS after approval from the release team. Resolving the bug as fixed.
Comment 29 agilmore 2006-10-17 06:17:52 UTC
I'll weigh in as one of those (happy) IMAP4 users.

For me, the current regular IMAP provider crashes regularly connecting to my Groupwise 6.5 IMAP server. The IMAP4rev1 provider does not. This has been consistent for years.

I'm willing to continue to rebuild my rpms everytime an upgrade comes out, but please do not completely remove this!
Comment 30 André Klapper 2006-10-17 09:59:37 UTC
the patch that has been applied for evolution 2.8 makes the IMAP4rev1 provider a conditional feature which is turned off by default.
however, it is not removed from the codebase.
Comment 31 agilmore 2006-10-17 13:59:57 UTC

I was referring to fejj's note:

"I kinda think the best approach to this is to remove imap4 now and see how many
people really need migration. if we find it's a problem, then we can write
migration code, but seeing as how no one is actively writing it now anyway and
we keep telling users who mention they are using imap4 to switch back to imap,"

Migration would not help me, since the regular IMAP provider core dumps when presented with slightly misformed IMAP messages. This is a longstanding bug, the solution to which is apparently to upgrade the server. Since my server is stuck on Groupwise 6.5, and out of my control, this doesn't help.

I know I still had issues with this in EDS 1.6. I'll reserver judgement on 1.8 until I get a chance to run it. FC6 is out today, no? :)

So, I again plead to not remove IMAP4 until and unless the IMAP provider is known working with GW 6.5.

Hopefully this makes a bit more sense.