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

NNTP命令扩展

备忘录地位

这份备忘录为因特网社区提供信息。它不是任何种类的因特网标准。文章的发布无任何限制。

版权通告

因特网社区(2000)拥有本文的版权，并保留一切权利。

摘要

本文记录并讨论了一部分正在流行的NNTP服务(定义在RFC977中)的扩展命令，本文不应该被视为任何种类的标准，它应该是未来的NNTP具体实现的参考文献。在这个前提下，本文将创建一种使不同扩展NNTP的实现可以在一定层度上协同工作的能力。

介绍

RFC977[1]定义了网络新闻组协议，并且已经发布十年之久了。因为这样，NNTP已经成为在因特网上使用最流行的协议。很多协议的实现在不同的平台和操作系统上被开发出来。随着协议使用的增多，在1991年开始了修订这个协议的工作，但是最后并没有产生的协议标准。然而，工作组的主意被包含在不同的NNTP实现中。加上很多其它被新闻读者或作者创建的扩展也在使用中。这份文档将在NNTP官方服务器版本中收集并定义所有有效的NNTP扩展。可能的化，首先实现了一个特别的扩展的NNTP软件将会得到注意。希望前后使用两种文档的作者不要再扩展已经有的功能了。软件开发者可能希望使用这份资料以及其他[2]一些开发新软件的资源。

这份文档没有说明任何类型的因特网标准。它仅仅是尝试着记录当前的一些实践情况。这份文档可能阐述了一些RFC977中部明确的地方，RFC977仍旧作为一份权威的标准。一些实现并没有严格的遵循RFC977标准，必然，这种对标准的背离将会得到注意。这份文档反映了由Ned Freed 和 Stan Barber领导的IETF NNTP-EXT 工作组的工作。

这份文档用于帮助不同的实现得到相同的扩展信息，然而，对于所有预期的实现，懂得在这里列出的扩展是很重要的并且它不是当前NNTP扩展的一部分。事实上，一些这里列出的扩展并不应当被包含在NNTP实现中因为它们已经不再被时下的NNTP使用。这样的命令会被认为是有名的并被公布在这份文档中。

扩展有以下三个方面：传输，新闻阅读和其他方面。传输扩展增加了一种在服务器间传递新闻文章的NNTP规范。新闻阅读扩展增加了一种帮助NNTP客户端从服务器那里选择和重新接收文章的NNTP规范。其他NNTP扩展是不包含在前面两方面扩展中的扩展。其他扩展的例子如鉴定和time-of-day(译者注：时间日期)扩展。对于每个命令，将使用RFC977中第三部分的格式。

1.  传输扩展

传输扩展主要用于服务器之间的传输。接下来是每个传输扩展命令的描述及它们的应答。

每一个命令都会有一个清楚的示例，虽然示例并不能很充分的说明NNTP命令。任何参数都是小写。如果一个参数包含在一个[]中，说明这个参数是可选的，如：[GMT]说明参数GMT可能会在命令中出现，也可能不会。重复的参数将会被省略号代替。

1.1.1 CHECK命令

CHECK <message-id>

CHECK命令用于在同等服务器间以发现标识符为<message-id>的文章是否被TAKETHIS命令传递到了服务器上。同等的主机不必再发送下一条命令前等待服务器的应答。

在按顺序使用CHECK命令的应答时，发送过来的文章列表将会被后来的TAKETHIS命令创建。

使用CHECK传输是可选的。一些实现会直接将发送队列中的所有文章发送给同等的服务器。

在一些实现上，当服务器为辅助服务器状态(由SLAVE命令)时是不允许使用CHECK命令的。

在X3X的应答中必须详细说明message-id。

1.1.2 应答

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 MODE STREAM命令

MODE STREAM

MODE STREAM用于同等服务器之间，指出服务器将要挂起服务器会话状态的锁定步骤并且以流的方式发送命令。

1.2.2 应答

203 Streaming is OK
500 Command not understood

1.3.1 TAKETHIS命令

TAKETHIS <message-id>

TAKETHIS命令用于在流模式下将文章发送给服务器。整篇文章(按头部，主体的顺序)将在对等服务器发送了TAKETHIS命令后马上发给服务器。同等的主机不必再发送下一条命令前等待服务器的应答。

在文章的传输过程中，对等主机间应当传输整篇文章，包括头部和主体，以发送服务器的文章习惯传输格式

在X3X的应答中必须详细说明message-id。

1.3.2 应答

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

1.4.1 XREPLIC命令

XREPLIC ggg:nnn[,ggg:nnn...]

XREPLIC命令为主机间严格的复制新闻池结构提供了一种可能。它首先出现在INN。

这个命令和RFC977中的IHAVE命令类似。它们的应答也一样。这一行将条目用逗号<,>隔开。每一个条目包含一个新闻组名称，一个冒号，一个文章号码。如果服务器返回一个335应答，则新闻组中指定号码的文章可以传输。如果文章因为已经被接受过一次而不能被成功的放入目录，将返回436或者437。

这个命令只能用于一个接收服务器和另一个服务器之间。常常的，当服务器有多个输入流的时候这个命令会失败。(译者注：这段可能有问题，原文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)

XREPLIC同步被INN1.7.2及以后的版本所反对。INN现在有一种透明的机制用于服务器间的同步，简单的传输文章的Xref头部。(在当前版本中，文章的Xref头部在本地产生并且在外传的时候去掉)

INN将来的版本很可能不再支持XREPLIC。

1.4.2 应答

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.  新闻阅读扩展

新闻阅读扩展主要用于新闻阅读客户端。接下来的是每一个新闻阅读扩展命令及其应答的描述。

每一个命令都会有一个清楚的示例，虽然示例并不能很充分的说明NNTP命令。任何参数都是小写。如果一个参数包含在一个[]中，说明这个参数是可选的，如：[GMT]说明参数GMT可能会在命令中出现，也可能不会。重复的参数将会被省略号代替。相比较的是，唯一的参数间以竖线<|>符号隔开。如，ggg|<message-id>指出ggg或者<message-id>会被说明，但不是全部。一些参数，特别是<message-id>将会是明确的。详细资料请查看RFC1036。

某些命令也利用一种方法去选择几个新闻组。这种方法所有的样式都基于Rich Salz在1986年介绍的一种wildmat样式。wildmat样式将会以一个wildmat串隔开。这种样式将会在文章的3.3部分讨论。

2.1.1 LIST命令的扩展

原先的LIST命令在RFC977中被无争议的定义了并且以一种特殊的格式返回有效文章的目录。因为原先的新闻阅读者(译者注：newsreader)在新闻中除了传输现有文件外还要传输软件，所以扩展的LIST命令被创建出来使得新信息对于NNTP新闻阅读者有效。可能还有其他的扩展仅仅返回文件的内容。这种方法是通过在LIST后面增加单词实现的。如，LIST MOTD可能会被用于替代XMOTD。

2.1.2 LIST ACTIVE

LIST ACTIVE [wildmat]

LIST ACTIVE与RFC977中的LIST命令严格一致。它的返回格式必须无条件的和LIST命令一致。如果有可选的匹配参数，则返回的列表中奖仅有和参数匹配的新闻组。指出一个新闻组对于服务器来说常常是非常有效的，并且很多的新闻组也许会通过使用wildmat样式(后面讨论)说明，而非正常的表达方式。如果没有匹配的新闻组，则返回一个空表，而非错误。这个命令首先出现在UNIX参考版本。

2.1.3 LIST ACTIVE.TIMES

LIST ACTIVE.TIMES

active.time文件由一些新闻文件系统维持，它包含了新的新闻组的创建时间和创建者。这个文件的格式有3个区域。第一个区域是新闻组名称。第二个区域是新闻组在这个服务器上被创建的时间，以距离1970年1月1日的秒数为准。第三个区域是新闻组创建者的电子邮箱地址。当命令执行的时候，文章信息会在215应答后显示。当显示完成的时候，服务器会发送一个仅有一个点号<.>的行。如果信息是无效的，服务器会返回503错误。这个命令首先出现在UNIX参考版本。

2.1.3.1 应答

215 information follows
503 program error, function not performed

2.1.4 LIST DISTRIBUTIONS

LIST DISTRIBUTIONS

分发文件被一些新闻传输系统保存，它包含了文章分发的有效信息值：一篇文章的一个头部行及这些值所代表的意义。每一行有两个部分：一个值及这个值得一个简短的解释。当命令执行的时候，文章信息会在215应答后显示。当显示完成的时候，服务器会发送一个仅有一个点号<.>的行。如果信息是无效的，服务器会返回503错误。这个命令首先出现在UNIX参考版本。

2.1.4.1 应答

215 information follows
503 program error, function not performed

2.1.5 LIST DISTRIB.PATS

LIST DISTRIB.PATS

DISTRIB.PATS文件被一些新闻传输系统保存，它包含了文章分发的有效信息值：一篇文章中描述文章被发布给特定新闻组时间的头部行。这个信息用于给分发提供一个默认的值：文章发布时间的一个头部行。返回的信息由3部分，以冒号隔开：第一列是一个权值。第二部分是一个组名称或一个能以wildmat格式匹配新闻组的表达式。第三个是分发的一个值：当新闻组名称匹配并且权值最高的时候应该用的一行。所有的这些处理都是在发布客户端，而非服务器本身。服务器仅仅是提供这些信息给客户端，客户端可以根据需要选择使用或者忽略它。当命令执行的时候，文章信息会在215应答后显示。当显示完成的时候，服务器会发送一个仅有一个点号<.>的行。如果信息是无效的，服务器会返回503错误。这个命令首先出现在INN。

2.1.5.1 应答

215 information follows
503 program error, function not performed

2.1.6 LIST NEWSGROUPS

LIST NEWSGROUPS [wildmat]

新闻组文件由一些传输系统维护，它包含了每个在服务器上活跃的新闻组的名称以及每个新闻组主题的描述。文件的每一行有两个部分：新闻组名称及新闻组目的简短解释。当命令执行的时候，文章信息会在215应答后显示。当显示完成的时候，服务器会发送一个仅有一个点号<.>的行。如果信息是无效的，服务器会返回503错误。如果有可选的匹配参数，则返回的列表中奖仅有和参数匹配的新闻组。指出一个新闻组对于服务器来说常常是非常有效的，并且很多的新闻组也许会通过使用wildmat样式(后面讨论)说明，而非正常的表达方式。如果没有匹配的新闻组，则返回一个空表，而非错误。

当有可选参数的时候，这个命令和XGTITLE命令一模一样，但是返回类型不同。

215 information follows
503 program error, function not performed

2.1.7 LIST OVERVIEW.FMT

LIST OVERVIEW.FMT

overview.fmt文件由一些传输系统维护，它包含了每个新闻组的文章头部被存储在overview数据库中的顺序信息。当命令被执行，紧跟着215应答的是以被存储在overview数据库[5]中的顺序进行排序的新闻文章的头部域，总共一行。

请注意如果头部在冒号后面有一个单词”full”(没有引用)，(译者注：这里理解有误，没有翻译，原文the header's name is prepended to its field in the output returned by the server)

很多的新闻阅读器能用Xref(一个可选项)工作得更好。

强烈推荐所有实现了XOVER命令的系统中也实现这个命令。查看文章的2.8部分得到XOVER命令的详细资料。

2.1.7.1 应答

215 information follows
503 program error, function not performed

2.1.8 LIST SUBSCRIPTIONS

LIST SUBSCRIPTIONS

这个命令用于得到服务器上新用户的默认订阅列表。新闻组的顺序是由意义的。当这个表示有效的，它会在215应答之前返回，并以一个仅含有单个点号<.>的行结束。如果无效，服务器返回503应答。

2.8.1.1 应答

215 information follows
503 program error, function not performed

2.2 LISTGROUP

LISTGROUP [ggg]

LISTGROUP命令用于得到一个特定新闻组的文章列表。

可选参数ggg是被选中的新闻组的名称(如，” news.software.b”)。有效新闻组的列表可以通过LIST命令获得。如果没有指定新闻组，会使用默认的当前新闻组。

选择成功的应答中会有一个组内文章号码的列表，跟着一个仅有单个点号<.>的行。

当一个新闻组被这个命令选中，系统内部维持的”当前文章点”会被设置为这个新闻组的第一篇文章。如果指定了一个有效组，当前被选中的新闻组和文章仍旧处于选中当中。如果选中了一个空新闻组，则”当前新闻点”处于一个不稳定状态并且不会被使用。

注意新闻组名称不是随意指定的。它必须匹配LIST命令列出的新闻组名称中的一个，否则会返回一个错误。

2.2.1 应答

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

2.3 MODE READER

MODE READER用于客户端向服务器报告自己是一个新闻阅读客户端。一些实现利用这些信息重组自己，使得自己可以在新闻读者的命令应答中表现得更好。这个命令可以和RFC977中没有广泛实现的SLAVE命令进行比较。MODE READER命令首先在INN中有效。

2.3.1 应答

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

2.4 XGTITLE

XGTITLE [wildmat]

XGTITLE命令用于找回特定的新闻组描述。这个扩展首先出现在ANU-NEWS，DECVMS机器的一个NNTP实现。可选参数是wildmat格式的表达式。当命令被执行，会在282应答后面跟着很多行，每行有两个部分，新闻组名称(和参数中的表达式匹配)和新闻组目的的一个简短解释。如果没有指明参数，默认的参数是当前新闻组。当显示完毕，服务器会发送一个自由单个点号<.>的行。

请注意这个命令和LIST NEWSGROUP命令提供了相同的功能，但是应答不同。

因为这个命令提供了和LIST NEWSGROUP相同的功能，所以建议忽略这个扩展并不再被新闻阅读服务器使用。

请注意XGTITLE命令的应答和其他的鉴定扩展的应答有冲突。

2.5.1 应答

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

2.6 XHDR

XHDR header [range|<message-id>]

XHDR命令用于找回特定的文章的头部。

必需的参数是新闻组文章中的一个头部行(如”subject”)。查看RFC1036得到有效的的头部列表。可选的范围参数是可能下面的任意一个：

一篇文章的号码
一篇文章的号码的后面跟随着一个表示全部后续的破折号(译者注：即以这个号码为起始直到末尾)
一篇文章的号码的后面跟随着一个破折号再跟随着其他的文章号码。

可选的message-id参数指明了一篇特殊的文章。范围和message-id参数是相互排斥的。如果没有指明参数，就会显示当前文章的信息。成功的应答以221应答起始，后面跟着来自所有匹配消息的匹配头部。每一行都是服务器返回的文章号码(或者是文章message-id,如果在命令中指出了)所代表的文章的头部，然后是至少一个空格，然后是请求的文章头部的值。一旦输出完毕，会发送一个只有单个点号<.>的行。如果可选参数是message-id并且没有匹配的文章，则会返回430错误应答。如果指明了范围参数，则在早先要选择新闻组，否则会返回421错误应答。如果范围中没有文章，则会返回420错误。如果客户端仅允许传输文章，则会返回520错误。

一些实现会返回一个”none”跟着一个只有单个点号<.>的行以表示在对文章的搜索中没有找到匹配的头部。有些返回221应答跟着一个只有单个点号<.>的行。

XHDR命令在UNIX最初的发行版本中有效。然而，知道现在，它已经只被记录在服务器的原始资料中(译者注：可能有问题，原文However, until now, it has been documented only in the source for the server)。

2.6.1 应答

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

XINDEX命令用于找回索引文件，它最初被TIN[6]新闻读者为了使用而创建。可选参数ggg是被选中的新闻组名称(如”news.software.b”)。一个有效的新闻组名称列表可以由LIST命令获得。

成功的选择应答将返回索引文件跟着一个只有单个点号<.>的行。

当一个新闻组被这个命令选中，系统内部维持的”当前文章点”会被设置为这个新闻组的第一篇文章。如果指定了一个有效组，当前被选中的新闻组和文章仍旧处于选中当中。如果选中了一个空新闻组，则”当前新闻点”处于一个不稳定状态并且不会被使用。

注意新闻组名称不是随意指定的。它必须匹配LIST命令列出的新闻组名称中的一个，否则会返回一个错误。

TIN风格格式的索引文件在TIN新闻阅读文档中被讨论。因为最近版本的TIN支持新闻预览(NOV)格式，所以推荐将这个扩展作为一个著名的命令并不再在当前或将来的版本中实现它。

2.7.1 应答

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

2.8 XOVER

XOVER [range]

XOVER命令用于从overview数据库返回指定文章的信息。这个命令被推荐作为OVERVIEW(在Geoff Collyer的”The Design of a Common Newsgroup Overview Database for Newsreaders”中描述，这份文档在Cnews中被发布)工作的一部分。可选的范围参数是下面中的任意一个：

一篇文章的号码
一篇文章的号码的后面跟随着一个表示全部后续的破折号(译者注：即以这个号码为起始直到末尾)
一篇文章的号码的后面跟随着一个破折号再跟随着其他的文章号码。

如果没有指明参数，则会显示当前文章的信息。成功的应答以224应答开始，跟着所有匹配消息的总体信息。一旦输出完毕，会发送一个只有单个点号<.>的行。如果没有指明参数，则会返回当前文章的信息。必需在早先选择新闻组，否则会返回412错误应答。如果在范围中没有文章，服务器会返回420错误。如果客户端仅允许传输文章，则会返回520错误。

输出的每一行的格式为：一个文章号码，紧跟着的是overview数据库中或文章本身(如果overview数据库中的头部无效)的每个头部，然后是一个用于隔开文章的TAB符号。头部域的顺序必须是：subject, author, date, message-id, references, byte count, 和 line count。 可能跟着其他的可选头部。这些域由LIST OVERVIEW.FMT命令描述。如果没有数据存在，必需提供一个空域(如，输出是两个相邻的TAB键)。服务器不应当输出在XOVER数据库被创建时已经被移除的文章域。

如果实现了XOVER命令，则应当实现LIST OVERVIEW.FMT命令。客户端可以使用LIST OVERVIEW.FMT命令确定可选域及他们被XOVER所显示的顺序。

注意任何在头部的TAB和行结束字符在返回的时候都会被修改成空格字符。

2.8.1 应答

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

XPAT命令用于在特定的文章中找回特定的头部，依靠表达式匹配头部的内容。这个命令首先在INN中有效。

必需的header参数为新闻组文章头部行的名称(如”subject”)，查看RFC1036得到有效的文章头部列表。可选的范围参数是下面中的任意一个：

一篇文章的号码
一篇文章的号码的后面跟随着一个表示全部后续的破折号(译者注：即以这个号码为起始直到末尾)
一篇文章的号码的后面跟随着一个破折号再跟随着其他的文章号码。

必需的<message-id>参数指明了一篇特定的文章。range参数和message-id参数是互斥的。如果还有额外的参数，则全部结合在一起以空格隔开。成功的应答以221应答起始，后面跟着所有和表达式中给定的头部内容匹配的消息的头部。这包括一个空表。一旦输出完毕，会发送一个只有单个点号<.>的行。如果可选参数是message-id，并且没有这样的文章存在，会返回430错误。如果客户端仅允许传输文章，则会返回520错误。

2.9.1 应答

221 Header follows
430 no such article
502 no permission

2.10 XPATH命令

XPATH <message-id>

XPATH命令用于确定把将文章归档的文件名。它首先出现在INN。

必需的参数message-id是文章message-id头部的内容。根据RFC1036，所有文章的消息标识在新闻网络中是唯一的，但是文章可以在多个新闻组中。XPATH命令的应答是一个存储了这篇文章的文件名列表，相互间以空格隔开，或者一个表示指定的message-id所代表的文章不存在的应答。返回的数据至于在客户端知道服务器的具体实现时才有效。因为这样，所以建议客户端避免使用这个命令。

2.10.1 应答

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

2.11 XROVER命令

XROVER [range]

XROVER命令从overview数据库中返回指定文章的引用信息。这个命令首先出现在UNIX的引用实现。可选的范围参数是下面中的任意一个：

一篇文章的号码
一篇文章的号码的后面跟随着一个表示全部后续的破折号(译者注：即以这个号码为起始直到末尾)
一篇文章的号码的后面跟随着一个破折号再跟随着其他的文章号码。

成功的应答以224应答起始，后面跟着所有匹配消息中的引用信息的内容。一旦输出完毕，将返回一个只有单个点号<.>的行。如果没有指定参数，则会返回当前文章的应用信息。必需在早先选择新闻组，否则会返回412错误应答。如果在范围中没有文章，服务器会返回420错误。如果客户端仅允许传输文章，则会返回520错误。

输出的格式为：一个文章号码，跟着的是引用内容：文章的引用行，但是不包含应用行头部名称。

这个命令提供了一个和XHDR(将“references”也作为一个头部参数)命令一样的基本功能，

2.11.1 应答

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

2.12 XTHREAD

XTHREAD [DBINIT|THREAD]

XTHREAD命令用于找回最初由使用TRN[6]的新闻读者创建的ing(译者注：作为特定名词没有翻译)信息。

XTHREAD DBINIT命令一般用于进入任意的组查看是否存在thread数据库。如果有，数据库的字节顺序和版本号将会以二进制的形式返回。

如果没有指明参数，则假定命令为XTHREAD THREAD。

为了使用XTHREAD THREAD，新的组必需在稍早前指定，否则会返回412错误。

当客户端只允许传输文章时，将返回502应答。如果返回503应答，则说明thread文件无效。

TRN风格格式的索引文件在TIN新闻阅读文档中被讨论。因为最近版本的TRN支持新闻预览(NOV)格式，所以推荐将这个扩展作为一个著名的命令并不再在当前或将来的版本中实现它。

2.12.1 应答

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

3.  其他扩展

3.1 AUTHINFO

AUTHINFO用于通知服务器关于这个服务器上一个用户的身份标识。在任何情况下，当服务器请求的时候，客户端必需提供这个信息。服务器没有必要接受被客户端自愿提供的鉴定信息。客户端必需容忍服务器拒绝任何客户端自愿提供的鉴定信息的行为。

AUTHINFO有3个版本。最初的版本，NNTP V2中叫做AUTHINFO SIMPLE，最近的版本中叫做AUTHINFO GENERIC。

3.1.1 最初的AUTHINFO

AUTHINFO USER 用户名
AUTHINFO PASS 密码

最初的AUTHINFO使用用户名/密码联合体向服务器提供一个身份实体。它首先出现在UNIX引用实现中。

当请求被许可，服务器会想请求许可的客户端发送一个480应答。客户端必需在AUTHINFO USER后面键入用户名。一旦发送，服务器会缓存用户名并且向客户端发送381应答，请求客户端发送与用户名对应的密码。一旦服务器使用381应答向客户端请求密码，客户端必需在AUTHINFO PASS后面键入密码并且服务器会检查鉴定服务器以确定用户名/密码是否有效。如果用户名/密码有效或者没有密码，服务器会返回281应答。然后客户端应当向返回218应答的服务器再次发送最初(译者注：这里的意思是其他的命令)的命令。然后这个命令才会被服务器正常的处理。如果用户名/密码无效，服务器会返回502应答。

当服务器请求的时候，客户端必需提供验证信息。一些实现可能接受在会话开始的时候的验证(译者注：这里的验证和上面的鉴定是一个意思)信息，但是这个不是这份规范最初的意图。如果客户端尝试再次验证，客户端会返回482应答指出新的验证数据已经被服务器拒绝了。当AUTHINFO命令没有按正确的信息键入(如一行两个AUTHINFO USER，或AUTHINFO PASS出现在AUTHINFO USER前面)时,会返回482应答。

所有的信息以明文方式传输。

当验证成功，服务器会为客户端创建一个电子邮件地址，其中用户名为AUTHINFO USER提供的用户名，主机名是通过反向查找客户端的IP地址产生。如果反向查找失败，IP地址将使用dotted-quad(译者注：即小黑点形式…)格式。一旦被验证，如果和客户端提供的FROM:行不匹配，就会使用由验证提供的电子邮件地址产生一个sender:行。另外，服务器会记录这个事件，包括电子邮件地址。这将会提供一种统计学产生的方法将新闻组与唯一的实体联系起来—不一定用名字(译者注：这里可能有问题，原文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 应答

281 Authentication accepted
381 More authentication information required
480 Authentication required
482 Authentication rejected
502 No permission

3.1.2 AUTHINFO SIMPLE

AUTHINFO SIMPLE
用户名 密码

这个版本的AUTHINFO是NNTP V2规范中的一部分，它开始与1991年且从来都没有被完善过，被一些服务器和客户端实现。它是原先的AUTHINFO的精简并且提供同样的基本功能，但是这个命令的顺序就简单多了。

当需要验证的时候，服务器会想发送验证请求的客户端发送450应答。客户端必须键入AUTHINFO SIMPLE。如果服务器接受这种格式的验证，将会返回一个350应答。然后客户端将会发送用户名，紧跟着的是一个或多个空格，再跟着的是密码。如果验证通过，则服务器会返回250应答并且客户端应当向返回218应答的服务器再次发送最初(译者注：这里的意思是其他的命令)的命令。如果用户名/密码无效，服务器会返回452应答。注意在这里使用的应答码是NNTP V2中的一部分并且是违反RFC977的。建议不要实现这个功能，但是如果要需要验证，请使用任意一个其他的AUTHINFO格式。

3.1.2.1 应答

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用于在使用专门的验证方式或者验证协议的服务器上验证一个具体的实体。期望的协议由authenticator参数提供，并且任何数量的参数都可以被传递给authenticator

当需要验证的时候，服务器会向请求验证的客户端发送480应答。客户端应当键入在AUTHINFO GENERIC后面键入验证者名称，和任何需要的参数。authenticator和arguments不应当含有”...”。

服务器会尝试着使服务器结束authenticator(译者注：这里翻译成验证者好像不太合适)，类似的，客户端也会使客户端终结authenticator。服务器终结了authenticator后会使用NNTP套接字初始化验证(如果有适当的验证协议)，使用被验证者名称指出的验证协议，这些验证协议不再本文档里，但是与RFC1731[8]中引用的IMAP-4协议相类似的结构(译者注：这句可能有问题，原文but are similar in structure to those referenced in RFC 1731 [8] for the IMAP-4 protocol.)。

如果服务器返回501，意味着验证方式存在语法上的错误，或不支持AUTHINFO GENERIC。客户端应当再次使用AUTHINFO USER命令。

如果被请求者不具备请求能力，服务器将返回503应答。

如果存在一些未说明的服务器程序错误，服务器将返回500应答。

请求者使用他们的协议交谈知道结束。如果验证成功，服务器的请求者会以一个218应答结束，客户端可以通过重新发送可以引起380应答的命令来继续。如果验证失败，服务器会返回502错误。

客户端必需在服务器要求的时候提供验证。服务器会在任何时间提出验证请求。服务器在单一的会话中可能会进行多次验证请求。

当验证完成的时候，它向服务器(使用这里未明确定义的机制)提供用户的电子邮件地址，并且允许用户访问。一旦验证，如果与用户提供的FROM:行不匹配，服务器就会使用验证者提供的电子邮件地址生成一个Sender:行。另外，服务器会记录这个事件，包括电子邮件地址。这将会提供一种统计学产生的方法将新闻组与唯一的实体联系起来—不一定用名字。

一些实现会通过向服务器发送无参数的AUTHINFO GENERIC命令而获得可用的验证方式列表。然后服务器返回一个支持的机制列表跟着一个只有单个点号<.>的行。

3.1.3.1 应答

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 DATA

DATA

第一个工作组讨论并提出了一个命令语法以帮助客户端找出当前相对于服务器的时间。在这个命令被讨论时(1991-1992)，网络新闻协议[9](NTP)还没有被广泛使用并且还存在小型系统可能没有能力使用NTP的问题。

这个命令返回一行应答，应答码为111，后面跟着服务器上的GMT日期和时间，格式为YYYYMMDDhhmmss。

3.2.1 应答

111 YYYYMMDDhhmmss

3.3 WILDMAT格式

WILDMAT格式首先是Rich Salz依据UNIX的”find”命令中详细说明文件名的格式发明的一种格式。它发明出来用于向UNIX shell文件匹配操作提供一种统一的匹配表达式。当进行匹配测试时，表达式会被默认放入每个字符串的开头和结尾。除了一种在表达式和被检查的匹配源之间严格的一对一匹配外，还有五种匹配表达式。第一种是星号<*>用于匹配0个或多个字符序列。第二种是问号<?>用于匹配单个字符。第三种指出了一个特定的字符串集合。这个集合可以是一个字符列表，也可以是开头和结尾被减号或者破折号隔开的一个范围，还可以是任意的字符列表和范围的结合体。破折号也可以作为一个字符包含在集合中，如果它出现在集合的开头或者结尾。这个集合被被包含在方括号中<[]>。方括号的结束符号<]>也可以作为一个字符出现在集合的开头。第四种操作与第三种逻辑上不同，但是用了和第三种一样的表达方式，即在测试串的开头插入<[^]>符号。最后一种方式使用反斜线<\>使方括号<]>，星号，反斜线，问号的特殊意义无效。两个反斜线号意味着使反斜线符号的特殊意义无效。

3.3.1 样例

a. [^]-] – 除了减号 波浪号/破折号，匹配任何单个的符号(译者注：这里有问题，原文matches any single character other than a close square bracket or a minus sign/dash.)

b. *bdc  -- 匹配任何以”bdc”结束的字符，包括”bdc”。

c. [0-9a-zA-Z] –匹配任何可打印的单个ASCII字母数字。

d. a??d  --  匹配任何以’a’开头，以’d’结尾的四个字符的串。

3.4 增加的头部

很多NNTP实现都在USENET文章经由NNTP发布额过程中向文章添加头部。这个部分将要讨论这些头部。没有头部会和RFC1036中说明的头部相冲突并且需要向RFC1036的头部一样被没有改变的传送。

3.4.1 NNTP-Posting-Host

这个头部在文章被发布的时候由服务器添加。头部内容是IP地址或者发布文章的主机的全名。服务器的全名可以通过DNS方向查找IP地址获得。如果客户端文章有这个头部，当USENET传输系统接受这篇文章前服务器会移除这个头部。

这个命令提供了文章实际发布主机的信息，与之对应的时文章中可能会出现的FROM行或者Sender行。自从发现可以用一种特定的方法欺骗反向查找DNS后，这个头部已经不是一种防欺骗的方法，但是这个讨论不再本文的范围之内。

3.4.2 X-Newsreader 和其他

也存在很多被客户端附加上的头部行。他们大部分用于指明发布文章的客户端阅读软件的类型。

4.0 一些具体的实现

一些NNTP实现没有跟随RFC977的要求。在这个部分，将要讨论其中一些普遍的实现版本。

4.1 LIST命令的应答

RFC977的中返回的“有效的相关新闻组信息列表”的第四部分必需有“’y’或者’n’，用以说明这个新闻组是否允许发布文章”。大部分的实现仅仅是精确输出了服务器上活跃的新闻组列表。更进一步的实现中第四部分才有’y’或者’n’。

4.2 文章和发布命令中必须的头部。

RFC977的3.10.1部分说文章的显示“应当包含有所得必需头部行”。事实上，时下的实现只需要From, Subject, 和 Newsgroups header 行，并且将会省略剩下的行；将来，很多的实现会相信最好给客户端产生尽可能少的头部，因为客户端常常不给其它头部进行正确的排版。

这种实现方式和Bnews和Cnews是一致的，都给直接提交上来的文件提供缺省的头部。

4.3 文章号码

RFC977并没有直接指出一种关于文章号码的规则。然而，当前的实现非常简单：文章战马是单调递增的，文章可能消失，并且因此GROUP命令返回的高和低的数字分别被认为是最大的下限和最小的上线。

4.4 RFC977中定义的有效命令

一些实现允许管理员禁止某些RFC977中定义的命令。一些实现有一个禁止执行的命令集合。这意味着客户端的实现不能取决于禁止执行的命令集合的有效性。这增加了客户端的有效性并且不鼓励具体的实现去优化实现那些不能很好执行的命令。

NEWNEWS是一个常常被禁止的命令。

4.5 Distribution头部和NEWNEWS命令

在RFC977的12.4部分，描述了可选参数distributions。根据RFC977，仅允许返回那些和distributions参数匹配的新闻组中的文章。

一些实现的方法是将文章的Distributions与Distribution的参数进行比较。其他的与新闻组名称进行匹配。

这种变化是对USENET文章格式演化的最好的说明。当RFC977被发布的时候，新闻组名称阐明了组怎样在整个网络中分布(译者注：这里可能有问题，原文the newsgroup name defined how the group was distributed throughout USENET.)。RFC1036改变了这个约定。因此那些严格参照RFC977的实现会将新闻组名称前缀与distribution参数进行匹配，并且只显示匹配的新闻组。问被原本意图的命令(被重定义的文章格式所修改)会将文章的distributions头部行与distribution参数进行匹配，并且只显示匹配的新闻组。

5.0 未来的工作

随着NNTP在因特网中的使用，需要创建一种最优化的服务器-服务器传输协议和一种最优化的客户端-服务器传输协议。也需要建立一种更好的机制使得在用户可以在正被阅读的新闻组中更好的审查信息。

一个IETF工作组已经成形了并且希望一些作者将他们的有用信息寄给该会议要论。

6.0 安全性考虑

AUTHINFO的使用时可选的。记录在这里的这个命令有许多安全暗示。在最初的原始的版本中，所有的密码是以明文形式发送，并且可以被各种不同类型的网络或系统监控发现。AUTHINFO GENERIC命令当用明文机制传输密码是也会有这个潜在的问题。RFC1731[8]详细的讨论了这个问题。

7.0 参考文献

[1]  Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC977, 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.

[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 注意

DEC是康柏电脑有限公司的注册商标。UNIX是开源社区的注册商标。VMS是康柏电脑有限公司的注册商标。

9.0 鸣谢

作者特别感谢由以下个人提供的信息：

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>

这份工作成果由以下列出的不同的新闻阅读程序和新闻服务器程序的作者促成：

Rick Adams    -- RN新闻阅读程序中NNTP扩展的最初作者和Bnews的最终维护人

Stan Barber   -- 作为Bnews一部分的NNTP扩展的最初作者

Geoff Collyer – 最早提出OVERVIEW 数据库并CNEWS的早期作者

Dan Curry     -- xvnews 新闻阅读程序的最初作者

Wayne Davison – RN新闻阅读程序中threading扩展的最初作者 (一般叫做TRN)

Geoff Huston  -- ANU NEWS的最初作者

Phil Lapsey   -- UNIX引用版本的最初作者

Iain Lea      -- TIN新闻阅读程序的最初作者

Chris Lewis   -- 第一个知道AUTHINFO GENERIC扩展

Rich Salz     -- INN最初作者

Henry Spencer -- CNEWS 的一个最初的作者

Kim Storm     -- NN新闻阅读程序的早期作者

10.0作者地址

Stan Barber
P.O. Box 300481
Houston, Texas, 77230

EMail: sob@academ.com

11.0著作版权声明

因特网社区(2000)拥有版权。并保留一切权利。

(译者注：后面的版权声明没有翻译)原文如下：

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

背景知识

RFC文档的编辑功能当前由因特网社区提供。