Project: Webinterface II - Msgbase Structures: Zvon - RFC 2980 [Common NNTP Extensions] - Other Extensions

AMBROSIA60-Portal  Webinterface II Project
ZVON > RFC Repository > RFC 2980
Prev | Next |

4. Other Extensions

4.1. AUTHINFO

   AUTHINFO is used to inform a server about the identity of a user of
   the server.  In all cases, clients must provide this information when
   requested by the server.  Servers are not required to accept
   authentication information that is volunteered by the client.
   Clients must accommodate servers that reject any authentication
   information volunteered by the client.

   There are three forms of AUTHINFO in use.  The original version, an
   NNTP v2 revision called AUTHINFO SIMPLE and a more recent version
   which is called AUTHINFO GENERIC.

4.1.1. Original AUTHINFO

   AUTHINFO USER username
   AUTHINFO PASS password

   The original AUTHINFO is used to identify a specific entity to the
   server using a simple username/password combination.  It first
   appeared in the UNIX reference implementation.

   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 may send a 381 response requesting the
   password associated with that username.  Should the server request a
   password using the 381 response, the client must enter AUTHINFO PASS
   followed by a password and the server will then check the
   authentication database to see if the username/password combination
   is valid.  If the combination is valid or if no password is required,
   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).

   All information is passed in cleartext.

   When authentication succeeds, the server will create an email address
   for the client from the user name supplied in the AUTHINFO USER
   command and the hostname generated by a reverse lookup on the IP
   address of the client.  If the reverse lookup fails, the IP address,
   represented in dotted-quad format, will be used.  Once authenticated,
   the server shall generate a Sender:  line using the email address
   provided by authentication if it does not match the client-supplied
   From: line.  Additionally, the server should log the event, including
   the email address.  This will provide a means by which subsequent
   statistics generation can associate newsgroup references with unique
   entities - not necessarily by name.

4.1.1.1. Responses

      281 Authentication accepted
      381 More authentication information required
      480 Authentication required
      482 Authentication rejected
      502 No permission

4.1.2. AUTHINFO SIMPLE

   AUTHINFO SIMPLE
   user password

   This version of AUTHINFO was part of a proposed NNTP V2
   specification, which was started in 1991 but never completed, and is
   implemented in some servers and clients.  It is a refinement of the
   original AUTHINFO and provides the same basic functionality, but the
   sequence of commands is much simpler.

   When authorization is required, the server sends a 450 response
   requesting authorization from the client.  The client must enter
   AUTHINFO SIMPLE.  If the server will accept this form of
   authentication, the server responds with a 350 response.  The client
   must then send the username followed by one or more space characters
   followed by the password.  If accepted, the server returns a 250
   response and the client should then retry the original command to
   which the server responded with the 450 response.  The command should
   then be processed by the server normally.  If the combination is not
   valid, the server will return a 452 response.

   Note that the response codes used here were part of the proposed NNTP
   V2 specification and are violations of RFC 977prop.  It is recommended
   that this command not be implemented, but use either or both of the
   other forms of AUTHINFO if such functionality if required.

4.1.2.1. Responses

      250 Authorization accepted
      350 Continue with authorization sequence
      450 Authorization required for this command
      452 Authorization rejected

4.1.3. AUTHINFO GENERIC

   AUTHINFO GENERIC authenticator arguments...

   AUTHINFO GENERIC is used to identify a specific entity to the server
   using arbitrary authentication  or identification protocols.  The
   desired protocol is indicated by the authenticator parameter, and any
   number of parameters can be passed to the authenticator.

   When authorization is required, the server will send a 480 response
   requesting authorization from the client.  The client should enter
   AUTHINFO GENERIC followed by the authenticator name, and the
   arguments if any.  The authenticator and arguments must not contain
   the sequence "..".

   The server will attempt to engage the server end authenticator,
   similarly, the client should engage the client end authenticator.
   The server end authenticator will then initiate authentication using
   the NNTP sockets (if appropriate for that authentication protocol),
   using the protocol specified by the authenticator name.  These
   authentication protocols are not included in this document, but are
   similar in structure to those referenced in RFC 1731prop [8] for the
   IMAP-4 protocol.

   If the server returns 501, this means that the authenticator
   invocation was syntactically incorrect, or that AUTHINFO GENERIC is
   not supported.  The client should retry using the AUTHINFO USER
   command.

   If the requested authenticator capability is not found, the server
   returns the 503 response code.

   If there is some other unspecified server program error, the server
   returns the 500 response code.

   The authenticators converse using their protocol until complete.  If
   the authentication succeeds, the server authenticator will terminate
   with a 281, and the client can continue by reissuing the command that
   prompted the 380.  If the authentication fails, the server will
   respond with a 502.

   The client must provide authentication when requested by the server.
   The server may request authentication at any time.  Servers may
   request authentication more than once during a single session.

   When the server authenticator completes, it provides to the server
   (by a mechanism herein undefined) the email address of the user, and
   potentially what the user is allowed to access.  Once authenticated,
   the server shall generate a Sender:  line using the email address
   provided by the authenticator if it does not match the user-supplied
   From: line.  Additionally, the server should log the event, including
   the user's authenticated email address (if available).  This will
   provide a means by which subsequent statistics generation can
   associate newsgroup references with unique entities - not necessarily
   by name.

   Some implementations make it possible to obtain a list of
   authentication procedures available by sending the server AUTHINFO
   GENERIC with no arguments.  The server then returns a list of
   supported mechanisms followed by a period on a line by itself.

4.1.3.1. Responses

      281 Authentication succeeded
      480 Authentication required
      500 Command not understood
      501 Command not supported
      502 No permission
      503 Program error, function not performed
      nnn  authenticator-specific protocol.

4.2. DATE

   DATE

   The first NNTP working group discussed and proposed a syntax for this
   command to help clients find out the current time from the server's
   perspective.  At the time this command was discussed (1991-1992), the
   Network Time Protocol [9] (NTP) was not yet in wide use and there was
   also some concern that small systems may not be able to make
   effective use of NTP.

   This command returns a one-line response code of 111 followed by the
   GMT date and time on the server in the form YYYYMMDDhhmmss.

4.2.1. Responses

      111 YYYYMMDDhhmmss

4.3. The WILDMAT format

   The WILDMAT format was first developed by Rich Salz based on the
   format used in the UNIX "find" command to articulate file names.  It
   was developed to provide a uniform mechanism for matching patterns in
   the same manner that the UNIX shell matches filenames.  Patterns are
   implicitly anchored at the beginning and end of each string when
   testing for a match.  There are five pattern matching operations
   other than a strict one-to-one match between the pattern and the
   source to be checked for a match.  The first is an asterisk (*) to
   match any sequence of zero or more characters.  The second is a
   question mark (?) to match any single character.  The third specifies
   a specific set of characters.  The set is specified as a list of
   characters, or as a range of characters where the beginning and end
   of the range are separated by a minus (or dash) character, or as any
   combination of lists and ranges.  The dash can also be included in
   the set as a character it if is the beginning or end of the set.
   This set is enclosed in square brackets.  The close square bracket
   (]) may be used in a set if it is the first character in the set.
   The fourth operation is the same as the logical not of the third
   operation and is specified the same way as the third with the
   addition of a caret character (^) at the beginning of the test string
   just inside the open square bracket.  The final operation uses the
   backslash character to invalidate the special meaning of the a open
   square bracket ([), the asterisk, backslash or the question mark.
   Two backslashes in sequence will result in the evaluation of the
   backslash as a character with no special meaning.

4.3.1. Examples

   a. [^]-] -- matches any single character other than a close square
               bracket or a minus sign/dash.

   b. *bdc  -- matches any string that ends with the string "bdc"
               including the string "bdc" (without quotes).

   c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
               character.

   d. a??d  --  matches any four character string which begins
                with a and ends with d.

4.4. Additional Headers

   Many NNTP implementations add headers to Usenet articles when then
   are POSTed via NNTP.  These headers are discussed in this section.
   None of these headers conflict with those specified in RFC 1036 and
   should be passed unchanged by Usenet transports conforming to RFC
   1036.

4.4.1. NNTP-Posting-Host

   This line is added to the header of a posted article by the server.
   The contents of the header is either the IP address or the fully
   qualified domain name of the client host posting the article.  The
   fully qualified domain name should be determined by doing a reverse
   lookup in the DNS on the IP address of the client.  If the client
   article contains this line, it is removed by the server before
   acceptance of the article by the Usenet transport system.

   This header provides some idea of the actual host posting the article
   as opposed to information in the Sender or From lines that may be
   present in the article.  This is not a fool-proof methodology since
   reverse lookups in the DNS are vulnerable to certain types of
   spoofing, but such discussions are outside the scope of this
   document.

4.4.2. X-Newsreader and others

   There are other lines that are added by clients as well.  Most of
   these indicate the type of newsreader software that is posting the
   article.


ZVON > RFC Repository > RFC 2980
Prev | Next |


© 2003-2024 by Ulrich Schroeter   00755