From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/64664 Path: news.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap vs dbmail Date: Wed, 23 May 2007 16:40:03 +0200 Message-ID: <87hcq34n98.fsf@mocca.josefsson.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179924129 12331 80.91.229.12 (23 May 2007 12:42:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 23 May 2007 12:42:09 +0000 (UTC) Cc: ding@gnus.org To: James Cloos Original-X-From: ding-owner+M13175@lists.math.uh.edu Wed May 23 14:42:01 2007 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1HqqAD-0002l1-8J for ding-account@gmane.org; Wed, 23 May 2007 14:42:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Hqq8h-0004zv-Co; Wed, 23 May 2007 07:40:27 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Hqq8e-0004ze-9M for ding@lists.math.uh.edu; Wed, 23 May 2007 07:40:24 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.67) (envelope-from ) id 1Hqq8X-000361-R6 for ding@lists.math.uh.edu; Wed, 23 May 2007 07:40:24 -0500 Original-Received: from vinyl.extundo.com ([83.241.192.59]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Hqq8W-00084c-00 for ; Wed, 23 May 2007 14:40:16 +0200 Original-Received: from mocca.josefsson.org ([83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4NCe3w9013151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 May 2007 14:40:10 +0200 OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Mail-Copies-To: nobody X-Hashcash: 1:22:070523:ding@gnus.org::Z6N71rmH1muOPZCc:1lEZ X-Hashcash: 1:22:070523:cloos@jhcloos.com::wl6G730gnrjsCLyv:8b5F In-Reply-To: (James Cloos's message of "Thu\, 17 May 2007 07\:33\:51 -0400") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:64664 Archived-At: James Cloos writes: > I'm looking into converting over to using imap as the backstore for my > mail and am looking at using dbmail for that. > > I'm seeing some buglets in nnimap. > > As an example, the unread article counts in the Group buffer are almost > always incorrect. And errors often get printed to the minibuffer. > > One issue is that dbmail gives each article a server-unique UID rather > than a just user-unique or folder-unique. So they are never contiguous. > nnimap seems to expect contiguous UIDs and goes searching for them, > causing IMAP errors. Actually, it is Gnus that assumes contiguous article numbers. When there are "holes" in the ranges, the Group buffer unread article count estimate (yes, it is documented as an estimate) will be wrong. This happens for nntp, nnml etc too. > ,----< 155 UID FETCH 3665,3667 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)]) > > | 155 BAD invalid message range specified > `---- > > So why fetch 3665 and 3667 if they were not listed in any of the UID > searches? They may be UNSEEN DELETED, but I agree that it should be able to figure out that these do not exist. I suspect that the reason nnimap asked about this is that Gnus asked about those articles. Running Gnus and nnimap under edebug will help to understand why information about those articles are requested. > > ,----< 156 UID FETCH 3665,3667 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)]) > > | 156 BAD invalid message range specified > `---- > > Twice, even. Huh, that's weird. It might indicate that something non-normal (i.e., a bug) is happening. > ,----< 157 UID STORE 3665,3667 +FLAGS (\Seen) > > | 157 BAD invalid message range specified > `---- > > And dbmail doesn't like storing flags for non-extant UIDs. RFC 3501 says: 6.4.8. UID Command ... A non-existent unique identifier is ignored without any error message generated. Thus, it is possible for a UID FETCH command to return an OK without any data or a UID COPY or UID STORE to return an OK without performing any operations. I'd say this is a dbmail bug. > This time the errors did not prevent me from seeing new mail, but that > isn't always the case. Some new mail is inaccessible in gnus because of > such errors. A test shows that one of those errors is probably due to > this line in list/imap.el: > > ,----[ from gnus/lisp/imap.el (imap-parse-body) ] > | (assert (eq (char-after) ?\)) nil "In imap-parse-body") > `---- > > Are those (assert)s necessary? They effectively lose mail. Can you quote the content of the ' *nnimap* foo' buffer when that happens? Alternatively, try '(setq imap-log t)' and quote the contents from *imap-log* related to that parse assertion. The reason for the assert is that imap.el cannot parse what the server is sending. I think there are only two reasons for that happening: imap.el is buggy or the server is buggy. The effects of either will be that it appears as if a message is missing (or even worse consequences). I'm not sure what could be done to avoid this. /Simon