Hello everybody,

just this weekend I investigated gnus' abilities in dealing with
imap. I've got imap accounts on three different servers and, very much
to my (rather unpleasant) surprise, I discovered that everything works
quite well on two of them whereas gnus fails to open the mailbox on
the third one. More precisely, I can connect to the (evil) server in
question and get the list of available groups (folders) including the
number of unseen articles available. After I had figured out that I
obviously can't browse nnimap groups as long as I'm not subscribed,
i.e. in the ephemeral'ish way (on all three servers), I subscribed to
the INBOX successfully on all three servers. Now, the difference is
that I can actually enter the newly generated group on to servers
while trying to enter the INBOX on the third one results in ... well
... nothing much apart from the message "nnimap: Updating info for
nnimap+web.de:INBOX..." and a cpu load of 100%. Since I found some
reports on the web that gnus might behave differently depending on
whether I define a server in the server buffer and subsequently
subscribe to group on it, or whether I add it to
gnus-secondary-select-methods, I tried the later one in
addition. The behaviour now is like this: When starting gnus, it asks
me for authentication data, connects successfully to the server and
hangs with precisely the same message as above. Only when I abort this
"Updating info..." with C-g, gnus skips it and checks the other
backends for new articles. The connection to the imap server is still
open, it's just the group I cannot enter.

Please find below the secondary-select-method as defined in my .gnus:
(setq gnus-secondary-select-methods '((nnimap "web.de"
	(nnimap-server-address "imap.web.de")
	(nnimap-stream tls)
	(nnimap-nov-is-evil t)
 )))

Just in case it might be of any use, here comes the backtrace
generated using debug-on-quit during the "heavily updating group info"
period: