3.0. Other Extensions
3.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.
3.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.
3.1.1.1. Responses
281 Authentication accepted
381 More authentication information required
480 Authentication required
482 Authentication rejected
502 No permission
3.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 977. 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.
3.1.2.1. Responses
250 Authorization accepted
350 Continue with authorization sequence
450 Authorization required for this command
452 Authorization rejected
3.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 1731 [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.
3.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.
3.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.
3.2.1. Responses
111 YYYYMMDDhhmmss
3.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.
3.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.
3.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.
3.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.
3.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.
|