HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:44:24 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 21 Jun 1995 22:00:00 GMT ETag: "2e7d7e-a408-2fe89660" Accept-Ranges: bytes Content-Length: 41992 Connection: close Content-Type: text/plain INTERNET-DRAFT S. Barber Expires: November 25, 1995 Academ Consulting Services June 1995 Common NNTP Extensions draft-barber-nntp-imp-00.txt Status of this Document This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract In this document, a number of popular extensions to the NNTP protocol defined in RFC977 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 implementors 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 RFC977[1] defines the NNTP protocol and was released almost 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 protocol specification. However, many ideas from that working group did find their way into many implementations of NNTP. Additionally, many other extensions are also in use. This document will capture and define all known extensions to NNTP as of this writing. It is the hope of the authors that using this document in tandem with RFC977 will limit the addition of new extensions that essentially do the same thing and provide for the Barber [Page 1] INTERNET-DRAFT Common NNTP Extensions June 1995 creation of a new forum to discuss an official revision of the NNTP specification. 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 RFC977, RFC977 should be regarded as authoritative in all cases. There are some implementations that are not strictly RFC977 compliant and where necessary, these deviations from the standard will be noted. 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 RFC977 will be used. 1. Transport Extensions 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. 1.1.1 The XPATH command XPATH The XPATH command is used to determine the filenames in which an article is filed. The required parameter message-id is the message id of an article as shown in that article's header. According to RFC 1036[2], 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 Barber [Page 2] INTERNET-DRAFT Common NNTP Extensions June 1995 exists. 1.1.2. Responses 223 path1[ path2 ...] 430 no such article on server 1.2.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. This command works similarly to the IHAVE command as specified in RFC977. 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 responses 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. 1.2.2. Responses 235 article transferred ok 335 send article to be transferred. End with . 435 article not wanted - do not send it 436 transfer failed - try again later 437 article rejected - do not try again 2. Newsreader Extensions 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| Barber [Page 3] INTERNET-DRAFT Common NNTP Extensions June 1995 indicates that a group name or a may be specified, but not both. Also, certain commands make use of a pattern for selection of multiple news groups. The pattern in all cases is based on the wildmat[3] 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 RFC977 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 the LIST command were created to make that information available to NNTP newsreaders. 2.1.2 LIST ACTIVE LIST ACTIVE [wildmat] LIST ACTIVE is exactly the same as the LIST command specified in RFC977. 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 (similar to file globbing), not regular expressions. If nothing is matched an empty list is returned, not an error. 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. Barber [Page 4] INTERNET-DRAFT Common NNTP Extensions June 1995 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 Distributions: line in a news article header and about what the values mean. Each line 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. 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. 2.1.5.1 Responses 215 information follows 503 program error, function not performed Barber [Page 5] INTERNET-DRAFT Common NNTP Extensions June 1995 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 the news groups. Each line in the file contains two fields, the news group name and a short explanation of the purpose of 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 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. 2.1.6.1 Responses 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[4] 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. 2.1.7.1 Responses 215 information follows 503 program error, function not performed Barber [Page 6] INTERNET-DRAFT Common NNTP Extensions June 1995 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 [Page 7] INTERNET-DRAFT Common NNTP Extensions June 1995 2.3 MODE QUERY MODE QUERY MODE QUERY is the same as MODE READER. See section 2.4. 2.4 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. 2.4.1 Responses 200 Hello, you can post 201 Hello, you can't post 2.5 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. 2.5.1 Responses 282 list of groups and descriptions follows Barber [Page 8] INTERNET-DRAFT Common NNTP Extensions June 1995 2.6 XHDR XHDR header [range|] 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. 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. The XHDR command has been available in the UNIX reference implementation from its first release. However, until now, it has only been documented in the source for the server. 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[5] 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. Barber [Page 9] INTERNET-DRAFT Common NNTP Extensions June 1995 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 2.8 XOVER XOVER [range] The XOVER command returns information from the overview database for the article(s) specified. 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. The output will be formatted with the article number, followed by each of the headers in the overview database for that article separated by a tab character. 2.8.1 Responses 224 Overview information follows 412 No news group current selected 420 No article(s) selected 502 no permission Barber [Page 10] INTERNET-DRAFT Common NNTP Extensions June 1995 2.9 XPAT XPAT header range| pat [pat...] The XPAT 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 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 the complete pattern. Successful responses start with a 221 response followed by a the headers from all matched messages. 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 2.10 XROVER XROVER [range] The XROVER command returns reference information from the overview database for the article(s) specified. 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 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. Barber [Page 11] INTERNET-DRAFT Common NNTP Extensions June 1995 The output will be formatted with the article number, followed by reference overview information separated by a tab character. 2.10.1 Responses 224 Overview information follows 412 No news group current selected 420 No article(s) selected 502 no permission 2.11 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.11.1 Responses 288 Binary data to follow 412 No newsgroup current selected 502 No permission 503 program error, function not performed Barber [Page 12] INTERNET-DRAFT Common NNTP Extensions June 1995 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. When authorization is required, the server will send a 380 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 send a 381 response requesting the password associated with that username. The client must enter AUTHINFO PASS followed by the password for the username. The server will then check the authentication database to see if the username/password combination is valid. If the combination is valid, the server will return a 281 response. The client should then retry the original command to which the server responded with the 380 response. The command should then be processed by the server normally. If the combination is not valid, the server will return a 502 response. Clients must provide authentication when requested by the server. It is possible that some implementations will accept authentication information at the beginning of a session, but this was not the original intent of the specification. If a client attempts to reauthenticate, the server may return 482 response indicating that the new authentication data is rejected by the server. The 482 code will also be returned when the AUTHINFO commands are not entered in the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO PASS preceding AUTHINFO USER). All information is passed in cleartext. When authentication succeeds, the server will create an email address for the client from the user name supplied in the AUTHINFO USER command and the hostname generated by a reverse lookup on the IP address of the client. If the reverse lookup fails, the IP address, represented in dotted-quad format, will be used. Once authenticated, the server shall generate a Sender: Barber [Page 13] INTERNET-DRAFT Common NNTP Extensions June 1995 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 380 Authentication required 482 Authentication rejected 502 No permission 3.1.2 AUTHINFO SIMPLE AUTHINFO SIMPLE user password This version of AUTHINFO was part of the proposed NNTP V2 specification 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 451 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 NNTP V2 specification and are violations of RFC 977. It is recommended that this command not be implemented, but use either or both of the other forms of AUTHINFO if such functionality if required. 3.1.2.1 Responses 250 Authorization accepted 350 Continue with authorization sequence 450 Authorization required for this command 452 Authorization rejected Barber [Page 14] INTERNET-DRAFT Common NNTP Extensions June 1995 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 380 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[7] 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 or there is some other unspecified server program error, the server returns the 503 response code. The authenticators converse using their protocol until complete. If the authentication succeeds, the server authenticator will terminate with a 281, and the client can continue by reissuing the command that prompted the 380. If the authentication fails, the server will respond with a 502. The client must provide authentication when requested by the server. The server may request authentication at any time. Servers may request authentication more than once during a single session. When the server authenticator completes, it provides to the server (by a mechanism herein undefined) the email address of the user, and potentially what the user is allowed to access. Once authenticated, the server shall generate a Sender: line using the email address provided by the authenticator if it does not match the user-supplied From: line. Additionally, the server should log the event, including the user's authenticated email address (if available). This will provide a means by which subsequent statistics generation can associate newsgroup references with unique entities - not necessarily by name. Barber [Page 15] INTERNET-DRAFT Common NNTP Extensions June 1995 3.1.3.1 Responses 281 Authentication succeeded 380 Authentication required 501 Command not supported or Command syntax error 502 No permission 503 Program error, function not performed nnn authenticator-specific protocol. 3.2 DATE DATE The NNTP v2 draft specification added 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 [8] (NTP) was not yet in wide use and there was also some concern that small systems may not be able to make effective use of NTP. This command returns a one-line response code of 111 followed by the GMT date and time on the server in the form YYYYMMDDhhmmss. 3.2.1 Responses 111 YYYYMMDDhhmmss 3.3 The WILDMAT format The WILDMAT format was first developed by Rich Salz to provide a uniform mechanism for matching patterns in the same manner that the UNIX shell matches filenames. 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 range as a character it if is the beginning or end of the range. This set is enclosed in square brackets. The close square bracket (]) may be used in a range 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, or the question mark. Barber [Page 16] INTERNET-DRAFT Common NNTP Extensions June 1995 3.3.1 Examples a. [^]-] -- matches any 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 alphanumeric string d. a??d -- matches any four character string which begins with a and ends with d. 3.4 Additional Headers Many NNTP implementations add headers to Usenet articles when then are POSTed via NNTP. These headers are discussed in this section. None of these headers conflict with those specified in RFC 1036 and should be passed unchanged by Usenet transports conforming to RFC 1036. 3.4.1 NNTP-Posting-Host This line is added to the header of a posted article by the server. The contents of the header is either the IP address or the fully qualified domain name of the client host posting the article. The fully qualified domain name should be determined by doing a reverse lookup in the DNS on the IP address of the client. If the client article contains this line, it is removed by the server before acceptance of the article by the Usenet transport system This header provides some idea of the actual host posting the article as opposed to information in the Sender or From lines that may be present in the article. This is not a fool-proof methodology since reverse lookups in the DNS are vulnerable to certain types of spoofing, but such discussions are outside the scope of this document. 3.4.2 X-Newsreader and others There are other lines that are added by clients as well. Most of these indicate the type of newsreader software that is posting the article. 4.0 Future 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. Barber [Page 17] INTERNET-DRAFT Common NNTP Extensions June 1995 How this will be done remains an open issue. 5.0 Security No security issues are discussed in this document. 6.0 References [1] Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC-977, U.C. San Diego and U.C. Berkeley, February, 1986. [2] Horton, M.R. and R. Adams, "Standard for interchange of USENET messages", RFC-1036, AT&T Bell Laboratories and Center for Seismic Studies, December, 1987. [3] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4 distribution, UUNET Technologies, Revision 1.10, April, 1992. [4] Anderson, Robert, "FAQ: Overview database / NOV General Information", USENET Message , April, 1995. [5] Lea, Ian, "FAQ about the TIN newsreader", http://www.scn.de/~iain/tin/faq.html, April, 1995. [6] Kappesser, Peter, "[news.software.readers] trn newsreader FAQ", 2 parts, USENET Messages and , April, 1995. [7] Meyers, J, "IMAP4 Authentication Mechanisms", RFC-1731, Carnegie Mellon, December, 1994. [8] Mills, David L., "Network Time Protocol (Version 3), Specification, Implementation and Analysis", RFC-1305, University of Delaware, March 1992. 7.0 Notes DEC is a registered trademark of Digital Equipment Corporation. UNIX is a registered trademark of the X/Open Consortium. VMS is a registered trademark of Digital Equipment Corporation. 8.0 Acknowledgments The author gratefully acknowledges the comments and additional information provided by the following individuals: Wayne Davison Chris Lewis Eric Schnoebelen Barber [Page 18] INTERNET-DRAFT Common NNTP Extensions June 1995 9.0 Author's Address Stan Barber P.O. Box 300481 Houston, Texas, 77230 Email: This document expires on November 25, 1995. Barber [Page 19]