From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/59749 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Connecting to imap INBOX fails on one out of three servers Date: Tue, 08 Feb 2005 16:47:49 +0100 Message-ID: References: <87wttj7ttt.fsf@denkblock.local> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1107877691 15507 80.91.229.2 (8 Feb 2005 15:48:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2005 15:48:11 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M8290@lists.math.uh.edu Tue Feb 08 16:48:11 2005 Original-Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by ciao.gmane.org with esmtp (Exim 4.43) id 1CyXaf-0008CR-4u for ding-account@gmane.org; Tue, 08 Feb 2005 16:47:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1CyXbq-0006KK-00; Tue, 08 Feb 2005 09:49:02 -0600 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1CyXbm-0006KF-00 for ding@lists.math.uh.edu; Tue, 08 Feb 2005 09:48:58 -0600 Original-Received: from quimby.gnus.org ([80.91.224.244]) by util2.math.uh.edu with esmtp (Exim 4.30) id 1CyXbf-0007WW-3D for ding@lists.math.uh.edu; Tue, 08 Feb 2005 09:48:51 -0600 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1CyXbR-00056k-00 for ; Tue, 08 Feb 2005 16:48:39 +0100 Original-Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j18Flqej013993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Feb 2005 16:48:20 +0100 Original-To: "E. Oltmanns" OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050208:ding@gnus.org::MctiHZCMcG0BwAhw:D6gE X-Hashcash: 1:21:050208:oltmanns@uni-bonn.de::wUM9xFwBWFdrWPAH:Wyhd In-Reply-To: <87wttj7ttt.fsf@denkblock.local> (E. Oltmanns's message of "Tue, 08 Feb 2005 00:56:30 +0000") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yxa-iv X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: -4.9 (----) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu X-MailScanner-From: ding-owner+m8290@lists.math.uh.edu X-MailScanner-To: ding-account@gmane.org Xref: main.gmane.org gmane.emacs.gnus.general:59749 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:59749 "E. Oltmanns" 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.