RFC850 1983年6月
USENET信息交換標準
Mark R. Horton
[這篇備忘錄以RFC格式發布只是為了能讓更多的使用ARPA網絡的研究者可以更容易的得到信息]
1. 導言
這篇文檔定義了一個在USENET間交換網絡新聞文章時用到的文章格式標準。它詳細描述了文章格式本身，也給出了部分的新聞傳輸標準。新聞的傳輸不需要完全按照標準格式以便于給個別的主機提供一個好的彈性去選擇傳輸的硬件和軟件環境，以及是否一次傳輸多個新聞等等。
文檔有五部分。第二部分定義了文章格式。第三部分定義了有效的控制信息。第四部分詳細說明了一些有效的傳輸方法。第五部分描述了全部的新聞傳播算法。
2. 文章格式
選擇文章格式首先要考慮的是使這種格式能盡可能的適應現有的一些工具。現有的工具包括各種郵件系統和新聞系統。(由伊利諾伊斯大學開發的NOTEFILES(譯者注：作為一個特定的名詞沒有翻譯)系統被認為是一種新聞系統)一種標準的郵件消息格式已經在ARPA(譯者注：ARPA網絡是Internet網絡的前身)網絡中存在多年了，它適合USENET系統絕大部份的需求。因為ARPA網絡格式是可以擴展的，所以在ARPA網絡標準中進行一些擴展使之適合USENET系統額外的需求是很容易的。因此，所有的USNNET新聞系統被排版成和由RFC822標準所定義的ARPA網絡中的有效的郵件格式一樣。這份標準在對每一篇文章發布一些額外的需求和禁止使用特定的ARPA特性上比ARPA網絡標準有更多的限制。無論如何，它應該總是可以使用一種工具使得一條ARPA網絡消息能處理一篇新聞文章。無論在什么情況下，當這份格式標準和ARPA標準發生沖突時，ARPA標準被認為是正確的。
用于舉例說明的一個樣例：
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.general
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.UUCP>
Date: Friday, 19-Nov-82 16:14:55 EST
Followup-To: net.news
Expires: Saturday, 1-Jan-83 00:00:00 EST
Date-Received: Friday, 19-Nov-82 16:59:30 EST
Organization: Bell Labs, Murray Hill
接下來是一個空行，然后是文章的主體。
這里有一個使用老的格式(在這份標準存在以前)的消息。建議具體的實現也能接受這種文章格式使得轉換更加的容易。
From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
Newsgroups: net.general
Title: Usenet Etiquette -- Please Read
Article-I.D.: eagle.642
Posted: Fri Nov 19 16:14:55 1982
Received: Fri Nov 19 16:59:30 1982
Expires: Mon Jan 1 00:00:00 1990
接下來是一個空行，然后是文章的主體。
一些新聞系統使用一種”A”格式傳輸新聞，如下：
Aeagle.642
net.general
cbosgd!mhuxj!mhuxt!eagle!jerry
Fri Nov 19 16:14:55 1982
Usenet Etiquette - Please Read
接下來直接是文章的主體。
一篇文章首先是很多頭部行，接下來是一個空行，接著是文章主題消息。頭部行包括一個關鍵字，一個冒號，一個空行，和一些附加信息。這是ARPA網絡標準的子集，可以使簡單的軟件輕松的處理它。”from”行可以隨意的以上面例子中給出的格式，或則使用ARPA的<>符號。為了使實現簡單，一些格式(比如：圓括號后面緊跟機器地址)是不允許出現的。
一些頭部是必需的，一些是可選的。所有的自定義頭部都是允許的，并且會被原樣傳送。必需的頭部有Relay-Version,Posting-Version,From,Date,Newsgroups,Subject,Message-ID,Path?？蛇x的頭部有Followup-To,Date-Received,Expires,Reply-To,Sender,References,Control,Distribution,Organization。
2.1 必需的頭部
2.1.1 Relay-Version 這個頭部行依靠一個將文章直接傳輸過來的連接確定程序的版本，即將這篇文章傳輸給下一個站點的程序。比如，站點A將文章發給站點B，B再發給C。從站點A發給站點B的消息中就有一個Relay-Version確定了程序是在A上運行的，從B發給C的消息中確定了程序是在在B上運行的。這個頭部可以用一種統一的方式說明一些老的頭部。Relay-Version選項必須出現在文章的開始；因此，所有符合標準的文章將會以大寫字母”R”開始。除此以外，文章頭部出現的順序沒有任何限制
這一行包含兩部分，以冒號隔開。分別是版本和站點全名。版本被定義為被使用的系統程序(比如使用字母”B”)，版本號，版本時間。舉個例子，這一行將包含以下內容
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
這個頭部項不會傳送給其他的站點。當一個傳播程序在傳輸文章時，只能包含于自己有關的Relay-Version，而不是其他站點的Relay-Version。(為了與老的程序兼容，當Relay-Version出現在文章除了開始以外的地方時，會被假定為一個更老版本的新聞并且被刪除)
2.1.2 Posting-Version 這個頭部行確定了將這個消息輸入網絡的軟件。它的格式和Relay-Version一樣。它通常確定的是和消息序列號一樣的站點，除非發布消息的站點正在作為一個網關在傳輸一條已經包含一個由郵件產生的消息序列號的消息。(當網關允許使用一個外部產生的消息序列號時，這個消息序列號會被檢查，確保它符合本標準和RFC822標準。)
2.1.3 From From行包含了發送這個消息的人的ARPA格式的郵箱地址。在郵箱地址后面可以跟著一對()符號，里面是一個全名。郵箱地址和現實中一樣由文章的作者確定，除非使From行不再被檢查的Sender頭部被使用。注意在所有的站點和域名中，大小寫是一樣的，因此，mark@cbosgd.UUCP,mark@cbosgd.uucp,和mark@CBosgD.UUcp是一個地址。用戶名可能大小寫敏感，也可能不敏感。比如，Billy@cbosgd.UUCP 也許會和BillY@cbosgd.UUCP不一樣。程序在傳輸郵件或新聞時應當避免改變電子郵件的語法。
RFC822指出在()中的文字都是注釋。在ARPA網絡中郵件也使用這種方法把用戶的全名作為注釋放在From行的結尾。這份標準作一個嚴格的規定。全名不是一個注釋，它是頭部行可選的一個部分。全名可能被省略，或者先出現電子郵件地址，然后緊跟著(全名)，或者先出現全名，然后緊跟著<電子郵件地址>。因此，以下三種格式都是允許的：
From: mark@cbosgd.UUCP
From: mark@cbosgd.UUCP (Mark Horton)
From: Mark Horton <mark@cbosgd.UUCP>
全名中會含有任何可以打印的ASCII字符(譯者注：這句可能有問題，原文Full names may contain any printing ASCII characters from space through tilde)，例外的是，里面沒有”(“或”)”符號，也沒有”<”或”>”符號。郵件標準會對全名產生額外的限制，特別的是字母逗號”,”，冒號”:”，分號”;”在全名中不可取。
2.1.4 Date Date行(以前稱”Posted”)是一個可以被ARPA網絡和日常生活所接受的日期格式，由文章發布到網路中的時間所決定。當文章在網路中傳播時，日期不會被改變。一個可以接受的Date格式如下
Weekday, DD-Mon-YY HH:MM:SS TIMEZONE
在前面的樣例中出現了很多日期格式。注意C(譯者注：原文為ctime,即c語言的時間格式)時間格式
Wdy Mon DD HH:MM:SS YYYY
是不允許的，因為它不是ARPA網絡中有效的時間格式。然而，因為老的軟件仍舊支持這種格式，建議新版本的程序也支持這種格式，并且將它轉化成一種可以接收的格式。
TIMEZONE域當前是世界時間分區的縮寫，包括通常的美國時間，北美時間(從白令海峽到紐芬蘭)，歐洲時間，澳大利亞時間，等等。因為當前缺少這樣一個列表(并且無法確定是否存在這樣一個列表)，軟件的開發者被鼓勵將處理TIMEZONE的代碼寫得有彈性一點，并且特別注意的是，不要假定時間分區名稱都是只由三個字母組成的。在實現的時候可以自由處理這個域，在保持時間一致的情況下，將時間域轉換為一個大家都知道的分區(使用適當的工具轉化本地時間)。
2.1.5 Newsgroups Newsgroups行確定文章屬于哪個新聞組。可能會出現多個新聞組，相互間用逗號隔開。新聞組的詳細描述必須是所有已經存在的新聞組的名稱，沒有新聞組會因為被簡單的發布而被建立。
通配符(比如單詞”all”)在Newsgroups中是不允許出現的。例如，新聞組”net.all”是無效的，但是新聞組名稱”net.sport.football”是允許的。
如果一篇接收到的文章中即有有效的新聞組，也有無效的新聞組，那么站點會忽略掉無效的新聞組，而不是將他們移除。比如，站點A訂閱了”btl.net”和”net.all”，它和一個訂閱了”btl.net”但沒有訂閱”net.all”的站點B交換新聞。假設A收到了一篇Newsgroups項為“Newsgroups: net.micro,btl.general“的新聞，則它會把這篇新聞發給B，因為B接受”net.micro”,但是不接受”btl.general”。A必須要保持文章的Newsgroups不變。如果它移除”btl.general”，編輯后的頭部可能是最后一次進入”btl.general”,導致很多訂閱了”btl.general”的用戶無法看到文章。此外，所有定閱了”btl.net”的用戶將不會再看到這種類型的文章。
2.1.6 Subject Subject行(過去稱為”Title”)告訴我們這篇文章的內容摘要。它應當包含足夠的文章內容使得讀者可以僅僅根據摘要來決定是否閱讀這篇文章。如果這篇文章僅僅是對另外一篇文章的應答(比如：跟帖)，默認的Subject為”Re: ”并且引用行是必需的。(用戶也許會認為編輯的主題和跟帖有關，但是默認的主題為”Re: ”(回復))
2.1.7 Message-ID Message-ID行給每個文章一個唯一的標識符。一個同樣的Message-ID不會再這篇文章還存在于任一個新聞組的時候被再次生成。(建議一樣的Message-ID在兩年內不要再次產生)Message-ID的語法格式如下
<不包含任何空格或”>”的字符串>
為了能和RFC822一致，Message-ID必需為以下的格式
<唯一的標識符@全域名>
全域名為文章第一次進入網絡時的主機全名，包括主機所在的域，和一個由不包含”<”，”>”或者”@”符號的可打印ASCII字符組成的唯一標識串。如，主機的唯一標識串可以是一個表示文章被放入網絡順序的整數，或者一個表示文章寫作時間和日期的字符串。例如，一篇從全域名為Berkeley.ARPA的站點ucbvax提交到網絡的文章的有效的Message-ID為<4123@ucbvax.Berkeley.ARPA>。程序員被要求不要假設Message-ID是來自其他主機的，而是將它們看作未知字符串處理。這是不安全的，例如，假設Message-ID會少于14個字符，而前14個字符不是唯一的。
尖括號被認為是Message-ID的一部分。因此，在如ihave/sendme和cancel控制消息的Message-ID中包含空格鍵。空字符(如空格或者TAB)在Message-ID中是不允許出現的。所有在<>中的ASCII字符必須是可打印的。
2.1.8 Path 這行顯示了文章到達當前系統的路徑。當一個系統傳遞信息時，它會在Path行加上它的特有的名稱。不同的名稱可以被任意的標點符號或者空格隔開，如，”cbosgd!mhuxj!mhuxt”，“cbosgd, mhuxj, mhuxt",和"@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp" 甚至"teklabs, zehntel, sri-unix@cca!decvax"都是有效的。(最后來的那個路徑顯示文章傳遞的順序為decvax, sri-unix, zehntel, teklabs)后來的名稱會被加在Path行的左邊，如，在第三個例子中，最近加入Path行的站點為”teklabs”。站點名稱可以包含字母，數字，點號，連字符；其他的標點符號被認為是名稱間的分隔符號。
一般來說，最右邊的站點名稱被認為是這篇文章的起始站點。然而，也允許在最右邊加上發送文章的人的名字。這是為了與其他的系統兼容。
Path行不會被用于回復中，并且不應當被弄成郵件地址的形式。它是用來顯示將文章傳遞到本地站點的路徑。這是一個很有用的信息。一方面可以監控USENET系統的執行情況。另一方面可以建立一條到達新站點的路徑。或許最重要的作用是檢測多余的無用通路，并且刪除它。特別的是，當站點A將文章傳輸給站點B，這時Path中就含有A，因此B就不會將文章反傳給A了。定義本站點的站點名時應該注意要能被它的鄰居站點所熟知，使得上述的優化得以實現。
當站點收到一篇文章時，它會在Path前面加上自己特有的名稱。因此，如果一條Path項為”A!X!Y!Z”的消息由A傳給B，則B會在消息的Path前面加上B!,如”B!A!X!Y!Z”如果B將消息傳給C，消息中含有”B!A!X!Y!Z”，則C會把接受到的消息Path項變成”C!B!A!X!Y!Z”。
需要注意一些特殊的兼容性：因為From,Sender和Reply-To是Internet(譯者注：互聯網)的格式，很多的USENET站點還沒有使用郵件的人有能力懂得Internet的格式，所以它會完全切斷Path和回復功能之間的聯系以破壞回復能力。因此，站點被要求以工作答復的形式盡可能多的保留Path，直到1984年1月1日。在早期的實現中，Path并不總是被認為是有效的回復串，并且這個問題沒有明確要求被實現。然而，一般約定是把站點名和一個”!”號放在Path前面，并且Path以站點名，”!”號,并且用戶名至少要保持到1984年。
2.2 Optional Headers
2.2.1 Reply-To 這一行的格式和From行一樣。如果被使用了，回復給作者時將從這里獲得作者名字。否則，回復給作者是將從From行得到作者名字。(譯者注：沒有翻譯This does not prevent additional copies from being sent to recipients named by the replier, or on To or Cc lines.)全名會隨便出現在From行的()中。
2.2.2 Sender 這個選項只有由文章提交者手動加入到From行。它被用來記錄將文章提交到網絡中的一個實際證據，并且由提交文章的主機上的軟件進行檢測。
例如，如果John Smith訪問CCA并且想使用名字Sarah Jones在網絡上發表一篇文章，則文章會是這樣的
From: smith@ucbvax.uucp (John Smith)
Sender: jones@cca.arpa (Sarah Jones)
如果網關程序將一封來自站點sri-unix的郵件發往網絡，則
From: John.Doe@CMU-CS-A.ARPA
Sender: network@sri-unix.ARPA
這個選項的只要目的是給文章留下個記號以確定它是怎樣被放入網絡中的。全名會隨便出現在From行的()中
2.2.3 Followup-To 這一行和Newsgroups行的格式一樣。如果被選中，跟帖的文章會被發布到這里列出的新聞組中。如果沒有被選中，跟貼的文章會被發送到Newsgroups行列出的新聞組中，例外的是，發往”net.general”的跟貼會代替發往”net.followup”的跟帖。
2.2.4 Date-Received 這一行(以前稱為”Received”)是一個合法的USENET日期格式。它記錄了文章在本地系統中第一次傳送的時間和日期。如果使用了這個選項的文章被主機傳送給其他的機器，接收主機會忽略這個選項，并且用當前時間替換這個選項。因為這個選項只是在本地使用，所以沒有站點被要求支持它。然而，沒有站點應當將這個選項沒有改變的傳遞給其他站點。
2.2.5 Expires 這個選項如果被選中，則是一個合法的USENET日期格式。它暗示了一個文章應該過期的日期。如果沒有被選中，使用本地默認的過期日期。
這個選項被用于清除有條件限制的文章，或者使重要文章能保留更長的時間。例如，一條通告某個研討會開幕的消息有最遲為研討會結束日期的時間限制，因為這條信息在研討會結束后就沒用了。因為本地主機對新聞的過期時間有自己的限制(如有效的磁盤限制)，所以用戶不得不給文章一個日期限制，除非這篇文章的主題有一個默認的日期限制。系統軟件幾乎從不提供Expires行。它會允許本地限制策略使用，除非有一個很好的理由不用它。
2.2.6 References 這個選項列出了所有在提交這篇文章時參考到的文章的Message-ID。所有的跟帖都需要這個選項，當一個新主題出現時，禁止使用這個選項。具體的實現需要提供一個跟帖命令，以使用戶可以發布跟帖。這個命令會產生和原文一樣的主題行，區別是原文主題行不以”Re: ”或者”re: ”開頭，而跟帖會在主題前加上”Re: ”四個字符。如果原文中沒有References選項，則跟帖中只會包含本文的Message-ID(在<>中)。如果原文中有References選項，則跟帖的主題行會包含References，一個空格，原文的Message-ID。
這個選項的主要目的是使文章成為一個組，則用戶程序就可以在組中進行交流了。它允許一個新聞組中的會話保持在一起。潛在的用會可以只關閉整個會話，而不需要到新聞組中取消預訂。這個選項可能對用戶界面無效，但是對于允許這個選項的系統來說，這個選項有益于產生自動回復，并且手動的回復(已經被打印的文章能被更好的輸入)也被鼓勵包含這個選項。
2.2.7 Control 如果文章含有Control行，則文章就是控制消息。控制信息用于USENET主機間通訊，不會被用戶讀到?？刂葡⒑鸵话阆⒁粯臃植荚诟鱾€新聞組之間。控制航的內容是給主機的消息。
因為兼容性的原因，匹配新聞組樣式”all.all.ctl”的信息也是控制信息。如果這樣的控制消息沒有Control項，則消息頭部中的主題作為控制消息。然而，匹配這種樣式的新聞組的消息和本標準是不一致的。
2.2.8 Distribution 這行可以改變發布消息的范圍。它和Newsgroup的格式一樣。用戶是否訂閱仍舊被Newsgroup選項控制，但是消息會發給所有在Distribution中列出的訂閱了這個新聞組的系統。因此，一個在新澤西販賣汽車的文章會有這樣的頭部
Newsgroups: net.auto,net.wanted
Distribution: nj.all
因而，文章僅會發給那些在新澤西訂閱了”net.auto”或”net.wanted”的個人。這個頭部項的目的是進一步限制文章在新聞組中的發布，而不是擴大。一個本地新聞組，如nj.crazy-eddie，在新澤西外面且認為這個新聞組無效的站點將不會被發布。Distribution行中允許出現通配符。跟帖文章默認和原先的文章有一樣Distribution。用戶可以給他增加更多的限制，如果原文由很多限制，但是需要更加廣泛的回復，則需要放寬這個限制。
2.2.9 Organization 這一行的文本簡短的描述了文章發送者，或者機器所屬的組織機構。這個選項的主要目的是確定文章發送者的身份，因為主機名常常是比較秘密的，以至于很難通過電子郵件地址確認組織。
3 控制消息
這個部分列出了當前定義的一些控制消息?？刂祁^部的主體是控制消息?？刂葡⑹且淮?個或多個單詞，并且單詞相互間以空格(空格或TaB)隔開的字符串。第一個單詞是控制信息的名稱，接下來一個是消息參數。剩余的串是消息主體，同時也是潛在的參數；如，From行會指出一個用于應答的地址。程序和管理員會選擇是將控制消息自動的發出，還是手動一個一個發出。然而，手動處理控制消息往往是很有效的。
3.1 Cancel
cancel <message ID>
如果Message-ID所對應的文章出現在本地系統中，則會刪除該文章。這個消息允許用戶刪除一篇已經進入網絡的文章。
只允許文章的作者或是本地超級用戶被允許使用這個命令。文章的發送者的校驗首先在Sender選項中進行，如果沒有這個選項，則在From中校驗。有效的Cancel消息的發送者必須是、原文章種Sender，或者From中的一個發送者。一個有效的發送者允許在原文中無效的From中出現。
3.2 Ihave/Sendme
ihave <message ID list> <remotesys>
sendme <message ID list> <remotesys>
這個消息屬于”Ihave/Sendme”協議部分。它允許站點A告訴另外一個站點B，它收到一條特別的消息。假設A收到文章”ucbvax.1234”，并且想把它傳送給站點B。A首先會傳送控制消息”ihave ucbvax.1234 A”給B(以發給“新聞組B”的形式發送)。如果B沒有收到過這篇文章，則返回一個控制消息”sendme ucbvax.1234 B”(發給“新聞組A”)。一旦A收到這條消息，它會把文章發給B。這個協議可以切斷兩個站點間的通道。只有在某些特殊情況下才可以使用這條消息。一般的情況是，大部分的消息是很短的，但是突然間需要用UUCP傳輸一個很長的消息，這時發送“ihave”消息比直接發送文章要經濟得多。
一個解決這種高消耗問題的方法是批請求。很多的Message-ID被包含在一個消息中。如果在控制消息中沒有Message-ID，則需要掃描消息主體來尋找Message-ID，一個一行。
3.3 Newgroup
newgroup <groupname>
這條控制消息創建一個給定名稱的新聞組。因為新聞組被創建前不會有文章被發布或者跟帖，所以這條消息在新聞組被使用前必需被使用。消息的主體應該是關于新聞組使用的一段簡短的描述。
3.4 Rmgroup
rmgroup <groupname>
這個消息刪除一個給定名稱的新聞組。因為這個命令會刪除所有站點中的選中的新聞組，所以管理員要十分小心的使用它。
3.5 Sendsys
sendsys (no arguments)
“sys”文件列出了所有的鄰居站點，并且那些被發送給每個鄰居的新聞組將會被郵寄給控制信息中指出的作者(首先在Reply-to中找，沒有再在From中找)。這個信息被認為是公開的信息，并且在USENET網絡會員的要求下，被按照要求的提供(譯者注：這里可能有問題，原文and it is a requirement of membership in USENET that this information be provided on request),或者是自動作為這個消息的應答信息，或者是手動發一份郵件給這條信息的作者。這些信息用于USENET保持一份地圖以便更新數據，并且決定哪些網絡新聞需要發布。
發給作者的郵件中的信息文件的格式和”sys”文件格式是一樣的。這種格式是每個鄰居站點一行(加上本地站點一行),包含以冒號隔開的四個不同的區域。第一個是鄰居站點的名稱，第二個是發送給鄰居的新聞組的樣式，第三個和第四個在這個標準中沒有定義。一個簡單的應答如下：
From cbosgd!mark Sun Mar 27 20:39:37 1983
Subject: response to your sendsys request
To: mark@cbosgd.UUCP
Responding-System: cbosgd.UUCP
cbosgd:osg,cb,btl,bell,net,fa,to,test
ucbvax:net,fa,to.ucbvax:L:
cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
3.6 Senduuname
senduuname (no arguments)
這個命令使得”uuname”程序被運行，結果是給控制消息中指出的作者(首先在Reply-to中尋找，沒有的話在From中尋找)發一封郵件。這個程序列出了所有與本地站點相鄰的可以使用UUCP功能的主機。這個信息用于建立一個UUCP網路的地圖。sys文件和UUCP的L.sys文件不一樣。沒有那些口令被列出的站點的同意，L.sys文件不會把自己傳送給另外的作者。
站點提供這些信息是可選的。一些回復應該給控制信息中提到的作者，以便使傳輸錯誤變得不是不可饒恕。它也允許站點使用運行uuname程序(或其他的方式決定UUCP鄰居)，并且將回復郵寄給作者前自動或手動的編輯信息。這個文件每一行一個站點，以UUCP站點名稱開頭。額外的信息可以加載站點名后面，兩者以空格或TAB鍵隔開。電話號碼和密碼不應該被包含在文件中，因為這個文件被認為是公開的信息(uuname程序只會傳送站點名稱，而非整個L.sys文件，因此，電話號碼和密碼不會被傳送)。
這個控制信息的目的是產生并且維持一個UUCP傳輸路徑圖。因此，連接可以通過那些可以發送電子郵件的站點！無論鏈接是否在物理層的UUCP鏈接，都因該包含一個用戶格式。如果一個郵件網關要用到它，也要包含它。因為所有這個信息的應答都是可選的，所以站點可以自由的編輯這個列表，并決定是否公開那些私有或秘密的行。
3.7 Version
version (no arguments)
運行在本地系統上的軟件的名稱和版本會被郵寄給控制消息中提到的作者(首先在Reply-to中尋找，沒有的話在From中尋找)。
傳輸方法
USENET系統不是一個物理級的網絡，而是存在于多個物理級網絡上的邏輯網絡。這些網絡包括，但不僅限于，UUCP，ARPANET，Ethernet，BLICN網，NSC Hyperchannel，和Berknet。重要的是在USENET兩個系統間有辦法交換文章，文章以這里列出的格式從一個系統到另外一個系統，并且在接收系統上，可以使用網絡新聞軟件處理接收到的文章。(在UNIX系統中，這樣常常意味著”rnews”程序開始處理在標準輸入中的文章)
雖然USENET上的系統不需要有能力去懂得ARPA互聯網上的郵件格式，但是我們強力建議具體的實現有這個能力。因為From,Reply-To,和 Sender 行使用的是互聯網的格式，所以用非互聯網格式回復變得不可能。一個沒有互聯網郵件系統的站點可以使用Path行來回復，但是這個選項不能確保是這個回復路徑是否還在工作中。在任何情況下，任何站點產生或者傳輸的新聞消息都需要有一個互聯網地址，允許它們接受來自使用互聯網郵件格式的站點的郵件，并且他們必須在他們的From行中包含他們的互聯網地址。
4.1 遠程執行
一些網絡允許遠程執行命令。在這些系統中，新聞會以命令和標準輸入的文章捆綁的形式發送。例如，如果遠程系統名叫”remote”，新聞會伴隨著命令” uux -remote!rnews”通過UUCP鏈接傳送，在Berknet中，命令為” net -mremote rnews”。因為文章是使用可靠的機制傳輸的，所以一般把命令和文章捆綁傳送，而不是遠程直接執行命令。這樣做的原因是，如果遠程系統關閉了，遠程命令就會失敗，并且文章也不會被傳送出去。如果文章被捆綁了，最后當系統都啟動后，它還是會被發送。
4.2 使用郵件傳送
在一些系統中，直接的捆綁遠程命令是不可以的，但是，絕大系統的文章都郵件功能，并且新聞文章可以以郵件的形式發送。一種方法是發送一封和新聞消息一樣的郵件消息：郵件頭是新聞頭，郵件主體是新聞主題。我們約定這種郵件是發給遠程機器上的用戶”newsmail”。
這種方法可能遇到的問題是郵件系統可能不認為消息中的From行是有效的，因為這個郵件消息是被系統程序自動產生的，和原文不一樣。還有一個問題是在郵件傳輸中產生的錯誤的消息會發給文章的作者，但是他不能控制文章在兩個協同工作主機間的傳送，也不知道應該通知誰。傳輸的錯誤信息應該發給發送機器上可靠的人。
解決這種問題的方法是將文章壓縮為一個郵件消息，以至于整個文章(頭部和主體)成為郵件主體的一部分。我們約定這種郵件是發給遠程機器上的用戶”rnews”。在新聞文章每一行的頭部加上一個字母’N’,再產生附加的郵件頭部，這樣就構成了一個郵件消息。加上’N’是為了防止文章中特殊的行妨礙郵件的傳送，也是方式在成為郵件的一部分時被插入額外的行(頭部，空行等等)。接收機器上的程序接收發給”rnews”的郵件并提取文章，然后調用”rnew”程序。消息郵件的一個例子為：
Date: Monday, 3-Jan-83 08:33:47 MST
From: news@cbosgd.UUCP
Subject: network news article
To: rnews@npois.UUCP
NRelay-Version: B 2.10 2/13/83 cbosgd.UUCP
NPosting-Version: B 2.9 6/21/82 sask.UUCP
NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
NFrom: derek@sask.UUCP (Derek Andrew)
NNewsgroups: net.test
NSubject: necessary test
NMessage-ID: <176@sask.UUCP>
NDate: Monday, 3-Jan-83 00:59:15 MST
N
NThis really is a test. If anyone out there more than 6
Nhops away would kindly confirm this note I would
Nappreciate it. We suspect that our news postings
Nare not getting out into the world.
N
使用郵件解決捆綁問題是因為當目標機器關閉的時候郵件必須被捆綁。然而，它增加了傳輸處理的消耗(為了壓縮和提取文章)，并且使得軟件在給郵件和新聞不同的優先權時產生了困難。
4.3 批處理
因為新聞問斬往往是很短的，并且在一天之中兩個站點間會傳送大量的文章，所以感覺可以批處理文章。很多文章可以使用在兩個站點間約定的習慣結合成一篇大的文章。一種批處理策略在這里討論，并且它是經過實驗的。
新聞文章被組合成劇本一樣，使用下面的方式隔開：
##! rnews 1234
1234是文章的字節長度。每一個這樣的行后面跟著一篇給定字節長度的文章。文章的最后一個新行有意被作為一個字符，即使它是以CRFL的形式存儲的。如，文章的批處理看起來是這樣的:
#! rnews 374
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.general
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.UUCP>
Date: Friday, 19-Nov-82 16:14:55 EST
這里是重要的USENET禮節信息。
#! rnews 378
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.followup
Subject: Notes on Etiquette article
Message-ID: <643@eagle.UUCP>
Date: Friday, 19-Nov-82 17:24:12 EST
這里有一些我在文章末尾忘記提及的內容。
因為消息的第一個字符是”#”，所以它被認為是一個批處理消息。這個消息隨后會被傳遞并且被解釋成非批處理的形式。
5 . 新聞的傳播算法
這個部分要介紹整個的USENET系統和站點將新聞傳送到整個網絡的算法。因為所有的站點都可能被不正確的文章格式和錯誤消息所影響，所以確定一個標準的方法是很重要的。USENET是一副有向圖。圖中的每個節點就是一臺主機，每條邊就是一條從一個主機到另外一個主機的傳播路徑。每條邊都被表上了一個新聞組樣式，用于說明在這個鏈接上傳輸的新聞組類。大部分的邊都是雙向的，那是因為如果A可以發送新聞組類到B，B往往也可以發送一樣新聞組類到A。這樣的雙向路徑不是必需的，但是不能沒有。
USENET有很多的子網組成。每個子網都有一個名字，如”net”或者”btl”。特殊的子網”net”被定義成USENET，雖然所有的子網合起來是USENET的超集(因為站點得到了本地的新聞組，但是沒有得到”net.all”)。沒一個子網都是一副連接圖，即在子網的兩個站點間至少存在一條路徑。額外的是，整個USENET圖(理論上)也是連接圖。(特別的是，一些政治上的考慮會使一些站點不能發布文章到網絡上的其他地方。)
一篇文章被發布到一篇公布了新聞組目錄的機器上。這臺機器的一些新聞組接受它，并且把它轉發給那些對它有興趣并且至少有一個新聞組的鄰居主機(站點A認為B對新聞有興趣，僅當文章所屬的新聞組匹配從A到B的路徑上的新聞組)。這個站點接收傳來的文章，檢查它是否為想要得到的文章，然后把它放到相應的新聞組，最后繼續將這篇文章傳遞給那些感興趣的鄰居主機。這個過程一直會持續到整個網絡都能看到這篇文章。
算法重要的一個部分就是防止文章在網絡中循環傳遞。上面的過程會導致消息在一個環中一直傳遞。特別的是，當站點A將文章傳遞給站點B后，B會把文章在反傳給A，這樣不斷的重復傳遞。一種解決方法是進行歷史記錄。每一個站點都將它已經看到的文章記錄下來(記錄Message-ID)，一旦它收到一篇它已經看到過的文章，就會馬上丟棄這篇文章。這個方法足可以解決循環傳遞問題了，但是還有更好的優化避免將文章簡單的丟棄。
一種優化方法是文章不會傳遞給那些在文章Path選項中列出的站點。當一個機器名字出現在Path行中時，意味著文章已經傳遞給這個機器了。還有一種優化是，如果文章在站點A被創建，則認為A已經看到過它了。(創建主機可以由Posting-Version選項確定)
因而，一篇發布給新聞組”net,misc”的文章會自動匹配”net.all”(“all”是通配符，并且匹配任何傳)，并且會被發布給訂閱了”net.all”的所有站點(由他們的鄰居發送給他們的信息決定)。這些站點構成了子網”net”。所有發給” btl.general”的文章都會到達接收”btl.all”的站點，但是不會到達沒有”btl.all”的站點。結果是文章到達了子網”btl”，發給” net.micro,btl.general”的文章會到達所有訂閱了”net.all”，或者”btl.all”的站點。
譯者注：所有的個人，媒體，和其他機構都可以無償轉發或者修正我的文章，但是任何的修正都要事先通知我，我的郵箱是：ghbxx2004@yahoo.com.cn。