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。可选的头部有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 控制消息
这个部分列出了当前定义的一些控制消息。控制头部的主体是控制消息。控制消息是一串有0个或多个单词，并且单词相互间以空格(空格或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。