From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5647 Path: main.gmane.org!not-for-mail From: gsstark@MIT.EDU (Greg Stark) Newsgroups: gmane.emacs.gnus.general Subject: Re: how to do authinfo for only one group? Date: 21 Mar 1996 15:10:10 -0500 Organization: Massachvsetts Institvte of Technology Sender: gsstark@fierce-bad-rabbit.MIT.EDU Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146220 922 80.91.224.250 (20 Oct 2002 20:37:00 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:37:00 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.3/8.6.9) with SMTP id MAA23846 for ; Thu, 21 Mar 1996 12:56:47 -0800 Original-Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id ; Thu, 21 Mar 1996 21:10:37 +0100 Original-Received: from FIERCE-BAD-RABBIT.MIT.EDU by MIT.EDU with SMTP id AA16424; Thu, 21 Mar 96 15:09:43 EST Original-Received: by fierce-bad-rabbit.MIT.EDU (5.57/4.7) id AA16473; Thu, 21 Mar 96 15:10:20 -0500 Original-To: larsi@ifi.uio.no (Lars Magne Ingebrigtsen) In-Reply-To: larsi@ifi.uio.no's message of 21 Mar 1996 19:12:28 +0100 Original-Lines: 39 X-Mailer: September Gnus v0.51/Emacs 19.30 Xref: main.gmane.org gmane.emacs.gnus.general:5647 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5647 Well, it's clear what is intended, i'm not sure how to make Gnus do this, but your server should probably follow this, aS well as supporting the common practice of allowing the client to authenticate immediately after the start of the session. When authorization is required, the server will send a 480 response requesting authorization from the client. The client must enter AUTHINFO USER followed by the username. Once sent, the server will cache the username and send a 381 response requesting the password associated with that username. The client must enter AUTHINFO PASS followed by the password for the username. The server will then check the authentication database to see if the username/password combination is valid. If the combination is valid, the server will return a 281 response. The client should then retry the original command to which the server responded with the 480 response. The command should then be processed by the server normally. If the combination is not valid, the server will return a 502 response. Clients must provide authentication when requested by the server. It is possible that some implementations will accept authentication information at the beginning of a session, but this was not the original intent of the specification. If a client attempts to reauthenticate, the server may return 482 response indicating that the new authentication data is rejected by the server. The 482 code will also be returned when the AUTHINFO commands are not entered in the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO PASS preceding AUTHINFO USER). Except that this excerpt comes from an expired draft from a working group that was dissolved. In fact I should mention to Lars that i was deceived when i suggested AUTHINFO GENERIC was something useful for Gnus to support. AUTHINFO GENERIC, as it's name implies, is intended to allow people to experiment with other authentication schemes. It doesn't specify any particular protocol. In fact it turns out no authentication scheme could possibly be secure given its framework.