Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

RFC 2980 defines a number of extensions that both add new commands to this set and

make changes to one of these commands (LIST). NNTP extensions are described in the

next topic.

Key Concept: The main NNTP standard defines a number of base NNTP

commands that are used by the device initiating an NNTP connection to accomplish

article propagation, posting or reading functions. NNTP commands consist of a

command code and optionally, parameters that specify how the command is to be carried

out.

LAST

Go To Last

Message

None

Tells the server to set its current article pointer to the

last message in the newsgroup.

LIST

List

Newsgroups

None

Asks the server to send a list of the newsgroups that it

supports, along with the first and last article number in

each group. The command as described in RFC 977 is

simple, supporting no parameters and causing the full

list of newsgroups to be sent to the client. NNTP

command extensions significantly expand the syntax of

this command.

NEWGROUPS

List New

Newsgroups

Date and time,

and optional

distribution

specification

Prompts the server to send a list of new newsgroups

created since the date and time specified. The client

may also restrict the command to return only new

newsgroups within a particular regional distribution.

NEWNEWS

List New

News

Articles

Date and time,

and optional

distribution

specification

Requests a list from the server of all new articles that

have arrived since a particular date and time. Like the

NEWGROUPS command, this may be restricted in

distribution. The server responds with a list of message

IDs of new articles.

Go To Next

Message

None

Advances the server's current article pointer to the next

message in the newsgroup.

POST Post Article None

Tells the server that the client would like to post a new

article. The server responds with either a positive or

negative acknowledgment. Assuming that posting is

allowed, the client then sends the full text of the

message to the server, which stores it and begins the

process of propagating it to other servers.

QUIT End Session None

Terminates the NNTP session. To be “polite”, the client

should issue this command prior to closing the TCP

connection.

SLAVE

Set Slave

Status

None

This command is intended for use in special configura-

tions where one NNTP server acts as a subsidiary to

others. It is not often used in practice.

Table 267: NNTP Base Commands (Page 2 of 2)

Command

Code

Command Parameters Description

NNTP Command Extensions

The base command set described in RFC 977 was sufficient to enable client-server and

inter-server functionality, but was in many ways quite basic and limited in efficiency and

usefulness. As Usenet grew larger and more popular in the late 1980s, demand grew for

changes to improve the usability of NNTP. In 1991, work began on a formal revision to the

NNTP standard, but was never completed. Despite this, many of the concepts from that

effort were adopted “informally” in NNTP implementations in subsequent years. In addition,

some Usenet software authors created their own non-standard features to improve the

protocol. Some of these themselves became de facto standards through widespread

adoption.

As a result, by the late 1990s, most Usenet software actually implemented variations of

NNTP with capabilities far exceeding what was documented in the standard. Naturally, not

all NNTP software supported the same “extra” features, leading to potential compatibility

difficulties between servers and clients. RFC 2980, Common NNTP Extensions, was

published in October 2000 to formalize many of these extensions to the base NNTP

standard as defined in RFC 977.

The NNTP extensions primarily consist of new NNTP commands that are added to the

basic NNTP command set, as well as some minor changes to how other commands and

functions of NNTP work. The extensions generally fall into three categories: those that

improve the efficiency of NNTP message transport between servers; those that make

NNTP more effective for client message access, and “miscellaneous” ones that don't fall

into either of those two groups.

NNTP Transport Extensions

The first group is called the NNTP transport extensions and consists of a small group of

related commands that are designed to improve inter-server message propagation. Most of

these implement NNTP's stream mode, which provides a more effective way of moving

large numbers of articles from one server to another, as described in the topic on inter-

server communication. Table 268 describes the new transport commands.

Table 268: NNTP Transport Extensions (Page 1 of 2)

Command

Code

Command Parameters Description

MODE

STREAM

Set Stream

Mode

None

Used to tell the server that the client wants to operate in

stream mode, using the CHECK and TAKETHIS

commands.

CHECK

Check If

Article Exists

Message ID

Used in stream mode by a server acting as a client to ask

another server if it has a copy of a particular article. The

server responds back indicating whether or not it wishes to

be sent a copy of the article. This command is similar to

IHAVE, except that the client does not have to wait for a

reply before sending the next command.

NNTP Newsreader Extensions

The second group of extensions defined by RFC 2980 are the newsreader extensions,

which focus primarily on commands used by newsreader clients in interactions with NNTP

servers. These extensions consist of several new commands as well as significant

enhancements to one important command that was very limited in its functionality in RFC

977: LIST.

The original LIST command has no parameters and only allows a client to retrieve the entire

list of newsgroups a server carries. This may have been sufficient when there were only a

few hundred Usenet newsgroups, but there are now tens of thousands. RFC 2980 defines a

number of new variations of the LIST command, to allow the client much more flexibility in

the types of information the server returns. Table 269 shows the new LIST command

variations.

TAKETHIS

Send Article

To Server

Message ID

When a server responds to a CHECK command indicating

that it wants a copy of a particular message, the client

sends it using this command.

XREPLIC

Replicate

Articles

List of

newsgroups

and article

numbers

This command was created for the special purpose of

copying large numbers of articles from one server to

another. It is not widely used.

Table 269: NNTP LIST Command Extensions (Page 1 of 2)

Command

Code

Command

Parame-

ters

Description

LIST ACTIVE

List Active

Newsgroups

Newsgroup

name or

pattern

Provides a list of active newsgroups on the server.

This is semantically the same as the original LIST

command, but the client may provide a newsgroup

name or a pattern to restrict the number of

newsgroups returned.

For example, the client can ask for a list of only the

newsgroups that contain “football” in them.

LIST

ACTIVE.TIMES

List Active

Newsgroup

Creation Times

None

Prompts the server to send the client its active.times

file, which contains information about when the

newsgroups carried by the server were created.

LIST

DISTRIBUTIONS

List Distributions None

Causes the server to sent the client the contents of

the distributions file, which shows what regional distri-

bution strings the server recognizes (for use in the

Distribution header of a message).

Table 268: NNTP Transport Extensions (Page 2 of 2)

Command

Code

Command Parameters Description

In addition to these changes to the LIST command, many new newsreader-related

command extensions are defined, which are described in Table 270.

LIST

DISTRIB.PATS

List Distribution

Patterns

None

Asks the server for its distribution.pats file, which is

like the distributions file but uses patterns to

summarize distribution information for different

newsgroups.

LIST

NEWSGROUPS

List Newsgroups

Newsgroup

name or

pattern

Provides a list of newsgroup names and descriptions.

This differs from LIST ACTIVE in that only the

newsgroup name and description are returned, and

not the article numbers for each newsgroup. It is

functionally the same as XGTITLE (see Table 270)

and is usually employed by a user to locate a

newsgroup to be added to his or her subscribed list.

LIST

OVERVIEW.FMT

Display Overview

Format

None

Prompts the server to display information about the

format of its overview file. See the XOVER command

description below for more.

LIST

SUBSCRIP-

TIONS

Retrieve Default

Subscription List

None

Asks the server to send the client a default list of

subscribed newsgroups. This is used to set up a new

user with a suggested list of newsgroups. For

example, if an organization has an internal support

newsgroup, they could put this group on the default

subscription list so all new users learn about it

immediately when they first start up their newsreader.

Table 270: NNTP Newsreader Extensions (Page 1 of 2)

Command

Code

Command Parameters Description

LISTGROUP

List Article

Numbers In

Newsgroup

Newsgroup name

Causes the server to return a list of local article

numbers for the current messages in the newsgroup.

The server's current article pointer is also set to the first

message in the group.

MODE

READER

Set

Newsreader

Mode

None

Tells the server that the device acting as a client is in

fact a client newsreader and not another NNTP server.

While technically not required—all commands can be

sent by any device acting as client—some servers may

be optimized to respond to newsreader-oriented

commands if given this command.

XGTITLE

Retrieve

Newsgroup

Descriptions

Newsgroup name

or pattern

Used to list the descriptions for a newsgroup or a set of

newsgroups matching a particular text pattern. This

command is functionally the same as the LIST

NEWSGROUP command extension (see Table 269). It

is therefore recommended that XGTITLE no longer be

used.

Table 269: NNTP LIST Command Extensions (Page 2 of 2)

Command

Code

Command

Parame-

ters

Description

XHDR

Retrieve

Article

Headers

Header name and

optionally, either a

message ID or a

range of article

numbers

Allows a client to ask for only a particular header from a

set of messages. If only the header name is provided,

the header is returned for all messages in the current

group. Otherwise, the header is provided for the

selected messages.

This extension provides a newsreader client with a

more efficient way of retrieving and displaying

important headers in a newsgroup to a user.

XINDEX

Retrieve

Index

Information

Newsgroup name

Retrieves an index file, used by the newsreader TIN to

improve the efficiency of newsgroup perusal. TIN now

supports the more common “overview” format, so the

XOVER command is preferred to this one.

XOVER

Retrieve

Overview

Information

Article number or

range of article

numbers in a

newsgroup

Retrieves the overview for an article or set of articles.

Servers supporting this feature maintain a special

database for their newsgroups that contains infor-

mation about current articles in a format that can be

used by a variety of newsreaders. Retrieving the

overview information allows features like message

threading to be performed more quickly than if the

client had to retrieve the headers of each message and

analyze them manually.

XPAT

Retrieve

Article

Headers

Matching A

Pattern

Header name,

pattern, and either

a message ID or a

range of article

numbers

This command is similar to XHDR in that it allows a

particular header to be retrieved for a set of messages.

The difference is that the client can specify a pattern

that must be matched for the header to be retrieved.

This allows the client to have the server search for and

return certain messages, such as those with a subject

line indicating a particular type of discussion, rather

than requiring the client to download all the headers

and search through them.

XPATH

Retrieve

Filename

Information

Message ID

Allows a client to ask for the name of the actual file in

which a particular message is stored on the server.

XROVER

Retrieve

Overview

Reference

Information

Article number or

range of article

numbers in a

newsgroup

Like the XOVER command, but specifically retrieves

information in the References header for the indicated

articles. This is, of course, the header containing the

data needed to create threaded conversations.

XTHREAD

Retrieve

Threading

Information

Optional “DBINIT”

parameter

Similar to XINDEX, but retrieves a special threading

information file in the format used by the newsreader

TRN. Like TIN, TRN now supports the common

“overview” format so XOVER is preferred to this

command.

The “DBINIT” parameter can be used to check for the

existence of a thread database.

Table 270: NNTP Newsreader Extensions (Page 2 of 2)

Command

Code

Command Parameters Description

Other NNTP Extensions

The last extension group is the “other” extensions, miscellaneous ones not strictly related to

either inter-server or client-server NNTP interaction. There are two commands in this group:

AUTHINFO and DATE. The latter is a simple command that causes the server to tell the

client its current date and time. AUTHINFO is more interesting: it is used by a client to

provide authentication data to a server.

You may have noticed that there are no commands related to security described in the RFC

977 protocol. That's because the original NNTP had no security features whatsoever. Like

many protocols written before the modern Internet era, security was not considered a big

issue back in the early 1980s. Most news servers were used only by people within the

organization owning the server, and simple security measures were used, such as

restricting access to servers by IP address or through the use of access lists.

One of the more important changes made by many NNTP software implementation as soon

as Usenet grew in size was to require authentication. Modern clients will usually issue

AUTHINFO as one of its first commands upon establishing a connection to a server,

because the server will refuse to accept most other commands before this is done. A

special reply code is also added to NNTP for a server to use if it rejects a command due to

improper authentication.

The AUTHINFO command can be invoked in several different ways. The original version of

the command required the client to issue an AUTHINFO USER command with a user

name, followed by AUTHINFO PASS with a password. Naturally, this is simple user/

password login authentication. A variation of this is the AUTHINFO SIMPLE command,

where the client needs to send just a password.

A client and server can also agree to use more sophisticated authentication methods by

making use of the AUTHINFO GENERIC command. The client provides to the server the

name of the authentication method it wants to use, along with any arguments required for

authentication. The client and server then exchange messages and authentication infor-

mation as required by the particular authenticator they are using.

Key Concept: A number of limitations in its base command set led to a proliferation

of non-standard enhancements to NNTP during the 1980s and 1990s. These were

eventually documented in a set of NNTP command extensions that formally

supplement the original RFC 977 commands. The extensions are conceptually divided into

three groups: transport extensions that refine how NNTP propagates messages;

newsreader extensions that improve client article access; and miscellaneous extensions, of

which the most important is the AUTHINFO extension that adds security to NNTP.

NNTP Status Responses and Response Codes

Each time the device acting as a client in an NNTP connection sends a command, the

server sends back a response. The response serves to acknowledge receipt of the

command, to inform the client of the results of processing the command, and possibly to

prompt for additional information. Since NNTP commands are structured and formatted in a

way very similar to that of SMTP commands, I'm sure it will come as no great surprise that

NNTP responses are likewise very similar to those of SMTP. In turn, SMTP responses are

based on the system designed for replies in FTP.

The first line of an NNTP response consists of a three-digit numerical response code, as

well as a line of descriptive text that summarizes the response. These response codes are

structured so that each digit has a particular significance, which allows the client to quickly

determine the status of the command to which the reply was sent. After the initial response

line, depending on the reply, a number of additional response lines may follow. For

example, a successful LIST command results in a 215 response code, followed by a list of

newsgroups.

Background Information: The topic on FTP reply codes discusses more

completely the reasons why numeric reply codes are used in addition to descriptive

text.

Reply Code Structure and Digit Interpretation

As with SMTP and FTP, NNTP reply codes can be considered to be of the form “xyz”, where

“x” is the first digit, “y” the second and “z” the third.

First Reply Code Digit (“x”)

The first digit indicates the success, failure or progress of the command in general terms,

whether a successful command is complete or incomplete, and the general reason why an

unsuccessful command did not work. The values of this digit are defined slightly differently

than in SMTP and FTP. In some cases, the terminology is just simplified; for example, the

second category is “Command OK” instead of “Positive Completion Reply”. Table 271

shows the specific meaning of the possible values of this digit.

Table 271: NNTP Reply Code Format: First Digit Interpretation (Page 1 of 2)

Code

Format

Meaning Description

1yz Informative Message General information; used for help information and debugging.

2yz Command OK The command was completed successfully.

Second Reply Code Digit (“y”)

The second digit categorizes messages into functional groups. This digit is used in the

same general way as in SMTP and FTP, but the functional groups are different; they are

described in Table 272.

Third Reply Code Digit (“z”)

This last digit indicates a specific type of message within each of the functional groups

described by the second digit. The third digit allows each functional group to have 10

different reply codes for each reply type given by the first code digit.

3yz

Command OK So Far,

Send The Rest

An intermediate reply, sent to prompt the client to send more infor-

mation. Typically used for replies to commands such as IHAVE or

POST, where the server acknowledges the command and then

requests that an article be transmitted by the client.

4yz

Command Was

Correct, But Couldn't

Be Performed

The command was valid but could not be performed. This type of

error usually occurs due to bad parameters, a transient problem with

the server, bad command sequence or similar situations.

5yz

Command Unimple-

mented Or Incorrect,

Or Serious Program

Error

The command was invalid or a significant program error prevented it

from being performed.

Table 272: NNTP Reply Code Format: Second Digit Interpretation

Code

Format

Meaning Description

x0z

Connection, Setup

and Miscellaneous

Generic and miscellaneous replies.

x1z Newsgroup Selection Messages related to commands used to select a newsgroup.

x2z Article Selection Messages related to commands used to select an article.

x3z Distribution Functions Messages related to the transfer of messages.

x4z Posting Messages related to posting messages.

x5z Authentication

Messages related to authentication and the AUTHINFO command

extension. (This category is not officially listed in the standard, but

these responses have a middle digit of “5”).

x8z

Nonstandard

Extensions

Reserved for private, non-standard implementation use.

x9z Debugging Debugging output messages.

Table 271: NNTP Reply Code Format: First Digit Interpretation (Page 2 of 2)

Code

Format

Meaning Description

Combining Digit Values to Make Specific Reply Codes

As in FTP and SMTP, these “x”, “y” and “z” digit meanings are combined to make specific

reply codes. For example, the reply code “435” is sent by the server if a client issues the

IHAVE command but the server doesn't want the article being offered. The command was

correct but the reply is negative, thus it starts with “4”, and the message is related to

message distribution, so the middle digit is “3”.

Common NNTP Reply Codes

Table 273 contains a list of some of the more common NNTP reply codes in numerical

order, along with typical reply text from the standard, and additional descriptive information.

Table 273: NNTP Reply Codes (Page 1 of 3)

Code

Reply Text Description

100 help text follows Precedes response to HELP command.

111 (date and time) Response to DATE command extension.

199 (debugging output) Debugging information.

200 server ready - posting allowed

Sent by the server upon initiation of the session, if the

client is allowed to post messages.

201 server ready - no posting allowed

Sent by the server upon initiation of the session, if the

client is not allowed to post messages.

202 slave status noted Response to the SLAVE command.

203 streaming is ok Successful response to MODE STREAM command.

205 closing connection - goodbye! Goodbye message sent in response to a QUIT message.

211 n f l s group selected

Successful response to the GROUP command, indicating

the estimated number of messages in the group (“n”), first

and last article numbers (“f” and “l”) and group name (“s”).

215

list of newsgroups follows (OR)

information follows

Successful response to LIST command. The second form

is for variations of LIST defined as NNTP command

extensions.

218 tin-style index follows Successful response to XINDEX command extension.

220

n <a> article retrieved - head and

body follow

Successful response to the ARTICLE command, indicating

the article number and message ID of the article.

221

n <a> article retrieved - head

follows

Successful response to the HEAD command, indicating

the article number and message ID of the article.

222

n <a> article retrieved - body

follows

Successful response to the BODY command, indicating

the article number and message ID of the article.

223

n <a> article retrieved - request

text separately

Successful response to the STAT command, indicating the

article number and message ID of the article.

224 overview information follows Successful response to the XOVER command extension.

230

list of new articles by message-id

follows

Successful response to the NEWNEWS command.

235 article transferred ok

Successful response to the IHAVE command, after article

has been sent.

239 article transferred ok Successful response to the TAKETHIS command.

240 article posted ok

Successful response to the POST command, after article

has been posted.

250 or 281 authentication accepted

Successful authentication using the AUTHINFO command

extension.

282

list of groups and descriptions

follows

Positive response to the XGTITLE command extension.

288 binary data to follow

Successful response to the XTHREAD command

extension.

335 send article to be transferred Preliminary response to the IHAVE command.

340 send article to be posted Preliminary response to the POST command.

381

more authentication information

required

Preliminary response to the AUTHINFO command

extension.

400 service discontinued Session is being terminated, perhaps due to user request.

411 no such newsgroup Invalid newsgroup name specified.

412 no newsgroup has been selected

Attempt to issue a command that refers to the current

newsgroup before one has been selected using GROUP.

420

no current article has been

selected

Attempt to issue a command that refers to the current

article using the server's current article pointer, before the

pointer has been set through article selection.

421 no next article in this group

Response to NEXT command when at last article of a

newsgroup.

422 no previous article in this group

Possible response to LAST; I have no idea why the word

“previous” is in there.

423

no such article number in this

group

Command with invalid article number.

430 no such article found Article not found; it may have been deleted.

435 article not wanted - do not send it

Negative response to IHAVE if server doesn't need the

article.

436 transfer failed - try again later Temporary failure of article transfer, retry.

437 article rejected - do not try again Article refused for whatever reason.

438

already have it, please don't send

it to me

Same as reply code 435, but for the CHECK command

extension.

440 posting not allowed POST command issued when posting is not allowed.

Table 273: NNTP Reply Codes (Page 2 of 3)

Code

Reply Text Description