ietf-nntp Server "modes" and response codes

Russ Allbery rra at stanford.edu
Thu May 15 13:31:34 PDT 2003


In news.software.nntp, Ken Murchison <ken at oceana.com> writes:

> What is the expected/common response code to a command that isn't
> allowed in a given mode?  Examples:

> - A server is in reader mode, either via MODE READER or use of a
> reader-only command like GROUP or POST and a client attempts to use
> IHAVE.

> - A server is in feeder/streaming mode either via MODE STREAM or use of
> IHAVE and a client attempts to use GROUP.

> It looks like INN uses 500 in most cases, and 480 when it applies.

I believe 502 is the correct error code.  The occurrences of 500 are an
accident of implementation in INN that should be corrected.  The uses of
480 are a flat-out bug in most cases:

  Summary: innd may return 480 instead of 500 for unrecognized commands
 Standard: draft-ietf-nntpext-base-15.txt, section 4.1.1
  Version: 1.0 to CURRENT 2002-12-26
Reference: innd/nc.c NCauthinfo()
 Severity: Violates MUST

The standard says:

    If the command is not recognized, or it is an optional command or
    extension that is not implemented by the server, the response code 500
    MUST be returned.

In innd, if the connection is determined to need authentication, all
incoming commands other than MODE are handed off to NCauthinfo() rather
than their normal command handlers.  NCauthinfo() responds with a 480
reply code to anything other than AUTHINFO USER, AUTHINFO PASS, or QUIT.

Impact:  Unlikely to cause problems in practice, but may confuse clients
that don't understand the rarely used innd-level authentication
mechanisms.

Suggested fix:  Restructure the command table so that each command also
has a flag indicating whether it requires authentication for peers that
are required to authenticate.  (Some commands, like HELP and MODE READER,
should be allowed without authentication.)  Then eliminate the special
casing of the state CSgetauth (it may be better to store whether the peer
has authenticated in the channel rather than in the channel state) and the
special handling in NCauthinfo.  This should also simplify the code.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

          Please post questions rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.



More information about the ietf-nntp mailing list