As per Relevance of the word followed, we have this rfc below:
Network Working Group S.
Request for Comments: 2980 Academ Consulting
Category: Informational October 2000
Common NNTP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
In this document, a number of popular extensions to the Network
Transfer Protocol (NNTP) protocol defined in RFC 977 are
and discussed. While this document is not intended to serve as
standard of any kind, it will hopefully serve as a reference
for future implementers of the NNTP protocol. In the role,
document would hopefully create the possibility for some level
interoperability among implementations that make use of extensions
RFC 977 [1] defines the NNTP protocol and was released over a
ago. Since then, NNTP has become one of the most popular
in use on the Internet. Many implementations of the protocol
been created on many different platforms and operating systems.
the growth in use of the protocol, work began on a revision to
in 1991, but that work did not result in a new standard
specification. However, many ideas from that working group did
their way into many implementations of NNTP. Additionally,
other extensions, often created by newsreader authors, are also
use. This document will capture and define all known extensions
NNTP available in official NNTP server releases of some type as
this writing. Where possible, the server software first
a particular extension will be noted. It is the hope of the
that using this document in tandem with RFC 977 will limit
addition of new extensions that essentially do the same thing
Software developers may wish to use this document and others [2] as
resource for the development of new software
Barber Informational [Page 1]
RFC 2980 Common NNTP Extensions October 2000
This document does not specify an Internet Standard of any kind.
only attempts to document current practices. While this document
clarify some ambiguity in RFC 977, RFC 977 should be regarded
authoritative in all cases. There are some implementations that
not strictly RFC 977 compliant and where necessary, these
from the standard will be noted. This document does reflect the
of the IETF NNTP-EXT working group chaired by Ned Freed and
Barber
This document is provided to help implementers have a uniform
of information about extensions, however, it is important for
prospective implementer to understand that the extensions listed
are NOT part of any current standard for NNTP. In fact, some of
ones listed in this document should not be included in new
implementations as they should no longer be used modern
environments. Such commands should be considered historic and
documented as such in this document
Extensions fall into three categories: transport, newsreader
other. Transport extensions are additions to the NNTP
that were made specifically to move news articles from one server
another server. Newsreader extensions are additions to the
specification that were made to assist NNTP clients in selecting
retrieving news articles from servers. Other extensions to the
specification are those which did not specifically fall into
of the other two categories. Examples of other extensions
authentication and time-of-day extensions. For each command,
format of section 3 of RFC 977 will be used
1. Transport
A transport extension is one which is primarily used in inter-
communications. Following are the descriptions of each
extension commands and the responses which will be returned by
commands
Each command is shown in upper case for clarity, although case
ignored in the interpretation of commands by the NNTP server.
parameters are shown in lower case. A parameter shown in [
brackets] is optional. For example, [GMT] indicates that
triglyph GMT may present or omitted. A parameter that may
repeated is followed by an ellipsis
Barber Informational [Page 2]
RFC 2980 Common NNTP Extensions October 2000
1.1.1 The CHECK
CHECK
CHECK is used by a peer to discover if the article with the
message-id should be sent to the server using the TAKETHIS command
The peer does not have to wait for a response from the server
sending the next command
From using the responses to the sequence of CHECK commands, a list
articles to be sent can be constructed for subsequent use by
TAKETHIS command
The use of the CHECK command for streaming is optional.
implementations will directly use the TAKETHIS command and send
articles in the send queue on that peer for the server
On some implementations, the use of the CHECK command is
permitted when the server is in slave mode (via the SLAVE command).
Responses that are of the form X3X must specify the message-id in
response
1.1.2.
238 no such article found, please send it to
400 not accepting
431 try sending it again
438 already have it, please don't send it to
480 Transfer permission
500 Command not
1.2.1 The MODE STREAM
MODE
MODE STREAM is used by a peer to indicate to the server that it
like to suspend the lock step conversational nature of NNTP and
commands in streams. This command should be used before TAKETHIS
CHECK. See the section on the commands TAKETHIS and CHECK for
details
1.2.2.
203 Streaming is
500 Command not
Barber Informational [Page 3]
RFC 2980 Common NNTP Extensions October 2000
1.3.1 The TAKETHIS
TAKETHIS
TAKETHIS is used to send articles to a server when in streaming mode
The entire article (header and body, in that sequence) is
immediately after the peer sends the TAKETHIS command. The peer
not have to wait for a response from the server before sending
next command and the associated article
During transmission of the article, the peer should send the
article, including header and body, in the manner specified for
transmission from the server. See RFC 977, Section 2.4.1
details
Responses that are of the form X3X must specify the message-id in
response
1.3.2.
239 article transferred
400 not accepting
439 article transfer
480 Transfer permission
500 Command not
1.4.1 The XREPLIC
XREPLIC ggg:nnn[,ggg:nnn...]
The XREPLIC command makes is possible to exactly duplicate the
spool structure of one server in another server. It first
in INN
This command works similarly to the IHAVE command as specified in
977. The same response codes are used. The command line
consist of entries separated by a single comma. Each entry
of a news group name, a colon, and an article number. If the
responds with a 335 response, the article should be filed in the
group(s) and article number(s) specified in the XREPLIC command line
If the server cannot do successfully install the article once it
accepted it, a 436 or 437 response code can be used to indicate
failure
This command should only be used when the receiving server is
fed by only one other server. It is likely that when used
servers that have multiple feeds that this command will
fail
Barber Informational [Page 4]
RFC 2980 Common NNTP Extensions October 2000
XREPLIC slaving has been deprecated in INN version 1.7.2 and later
INN now has the ability to slave servers via transparent means
simply by having the article's Xref header transferred. (In
versions, this header was generated locally and stripped off
outgoing feeds.)
It is likely that future versions of INN will no longer
XREPLIC
1.4.2.
235 article transferred
335 send article to be transferred. End with .
435 article not wanted - do not send
436 transfer failed - try again
437 article rejected - do not try
2. Newsreader
Newsreader extensions are those which are primarily used
newsreading clients. Following are the descriptions of
newsreader extension commands and the responses which will
returned by those commands
Each command is shown in upper case for clarity, although case
ignored in the interpretation of commands by the NNTP server.
parameters are shown in lower case. A parameter shown in [
brackets] is optional. For example, [GMT] indicates that
triglyph GMT may present or omitted. A parameter that may
repeated is followed by an ellipsis. Mutually exclusive
are separated by a vertical bar (|) character. For example
ggg| indicates that a group name or a
be specified, but not both. Some parameters, notably ,
is case specific. See RFC 1036 for these details
Also, certain commands make use of a pattern for selection
multiple news groups. The pattern in all cases is based on
wildmat [4] format introduced by Rich Salz in 1986.
expected to be in wildmat format will be represented by the
wildmat. This format is discussed in detail in section 3.3 of
document
2.1.1 Extensions to the LIST
The original LIST command took no arguments in RFC 977 and
the contents of the active file in a specific format. Since
original newsreaders made use of other information available in
news transport software in addition to the active file, extensions
Barber Informational [Page 5]
RFC 2980 Common NNTP Extensions October 2000
the LIST command were created to make that information available
NNTP newsreaders. There may be other extensions to the LIST
that simply return the contents of a file. This approach
suggested over the addition of over verbs. For example, LIST
could be used instead of adding XMOTD
2.1.2 LIST
LIST ACTIVE [wildmat
LIST ACTIVE is exactly the same as the LIST command specified in
977. The responses and the format should exactly match the
command without arguments. If the optional matching parameter
specified, the list is limited to only the groups that match
pattern. Specifying a single group is usually very efficient for
server, and multiple groups may be specified by using
patterns (described later in this document), not regular expressions
If nothing is matched an empty list is returned, not an error.
command first appeared in the UNIX reference version
2.1.3 LIST ACTIVE.
LIST ACTIVE.
The active.times file is maintained by some news transports
to contain information about the when and who created a
news group. The format of this file generally include three fields
The first field is the name of the news group. The second is
time when this group was created on this news server measured
seconds since January 1, 1970. The third is the email address of
entity that created the news group. When executed, the
is displayed following the 215 response. When display is completed
the server will send a period on a line by itself. If
information is not available, the server will return the 503
response. This command first appeared in the UNIX reference version
2.1.3.1
215 information
503 program error, function not
2.1.4 LIST
LIST
The distributions file is maintained by some news transport
to contain information about valid values for the Distribution:
in a news article header and about what the values mean. Each
Barber Informational [Page 6]
RFC 2980 Common NNTP Extensions October 2000
contains two fields, the value and a short explanation on the
of the value. When executed, the information is displayed
the 215 response. When display is completed, the server will send
period on a line by itself. If the information is not available,
server will return the 503 error response. This command
appeared in the UNIX reference version
2.1.4.1
215 information
503 program error, function not
2.1.5 LIST DISTRIB.
LIST DISTRIB.
The distrib.pats file is maintained by some news transport systems
contain default values for the Distribution: line in a news
header when posting to particular news groups. This
could be used to provide a default value for the Distribution:
in the header when posting an article. The information
involves three fields separated by colons. The first column is
weight. The second is a group name or a pattern that can be used
match a group name in the wildmat format. The third is the value
the Distribution: line that should be used when the group
matches and the weight value is the highest. All this processing
done by the news posting client and not by the server itself.
server just provides this information to the client for it to use
ignore as it chooses. When executed, the information is
following the 215 response. When display is completed, the
will send a period on a line by itself. If the information is
available, the server will return the 503 error response.
command first appeared in INN
2.1.5.1
215 information
503 program error, function not
2.1.6 LIST
LIST NEWSGROUPS [wildmat
The newsgroups file is maintained by some news transport systems
contain the name of each news group which is active on the server
a short description about the purpose of each news group. Each
in the file contains two fields, the news group name and a
explanation of the purpose of that news group. When executed,
Barber Informational [Page 7]
RFC 2980 Common NNTP Extensions October 2000
information is displayed following the 215 response. When display
completed, the server will send a period on a line by itself. If
information is not available, the server will return the 503
response. If the optional matching parameter is specified, the
is limited to only the groups that match the pattern (no matching
done on the group descriptions). Specifying a single group
usually very efficient for the server, and multiple groups may
specified by using wildmat patterns (similar to file globbing),
regular expressions. If nothing is matched an empty list
returned, not an error
When the optional parameter is specified, this command is
to the XGTITLE command, though the response code are different
215 information
503 program error, function not
2.1.7 LIST OVERVIEW.
LIST OVERVIEW.
The overview.fmt file is maintained by some news transport systems
contain the order in which header information is stored in
overview databases for each news group. When executed, news
header fields are displayed one line at a time in the order in
they are stored in the overview database [5] following the 215
response. When display is completed, the server will send a
on a line by itself. If the information is not available, the
will return the 503 response
Please note that if the header has the word "full" (without quotes
after the colon, the header's name is prepended to its field in
output returned by the server
Many newsreaders work better if Xref: is one of the optional fields
It is STRONGLY recommended that this command be implemented in
server that implements the XOVER command. See section 2.8 for
details about the XOVER command
2.1.7.1
215 information
503 program error, function not
Barber Informational [Page 8]
RFC 2980 Common NNTP Extensions October 2000
2.1.8 LIST
LIST
This command is used to get a default subscription list for new
of this server. The order of groups is significant
When this list is available, it is preceded by the 215 response
followed by a period on a line by itself. When this list is
available, the server returns a 503 response code
2.1.8.1
215 information
503 program error, function not
2.2
LISTGROUP [ggg
The LISTGROUP command is used to get a listing of all the
numbers in a particular news group
The optional parameter ggg is the name of the news group to
selected (e.g. "news.software.b"). A list of valid news groups
be obtained from the LIST command. If no group is specified,
current group is used as the default argument
The successful selection response will be a list of the
numbers in the group followed by a period on a line by itself
When a valid group is selected by means of this command,
internally maintained "current article pointer" is set to the
article in the group. If an invalid group is specified,
previously selected group and article remain selected. If an
news group is selected, the "current article pointer" is in
indeterminate state and should not be used
Note that the name of the news group is not case-dependent. It
otherwise match a news group obtained from the LIST command or
error will result
2.2.1
211 list of article numbers
412 Not currently in
502 no
Barber Informational [Page 9]
RFC 2980 Common NNTP Extensions October 2000
2.3 MODE
MODE READER is used by the client to indicate to the server that
is a news reading client. Some implementations make use of
information to reconfigure themselves for better performance
responding to news reader commands. This command can be
with the SLAVE command in RFC 977, which was not widely implemented
MODE READER was first available in INN
2.3.1
200 Hello, you can
201 Hello, you can't
2.4
XGTITLE [wildmat
The XGTITLE command is used to retrieve news group descriptions
specific news groups
This extension first appeared in ANU-NEWS, an NNTP implementation
DEC's VMS. The optional parameter is a pattern in wildmat format
When executed, a 282 response is given followed by lines that
two fields, the news group name (which matches the pattern in
argument) and a short explanation of the purpose of the news group
When no argument is specified, the default argument is the
group name. When display is completed, the server sends a period
a line by itself
Please note that this command and the LIST NEWSGROUP command
the same functionality with different response codes
Since this command provides the same functionality as LIST
it is suggested that this extension be deprecated and no longer
used in newsreading clients
Note that there is a conflict in one of the response codes
XGTITLE and some of the authentication extensions
2.5.1
481 Groups and descriptions
282 list of groups and descriptions
Barber Informational [Page 10]
RFC 2980 Common NNTP Extensions October 2000
2.6
XHDR header [range|]
The XHDR command is used to retrieve specific headers from
articles
The required parameter is the name of a header line (e.g. "subject")
in a news group article. See RFC 1036 for a list of valid
lines. The optional range argument may be any of the following
an article
an article number followed by a dash to
all
an article number followed by a dash followed
another article
The optional message-id argument indicates a specific article.
range and message-id arguments are mutually exclusive. If
argument is specified, then information from the current article
displayed. Successful responses start with a 221 response
by a the matched headers from all matched messages. Each
containing matched headers returned by the server has an
number (or message ID, if a message ID was specified in the command),
then one or more spaces, then the value of the requested header
that article. Once the output is complete, a period is sent on
line by itself. If the optional argument is a message-id and no
article exists, the 430 error response is returned. If a range
specified, a news group must have been selected earlier, else a 412
error response is returned. If no articles are in the
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission
transfer articles
Some implementations will return "(none)" followed by a period on
line by itself if no headers match in any of the articles searched
Others return the 221 response code followed by a period on a line
itself
The XHDR command has been available in the UNIX
implementation from its first release. However, until now, it
been documented only in the source for the server
Barber Informational [Page 11]
RFC 2980 Common NNTP Extensions October 2000
2.6.1
221 Header
412 No news group current
420 No current article
430 no such
502 no
2.7
XINDEX
The XINDEX command is used to retrieve an index file in the format
originally created for use by the TIN [6] news reader
The required parameter ggg is the name of the news group to
selected (e.g. "news.software.b"). A list of valid news groups
be obtained from the LIST command
The successful selection response will return index file in
format used by the TIN news reader followed by a period on a line
itself
When a valid group is selected by means of this command,
internally maintained "current article pointer" is set to the
article in the group. If an invalid group is specified,
previously selected group and article remain selected. If an
news group is selected, the "current article pointer" is in
indeterminate state and should not be used
Note that the name of the news group is not case-dependent. It
otherwise match a news group obtained from the LIST command or
error will result
The format of the tin-style index file is discussed in
documentation for the TIN newsreader. Since more recent versions
TIN support the news overview (NOV) format, it is recommended
this extension become historic and no longer be used in
servers or future implementations
2.7.1
218 tin-style index
418 no tin-style index is available for this news
Barber Informational [Page 12]
RFC 2980 Common NNTP Extensions October 2000
2.8
XOVER [range
The XOVER command returns information from the overview database
the article(s) specified. This command was originally suggested
part of the OVERVIEW work described in "The Design of a
Newsgroup Overview Database for Newsreaders" by Geoff Collyer.
document is distributed in the Cnews distribution. The
range argument may be any of the following
an article
an article number followed by a dash to
all
an article number followed by a dash followed
another article
If no argument is specified, then information from the
article is displayed. Successful responses start with a 224
followed by the overview information for all matched messages.
the output is complete, a period is sent on a line by itself. If
argument is specified, the information for the current article
returned. A news group must have been selected earlier, else a 412
error response is returned. If no articles are in the
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission
transfer articles
Each line of output will be formatted with the article number
followed by each of the headers in the overview database or
article itself (when the data is not available in the
database) for that article separated by a tab character.
sequence of fields must be in this order: subject, author, date
message-id, references, byte count, and line count. Other
fields may follow line count. Other optional fields may follow
count. These fields are specified by examining the response to
LIST OVERVIEW.FMT command. Where no data exists, a null field
be provided (i.e. the output will have two tab characters adjacent
each other). Servers should not output fields for articles that
been removed since the XOVER database was created
The LIST OVERVIEW.FMT command should be implemented if XOVER
implemented. A client can use LIST OVERVIEW.FMT to determine
optional fields and in which order all fields will be supplied
the XOVER command. See Section 2.1.7 for more details about the
OVERVIEW.FMT command
Barber Informational [Page 13]
RFC 2980 Common NNTP Extensions October 2000
Note that any tab and end-of-line characters in any header data
is returned will be converted to a space character
2.8.1
224 Overview information
412 No news group current
420 No article(s)
502 no
2.9
XPAT header range| pat [pat...]
The XPAT command is used to retrieve specific headers from
articles, based on pattern matching on the contents of the header
This command was first available in INN
The required header parameter is the name of a header line (e.g
"subject") in a news group article. See RFC 1036 for a list of
header lines. The required range argument may be any of
following
an article
an article number followed by a dash to
all
an article number followed by a dash followed
another article
The required message-id argument indicates a specific article.
range and message-id arguments are mutually exclusive. At least
pattern in wildmat must be specified as well. If there
additional arguments the are joined together separated by a
space to form one complete pattern. Successful responses start
a 221 response followed by a the headers from all messages in
the pattern matched the contents of the specified header line.
includes an empty list. Once the output is complete, a period
sent on a line by itself. If the optional argument is a message-
and no such article exists, the 430 error response is returned.
502 response will be returned if the client only has permission
transfer articles
2.9.1
221 Header
430 no such
502 no
Barber Informational [Page 14]
RFC 2980 Common NNTP Extensions October 2000
2.10 The XPATH
XPATH
The XPATH command is used to determine the filenames in which
article is filed. It first appeared in INN
The required parameter message-id is the message id of an article
shown in that article's message-id header. According to RFC 1036
[3], all message ids for all articles within the netnews
are unique, but articles may be crossposted to multiple groups.
response to an XPATH command will include a listing of all
in which an article is stored separated by spaces or a
indicating that no article with the specified message-id exists.
returned data is only useful if the news client knows
implementation details of the server. Because of this, it
recommended that client avoid using this command
2.10.1
223 path1[ path2 ...]
430 no such article on
2.11 The XROVER
XROVER [range
The XROVER command returns reference information from the
database for the article(s) specified. This command first
in the Unix reference implementation. The optional range
may be any of the following
an article
an article number followed by a dash to
all
an article number followed by a dash followed
another article
Successful responses start with a 224 response followed by
contents of reference information for all matched messages. Once
output is complete, a period is sent on a line by itself. If
argument is specified, the information for the current article
returned. A news group must have been selected earlier, else a 412
error response is returned. If no articles are in the
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission
transfer articles
Barber Informational [Page 15]
RFC 2980 Common NNTP Extensions October 2000
The output will be formatted with the article number, followed by
contents of the References: line for that article, but does
contain the field name itself
This command provides the same basic functionality as using the
command and "references" as the header argument
2.11.1
224 Overview information
412 No news group current
420 No article(s)
502 no
2.12
XTHREAD [DBINIT|THREAD
The XTHREAD command is used to retrieve threading
in format of originally created for use by the TRN [6]
reader
The command XTHREAD DBINIT may be issued prior to
any groups to see if a thread database exists. If it does
the database's byte order and version number are
as binary data
If no parameter is given, XTHREAD THREAD is assumed
To use XTHREAD THREAD, a news group must have been
earlier, else a 412 error response is returned
A 502 response will be returned if the client only
permission to transfer articles. A 503 response is
if the threading files are not available
The format of the trn-style thread format is discussed
the documentation for the TRN newsreader. Since more
versions of TRN support the news overview (NOV) format,
is recommended that this extension become historic and
longer be used in current servers or future implementations
2.12.1
288 Binary data to
412 No newsgroup current
502 No
503 program error, function not
Barber Informational [Page 16]
RFC 2980 Common NNTP Extensions October 2000
3. Other
3.1
AUTHINFO is used to inform a server about the identity of a user
the server. In all cases, clients must provide this information
requested by the server. Servers are not required to
authentication information that is volunteered by the client
Clients must accommodate servers that reject any
information volunteered by the client
There are three forms of AUTHINFO in use. The original version,
NNTP v2 revision called AUTHINFO SIMPLE and a more recent
which is called AUTHINFO GENERIC
3.1.1 Original
AUTHINFO USER
AUTHINFO PASS
The original AUTHINFO is used to identify a specific entity to
server using a simple username/password combination. It
appeared in the UNIX reference implementation
When authorization is required, the server will send a 480
requesting authorization from the client. The client must
AUTHINFO USER followed by the username. Once sent, the server
cache the username and may send a 381 response requesting
password associated with that username. Should the server request
password using the 381 response, the client must enter AUTHINFO
followed by a password and the server will then check
authentication database to see if the username/password
is valid. If the combination is valid or if no password is required
the server will return a 281 response. The client should then
the original command to which the server responded with the 480
response. The command should then be processed by the
normally. If the combination is not valid, the server will return
502 response
Clients must provide authentication when requested by the server.
is possible that some implementations will accept
information at the beginning of a session, but this was not
original intent of the specification. If a client attempts
reauthenticate, the server may return 482 response indicating
the new authentication data is rejected by the server. The 482
will also be returned when the AUTHINFO commands are not entered
the correct sequence (like two AUTHINFO USERs in a row, or
PASS preceding AUTHINFO USER).
Barber Informational [Page 17]
RFC 2980 Common NNTP Extensions October 2000
All information is passed in cleartext
When authentication succeeds, the server will create an email
for the client from the user name supplied in the AUTHINFO
command and the hostname generated by a reverse lookup on the
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
provided by authentication if it does not match the client-
From: line. Additionally, the server should log the event,
the email address. This will provide a means by which
statistics generation can associate newsgroup references with
entities - not necessarily by name
3.1.1.1
281 Authentication
381 More authentication information
480 Authentication
482 Authentication
502 No
3.1.2 AUTHINFO
AUTHINFO
user
This version of AUTHINFO was part of a proposed NNTP V
specification, which was started in 1991 but never completed, and
implemented in some servers and clients. It is a refinement of
original AUTHINFO and provides the same basic functionality, but
sequence of commands is much simpler
When authorization is required, the server sends a 450
requesting authorization from the client. The client must
AUTHINFO SIMPLE. If the server will accept this form
authentication, the server responds with a 350 response. The
must then send the username followed by one or more space
followed by the password. If accepted, the server returns a 250
response and the client should then retry the original command
which the server responded with the 450 response. The command
then be processed by the server normally. If the combination is
valid, the server will return a 452 response
Note that the response codes used here were part of the proposed
V2 specification and are violations of RFC 977. It is
that this command not be implemented, but use either or both of
other forms of AUTHINFO if such functionality if required
Barber Informational [Page 18]
RFC 2980 Common NNTP Extensions October 2000
3.1.2.1
250 Authorization
350 Continue with authorization
450 Authorization required for this
452 Authorization
3.1.3 AUTHINFO
AUTHINFO GENERIC authenticator arguments...
AUTHINFO GENERIC is used to identify a specific entity to the
using arbitrary authentication or identification protocols.
desired protocol is indicated by the authenticator parameter, and
number of parameters can be passed to the authenticator
When authorization is required, the server will send a 480
requesting authorization from the client. The client should
AUTHINFO GENERIC followed by the authenticator name, and
arguments if any. The authenticator and arguments must not
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
the NNTP sockets (if appropriate for that authentication protocol),
using the protocol specified by the authenticator name.
authentication protocols are not included in this document, but
similar in structure to those referenced in RFC 1731 [8] for
IMAP-4 protocol
If the server returns 501, this means that the
invocation was syntactically incorrect, or that AUTHINFO GENERIC
not supported. The client should retry using the AUTHINFO
command
If the requested authenticator capability is not found, the
returns the 503 response code
If there is some other unspecified server program error, the
returns the 500 response code
The authenticators converse using their protocol until complete.
the authentication succeeds, the server authenticator will
with a 281, and the client can continue by reissuing the command
prompted the 380. If the authentication fails, the server
respond with a 502.
Barber Informational [Page 19]
RFC 2980 Common NNTP Extensions October 2000
The client must provide authentication when requested by the server
The server may request authentication at any time. Servers
request authentication more than once during a single session
When the server authenticator completes, it provides to the
(by a mechanism herein undefined) the email address of the user,
potentially what the user is allowed to access. Once authenticated
the server shall generate a Sender: line using the email
provided by the authenticator if it does not match the user-
From: line. Additionally, the server should log the event,
the user's authenticated email address (if available). This
provide a means by which subsequent statistics generation
associate newsgroup references with unique entities - not
by name
Some implementations make it possible to obtain a list
authentication procedures available by sending the server
GENERIC with no arguments. The server then returns a list
supported mechanisms followed by a period on a line by itself
3.1.3.1
281 Authentication
480 Authentication
500 Command not
501 Command not
502 No
503 Program error, function not
nnn authenticator-specific protocol
3.2
The first NNTP working group discussed and proposed a syntax for
command to help clients find out the current time from the server'
perspective. At the time this command was discussed (1991-1992),
Network Time Protocol [9] (NTP) was not yet in wide use and there
also some concern that small systems may not be able to
effective use of NTP
This command returns a one-line response code of 111 followed by
GMT date and time on the server in the form YYYYMMDDhhmmss
3.2.1
111
Barber Informational [Page 20]
RFC 2980 Common NNTP Extensions October 2000
3.3 The WILDMAT
The WILDMAT format was first developed by Rich Salz based on
format used in the UNIX "find" command to articulate file names.
was developed to provide a uniform mechanism for matching patterns
the same manner that the UNIX shell matches filenames. Patterns
implicitly anchored at the beginning and end of each string
testing for a match. There are five pattern matching
other than a strict one-to-one match between the pattern and
source to be checked for a match. The first is an asterisk (*)
match any sequence of zero or more characters. The second is
question mark (?) to match any single character. The third
a specific set of characters. The set is specified as a list
characters, or as a range of characters where the beginning and
of the range are separated by a minus (or dash) character, or as
combination of lists and ranges. The dash can also be included
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
(]) 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
operation and is specified the same way as the third with
addition of a caret character (^) at the beginning of the test
just inside the open square bracket. The final operation uses
backslash character to invalidate the special meaning of the a
square bracket ([), the asterisk, backslash or the question mark
Two backslashes in sequence will result in the evaluation of
backslash as a character with no special meaning
3.3.1
a. [^]-] -- matches any single character other than a close
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
character
d. a??d -- matches any four character string which
with a and ends with d
Barber Informational [Page 21]
RFC 2980 Common NNTP Extensions October 2000
3.4 Additional
Many NNTP implementations add headers to Usenet articles when
are POSTed via NNTP. These headers are discussed in this section
None of these headers conflict with those specified in RFC 1036
should be passed unchanged by Usenet transports conforming to
1036.
3.4.1 NNTP-Posting-
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
qualified domain name of the client host posting the article.
fully qualified domain name should be determined by doing a
lookup in the DNS on the IP address of the client. If the
article contains this line, it is removed by the server
acceptance of the article by the Usenet transport system
This header provides some idea of the actual host posting the
as opposed to information in the Sender or From lines that may
present in the article. This is not a fool-proof methodology
reverse lookups in the DNS are vulnerable to certain types
spoofing, but such discussions are outside the scope of
document
3.4.2 X-Newsreader and
There are other lines that are added by clients as well. Most
these indicate the type of newsreader software that is posting
article
4.0 Common Implementation
Many NNTP implementations do not follow the specifications in
977. In this section, some common implementation issues
summarized
4.1 The Response to the LIST
RFC 977 says that the fourth field of the "list of valid
associated information" returned must be "either 'y' or 'n
indicating whether posting to this newsgroup is allowed ('y')
prohibited ('n'). Most implementations simply output the
contents of the transport system's active newsgroup list. For
implementations, the fourth field usually has more values that 'y'
'n'.
Barber Informational [Page 22]
RFC 2980 Common NNTP Extensions October 2000
4.2 The Required Headers in an Article and the POST
RFC 977 notes in section 3.10.1 that articles presented "
include all required header lines." In fact, modern
only require From, Subject, and Newsgroups header lines and
supply the rest; further, many implementers believe that it is
for clients to generate as few headers as possible, since
often do not format other headers correctly
This implementation behavior is consistent with both Bnews and
which would supply missing headers for articles directly submitted
them
4.3 Article
RFC 977 does not directly address the rules concerning
number. However, the current practice is simple: article numbers
monotonically increasing, articles may disappear, and therefore
high and low water marks returned in a GROUP command should
treated as maximum minima, and minimum maxima, respectively
4.4 Availability of commands defined in RFC 977
Some implementations permit administrators to disable
defined RFC 977. Some implementations have some set of
disabled by default. This means that client implementations
depend on the availability of the disabled set of commands.
increases the complexity of the client and does not
implementors to optimize the implementation of commands that don'
perform well
NEWNEWS is one of the commands frequently disabled
4.5 The Distribution header and
In section 12.4 of RFC 977, the optional distributions argument
described. This argument, according to RFC 977, would limit
responses to articles that were in newsgroups with prefixes
matched the optional distributions argument
Some implementations implement this by matching the
header in articles to the distribution argument. Others do the
against segments of the newsgroup's name
This variation is probably best explained by the evolution of
USENET article format. At the time RFC 977 was specified,
newsgroup name defined how the group was distributed
USENET. RFC 1036 changed this convention. So, those that
Barber Informational [Page 23]
RFC 2980 Common NNTP Extensions October 2000
strictly implementing RFC 977 would match the newsgroup name
against the distribution argument and only display matches.
that implement against the intent of the command (as modified by
redefinition of the article format)would match the
header against the distribution argument and only display
matches
5.0 Further
With the continued use of NNTP on the Internet, there remains
interest in creating an optimized transport protocol for server-to
server transfers and an optimized client protocol for client-to
server interactions. There is also considerable interest is
better mechanisms to provide audit information on which news
are being read by which users
An IETF working group has been formed and it is the hope of
author that these issues will be addressed in that forum
6.0 Security
The use of the AUTHINFO is optional. This command as documented
a number of security implications. In the original and simple forms
all passwords are passed in plaintext and could be discovered
various forms of network or system surveillance. The
GENERIC command has the potential for the same problems if
mechanism is used that also passes cleartext passwords. RFC 1731 [8]
discusses these issues in greater detail
7.0
[1] Kantor, B and P. Lapsley, "Network News Transfer Protocol",
977, February 1986.
[2] Limoncelli, Tom, "Read This Before You Write a Newsreader",
http://mars.superlink.net/tal/news-software-authors.html, June
1996.
[3] Horton, M. and R. Adams, "Standard for interchange of
messages", RFC 1036, December 1987.
[4] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
distribution, UUNET Technologies, Revision 1.10, April, 1992.
[5] Robertson, Rob, "FAQ: Overview database / NOV
Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq
nov.Z, January, 1995.
Barber Informational [Page 24]
RFC 2980 Common NNTP Extensions October 2000
[6] Lea, Iain, "FAQ about the TIN newsreader",
http://www.cs.unca.edu/~davidson/handouts/tinfaq.
[7] Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news
software/readers/%5Bnews.software.readers%5D_trn_
_FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-
-hierarchy/news/software/readers/%5Bnews.software.
%5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.
[8] Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
December 1994.
[9] Mills, D., "Network Time Protocol (Version 3), Specification
Implementation and Analysis", RFC 1305, March 1992.
8.0
DEC is a registered trademark of Compaq Computer Corporation.
is a registered trademark of The Open Group. VMS is a
trademark of Compaq Computer Corporation
9.0
The author gratefully acknowledges the comments and
information provided by the following individuals
Wayne Davison
Chris Lewis
Tom Limoncelli
Eric Schnoebelen
Rich Salz
This work was precipitated by the work of various newsreader
and newsserver authors which includes those listed below
Rick Adams -- Original author of the NNTP extensions to the
newsreader and last maintainer of
Stan Barber -- Original author of the NNTP extensions to
newsreaders that are part of Bnews
Geoff Collyer -- Original author of the OVERVIEW database proposal
one of the original authors of
Dan Curry -- Original author of the xvnews
Wayne Davison -- Author of the first threading extensions to
RN newsreader (commonly called TRN).
Geoff Huston -- Original author of ANU
Barber Informational [Page 25]
RFC 2980 Common NNTP Extensions October 2000
Phil Lapsey -- Original author of the UNIX
Iain Lea -- Original maintainer of the TIN
Chris Lewis -- First known implementor of the AUTHINFO
Rich Salz -- Original author of
Henry Spencer -- One of the original authors of
Kim Storm -- Original author of the NN
10.0 Author's
Stan
P.O. Box 300481
Houston, Texas, 77230
EMail: sob@academ.
Barber Informational [Page 26]
RFC 2980 Common NNTP Extensions October 2000
11.0 Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Barber Informational [Page 27]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
