Connecting to imap INBOX fails on one out of three servers

Connecting to imap INBOX fails on one out of three servers

[E. Oltmanns]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

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:

[-- Attachment #2: Backtrace --]
[-- Type: text/plain, Size: 605 bytes --]

Debugger entered--Lisp error: (quit)
  gnus-uncompress-range(((1 . 31822794)))
  nnimap-request-update-info-internal("INBOX" ("nnimap+web.de:INBOX" 3 ((1 . 31822794)) nil "web.de" ((uidvalidity . "1"))) "web.de")
  nnimap-request-group("INBOX" "web.de" t)
  gnus-request-group("nnimap+web.de:INBOX" t)
  gnus-select-newsgroup("nnimap+web.de:INBOX" nil nil)
  gnus-summary-read-group-1("nnimap+web.de:INBOX" nil t nil nil nil)
  gnus-summary-read-group("nnimap+web.de:INBOX" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  call-interactively(gnus-group-select-group)

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]


Moreover, I've produced an imap-log which is rather long so I just
included the statements which seemed most striking to me:

[-- Attachment #4: imap-log --]
[-- Type: text/plain, Size: 1939 bytes --]

Connecting to '217.72.192.135:993'...
Resolving 'imap.web.de'...
[successfully established tls connection]
- Handshake was completed

- Simple Client Mode:

* OK WEB.DE IMAP4-Server
1 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 LITERAL+ UIDPLUS X-NETSCAPE
1 OK CAPABILITY Completed
2 LOGIN "user" "password"
2 OK LOGIN Completed: User logged in
3 STATUS "INBOX" (uidvalidity uidnext unseen)
4 EXAMINE "INBOX"
* STATUS "INBOX" (UIDNEXT 1374000075 UIDVALIDITY 1 UNSEEN 1)
3 OK STATUS Completed
* 1 EXISTS
* OK [UNSEEN 1] Message 1 is first unseen
* OK [PERMANENTFLAGS (\Deleted \Seen \Answered)]
* OK [UIDVALIDITY 1]
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
4 OK [READ-ONLY] EXAMINE Completed
5 FETCH 1,* UID
* 1 FETCH (UID 1374000074)
* 1 FETCH (UID 1374000074)
5 OK FETCH Completed
6 LSUB "" "*%"
* LSUB (\Noinferiors) "/" "INBOX"
* LSUB (\Noinferiors) "/" "Entwurf"
* LSUB (\Noinferiors) "/" "Papierkorb"
* LSUB (\Noinferiors) "/" "Gesendet"
* LSUB (\Noinferiors) "/" "Postausgang"
6 OK LSUB Completed
7 EXAMINE "Postausgang"
* 0 EXISTS
* OK [UNSEEN 0]
* OK [PERMANENTFLAGS (\Deleted \Seen \Answered)]
* OK [UIDVALIDITY 1]
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
7 OK [READ-ONLY] EXAMINE Completed
8 EXAMINE "INBOX"
* 1 EXISTS
* OK [UNSEEN 1] Message 1 is first unseen
* OK [PERMANENTFLAGS (\Deleted \Seen \Answered)]
* OK [UIDVALIDITY 1]
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
8 OK [READ-ONLY] EXAMINE Completed
9 FETCH 1,* UID
* 1 FETCH (UID 1374000074)
* 1 FETCH (UID 1374000074)
9 OK FETCH Completed
[EXAMINE the others successfully (READ_ONLY)]
13 STATUS "INBOX" (uidvalidity uidnext unseen)
* STATUS "INBOX" (UIDNEXT 1374000075 UIDVALIDITY 1 UNSEEN 1)
13 OK STATUS Completed
14 SELECT "INBOX"
* 1 EXISTS
* OK [UNSEEN 1] Message 1 is first unseen
* OK [PERMANENTFLAGS (\Deleted \Seen \Answered)]
* OK [UIDVALIDITY 1]
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
14 OK [READ-WRITE] SELECT Completed

[-- Attachment #5: Type: text/plain, Size: 675 bytes --]


BTW, I consider the appearance of username and password in the output
of imap-log as a rather serious security issue. Perhaps you could give
me a good reason for this behaviour.

Please note that the to other imap servers listed far more
capabilities during session initiation than this one. That's why I
thought that gnus might perhaps deal badly with the lack of a certain
capability by the server. Yet, I can perfectly well connect to this
server and browse the INBOX with other imap clients as, for instance,
mutt.

Please let me know, if you need any further information.

Thank you very much for any tips,

Elias

PS: Gnus v5.10.7, emacs 21.3.1 (debian sarge package)

Re: Connecting to imap INBOX fails on one out of three servers

[Simon Josefsson]

"E. Oltmanns" <oltmanns@uni-bonn.de> writes:

> ... nothing much apart from the message "nnimap: Updating info for
> nnimap+web.de:INBOX..." and a cpu load of 100%.

How long did you wait?  I think it will work eventually.

> Debugger entered--Lisp error: (quit)
>   gnus-uncompress-range(((1 . 31822794)))
>   nnimap-request-update-info-internal("INBOX" ("nnimap+web.de:INBOX" 3 ((1 . 31822794)) nil "web.de" ((uidvalidity . "1"))) "web.de")

Sadly, Gnus does not like the large article numbers used by this
server, it will be slow.  It could be improved, but I'm not aware of
anyone working on this.

> BTW, I consider the appearance of username and password in the output
> of imap-log as a rather serious security issue. Perhaps you could give
> me a good reason for this behaviour.

Imap-log is disabled by default.  I've fixed the docstring, it now
reads:

 If non-nil, a imap session trace is placed in *imap-log* buffer.
 Note that username, passwords and other privacy sensitive
 information (such as e-mail) may be stored in the *imap-log*
 buffer.  It is not written to disk, however.  Do not enable this
 variable unless you are comfortable with that.

> Please note that the to other imap servers listed far more
> capabilities during session initiation than this one. That's why I
> thought that gnus might perhaps deal badly with the lack of a certain
> capability by the server.

No, it is likely only because the server uses article ranges with
large "holes", which make Gnus inefficient.