From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/30355 Path: main.gmane.org!not-for-mail From: Chris Brierley Newsgroups: gmane.emacs.gnus.general Subject: Re: .authinfo support broken in Gnus 5.8.5? Date: 25 Apr 2000 11:16:15 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: <2n4s8rm16p.fsf@tiger.jia.vnet> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035166905 7999 80.91.224.250 (21 Oct 2002 02:21:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:21:45 +0000 (UTC) Return-Path: Original-Received: from lisa.math.uh.edu (lisa.math.uh.edu [129.7.128.49]) by mailhost.sclp.com (Postfix) with ESMTP id E2A50D051E for ; Tue, 25 Apr 2000 11:16:26 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by lisa.math.uh.edu (8.9.1/8.9.1) with ESMTP id KAB23429; Tue, 25 Apr 2000 10:16:24 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 25 Apr 2000 10:15:43 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id KAA04480 for ; Tue, 25 Apr 2000 10:15:32 -0500 (CDT) Original-Received: from optical.mindstorm.com (optical.mindstorm.com [209.113.156.7]) by mailhost.sclp.com (Postfix) with ESMTP id E4C92D051E for ; Tue, 25 Apr 2000 11:15:47 -0400 (EDT) Original-Received: from OUTLAND.pobox.com (localhost [127.0.0.1]) by optical.mindstorm.com (MindstorM/MindstorM) with ESMTP id LAA29013 for ; Tue, 25 Apr 2000 11:15:48 -0400 Original-To: ding@gnus.org In-Reply-To: Shenghuo ZHU's message of "24 Apr 2000 21:14:38 -0400" Original-Lines: 56 User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.6 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:30355 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:30355 On 2000-04-24, Shenghuo ZHU wrote: > Fixed in the latest CVS version. Please test. Well, it is fixed, but the behavior is still a little weird, IMO. How do I explain this. It seems to me that the purpose of the change to gnus-netrc-machine to add a port parameter was to allow multiple entries in .authinfo for the same machine but a different servers (i.e. nntp or imap). If you *do not* specify a port when you call gnus-netrc-machine it will prefer the first entry from .authinfo which matches the machine and *either* has no port specified or port nntp specified. That is, regardless of whether there is no port or "port nntp", the first machine that matches in the file will be returned. This works fine if you specify your NNTP server with "port nntp" and your IMAP server with no port information. However, if you specify your IMAP server in .authinfo *with* "port imap" (in fact, if you specify any port info other than nntp) gnus-netrc-machine called without a port parameter will never find it. It will prefer an entry with no port information, or port nntp, and if it can't find those it will return nil. This is all probably fine in terms of the way this new functionality is intended for use. The problem here is that nnimap.el does not currently call gnus-netrc-machine with a port parameter. So, if your .authinfo looks something like this: ,----- | machine personal login foobar port imap | machine personal login wubba port nntp `----- ... the entry for IMAP will never be used in the current version of Gnus. This is all a bit funky. Perhaps the best fix is to change nnimap.el to specify a port when it uses gnus-netrc-machine. However, that would *require* users to specify port information for any server other than nntp, as an entry with no port information will not be returned by: (gnus-netrc-machine list machine "imap") Maybe it would be better for the function to only bring port information into play *only* if there is more than one entry which matches the machine. Backends would be required to call gnus-netrc-machine with port information in case there was a collision in the file, but users wouldn't be required to specify the port information unless they had two entries for the same host. Make sense?