Network Working Group M. Horton
Request for Comments: 1036 AT&T Bell Laboratories
Obsoletes: RFC-850 R. Adams
Center for Seismic Studies
December 1987
USENET消息交換標準
備忘錄地位
這份文檔定義了在USENET主機間交換網(wǎng)絡新聞消息的標準格式。它更新并替換了RFC850，參照了新聞程序B2.11。這份備忘錄以RFC形式發(fā)布是為了使因特網(wǎng)社區(qū)更容易的得到這個信息。它沒有指出一種因特網(wǎng)標準。備忘錄的發(fā)行沒有任何限制。
1. 介紹
這份文檔定義了在USENET主機間交換網(wǎng)絡新聞所用到的標準消息格式。它詳細描述了消息格式本身，也給出了部分的新聞傳輸標準。新聞的傳輸不需要完全按照標準格式以便于給個別的主機提供一個好的彈性去選擇傳輸?shù)挠布蛙浖h(huán)境，以及是否一次傳輸多個新聞等等。
文檔有五部分。第二部分定義了消息格式。第三部分定義了有效的控制信息。第四部分詳細說明了一些有效的傳輸方法。第五部分描述了全部的新聞傳播算法。
2. 消息格式
選擇消息格式首先要考慮的是使這種格式能盡可能的適應現(xiàn)有的一些工具。現(xiàn)有的工具包括各種郵件系統(tǒng)和新聞系統(tǒng)。(由伊利諾伊斯大學開發(fā)的NOTEFILES(譯者注：作為一個特定的名詞沒有翻譯)系統(tǒng)被認為是一種新聞系統(tǒng))一種標準的郵件消息格式已經(jīng)在Internet網(wǎng)絡中存在多年了，它適合USENET系統(tǒng)絕大部份的需求。因為Internet網(wǎng)絡格式是可以擴展的，所以在Internet網(wǎng)絡標準中進行一些擴展使之適合USENET系統(tǒng)額外的需求是很容易的。因此，所有的USNNET新聞系統(tǒng)被排版成和由RFC822標準所定義的Internet網(wǎng)絡中的有效的郵件格式一樣。這份標準在對每一篇消息發(fā)布一些額外的需求和禁止使用特定的Internet特性上比ARPA網(wǎng)絡標準有更多的限制。無論如何，它應該總是可以使用一種工具使得一條Internet網(wǎng)絡消息能處理一篇新聞消息。無論在什么情況下，當這份格式標準和Internet標準發(fā)生沖突時，RFC822被認為是正確的。
用于舉例說明的一個樣例：
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.ATT.COM>
Date: Fri, 19 Nov 82 16:14:55 GMT
Followup-To: news.misc
Expires: Sat, 1 Jan 83 00:00:00 -0500
Organization: AT&T Bell Laboratories, Murray Hill
接下來是一個空行，然后是消息的主體。
這里有一個使用老的格式(在這份標準存在以前)的消息。建議具體的實現(xiàn)也能接受這種消息格式使得轉換更加的容易。
From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
Newsgroups: news.misc
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
接下來是一個空行，然后是消息的主體。
一些新聞系統(tǒng)使用一種”A”格式傳輸新聞，如下：
Aeagle.642
news.misc
cbosgd!mhuxj!mhuxt!eagle!jerry
Fri Nov 19 16:14:55 1982
Usenet Etiquette - Please Read
接下來直接是消息的主體。
標準的USENET消息有很多頭部行，接下來是一個空行，接著是消息主體消息。每一個頭部行包括一個關鍵字，一個冒號，一個空行，和一些附加信息。這是Internet網(wǎng)絡標準的子集，可以使簡單的軟件輕松的處理它。”from”行可以隨意的以上面例子中給出的格式，或則使用Internet的<>符號。為了使實現(xiàn)簡單，一些格式(比如：圓括號后面緊跟機器地址)是不允許出現(xiàn)的。
一些頭部是必需的，一些是可選的。所有的自定義頭部都是允許的，并且會被原樣傳送。必需的頭部有"From", "Date", "Newsgroups", "Subject", "Message-ID", 和 "Path"。可選的頭部有"Followup-To", "Expires", "Reply-To", "Sender", "References", "Control", "Distribution", "Keywords", "Summary", "Approved", "Lines", "Xref", 和 "Organization"。
2.1 必需的頭部
2.1.1 From
這行包含了發(fā)送這個消息的人的Internet格式的郵箱地址。在郵箱地址后面可以跟著一對()符號，里面是一個全名。郵箱地址和現(xiàn)實中一樣由消息的作者確定，除非使From行不再被檢查的Sender頭部被使用。注意在所有的站點和域名中，大小寫是一樣的，因此，mark@cbosgd.ATT.COM, mark@cbosgd.att.com,和mark@CBosgD.ATt.COm是一個地址。用戶名可能大小寫敏感，也可能不敏感。比如，Billy@cbosgd.ATT.COM 也許會和BillY@cbosgd.ATT.COM不一樣。程序在傳輸郵件或新聞時應當避免改變電子郵件的語法。
RFC822指出在()中的文字都是注釋。在Internet網(wǎng)絡中郵件也使用這種方法把用戶的全名作為注釋放在From行的結尾。這份標準作一個嚴格的規(guī)定。全名不是一個注釋，它是頭部行可選的一個部分。全名可能被省略，或者先出現(xiàn)電子郵件地址，然后緊跟著(全名)，或者先出現(xiàn)全名，然后緊跟著<電子郵件地址>。因此，以下三種格式都是允許的：
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)，例外的是，里面沒有”(“或”)”符號，也沒有”<”或”>”符號。郵件標準會對全名產(chǎn)生額外的限制，特別的是字母逗號”,”，冒號”:”，分號”;”在全名中不可取。
2.1.2 Data
Date行(以前稱”Posted”)是一個可以被RFC822和USENET軟件中的日期程序接受的日期。當消息在網(wǎng)路中傳播時，日期不會被改變。一個可以接受的Date格式如下
Wdy, DD Mon YY HH:MM:SS TIMEZONE
在前面的樣例中出現(xiàn)了很多日期格式。注意C(譯者注：原文為ctime,即c語言的時間格式)時間格式
Wdy Mon DD HH:MM:SS YYYY
是不允許的，因為它不是RFC822中有效的時間格式。然而，因為老的軟件仍舊支持這種格式，建議新版本的程序也支持這種格式，并且將它轉化成一種可以接受的格式
不期待有一個我完整的TIMEZONE域列表。國際時間(GMT)，北美時間(PST, PDT, MST, MDT, CST, CDT, EST, EDT)和在RFC822被說明的+/-hhmm(這里作為一個名詞沒有翻譯)偏移都應當被支持。
2.1.3 Newsgroups
Newsgroups行確定消息屬于哪個新聞組。可能會出現(xiàn)多個新聞組，相互間用逗號隔開。新聞組的詳細描述必須是所有已經(jīng)存在的新聞組的名稱，沒有新聞組會因為被簡單的發(fā)布而被建立。
通配符(比如單詞”all”)在Newsgroups中是不允許出現(xiàn)的。例如，新聞組”net.all”是無效的，但是新聞組名稱”net.sport.football”是允許的。
如果一個接收到的消息中即有有效的新聞組，也有無效的新聞組，那么站點會忽略掉無效的新聞組，而不是將他們移除。比如，站點A訂閱了”btl.net”和”comp.all”，它和一個訂閱了”btl.net”但沒有訂閱”comp.all”的站點B交換新聞消息。假設A收到了一篇Newsgroups項為“Newsgroups: comp.unix,btl.general“的消息。
這個消息會發(fā)給B，因為B接受” comp.unix”,但是不接受”btl.general”。A必須要保持消息的Newsgroups不變。如果它移除”btl.general”，編輯后的頭部可能是最后一次進入”btl.general”,導致很多訂閱了”btl.general”的用戶無法看到消息。此外，所有定閱了”btl.net”的用戶將不會再看到這種類型的消息。
2.1.4 Subject
Subject行(過去稱為”Title”)告訴我們這個消息的內(nèi)容摘要。它應當包含足夠的消息內(nèi)容使得讀者可以僅僅根據(jù)摘要來決定是否閱讀這個消息。如果這個消息僅僅是對另外一個消息的應答(比如：跟帖)，默認的Subject為”Re: ”并且引用行是必需的。因為是跟帖，所以推薦使用”Summary”行。
2.1.5 Message-ID
Message-ID行給每個消息一個唯一的標識符。一個同樣的Message-ID不會再這篇消息還存在于任一個新聞組的時候被再次生成。(建議一樣的Message-ID在兩年內(nèi)不要再次產(chǎn)生)Message-ID的語法格式如下
<不包含任何空格或”>”的字符串>
為了能和RFC822一致，Message-ID必需為以下的格式
<唯一的標識符@full_domain_name>
full_domain_name為消息第一次進入網(wǎng)絡時的主機全名，包括主機所在的域，和一個由不包含”<”，”>”或者”@”符號的可打印ASCII字符組成的唯一標識串。
如，主機的唯一標識串可以是一個表示消息被放入網(wǎng)絡順序的整數(shù)，或者一個表示消息寫作時間和日期的字符串。例如，一篇從全域名為Berkeley.EDU的站點ucbvax提交到網(wǎng)絡的消息的有效的Message-ID為<4123@ucbvax.Berkeley.EDU>。程序員被要求不要假設Message-ID是來自其他主機的，而是將它們看作未知字符串處理。這是不安全的，例如，假設Message-ID會少于14個字符，而前14個字符不是唯一的也不要認為不會含有”/”。
尖括號被認為是Message-ID的一部分。因此，在如ihave/sendme和cancel控制消息的Message-ID中包含空格鍵。空字符(如空格或者TAB)在Message-ID中是不允許出現(xiàn)的，盡可能不要使用”/”。所有在”<>”中的ASCII字符必須是可打印的。
2.1.6 Path
這行顯示了信息到達當前系統(tǒng)的路徑。當一個系統(tǒng)傳遞信息時，它會在Path行加上它的特有的名稱。不同的名稱可以被任意的標點符號或者空格隔開。因此，下面的是有效的：
cbosgd!mhuxj!mhuxt
cbosgd, mhuxj, mhuxt
@cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
teklabs, zehntel, sri-unix@cca!decvax
(最后來的那個路徑顯示信息傳遞的順序為decvax, sri-unix, zehntel, teklabs)后來的名稱會被加在Path行的左邊，如，在第三個例子中，最近加入Path行的站點為”teklabs”。站點名稱可以包含字母，數(shù)字，點號，連字符；其他的標點符號被認為是名稱間的分隔符號。
一般來說，最右邊的主機名稱被認為是這篇信息的起始站點。然而，也允許在最右邊加上發(fā)送信息的人的名字。這是為了與其他的系統(tǒng)兼容。
Path行不會被用于回復中，并且不應當被弄成郵件地址的形式。它是用來顯示將信息傳遞到本地主機的路徑。這是一個很有用的信息。一方面可以監(jiān)控USENET系統(tǒng)的執(zhí)行情況。另一方面可以建立一條到達新主機的路徑。或許最重要的作用是檢測多余的無用通路，并且刪除它。特別的是，當主機A將信息傳輸給主機B，這時Path中就含有A，因此B就不會將信息反傳給A了。定義本主機的主機名時應該注意要能被它的鄰居主機所熟知，使得上述的優(yōu)化得以實現(xiàn)。
當主機收到一篇消息時，它會在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(譯者注：互聯(lián)網(wǎng))的格式，很多的USENET主機還沒有使用郵件的人有能力懂得Internet的格式，所以它會完全切斷Path和回復功能之間的聯(lián)系以破壞回復能力。在早期的實現(xiàn)中，Path并不總是被認為是有效的回復串，并且這個問題沒有明確要求被實現(xiàn)。然而，一般約定是把主機名和一個”!”號放在Path前面，并且Path以主機名，和一個”!”號,并且要盡可能的保持。
2.2 可選頭部
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.)全名會隨便出現(xiàn)在’From’行的()中。
2.2.2 Sender
這個選項只有由消息提交者手動加入到From行。它被用來記錄將消息提交到網(wǎng)絡中的一個實際證據(jù)，并且由提交消息的主機上的軟件進行檢測。
例如，如果John Smith訪問CCA并且想使用名字Sarah Jones在網(wǎng)絡上發(fā)表一個消息，則消息會是這樣的
From: smith@ucbvax.Berkeley.EDU (John Smith)
Sender: jones@cca.COM (Sarah Jones)
如果網(wǎng)關程序?qū)⒁环鈦碜哉军cunix.SRI.COM的郵件發(fā)往網(wǎng)絡，則
From: John.Doe@A.CS.CMU.EDU
Sender: network@unix.SRI.COM
這個選項的只要目的是給消息留下個記號以確定它是怎樣被放入網(wǎng)絡中的。全名會隨意的出現(xiàn)在From行的圓括號<()>中
2.2.3 Followup-To
這一行和Newsgroups行的格式一樣。如果有這個頭部，跟帖的消息會被發(fā)布到這里列出的新聞組中。如果沒有被選中，跟貼的消息會被發(fā)送到”Newsgroups”行列出的新聞組中。
如果有發(fā)布者的關鍵字，跟帖消息不不被允許的。這個消息應該被郵件郵寄到消息的發(fā)送者。
2.2.4 Expires
這個選項如果被選中，則是一個合法的USENET日期格式。它暗示了一個消息應該過期的日期。如果沒有被選中，使用本地默認的過期日期。這個選項被用于清除有條件限制的文章，或者使重要文章能保留更長的時間。例如，一條通告某個研討會開幕的消息有最遲為研討會結束日期的時間限制，因為這條信息在研討會結束后就沒用了。因為本地主機對新聞的過期時間有自己的限制(如有效的磁盤限制)，所以用戶給消息一個日期限制也沒什么用，除非這個消息的主題有一個默認的日期限制。系統(tǒng)軟件幾乎從不提供Expires行。它允許使用本地限制策略，除非有一個很好的理由不用它。
2.2.5 References
這個選項列出了所有在提交這個消息時參考到的消息的Message-ID。所有的跟帖都需要這個選項，當一個新主題出現(xiàn)時，禁止使用這個選項。具體的實現(xiàn)需要提供一個跟帖命令，以使用戶可以發(fā)布跟帖。這個命令會產(chǎn)生和原文一樣的主題行，區(qū)別是原文主題行不以”Re: ”或者”re: ”開頭，而跟帖會在主題前加上”Re: ”四個字符。如果原文中沒有References選項，則跟帖中只會包含本文的Message-ID(在<>中)。如果原文中有References選項，則跟帖的主題行會包含References，一個空格，原文的Message-ID。
這個選項的主要目的是使消息成為一個組，則用戶程序就可以在組中進行交流了。它允許一個新聞組中的會話保持在一起。潛在的用會可以只關閉整個會話，而不需要到新聞組中取消預訂。這個選項可能對用戶界面無效，但是對于允許這個選項的系統(tǒng)來說，這個選項有益于產(chǎn)生自動回復，并且手動的回復(已經(jīng)被打印的文章能被更好的輸入)也被鼓勵包含這個選項。
如果前面的”References”行太長了，則允許不包含全部的引用。需要嘗試包含合理數(shù)量的后面的引用。
2.2.6 Control
如果文章含有Control行，則文章就是控制消息。控制信息用于USENET主機間通訊，不會被用戶讀到。控制消息和一般消息一樣分布在各個新聞組之間。控制航的內(nèi)容是給主機的消息。
因為兼容性的原因，匹配新聞組樣式”all.all.ctl”的信息也是控制信息。如果這樣的控制消息沒有Control項，則消息頭部中的主題作為控制消息。然而，匹配這種樣式的新聞組的消息和本標準是不一致的。
也是兼容性原因，如果"Subject:"行的前4個字母是"cmsg"，則剩下的"Subject:"行的內(nèi)容被認為是一個控制消息。
2.2.7 Distribution
這行可以改變發(fā)布消息的范圍。它和Newsgroup的格式一樣。用戶是否訂閱仍舊被Newsgroup選項控制，但是消息除了” Newsgroup”之外，還發(fā)給所有在Distribution中列出的訂閱了這個消息新聞組系統(tǒng)。一旦這個消息被傳輸，接收站點必須正常的將這個消息接收到” Newsgroup”中指出的一個新聞組外還要將之接收到” Distribution”中的一個組中。因此，一個在新澤西販賣汽車的文章會有這樣的頭部：
Newsgroups: rec.auto,misc.forsale
Distribution: nj,ny
因而，消息僅會發(fā)給那些在新澤西訂閱了”net.auto”或” misc.forsale”的個人。這個頭部項的目的是進一步限制文章在新聞組中的發(fā)布，而不是擴大。一個本地新聞組，如nj.crazy-eddie，在新澤西外面且認為這個新聞組無效的主機將不會被發(fā)布。Distribution行中允許出現(xiàn)通配符。跟帖文章默認和原先的文章有一樣Distribution。用戶可以給他增加更多的限制，如果原文由很多限制，但是需要更加廣泛的回復，則需要放寬這個限制。
2.2.8 Organization
這一行的文本簡短的描述了文章發(fā)送者，或者機器所屬的組織機構。這個選項的主要目的是確定文章發(fā)送者的身份，因為主機名常常是比較秘密的，以至于很難通過電子郵件地址確認組織。
2.2.9 Keywords
一些被很好選擇的消息的標識符會出現(xiàn)在這行。它用于幫助讀者確定這篇文章是否有興趣去讀。
2.2.10 Summary
這一行是消息的大概摘要。它經(jīng)常被作為其它消息跟帖的一部分。此外，它對于讀者確定是否讀這個消息也是很有用的。
2.2.11 Approved
任何發(fā)布到中介新聞組(譯者注：這里的意思是這個新聞組的新聞需要審查)的消息都需要這一行。它由中介人添加，內(nèi)容是中介人的電子郵件地址。控制信息也需要這一行。
2.2.12 Lines
這一行為消息內(nèi)容的行數(shù)。
2.2.13 Xref
這行為一個主機名(省略域名)，一個空格，一個用冒號<:>隔開的列表，列表中的信息分別為在”Newsgroups”中列出的新聞組中的號碼。
這個值僅用于本地系統(tǒng)，所以他不會被傳播。如下：
Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
From: reid@decwrl.DEC.COM (Brian Reid)
Newsgroups: news.lists,news.groups
Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
Message-ID: <5658@decwrl.DEC.COM>
Date: 1 Oct 86 11:26:15 GMT
Organization: DEC Western Research Laboratory
Lines: 441
Approved: reid@decwrl.UUCP
Xref: seismo news.lists:461 news.groups:6378
這里的”Xref”指出在主機seismo上的文章在新聞組”news.lists”中的號碼是641，在新聞組”news.groups”上的號碼是63778。
3 控制消息
這個部分列出了當前定義的一些控制消息。控制頭部的主體是控制消息。控制消息是一串有0個或多個單詞，并且單詞相互間以空格(空格或TaB)隔開的字符串。第一個單詞是控制信息的名稱，接下來一個是消息參數(shù)。剩余的串是消息主體，同時也是潛在的參數(shù)；如”From”行會指出一個用于應答的地址。
程序和管理員會選擇是將控制消息自動的發(fā)出，還是手動一個一個發(fā)出。然而，手動處理控制消息往往是很有效的。
3.1 Cancel
cancel <message ID>
如果Message-ID所對應的消息出現(xiàn)在本地系統(tǒng)中，則會刪除該消息。這個消息允許用戶刪除一篇已經(jīng)進入網(wǎng)絡的消息。
如果系統(tǒng)不能刪除被請求的消息，它將不會把該cancel消息傳遞給它的鄰居主機。
只允許消息的作者或是本地超級用戶被允許使用這個命令。消息的發(fā)送者的校驗首先在”Sender”選項中進行，如果沒有這個選項，則在”From”中校驗。有效的Cancel消息的發(fā)送者必須是原消息中”Sender”，或者”From”中的一個發(fā)送者。一個有效的發(fā)送者允許在原文中無效的”From”中出現(xiàn)。
3.2 Ihave/Sendme
ihave <message ID list> <remotesys>
sendme <message ID list> <remotesys>
這個消息屬于”Ihave/Sendme”協(xié)議部分。它允許主機A告訴另外一個主機B，它收到一條特別的消息。假設A收到消息”<1234@ucbvax.Berkeley.edu>”，并且想把它傳送給主機B。
A首先會傳送控制消息”ihave <1234@ucbvax.Berkeley.edu>”給B(以發(fā)給“新聞組B”的形式發(fā)送)。如果B沒有收到過這篇文章，則返回一個控制消息”sendme <1234@ucbvax.Berkeley.edu> B”(發(fā)給“新聞組A”)。一旦A收到這條消息，它會把消息發(fā)給B。
這個協(xié)議可以切斷兩個主機間的通道。它是可選的并且只有在某些值得去做的情況下才可以使用這條消息。一般的情況是，大部分的消息是很短的，但是突然間需要用UUCP傳輸一個很長的消息，這時發(fā)送“ihave”消息比直接發(fā)送消息要經(jīng)濟得多。
一個解決這種高消耗問題的方法是批請求。很多的Message-ID被包含在一個消息中。如果在控制消息中沒有Message-ID，則需要掃描消息主體來尋找Message-ID，一個一行。
3.3 Newgroup
newgroup <groupname> [moderated]
這條控制消息創(chuàng)建一個給定名稱的新聞組。因為新聞組被創(chuàng)建前不會有消息被發(fā)布或者跟帖，所以這條消息在新聞組被使用前必需被使用。消息的主體應該是關于新聞組使用的一段簡短的描述。
如果有第二個參數(shù)并且是模板的關鍵字，這個新聞組將會以”moderated”中指明的模板而不是默認的模板創(chuàng)建。除非newgroup消息中有”Approved”行，否則消息將會被忽略。
3.4 Rmgroup
rmgroup <groupname>
這個消息刪除一個給定名稱的新聞組。因為這個命令會刪除所有站點中的選中的新聞組，所以管理員要十分小心的使用它。除非rmgroup消息中有”Approved”行，否則消息將會被忽略。
3.5 Sendsys
sendsys (no arguments)
“sys”文件列出了所有的鄰居站點，并且那些被發(fā)送給每個鄰居的新聞組將會被郵寄給控制信息中指出的作者(首先在Reply-to中找，沒有再在From中找)。這個信息被認為是公開的信息，并且在USENET網(wǎng)絡會員的要求下，被按照要求的提供(譯者注：這里可能有問題，原文and it is a requirement of membership in USENET that this information be provided on request),或者是自動作為這個消息的應答信息，或者是手動發(fā)一份郵件給這條信息的作者。這些信息用于USENET保持一份地圖以便更新數(shù)據(jù)，并且決定哪些網(wǎng)絡新聞需要發(fā)布。
發(fā)給作者的郵件中的信息文件的格式和”sys”文件格式是一樣的。這種格式是每個鄰居站點一行(加上本地站點一行),包含以冒號隔開的四個不同的區(qū)域。第一個是鄰居站點的名稱，第二個是發(fā)送給鄰居的新聞組的樣式，第三個和第四個在這個標準中沒有定義。一個簡單的應答如下：
From: cbosgd!mark (Mark Horton)
Date: Sun, 27 Mar 83 20:39:37 -0500
Subject: response to your sendsys request
To: mark@cbosgd.ATT.COM
Responding-System: cbosgd.ATT.COM
cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,test
ucbvax:world,comp,to.ucbvax:L:
cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
3.6 Version
version (no arguments)
運行在本地系統(tǒng)上的軟件的名稱和版本會被郵寄給控制消息中提到的作者(首先在”Reply-to”中尋找，沒有的話在”From”中尋找)。
傳輸方法
USENET系統(tǒng)不是一個物理級的網(wǎng)絡，而是存在于多個物理級網(wǎng)絡上的邏輯網(wǎng)絡。這些網(wǎng)絡包括，但不僅限于，UUCP，ARPANET，Ethernet，BLICN網(wǎng)，NSC Hyperchannel，和Berknet。重要的是在USENET兩個系統(tǒng)間有辦法交換消息，消息以這里列出的格式從一個系統(tǒng)到另外一個系統(tǒng)，并且在接收系統(tǒng)上，可以使用網(wǎng)絡新聞軟件處理接收到的文章。(在UNIX系統(tǒng)中，這樣常常意味著”rnews”程序開始處理在標準輸入中的消息<1>)
雖然USENET上的系統(tǒng)不需要有能力去懂得互聯(lián)網(wǎng)上的郵件格式，但是我們強力建議具體的實現(xiàn)有這個能力。因為From,Reply-To,和 Sender 行使用的是互聯(lián)網(wǎng)的格式，所以用非互聯(lián)網(wǎng)格式回復變得不可能。一個沒有互聯(lián)網(wǎng)郵件系統(tǒng)的站點可以使用Path行來回復，但是這個選項不能確保是這個回復路徑是否還在工作中。在任何情況下，任何站點產(chǎn)生或者傳輸?shù)男侣勏⒍夹枰幸粋€互聯(lián)網(wǎng)地址，允許它們接受來自使用互聯(lián)網(wǎng)郵件格式的站點的郵件，并且他們必須在他們的From行中包含他們的互聯(lián)網(wǎng)地址。
4.1 遠程執(zhí)行
一些網(wǎng)絡允許遠程執(zhí)行命令。在這些系統(tǒng)中，新聞會以命令和標準輸入的文章捆綁的形式發(fā)送。例如，如果遠程系統(tǒng)名叫”remote”。
在UUCP中新聞會伴隨著命令：
” uux -remote!rnews”
在Berknet中，命令為：
” net -mremote rnews”。
因為文章是使用可靠的機制傳輸?shù)模砸话惆衙詈拖⒗墏魉停皇沁h程直接執(zhí)行命令。這樣做的原因是，如果遠程系統(tǒng)關閉了，遠程命令就會失敗，并且消息也不會被傳送出去。如果消息被捆綁了，最后當系統(tǒng)都啟動后，它還是會被發(fā)送。
4.2 使用郵件系統(tǒng)傳送
在一些系統(tǒng)中，直接的捆綁遠程命令是不可以的，但是，絕大系統(tǒng)都郵件功能，并且新聞消息可以以郵件的形式發(fā)送。一種方法是發(fā)送一封和新聞消息一樣的郵件消息：郵件頭是新聞頭，郵件主體是新聞主題。我們約定這種郵件是發(fā)給遠程機器上的用戶”newsmail”。
這種方法可能遇到的問題是郵件系統(tǒng)可能不認為消息中的From行是有效的，因為這個郵件消息是被系統(tǒng)程序自動產(chǎn)生的，和原文不一樣。還有一個問題是在郵件傳輸中產(chǎn)生的錯誤的消息會發(fā)給消息的作者，但是他不能控制消息在兩個協(xié)同工作主機間的傳送，也不知道應該通知誰。傳輸?shù)腻e誤信息應該發(fā)給發(fā)送機器上可靠的人。
解決這種問題的方法是將消息壓縮為一個郵件消息，以至于整個消息(頭部和主體)成為郵件主體的一部分。我們約定這種郵件是發(fā)給遠程機器上的用戶”rnews”。在新聞文章每一行的頭部加上一個字母’N’,再產(chǎn)生附加的郵件頭部，這樣就構成了一個郵件消息。加上’N’是為了防止消息中特殊的行妨礙郵件的傳送，也是方式在成為郵件的一部分時被插入額外的行(頭部，空行等等)。接收機器上的程序接收發(fā)給”rnews”的郵件并提取消息，然后調(diào)用”rnew”程序。消息郵件的一個例子為：
Date: Mon, 3 Jan 83 08:33:47 MST
From: news@cbosgd.ATT.COM
Subject: network news message
To: rnews@npois.ATT.COM
NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
NFrom: derek@sask.UUCP (Derek Andrew)
NNewsgroups: misc.test
NSubject: necessary test
NMessage-ID: <176@sask.UUCP>
NDate: Mon, 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
使用郵件解決捆綁問題是因為當目標機器關閉的時候郵件必須被捆綁。然而，它增加了傳輸處理的消耗(為了壓縮和提取消息)，并且使得軟件在給郵件和新聞不同的優(yōu)先權時產(chǎn)生了困難。
4.3 批處理
因為新聞消息往往是很短的，并且在一天之中兩個站點間會傳送大量的消息，所以感覺可以批處理消息。很多消息可以使用在兩個站點間約定的習慣結合成一篇大的消息。一種批處理策略在這里討論，并且它是經(jīng)過實驗的。
新聞消息被組合成劇本一樣，使用下面的方式隔開：
##! rnews 1234
1234是消息的字節(jié)長度。每一個這樣的行后面跟著一篇給定字節(jié)長度的消息。消息的最后一個新行有意被作為一個字符，即使它是以CRFL的形式存儲的。如，消息的批處理看起來是這樣的:
#! rnews 239
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.ATT.COM>
Date: Fri, 19 Nov 82 16:14:55 EST
Approved: mark@cbosgd.ATT.COM
這里是重要的USENET禮節(jié)信息。
#! rnews 234
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Notes on Etiquette message
Message-ID: <643@eagle.ATT.COM>
Date: Fri, 19 Nov 82 17:24:12 EST
Approved: mark@cbosgd.ATT.COM
這里有一些我在文章末尾忘記提及的內(nèi)容。
因為消息的第一個字符是”#”，所以它被認為是一個批處理消息。這個消息隨后會被傳遞并且被解釋成非批處理的形式。
第二個參數(shù)(樣例rnew中)決定了使用哪種其處理機制。共同運作的主機會選擇任何合適的機制。
新聞傳播算法
這個部分要介紹整個的USENET系統(tǒng)和站點將新聞傳送到整個網(wǎng)絡的算法。因為所有的站點都可能被不正確的消息格式和錯誤消息所影響，所以確定一個標準的方法是很重要的。USENET是一幅有向圖。圖中的每個節(jié)點就是一臺主機，每條邊就是一條從一個主機到另外一個主機的傳播路徑。每條邊都被表上了一個新聞組樣式，用于說明在這個鏈接上傳輸?shù)男侣劷M類。大部分的邊都是雙向的，那是因為如果A可以發(fā)送新聞組類到B，B往往也可以發(fā)送一樣新聞組類到A。這樣的雙向路徑不是必需的，但是不能沒有。
USENET有很多的子網(wǎng)組成。每個子網(wǎng)都有一個名字，如”net”或者”btl”。特殊的子網(wǎng)”net”被定義成USENET，雖然所有的子網(wǎng)合起來是USENET的超集(因為站點得到了本地的新聞組，但是沒有得到”net.all”)。沒一個子網(wǎng)都是一副連接圖，即在子網(wǎng)的兩個站點間至少存在一條路徑。額外的是，整個USENET圖(理論上)也是連接圖。(特別的是，一些政治上的考慮會使一些站點不能發(fā)布文章到網(wǎng)絡上的其他地方。)
一篇消息被發(fā)布到一篇公布了新聞組目錄的機器上。這臺機器的一些新聞組接受它，并且把它轉發(fā)給那些對它有興趣并且至少有一個新聞組的鄰居主機(站點A認為B對新聞有興趣，僅當消息所屬的新聞組匹配從A到B的路徑上的新聞組)。這個站點接收傳來的消息，檢查它是否為想要得到的消息，然后把它放到相應的新聞組，最后繼續(xù)將這篇消息傳遞給那些感興趣的鄰居主機。這個過程一直會持續(xù)到整個網(wǎng)絡都能看到這篇消息。
算法重要的一個部分就是防止消息在網(wǎng)絡中循環(huán)傳遞。上面的過程會導致消息在一個環(huán)中一直傳遞。特別的是，當站點A將消息傳遞給站點B后，B會把消息在反傳給A，這樣不斷的重復傳遞。一種解決方法是進行歷史記錄。每一個站點都將它已經(jīng)看到的消息記錄下來(記錄Message-ID)，一旦它收到一篇它已經(jīng)看到過的消息，就會馬上丟棄這篇消息。這個方法足可以解決循環(huán)傳遞問題了，但是還有更好的優(yōu)化避免將消息簡單的丟棄。
一種優(yōu)化方法是消息不會傳遞給那些在消息Path選項中列出的站點。當一個機器名字出現(xiàn)在Path行中時，意味著消息已經(jīng)傳遞給這個機器了。還有一種優(yōu)化是，如果消息在站點A被創(chuàng)建，則認為A已經(jīng)看到過它了。(創(chuàng)建主機可以由Posting-Version選項確定)
因而，一篇發(fā)布給新聞組misc。misc，它的文章會自動匹配”misc.all”(“all”是通配符，并且匹配任何傳)，并且會被發(fā)布給訂閱了”misc.all”的所有站點(由他們的鄰居發(fā)送給他們的信息決定)。這些站點構成了子網(wǎng)”misc”。所有發(fā)給” btl.general”的文章都會到達接收”btl.all”的站點，但是不會到達沒有”btl.all”的站點。結果是文章到達了子網(wǎng)”btl”，發(fā)給” net.micro,btl.general”的文章會到達所有訂閱了”net.all”，或者”btl.all”的站點。
注意：
<1> UNIX是AT&T的注冊商標
譯者注：所有的個人，媒體，和其他機構都可以無償轉發(fā)或者修正我的文章，但是任何的修正都要事先通知我，我的郵箱是：ghbxx2004@yahoo.com.cn。