GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2980

Network Working Group S. Barber Request for Comments: 2980 Academ Consulting Services Category: Informational October 2000

                       Common NNTP Extensions

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

 In this document, a number of popular extensions to the Network News
 Transfer Protocol (NNTP) protocol defined in RFC 977 are documented
 and discussed.  While this document is not intended to serve as a
 standard of any kind, it will hopefully serve as a reference document
 for future implementers of the NNTP protocol.  In the role, this
 document would hopefully create the possibility for some level of
 interoperability among implementations that make use of extensions.

Introduction

 RFC 977 [1] defines the NNTP protocol and  was released over a decade
 ago.  Since then, NNTP has become one of the most popular protocols
 in use on the Internet.  Many implementations of the protocol have
 been created on many different platforms and operating systems.  With
 the growth in use of the protocol, work began on a revision to NNTP
 in 1991, but that work did not result in a new standard protocol
 specification.  However, many ideas from that working group did find
 their way into many implementations of NNTP.  Additionally, many
 other extensions, often created by newsreader authors, are also in
 use.  This document will capture and define all known extensions to
 NNTP available in official NNTP server releases of some type as of
 this writing.  Where possible, the server software first implementing
 a particular extension will be noted.  It is the hope of the author
 that using this document in tandem with RFC 977 will limit the
 addition of new extensions that essentially do the same thing.
 Software developers may wish to use this document and others [2] as a
 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.  It
 only attempts to document current practices.  While this document may
 clarify some ambiguity in RFC 977, RFC 977 should be regarded as
 authoritative in all cases.  There are some implementations that are
 not strictly RFC 977 compliant and where necessary, these deviations
 from the standard will be noted.  This document does reflect the work
 of the IETF NNTP-EXT working group chaired by Ned Freed and Stan
 Barber.
 This document is provided to help implementers have a uniform source
 of information about extensions, however, it is important for any
 prospective implementer to understand that the extensions listed here
 are NOT part of any current standard for NNTP.  In fact, some of the
 ones listed in this document should not be included in new NNTP
 implementations as they should no longer be used modern NNTP
 environments.  Such commands should be considered historic and are
 documented as such in this document.
 Extensions fall into three categories: transport, newsreader and
 other.  Transport extensions are additions to the NNTP specification
 that were made specifically to move news articles from one server to
 another server.  Newsreader extensions are additions to the NNTP
 specification that were made to assist NNTP clients in selecting and
 retrieving news articles from servers.  Other extensions to the NNTP
 specification are those which did not specifically fall into either
 of the other two categories.  Examples of other extensions include
 authentication and time-of-day extensions.  For each command, the
 format of section 3 of RFC 977 will be used.

1. Transport Extensions

 A transport extension is one which is primarily used in inter-server
 communications.  Following are the descriptions of each transport
 extension commands and the responses which will be returned by those
 commands.
 Each command is shown in upper case for clarity, although case is
 ignored in the interpretation of commands by the NNTP server.  Any
 parameters are shown in lower case.  A parameter shown in [square
 brackets] is optional.  For example, [GMT] indicates that the
 triglyph GMT may present or omitted.  A parameter that may be
 repeated is followed by an ellipsis.

Barber Informational [Page 2] RFC 2980 Common NNTP Extensions October 2000

1.1.1 The CHECK command

 CHECK <message-id>
 CHECK is used by a peer to discover if the article with the specified
 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 before
 sending the next command.
 From using the responses to the sequence of CHECK commands, a list of
 articles to be sent can be constructed for subsequent use by the
 TAKETHIS command.
 The use of the CHECK command for streaming is optional.  Some
 implementations will directly use the TAKETHIS command and send all
 articles in the send queue on that peer for the server.
 On some implementations, the use of the CHECK command is not
 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 the
 response.

1.1.2. Responses

    238 no such article found, please send it to me
    400 not accepting articles
    431 try sending it again later
    438 already have it, please don't send it to me
    480 Transfer permission denied
    500 Command not understood

1.2.1 The MODE STREAM command

 MODE STREAM
 MODE STREAM is used by a peer to indicate to the server that it would
 like to suspend the lock step conversational nature of NNTP and send
 commands in streams.  This command should be used before TAKETHIS and
 CHECK.  See the section on the commands TAKETHIS and CHECK for more
 details.

1.2.2. Responses

    203 Streaming is OK
    500 Command not understood

Barber Informational [Page 3] RFC 2980 Common NNTP Extensions October 2000

1.3.1 The TAKETHIS command

 TAKETHIS <message-id>
 TAKETHIS is used to send articles to a server when in streaming mode.
 The entire article (header and body, in that sequence) is sent
 immediately after the peer sends the TAKETHIS command.  The peer does
 not have to wait for a response from the server before sending the
 next command and the associated article.
 During transmission of the article, the peer should send the entire
 article, including header and body, in the manner specified for text
 transmission from the server.  See RFC 977, Section 2.4.1 for
 details.
 Responses that are of the form X3X must specify the message-id in the
 response.

1.3.2. Responses

    239 article transferred ok
    400 not accepting articles
    439 article transfer failed
    480 Transfer permission denied
    500 Command not understood

1.4.1 The XREPLIC command

 XREPLIC ggg:nnn[,ggg:nnn...]
 The XREPLIC command makes is possible to exactly duplicate the news
 spool structure of one server in another server.  It first appeared
 in INN.
 This command works similarly to the IHAVE command as specified in RFC
 977.  The same response codes are used.  The command line arguments
 consist of entries separated by a single comma.  Each entry consists
 of a news group name, a colon, and an article number.  If the server
 responds with a 335 response, the article should be filed in the news
 group(s) and article number(s) specified in the XREPLIC command line.
 If the server cannot do successfully install the article once it has
 accepted it, a 436 or 437 response code can be used to indicate the
 failure.
 This command should only be used when the receiving server is being
 fed by only one other server.  It is likely that when used with
 servers that have multiple feeds that this command will frequently
 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 previous
 versions, this header was generated locally and stripped off on
 outgoing feeds.)
 It is likely that future versions of INN will no longer support
 XREPLIC.

1.4.2. Responses

    235 article transferred ok
    335 send article to be transferred.  End with <CR-LF>.<CR-LF>
    435 article not wanted - do not send it
    436 transfer failed - try again later
    437 article rejected - do not try again

2. Newsreader Extensions

 Newsreader extensions are those which are primarily used by
 newsreading clients.  Following are the descriptions of each
 newsreader extension commands and the responses which will be
 returned by those commands.
 Each command is shown in upper case for clarity, although case is
 ignored in the interpretation of commands by the NNTP server.  Any
 parameters are shown in lower case.  A parameter shown in [square
 brackets] is optional.  For example, [GMT] indicates that the
 triglyph GMT may present or omitted.  A parameter that may be
 repeated is followed by an ellipsis.  Mutually exclusive parameters
 are separated by a vertical bar (|) character.  For example,
 ggg|<message-id> indicates that  a group name or a <message-id> may
 be specified, but not both.  Some parameters, notably <message-id>,
 is case specific.  See RFC 1036 for these details.
 Also, certain commands make use of a pattern for selection of
 multiple news groups.  The pattern in all cases is based on the
 wildmat [4] format introduced by Rich Salz in 1986.  Arguments
 expected to be in wildmat format will be represented by the string
 wildmat.  This format is discussed in detail in section 3.3 of this
 document.

2.1.1 Extensions to the LIST command

 The original LIST command took no arguments in RFC 977 and returned
 the contents of the active file in a specific format.  Since the
 original newsreaders made use of other information available in the
 news transport software in addition to the active file, extensions to

Barber Informational [Page 5] RFC 2980 Common NNTP Extensions October 2000

 the LIST command were created to make that information available to
 NNTP newsreaders.  There may be other extensions to the LIST command
 that simply return the contents of a file.  This approach is
 suggested over the addition of over verbs.  For example, LIST MOTD
 could be used instead of adding XMOTD.

2.1.2 LIST ACTIVE

 LIST ACTIVE [wildmat]
 LIST ACTIVE is exactly the same as the LIST command specified in RFC
 977.  The responses and the format should exactly match the LIST
 command without arguments.  If the optional matching parameter is
 specified, the list is limited to only the groups that match the
 pattern.  Specifying a single group is usually very efficient for the
 server, and multiple groups may be specified by using wildmat
 patterns (described later in this document), not regular expressions.
 If nothing is matched an empty list is returned, not an error.  This
 command first appeared in the UNIX reference version.

2.1.3 LIST ACTIVE.TIMES

 LIST ACTIVE.TIMES
 The active.times file is maintained by some news transports systems
 to contain information about the when and who created a particular
 news group.  The format of this file generally include three fields.
 The first field is the name of the news group.  The second is the
 time when this group was created on this news server measured in
 seconds since January 1, 1970.  The third is the email address of the
 entity that created the news group.  When executed, the information
 is displayed following the 215 response.  When display is completed,
 the server will send a period on a line by itself.  If the
 information is not available, the server will return the 503 error
 response.  This command first appeared in the UNIX reference version.

2.1.3.1 Responses

    215 information follows
    503 program error, function not performed

2.1.4 LIST DISTRIBUTIONS

 LIST DISTRIBUTIONS
 The distributions file is maintained by some news transport systems
 to contain information about valid values for the Distribution: line
 in a news article header and about what the values mean.  Each line

Barber Informational [Page 6] RFC 2980 Common NNTP Extensions October 2000

 contains two fields, the value and a short explanation on the meaning
 of the value.  When executed, the information is displayed following
 the 215 response.  When display is completed, the server will send a
 period on a line by itself.  If the information is not available, the
 server will return the 503 error response.  This command first
 appeared in the UNIX reference version.

2.1.4.1 Responses

    215 information follows
    503 program error, function not performed

2.1.5 LIST DISTRIB.PATS

 LIST DISTRIB.PATS
 The distrib.pats file is maintained by some news transport systems to
 contain default values for the Distribution:  line in a news article
 header when posting to particular news groups.  This information
 could be used to provide a default value for the Distribution: line
 in the header when posting an article.  The information returned
 involves three fields separated by colons.  The first column is a
 weight.  The second is a group name or a pattern that can be used to
 match a group name in the wildmat format.  The third is the value of
 the Distribution:  line that should be used when the group name
 matches and the weight value is the highest.  All this processing is
 done by the news posting client and not by the server itself.  The
 server just provides this information to the client for it to use or
 ignore as it chooses.  When executed, the information is displayed
 following the 215 response.  When display is completed, the server
 will send a period on a line by itself.  If the information is not
 available, the server will return the 503 error response.  This
 command first appeared in INN.

2.1.5.1 Responses

    215 information follows
    503 program error, function not performed

2.1.6 LIST NEWSGROUPS

 LIST NEWSGROUPS [wildmat]
 The newsgroups file is maintained by some news transport systems to
 contain the name of each news group which is active on the server and
 a short description about the purpose of each news group.  Each line
 in the file contains two fields, the news group name and a short
 explanation of the purpose of that news group.  When executed, the

Barber Informational [Page 7] RFC 2980 Common NNTP Extensions October 2000

 information is displayed following the 215 response.  When display is
 completed, the server will send a period on a line by itself.  If the
 information is not available, the server will return the 503
 response.  If the optional matching parameter is specified, the list
 is limited to only the groups that match the pattern (no matching is
 done on the group descriptions).  Specifying a single group is
 usually very efficient for the server, and multiple groups may be
 specified by using wildmat patterns (similar to file globbing), not
 regular expressions.  If nothing is matched an empty list is
 returned, not an error.
 When the optional parameter is specified, this command is equivalent
 to the XGTITLE command, though the response code are different.
    215 information follows
    503 program error, function not performed

2.1.7 LIST OVERVIEW.FMT

 LIST OVERVIEW.FMT
 The overview.fmt file is maintained by some news transport systems to
 contain the order in which header information is stored in the
 overview databases for each news group.  When executed, news article
 header fields are displayed one line at a time in the order in which
 they are stored in the overview database [5] following the 215
 response.  When display is completed, the server will send a period
 on a line by itself.  If the information is not available, the server
 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 the
 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 any
 server that implements the XOVER command.  See section 2.8 for more
 details about the XOVER command.

2.1.7.1 Responses

    215 information follows
    503 program error, function not performed

Barber Informational [Page 8] RFC 2980 Common NNTP Extensions October 2000

2.1.8 LIST SUBSCRIPTIONS

 LIST SUBSCRIPTIONS
 This command is used to get a default subscription list for new users
 of this server.  The order of groups is significant.
 When this list is available, it is preceded by the 215 response and
 followed by a period on a line by itself.  When this list is not
 available, the server returns a 503 response code.

2.1.8.1 Responses

    215 information follows
    503 program error, function not performed

2.2 LISTGROUP

 LISTGROUP [ggg]
 The LISTGROUP command is used to get a listing of all the article
 numbers in a particular news group.
 The optional parameter ggg is the name of the news group to be
 selected (e.g. "news.software.b").  A list of valid news groups may
 be obtained from the LIST command.  If no group is specified, the
 current group is used as the default argument.
 The successful selection response will be a list of the article
 numbers in the group followed by a period on a line by itself.
 When a valid group is selected by means of this command, the
 internally maintained "current article pointer" is set to the first
 article in the group.  If an invalid group is specified, the
 previously selected group and article remain selected.  If an empty
 news group is selected, the "current article pointer" is in an
 indeterminate state and should not be used.
 Note that the name of the news group is not case-dependent.  It must
 otherwise match a news group obtained from the LIST command or an
 error will result.

2.2.1 Responses

    211 list of article numbers follow
    412 Not currently in newsgroup
    502 no permission

Barber Informational [Page 9] RFC 2980 Common NNTP Extensions October 2000

2.3 MODE READER

 MODE READER is used by the client to indicate to the server that it
 is a news reading client.  Some implementations make use of this
 information to reconfigure themselves for better performance in
 responding to news reader commands.  This command can be contrasted
 with the SLAVE command in RFC 977, which was not widely implemented.
 MODE READER was first available in INN.

2.3.1 Responses

    200 Hello, you can post
    201 Hello, you can't post

2.4 XGTITLE

 XGTITLE [wildmat]
 The XGTITLE command is used to retrieve news group descriptions for
 specific news groups.
 This extension first appeared in ANU-NEWS, an NNTP implementation for
 DEC's VMS.  The optional parameter is a pattern in wildmat format.
 When executed, a 282 response is given followed by lines that have
 two fields, the news group name (which matches the pattern in the
 argument) and a short explanation of the purpose of the news group.
 When no argument is specified, the default argument is the current
 group name.  When display is completed, the server sends a period on
 a line by itself.
 Please note that this command and the LIST NEWSGROUP command provide
 the same functionality with different response codes.
 Since this command provides the same functionality as LIST NEWSGROUP
 it is suggested that this extension be deprecated and no longer be
 used in newsreading clients.
 Note that there is a conflict in one of the response codes from
 XGTITLE and some of the authentication extensions.

2.5.1 Responses

    481 Groups and descriptions unavailable
    282 list of groups and descriptions follows

Barber Informational [Page 10] RFC 2980 Common NNTP Extensions October 2000

2.6 XHDR

 XHDR header [range|<message-id>]
 The XHDR command is used to retrieve specific headers from specific
 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 header
 lines.  The optional range argument may be any of the following:
             an article number
             an article number followed by a dash to indicate
                all following
             an article number followed by a dash followed by
                another article number
 The optional message-id argument indicates a specific article.  The
 range and message-id arguments are mutually exclusive.  If no
 argument is specified, then information from the current article is
 displayed.  Successful responses start with a 221 response followed
 by a the matched headers from all matched messages.  Each line
 containing matched headers returned by the server has an article
 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 in
 that article.  Once the output is complete, a period is sent on a
 line by itself.  If the optional argument is a message-id and no such
 article exists, the 430 error response is returned.  If a range is
 specified, a news group must have been selected earlier, else a 412
 error response is returned.  If no articles are in the range
 specified, a 420 error response is returned by the server.  A 502
 response will be returned if the client only has permission to
 transfer articles.
 Some implementations will return "(none)" followed by a period on a
 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 by
 itself.
 The XHDR command has been available in the UNIX reference
 implementation from its first release.  However, until now, it has
 been documented only in the source for the server.

Barber Informational [Page 11] RFC 2980 Common NNTP Extensions October 2000

2.6.1 Responses

    221 Header follows
    412 No news group current selected
    420 No current article selected
    430 no such article
    502 no permission

2.7 XINDEX

 XINDEX ggg
 The XINDEX command is used to retrieve an index file in the format of
 originally created for use by the TIN [6] news reader.
 The required parameter ggg is the name of the news group to be
 selected (e.g. "news.software.b").  A list of valid news groups may
 be obtained from the LIST command.
 The successful selection response will return index file in the
 format used by the TIN news reader followed by a period on a line by
 itself.
 When a valid group is selected by means of this command, the
 internally maintained "current article pointer" is set to the first
 article in the group.  If an invalid group is specified, the
 previously selected group and article remain selected.  If an empty
 news group is selected, the "current article pointer" is in an
 indeterminate state and should not be used.
 Note that the name of the news group is not case-dependent.  It must
 otherwise match a news group obtained from the LIST command or an
 error will result.
 The format of the tin-style index file is discussed in the
 documentation for the TIN newsreader.  Since more recent versions of
 TIN support the news overview (NOV) format, it is recommended that
 this extension become historic and no longer be used in current
 servers or future implementations.

2.7.1 Responses

    218 tin-style index follows
    418 no tin-style index is available for this news group

Barber Informational [Page 12] RFC 2980 Common NNTP Extensions October 2000

2.8 XOVER

 XOVER [range]
 The XOVER command returns information from the overview database for
 the article(s) specified.  This command was originally suggested as
 part of the OVERVIEW work described in "The Design of a Common
 Newsgroup Overview Database for Newsreaders" by Geoff Collyer.  This
 document is distributed in the Cnews distribution.  The optional
 range argument may be any of the following:
             an article number
             an article number followed by a dash to indicate
                all following
             an article number followed by a dash followed by
                another article number
 If no argument is specified, then information from the current
 article is displayed.  Successful responses start with a 224 response
 followed by the overview information for all matched messages.  Once
 the output is complete, a period is sent on a line by itself.  If no
 argument is specified, the information for the current article is
 returned.  A news group must have been selected earlier, else a 412
 error response is returned.  If no articles are in the range
 specified, a 420 error response is returned by the server.  A 502
 response will be returned if the client only has permission to
 transfer articles.
 Each line of output will be formatted with the article number,
 followed by each of the headers in the overview database or the
 article itself (when the data is not available in the overview
 database) for that article separated by a tab character.  The
 sequence of fields must be in this order: subject, author, date,
 message-id, references, byte count, and line count.  Other optional
 fields may follow line count.  Other optional fields may follow line
 count.  These fields are specified by examining the response to the
 LIST OVERVIEW.FMT command.  Where no data exists, a null field must
 be provided (i.e. the output will have two tab characters adjacent to
 each other).  Servers should not output fields for articles that have
 been removed since the XOVER database was created.
 The LIST OVERVIEW.FMT command should be implemented if XOVER is
 implemented.  A client can use LIST OVERVIEW.FMT to determine what
 optional fields  and in which order all fields will be supplied by
 the XOVER command.  See Section 2.1.7 for more details about the LIST
 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 that
 is returned will be converted to a space character.

2.8.1 Responses

    224 Overview information follows
    412 No news group current selected
    420 No article(s) selected
    502 no permission

2.9 XPAT

 XPAT header range|<message-id> pat [pat...]
 The XPAT command is used to retrieve specific headers from specific
 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 valid
 header lines.  The required range argument may be any of the
 following:
             an article number
             an article number followed by a dash to indicate
                all following
             an article number followed by a dash followed by
                another article number
 The required message-id argument indicates a specific article.  The
 range and message-id arguments are mutually exclusive.  At least one
 pattern in wildmat must be specified as well.  If there are
 additional arguments the are joined together separated by a single
 space to form one complete pattern.  Successful responses start with
 a 221 response followed by a the headers from all messages in which
 the pattern matched the contents of the specified header line.  This
 includes an empty list.  Once the output is complete, a period is
 sent on a line by itself.  If the optional argument is a message-id
 and no such article exists, the 430 error response is returned.  A
 502 response will be returned if the client only has permission to
 transfer articles.

2.9.1 Responses

    221 Header follows
    430 no such article
    502 no permission

Barber Informational [Page 14] RFC 2980 Common NNTP Extensions October 2000

2.10 The XPATH command

 XPATH <message-id>
 The XPATH command is used to determine the filenames in which an
 article is filed.  It first appeared in INN.
 The required parameter message-id is the message id of an article as
 shown in that article's message-id header.  According to RFC 1036
 [3], all message ids for all articles within the netnews environment
 are unique, but articles may be crossposted to multiple groups.  The
 response to an XPATH command will include a listing of all filenames
 in which an article is stored separated by spaces or a response
 indicating that no article with the specified message-id exists.  The
 returned data is only useful if the news client knows the
 implementation details of the server.  Because of this, it is
 recommended that client avoid using this command.

2.10.1 Responses

    223 path1[ path2 ...]
    430 no such article on server

2.11 The XROVER command

 XROVER [range]
 The XROVER command returns reference information from the overview
 database for the article(s) specified.  This command first appeared
 in the Unix reference implementation.  The optional range argument
 may be any of the following:
             an article number
             an article number followed by a dash to indicate
                  all following
             an article number followed by a dash followed by
                 another article number
 Successful responses start with a 224 response followed by the
 contents of reference information for all matched messages.  Once the
 output is complete, a period is sent on a line by itself.  If no
 argument is specified, the information for the current article is
 returned.  A news group must have been selected earlier, else a 412
 error response is returned.  If no articles are in the range
 specified, a 420 error response is returned by the server.  A 502
 response will be returned if the client only has permission to
 transfer articles.

Barber Informational [Page 15] RFC 2980 Common NNTP Extensions October 2000

 The output will be formatted with the article number, followed by the
 contents of the References: line for that article, but does not
 contain the field name itself.
 This command provides the same basic functionality as using the XHDR
 command and "references" as the header argument.

2.11.1 Responses

    224 Overview information follows
    412 No news group current selected
    420 No article(s) selected
    502 no permission

2.12 XTHREAD

 XTHREAD [DBINIT|THREAD]
 The XTHREAD command is used to retrieve threading information
 in format of originally created for use by the TRN [6] news
 reader.
 The command XTHREAD DBINIT may be issued prior to entering
 any groups to see if a thread database exists.  If it does,
 the database's byte order and version number are returned
 as binary data.
 If no parameter is given, XTHREAD THREAD is assumed.
 To use XTHREAD THREAD, a news group must have been selected
 earlier, else a 412 error response is returned.
 A 502 response will be returned if the client only has
 permission to transfer articles.  A 503 response is returned
 if the threading files are not available.
 The format of the trn-style thread format is discussed in
 the documentation for the TRN newsreader.  Since more recent
 versions of TRN support the news overview (NOV) format, it
 is recommended that this extension become historic and no
 longer be used in current servers or future implementations.

2.12.1 Responses

    288 Binary data to follow
    412 No newsgroup current selected
    502 No permission
    503 program error, function not performed

Barber Informational [Page 16] RFC 2980 Common NNTP Extensions October 2000

3. 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).

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 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.

Barber Informational [Page 18] RFC 2980 Common NNTP Extensions October 2000

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.

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 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

Barber Informational [Page 20] RFC 2980 Common NNTP Extensions October 2000

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.

Barber Informational [Page 21] RFC 2980 Common NNTP Extensions October 2000

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.

4.0 Common Implementation Issues

 Many NNTP implementations do not follow the specifications in RFC
 977.  In this section, some common implementation issues are
 summarized.

4.1 The Response to the LIST command

 RFC 977 says that the fourth field of the "list of valid newsgroups
 associated information" returned must be "either 'y' or 'n'
 indicating whether posting to this newsgroup is allowed ('y') or
 prohibited ('n').  Most implementations simply output the exact
 contents of the transport system's active newsgroup list.  For more
 implementations, the fourth field usually has more values that 'y' or
 'n'.

Barber Informational [Page 22] RFC 2980 Common NNTP Extensions October 2000

4.2 The Required Headers in an Article and the POST command

 RFC 977 notes in section 3.10.1 that articles presented "should
 include all required header lines." In fact, modern implementations
 only require From, Subject, and Newsgroups header lines and will
 supply the rest; further, many implementers believe that it is best
 for clients to generate as few headers as possible, since clients
 often do not format other headers correctly.
 This implementation behavior is consistent with both Bnews and Cnews
 which would supply missing headers for articles directly submitted to
 them.

4.3 Article Numbering

 RFC 977 does not directly address the rules concerning articles
 number.  However, the current practice is simple: article numbers are
 monotonically increasing, articles may disappear, and therefore the
 high and low water marks returned in a GROUP command should be
 treated as maximum minima, and minimum maxima, respectively.

4.4 Availability of commands defined in RFC 977

 Some implementations permit administrators to disable commands
 defined RFC 977.  Some implementations have some set of commands
 disabled by default.  This means that client implementations cannot
 depend on the availability of the disabled set of commands.  This
 increases the complexity of the client and does not encourage
 implementors to optimize the implementation of commands that don't
 perform well.
 NEWNEWS is one of the commands frequently disabled.

4.5 The Distribution header and NEWNEWS

 In section 12.4 of RFC 977, the optional distributions argument is
 described.  This argument, according to RFC 977, would limit the
 responses to articles that were in newsgroups with prefixes that
 matched the optional distributions argument.
 Some implementations implement this by matching the Distributions
 header in articles to the distribution argument.  Others do the match
 against segments of the newsgroup's name.
 This variation is probably best explained by the evolution of the
 USENET article format.  At the time RFC 977 was specified, the
 newsgroup name defined how the group was distributed throughout
 USENET.  RFC 1036 changed this convention.  So, those that are

Barber Informational [Page 23] RFC 2980 Common NNTP Extensions October 2000

 strictly implementing RFC 977 would match the newsgroup name prefix
 against the distribution argument and only display matches.  Those
 that implement against the intent of the command (as modified by the
 redefinition of the article format)would match the Distributions
 header against the distribution argument and only display those
 matches.

5.0 Further Work

 With the continued use of NNTP on the Internet, there remains an
 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 building
 better mechanisms to provide audit information on which news groups
 are being read by which users.
 An IETF working group has been formed and it is the hope of this
 author that these issues will be addressed in that forum.

6.0 Security Considerations

 The use of the AUTHINFO is optional.  This command as documented has
 a number of security implications.  In the original and simple forms,
 all passwords are passed in plaintext and could be discovered by
 various forms of network or system surveillance.  The AUTHINFO
 GENERIC command has the potential for the same problems if a
 mechanism is used that also passes cleartext passwords.  RFC 1731 [8]
 discusses these issues in greater detail.

7.0 References

 [1]  Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
      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 USENET
      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 General
      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.html
 [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_newsreader
      _FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
      -hierarchy/news/software/readers/%5Bnews.software.readers
      %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 Notes

 DEC is a registered trademark of Compaq Computer Corporation.  UNIX
 is a registered trademark of The Open Group.  VMS is a registered
 trademark of Compaq Computer Corporation.

9.0 Acknowledgments

 The author gratefully acknowledges the comments and additional
 information provided by the following individuals:
 Wayne Davison <davison@armory.com>
 Chris Lewis <clewis@bnr.ca>
 Tom Limoncelli <tal@lucent.com>
 Eric Schnoebelen <eric@egsner.cirr.com>
 Rich Salz <rsalz@osf.org>
 This work was precipitated by the work of various newsreader authors
 and newsserver authors which includes those listed below:
 Rick Adams    -- Original author of the NNTP extensions to the RN
                  newsreader and last maintainer of Bnews
 Stan Barber   -- Original author of the NNTP extensions to the
                  newsreaders that are part of Bnews.
 Geoff Collyer -- Original author of the OVERVIEW database proposal and
                  one of the original authors of CNEWS
 Dan Curry     -- Original author of the xvnews newsreader
 Wayne Davison -- Author of the first threading extensions to the
                  RN newsreader (commonly called TRN).
 Geoff Huston  -- Original author of ANU NEWS

Barber Informational [Page 25] RFC 2980 Common NNTP Extensions October 2000

 Phil Lapsey   -- Original author of the UNIX reference
                  implementation
 Iain Lea      -- Original maintainer of the TIN newsreader
 Chris Lewis   -- First known implementor of the AUTHINFO GENERIC
                  extension
 Rich Salz     -- Original author of INN
 Henry Spencer -- One of the original authors of CNEWS
 Kim Storm     -- Original author of the NN newsreader

10.0 Author's Address

 Stan Barber
 P.O. Box 300481
 Houston, Texas, 77230
 EMail: sob@academ.com

Barber Informational [Page 26] RFC 2980 Common NNTP Extensions October 2000

11.0 Full Copyright Statement

 Copyright (C) The Internet Society (2000).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Barber Informational [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2980.txt · Last modified: 2000/10/17 20:01 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki