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主机间交换网络新闻消息的标准格式。它更新并替换了RFC850，参照了新闻程序B2.11。这份备忘录以RFC形式发布是为了使因特网社区更容易的得到这个信息。它没有指出一种因特网标准。备忘录的发行没有任何限制。
1. 介绍
这份文档定义了在USENET主机间交换网络新闻所用到的标准消息格式。它详细描述了消息格式本身，也给出了部分的新闻传输标准。新闻的传输不需要完全按照标准格式以便于给个别的主机提供一个好的弹性去选择传输的硬件和软件环境，以及是否一次传输多个新闻等等。
文档有五部分。第二部分定义了消息格式。第三部分定义了有效的控制信息。第四部分详细说明了一些有效的传输方法。第五部分描述了全部的新闻传播算法。
2. 消息格式
选择消息格式首先要考虑的是使这种格式能尽可能的适应现有的一些工具。现有的工具包括各种邮件系统和新闻系统。(由伊利诺伊斯大学开发的NOTEFILES(译者注：作为一个特定的名词没有翻译)系统被认为是一种新闻系统)一种标准的邮件消息格式已经在Internet网络中存在多年了，它适合USENET系统绝大部份的需求。因为Internet网络格式是可以扩展的，所以在Internet网络标准中进行一些扩展使之适合USENET系统额外的需求是很容易的。因此，所有的USNNET新闻系统被排版成和由RFC822标准所定义的Internet网络中的有效的邮件格式一样。这份标准在对每一篇消息发布一些额外的需求和禁止使用特定的Internet特性上比ARPA网络标准有更多的限制。无论如何，它应该总是可以使用一种工具使得一条Internet网络消息能处理一篇新闻消息。无论在什么情况下，当这份格式标准和Internet标准发生冲突时，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
接下来是一个空行，然后是消息的主体。
这里有一个使用老的格式(在这份标准存在以前)的消息。建议具体的实现也能接受这种消息格式使得转换更加的容易。
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
接下来是一个空行，然后是消息的主体。
一些新闻系统使用一种”A”格式传输新闻，如下：
Aeagle.642
news.misc
cbosgd!mhuxj!mhuxt!eagle!jerry
Fri Nov 19 16:14:55 1982
Usenet Etiquette - Please Read
接下来直接是消息的主体。
标准的USENET消息有很多头部行，接下来是一个空行，接着是消息主体消息。每一个头部行包括一个关键字，一个冒号，一个空行，和一些附加信息。这是Internet网络标准的子集，可以使简单的软件轻松的处理它。”from”行可以随意的以上面例子中给出的格式，或则使用Internet的<>符号。为了使实现简单，一些格式(比如：圆括号后面紧跟机器地址)是不允许出现的。
一些头部是必需的，一些是可选的。所有的自定义头部都是允许的，并且会被原样传送。必需的头部有"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
这行包含了发送这个消息的人的Internet格式的邮箱地址。在邮箱地址后面可以跟着一对()符号，里面是一个全名。邮箱地址和现实中一样由消息的作者确定，除非使From行不再被检查的Sender头部被使用。注意在所有的站点和域名中，大小写是一样的，因此，mark@cbosgd.ATT.COM, mark@cbosgd.att.com,和mark@CBosgD.ATt.COm是一个地址。用户名可能大小写敏感，也可能不敏感。比如，Billy@cbosgd.ATT.COM 也许会和BillY@cbosgd.ATT.COM不一样。程序在传输邮件或新闻时应当避免改变电子邮件的语法。
RFC822指出在()中的文字都是注释。在Internet网络中邮件也使用这种方法把用户的全名作为注释放在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.2 Data
Date行(以前称”Posted”)是一个可以被RFC822和USENET软件中的日期程序接受的日期。当消息在网路中传播时，日期不会被改变。一个可以接受的Date格式如下
Wdy, DD Mon YY HH:MM:SS TIMEZONE
在前面的样例中出现了很多日期格式。注意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行确定消息属于哪个新闻组。可能会出现多个新闻组，相互间用逗号隔开。新闻组的详细描述必须是所有已经存在的新闻组的名称，没有新闻组会因为被简单的发布而被建立。
通配符(比如单词”all”)在Newsgroups中是不允许出现的。例如，新闻组”net.all”是无效的，但是新闻组名称”net.sport.football”是允许的。
如果一个接收到的消息中即有有效的新闻组，也有无效的新闻组，那么站点会忽略掉无效的新闻组，而不是将他们移除。比如，站点A订阅了”btl.net”和”comp.all”，它和一个订阅了”btl.net”但没有订阅”comp.all”的站点B交换新闻消息。假设A收到了一篇Newsgroups项为“Newsgroups: comp.unix,btl.general“的消息。
这个消息会发给B，因为B接受” comp.unix”,但是不接受”btl.general”。A必须要保持消息的Newsgroups不变。如果它移除”btl.general”，编辑后的头部可能是最后一次进入”btl.general”,导致很多订阅了”btl.general”的用户无法看到消息。此外，所有定阅了”btl.net”的用户将不会再看到这种类型的消息。
2.1.4 Subject
Subject行(过去称为”Title”)告诉我们这个消息的内容摘要。它应当包含足够的消息内容使得读者可以仅仅根据摘要来决定是否阅读这个消息。如果这个消息仅仅是对另外一个消息的应答(比如：跟帖)，默认的Subject为”Re: ”并且引用行是必需的。因为是跟帖，所以推荐使用”Summary”行。
2.1.5 Message-ID
Message-ID行给每个消息一个唯一的标识符。一个同样的Message-ID不会再这篇消息还存在于任一个新闻组的时候被再次生成。(建议一样的Message-ID在两年内不要再次产生)Message-ID的语法格式如下
<不包含任何空格或”>”的字符串>
为了能和RFC822一致，Message-ID必需为以下的格式
<唯一的标识符@full_domain_name>
full_domain_name为消息第一次进入网络时的主机全名，包括主机所在的域，和一个由不包含”<”，”>”或者”@”符号的可打印ASCII字符组成的唯一标识串。
如，主机的唯一标识串可以是一个表示消息被放入网络顺序的整数，或者一个表示消息写作时间和日期的字符串。例如，一篇从全域名为Berkeley.EDU的站点ucbvax提交到网络的消息的有效的Message-ID为<4123@ucbvax.Berkeley.EDU>。程序员被要求不要假设Message-ID是来自其他主机的，而是将它们看作未知字符串处理。这是不安全的，例如，假设Message-ID会少于14个字符，而前14个字符不是唯一的也不要认为不会含有”/”。
尖括号被认为是Message-ID的一部分。因此，在如ihave/sendme和cancel控制消息的Message-ID中包含空格键。空字符(如空格或者TAB)在Message-ID中是不允许出现的，尽可能不要使用”/”。所有在”<>”中的ASCII字符必须是可打印的。
2.1.6 Path
这行显示了信息到达当前系统的路径。当一个系统传递信息时，它会在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”。站点名称可以包含字母，数字，点号，连字符；其他的标点符号被认为是名称间的分隔符号。
一般来说，最右边的主机名称被认为是这篇信息的起始站点。然而，也允许在最右边加上发送信息的人的名字。这是为了与其他的系统兼容。
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并不总是被认为是有效的回复串，并且这个问题没有明确要求被实现。然而，一般约定是把主机名和一个”!”号放在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.)全名会随便出现在’From’行的()中。
2.2.2 Sender
这个选项只有由消息提交者手动加入到From行。它被用来记录将消息提交到网络中的一个实际证据，并且由提交消息的主机上的软件进行检测。
例如，如果John Smith访问CCA并且想使用名字Sarah Jones在网络上发表一个消息，则消息会是这样的
From: smith@ucbvax.Berkeley.EDU (John Smith)
Sender: jones@cca.COM (Sarah Jones)
如果网关程序将一封来自站点unix.SRI.COM的邮件发往网络，则
From: John.Doe@A.CS.CMU.EDU
Sender: network@unix.SRI.COM
这个选项的只要目的是给消息留下个记号以确定它是怎样被放入网络中的。全名会随意的出现在From行的圆括号<()>中
2.2.3 Followup-To
这一行和Newsgroups行的格式一样。如果有这个头部，跟帖的消息会被发布到这里列出的新闻组中。如果没有被选中，跟贴的消息会被发送到”Newsgroups”行列出的新闻组中。
如果有发布者的关键字，跟帖消息不不被允许的。这个消息应该被邮件邮寄到消息的发送者。
2.2.4 Expires
这个选项如果被选中，则是一个合法的USENET日期格式。它暗示了一个消息应该过期的日期。如果没有被选中，使用本地默认的过期日期。这个选项被用于清除有条件限制的文章，或者使重要文章能保留更长的时间。例如，一条通告某个研讨会开幕的消息有最迟为研讨会结束日期的时间限制，因为这条信息在研讨会结束后就没用了。因为本地主机对新闻的过期时间有自己的限制(如有效的磁盘限制)，所以用户给消息一个日期限制也没什么用，除非这个消息的主题有一个默认的日期限制。系统软件几乎从不提供Expires行。它允许使用本地限制策略，除非有一个很好的理由不用它。
2.2.5 References
这个选项列出了所有在提交这个消息时参考到的消息的Message-ID。所有的跟帖都需要这个选项，当一个新主题出现时，禁止使用这个选项。具体的实现需要提供一个跟帖命令，以使用户可以发布跟帖。这个命令会产生和原文一样的主题行，区别是原文主题行不以”Re: ”或者”re: ”开头，而跟帖会在主题前加上”Re: ”四个字符。如果原文中没有References选项，则跟帖中只会包含本文的Message-ID(在<>中)。如果原文中有References选项，则跟帖的主题行会包含References，一个空格，原文的Message-ID。
这个选项的主要目的是使消息成为一个组，则用户程序就可以在组中进行交流了。它允许一个新闻组中的会话保持在一起。潜在的用会可以只关闭整个会话，而不需要到新闻组中取消预订。这个选项可能对用户界面无效，但是对于允许这个选项的系统来说，这个选项有益于产生自动回复，并且手动的回复(已经被打印的文章能被更好的输入)也被鼓励包含这个选项。
如果前面的”References”行太长了，则允许不包含全部的引用。需要尝试包含合理数量的后面的引用。
2.2.6 Control
如果文章含有Control行，则文章就是控制消息。控制信息用于USENET主机间通讯，不会被用户读到。控制消息和一般消息一样分布在各个新闻组之间。控制航的内容是给主机的消息。
因为兼容性的原因，匹配新闻组样式”all.all.ctl”的信息也是控制信息。如果这样的控制消息没有Control项，则消息头部中的主题作为控制消息。然而，匹配这种样式的新闻组的消息和本标准是不一致的。
也是兼容性原因，如果"Subject:"行的前4个字母是"cmsg"，则剩下的"Subject:"行的内容被认为是一个控制消息。
2.2.7 Distribution
这行可以改变发布消息的范围。它和Newsgroup的格式一样。用户是否订阅仍旧被Newsgroup选项控制，但是消息除了” Newsgroup”之外，还发给所有在Distribution中列出的订阅了这个消息新闻组系统。一旦这个消息被传输，接收站点必须正常的将这个消息接收到” Newsgroup”中指出的一个新闻组外还要将之接收到” Distribution”中的一个组中。因此，一个在新泽西贩卖汽车的文章会有这样的头部：
Newsgroups: rec.auto,misc.forsale
Distribution: nj,ny
因而，消息仅会发给那些在新泽西订阅了”net.auto”或” misc.forsale”的个人。这个头部项的目的是进一步限制文章在新闻组中的发布，而不是扩大。一个本地新闻组，如nj.crazy-eddie，在新泽西外面且认为这个新闻组无效的主机将不会被发布。Distribution行中允许出现通配符。跟帖文章默认和原先的文章有一样Distribution。用户可以给他增加更多的限制，如果原文由很多限制，但是需要更加广泛的回复，则需要放宽这个限制。
2.2.8 Organization
这一行的文本简短的描述了文章发送者，或者机器所属的组织机构。这个选项的主要目的是确定文章发送者的身份，因为主机名常常是比较秘密的，以至于很难通过电子邮件地址确认组织。
2.2.9 Keywords
一些被很好选择的消息的标识符会出现在这行。它用于帮助读者确定这篇文章是否有兴趣去读。
2.2.10 Summary
这一行是消息的大概摘要。它经常被作为其它消息跟帖的一部分。此外，它对于读者确定是否读这个消息也是很有用的。
2.2.11 Approved
任何发布到中介新闻组(译者注：这里的意思是这个新闻组的新闻需要审查)的消息都需要这一行。它由中介人添加，内容是中介人的电子邮件地址。控制信息也需要这一行。
2.2.12 Lines
这一行为消息内容的行数。
2.2.13 Xref
这行为一个主机名(省略域名)，一个空格，一个用冒号<:>隔开的列表，列表中的信息分别为在”Newsgroups”中列出的新闻组中的号码。
这个值仅用于本地系统，所以他不会被传播。如下：
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)隔开的字符串。第一个单词是控制信息的名称，接下来一个是消息参数。剩余的串是消息主体，同时也是潜在的参数；如”From”行会指出一个用于应答的地址。
程序和管理员会选择是将控制消息自动的发出，还是手动一个一个发出。然而，手动处理控制消息往往是很有效的。
3.1 Cancel
cancel <message ID>
如果Message-ID所对应的消息出现在本地系统中，则会删除该消息。这个消息允许用户删除一篇已经进入网络的消息。
如果系统不能删除被请求的消息，它将不会把该cancel消息传递给它的邻居主机。
只允许消息的作者或是本地超级用户被允许使用这个命令。消息的发送者的校验首先在”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收到消息”<1234@ucbvax.Berkeley.edu>”，并且想把它传送给主机B。
A首先会传送控制消息”ihave <1234@ucbvax.Berkeley.edu>”给B(以发给“新闻组B”的形式发送)。如果B没有收到过这篇文章，则返回一个控制消息”sendme <1234@ucbvax.Berkeley.edu> B”(发给“新闻组A”)。一旦A收到这条消息，它会把消息发给B。
这个协议可以切断两个主机间的通道。它是可选的并且只有在某些值得去做的情况下才可以使用这条消息。一般的情况是，大部分的消息是很短的，但是突然间需要用UUCP传输一个很长的消息，这时发送“ihave”消息比直接发送消息要经济得多。
一个解决这种高消耗问题的方法是批请求。很多的Message-ID被包含在一个消息中。如果在控制消息中没有Message-ID，则需要扫描消息主体来寻找Message-ID，一个一行。
3.3 Newgroup
newgroup <groupname> [moderated]
这条控制消息创建一个给定名称的新闻组。因为新闻组被创建前不会有消息被发布或者跟帖，所以这条消息在新闻组被使用前必需被使用。消息的主体应该是关于新闻组使用的一段简短的描述。
如果有第二个参数并且是模板的关键字，这个新闻组将会以”moderated”中指明的模板而不是默认的模板创建。除非newgroup消息中有”Approved”行，否则消息将会被忽略。
3.4 Rmgroup
rmgroup <groupname>
这个消息删除一个给定名称的新闻组。因为这个命令会删除所有站点中的选中的新闻组，所以管理员要十分小心的使用它。除非rmgroup消息中有”Approved”行，否则消息将会被忽略。
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 (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)
运行在本地系统上的软件的名称和版本会被邮寄给控制消息中提到的作者(首先在”Reply-to”中寻找，没有的话在”From”中寻找)。
传输方法
USENET系统不是一个物理级的网络，而是存在于多个物理级网络上的逻辑网络。这些网络包括，但不仅限于，UUCP，ARPANET，Ethernet，BLICN网，NSC Hyperchannel，和Berknet。重要的是在USENET两个系统间有办法交换消息，消息以这里列出的格式从一个系统到另外一个系统，并且在接收系统上，可以使用网络新闻软件处理接收到的文章。(在UNIX系统中，这样常常意味着”rnews”程序开始处理在标准输入中的消息<1>)
虽然USENET上的系统不需要有能力去懂得互联网上的邮件格式，但是我们强力建议具体的实现有这个能力。因为From,Reply-To,和 Sender 行使用的是互联网的格式，所以用非互联网格式回复变得不可能。一个没有互联网邮件系统的站点可以使用Path行来回复，但是这个选项不能确保是这个回复路径是否还在工作中。在任何情况下，任何站点产生或者传输的新闻消息都需要有一个互联网地址，允许它们接受来自使用互联网邮件格式的站点的邮件，并且他们必须在他们的From行中包含他们的互联网地址。
4.1 远程执行
一些网络允许远程执行命令。在这些系统中，新闻会以命令和标准输入的文章捆绑的形式发送。例如，如果远程系统名叫”remote”。
在UUCP中新闻会伴随着命令：
” uux -remote!rnews”
在Berknet中，命令为：
” net -mremote rnews”。
因为文章是使用可靠的机制传输的，所以一般把命令和消息捆绑传送，而不是远程直接执行命令。这样做的原因是，如果远程系统关闭了，远程命令就会失败，并且消息也不会被传送出去。如果消息被捆绑了，最后当系统都启动后，它还是会被发送。
4.2 使用邮件系统传送
在一些系统中，直接的捆绑远程命令是不可以的，但是，绝大系统都邮件功能，并且新闻消息可以以邮件的形式发送。一种方法是发送一封和新闻消息一样的邮件消息：邮件头是新闻头，邮件主体是新闻主题。我们约定这种邮件是发给远程机器上的用户”newsmail”。
这种方法可能遇到的问题是邮件系统可能不认为消息中的From行是有效的，因为这个邮件消息是被系统程序自动产生的，和原文不一样。还有一个问题是在邮件传输中产生的错误的消息会发给消息的作者，但是他不能控制消息在两个协同工作主机间的传送，也不知道应该通知谁。传输的错误信息应该发给发送机器上可靠的人。
解决这种问题的方法是将消息压缩为一个邮件消息，以至于整个消息(头部和主体)成为邮件主体的一部分。我们约定这种邮件是发给远程机器上的用户”rnews”。在新闻文章每一行的头部加上一个字母’N’,再产生附加的邮件头部，这样就构成了一个邮件消息。加上’N’是为了防止消息中特殊的行妨碍邮件的传送，也是方式在成为邮件的一部分时被插入额外的行(头部，空行等等)。接收机器上的程序接收发给”rnews”的邮件并提取消息，然后调用”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
使用邮件解决捆绑问题是因为当目标机器关闭的时候邮件必须被捆绑。然而，它增加了传输处理的消耗(为了压缩和提取消息)，并且使得软件在给邮件和新闻不同的优先权时产生了困难。
4.3 批处理
因为新闻消息往往是很短的，并且在一天之中两个站点间会传送大量的消息，所以感觉可以批处理消息。很多消息可以使用在两个站点间约定的习惯结合成一篇大的消息。一种批处理策略在这里讨论，并且它是经过实验的。
新闻消息被组合成剧本一样，使用下面的方式隔开：
##! rnews 1234
1234是消息的字节长度。每一个这样的行后面跟着一篇给定字节长度的消息。消息的最后一个新行有意被作为一个字符，即使它是以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礼节信息。
#! 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
这里有一些我在文章末尾忘记提及的内容。
因为消息的第一个字符是”#”，所以它被认为是一个批处理消息。这个消息随后会被传递并且被解释成非批处理的形式。
第二个参数(样例rnew中)决定了使用哪种其处理机制。共同运作的主机会选择任何合适的机制。
新闻传播算法
这个部分要介绍整个的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选项确定)
因而，一篇发布给新闻组misc。misc，它的文章会自动匹配”misc.all”(“all”是通配符，并且匹配任何传)，并且会被发布给订阅了”misc.all”的所有站点(由他们的邻居发送给他们的信息决定)。这些站点构成了子网”misc”。所有发给” btl.general”的文章都会到达接收”btl.all”的站点，但是不会到达没有”btl.all”的站点。结果是文章到达了子网”btl”，发给” net.micro,btl.general”的文章会到达所有订阅了”net.all”，或者”btl.all”的站点。
注意：
<1> UNIX是AT&T的注册商标
译者注：所有的个人，媒体，和其他机构都可以无偿转发或者修正我的文章，但是任何的修正都要事先通知我，我的邮箱是：ghbxx2004@yahoo.com.cn。