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文檔的編輯功能當前由因特網社區提供。