rfcrfc976.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：王安鹏（anpengwang    [e-mail]）
译文发布时间：2001-5-24
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                    Mark. R. Horton
Request for Comments: 976                              Bell Laboratories
February 1986


UUCP邮件交换格式标准
（RFC976 UUCP Mail Interchange Format Standard）


备忘录状态
为了适应维护ARPA网上不同项目的状态和进展的当前情况的要求，特为社区成员发布
本RFC。本文档的内容截止到发布之日是精确的，但目的在于进一步改进。后续的RFC将
会反映这些改进。
   本文档定义了UUCP项目中两台机器之间传递邮件消息的标准格式。本文没有涉及单台
机器上消息的存储格式，也不包括一台机器从另一台机器上获取数据的底层传输机制。本文
讲述了UUCP区中的主机应遵循的标准。本备忘录的分发不受限制。

目录
1.  简介	1
2.  基础	2
2.1  混合地址（Hybrid Addresses）	2
2.2  传输	3
2.3  批处理SMTP	3
2.4  信封（Envelope）	4
2.5  邮件路由	5
3.  算法	5
4.  例子	6
5.  结论	7
6.  参考	8

1.  简介
本文的目的在于定义UUCP项目中主机之间传递邮件消息的标准格式，没有讨论消息在
一台机器上的存储格式，也不涉及一台机器从另一台机器上获取数据的底层传输机制。我们
假定远程执行rmail（或者等价的）命令是UUCP网络的基本操作。
一条基本法则是：如果我们试图发明一种新的标准，通常无法与现有的系统兼容。世界
上已经有太多的（互相矛盾的）标准，引起了混淆，比如a!b@c.d按照旧的UUCP标准被解
释为a!(b@c.d)，而在Internet世界里则被解释为(a!b)@c.d。（两个标准都不支持括号，否则
就可以兼容了。外壳（shell）和UUCP传输机制同样存在严重的问题）。
ARPA社区已经定义了明确的、具有完善文档的、可扩展的标准族，我们也选择这些标
准应用于UUCP区。（UUCP区是使用UUCP连接并注册到UUCP项目的社区的子集，代表
一个管理实体。）因为实际的传输机制取决于两台主机的安排，可能包括UUCP、SMTP、
NMDF或者其它工具，我们选用RFC920（域）和RFC822（邮件格式）作为UUCP区的标
准。所有系统间的邮件传输都应遵循这两个标准。另外，如果ARPA社区在以后改变了他
们的标准，我们也将修改我们的标准以保证与之兼容，以便提供一个合理的软件升级时间。
本文详述了RFC822和RFC920在UUCP世界中的解释，说明了如何对信封编码以及在
混合实现环境中如何实现UUCP寻路。

2.  基础
消息可以分为两部分：信封和消息本身。信封包含邮件传输服务所需要的信息，消息包
含对收发方有用的信息。消息分为首部和主体。有时候中间主机会改变消息（如增加Received
行），但除非是网关需要改变传输格式，中间主机一般不得修改消息本身。在UUCP世界中，
信封包括“目的地址”（通常表现为rmail命令的参数）和“源地址”（通常由消息的第一行
或者最初几行表示，以“From”或者“>From”开始，又称为“From行”）。RFC32的报头
行（包括“From：”和“To：”）作为消息的一部分是消息体本身的文本。
UUCP在运输层及以下各层使用短主机名，如“ucbvax”。我们把这种短名称为“6字符
名”，因为任何UUCP的实现都至少把前6个字符视为有效的。（有一些把前7个或者前14
个字符视为有效，但我们必须使用最低的通用标准。）UUCP名可以长于6个字符，但其前
6个必须各不相同。RFC920域的名称，如“ucbvax Berkeley.EDU”称为“域名”。这两个名
是不同的。大小写对于6字符名被认为是不同的，但对于域名则认为是相同的。6字符名后
加上“.UUCP”，如“ubcvax.UUCP”在过去作为对使用6字符名的主机的域格式的引用。
随着对组织化的域名如“ucbvax.Berkelry.EDU”的支持，这一类名称正在逐步淘汰。
2.1  混合地址（Hybrid Addresses）
在UUCP世界中主要使用两种邮件地址语法：旧式UUCP软件使用的“a!b!c!user”（完
全路径）格式指明了传送邮件到目的地址的路线；遵循RFC822的“user@domain”（域）语
法格式。大部分情况下都可以根据给定的地址判定地址的类型。但是对于@左侧包含“a!”
的混合地址，如a!b@c就出现了混淆：即可以解释为(a!b)@c.d，也可以解释为a!(b@c.d)。这
两种解释都有意义，前者用于RFC822，后者是UUCP软件事实上的标准。
由于混合地址带来的混乱，我们建议所有的运输层软件在任何时候都应该避免使用混合
地址。纯粹的完全地址语法可以用来澄清这种混淆，上例中的第一种解释可以写为“c.d!a!b”，
第二种解释写为“a!c.d!b”。我们建议所有的实现都是用这种“完全域”语法，除非他们确
实知道下一台机器上运行什么。
按照RFC822和AT&T消息传输体系，我们建议所有允许混合地址的主机采用(a!b)@c.d
这种解释。

2.2  传输
因为许多UUCP域不支持SMTP，我们把用于“远程执行”的方法定义在传输机制的
基础上。要“远程执行”的命令与其标准输出信息应一起读作：rmail user@domain ...。参数
user@domain必须符合RFC920和RFC822。允许包含多个地址参数，这样把同一个消息发
往多个接收方时可以节省传输时间。
另一种方式是“rmail domain!user”，其中“domain”至少包含一个逗点而且不含“!”。
这种表示可以被准确地解释为user@domain，可以通过旧式的UUCP主机传输消息而无需担
心地址被改变。“user”字符串可以包含除“@”之外的任意字符，禁止该字符是因为无法
确定中间主机如何处理它。（同样建议避免使用“%”，有些主机把“%”视为“@”的同义
字。）不过，如果传输路径包含不理解域的主机，下面的格式是可能的：
      rmail a!b!c!domain!user
域至少要包含一个逗点，因而可以与6字符的UUCP站点名区分开。（单层的域没有逗
点，应在尾部增加额外的逗点，比如Mark.Horton@att 就成了“att.!Mark.Horton”。把!格式
改为@格式的解释器应该删除尾部逗点——如果有的话。）我们不希望发生此类情况，除非
本地网络使用类似user@host的地址。
简单的应用可以只使用domain!user语法（而不是user@domian），因为这种方式对3类
网关（参见节3.5）也是安全的。

2.3  批处理SMTP
符合标准的实现可能会选择支持一种称为“批处理SMTP”的协议。SMTP（简单邮件
传输协议）是ARPA社区的标准邮件传输协议（RFC821），BITNET和Mailnet也使用该协
议。因为SMTP被设计为交互式的，把一系列命令组成以批发到远程机器上成批执行是可
能的。BSMTP的一个优点是UNIX外壳不参与消息的解释，因而电子信息中可以包含空格
和括号这样的特殊字符（这些字符在X.400地址中将会非常普遍）。
为了使UNIX支持BSMTP，符合标准的主机应当把用户的邮件命令“b-smtp”解释为
批处理SMTP（我们使用“b-smtp”而不是“bsmtp”是因为后者与一个登录名冲突）。因为
许多邮件系统把包含单个逗点一行当作“文件尾”的标志处理，而SMTP把逗点用作必需
的文件尾标志，为了区分出报头，我们在BSMTP的每一行增加一个特殊的“#”。在邮件发
送系统中实现这一点的简单方法是包括如下别名：
      b-smtp: "|egrep '^#' | sed 's/^#//' | /usr/lib/sendmail -bs"
这样就可以把命令输送给SMTP解释器。更好的方案还要同时检查错误并把错误信息反馈
给发送方。
下面的例子说明了一个从seismo.CSS.GOV发往cbosgd.ATT.COM的BSMTP消息。这
个例子是通过UUCP连接传递给命令“rmail b-smtp”的文件。注意RFC- 822 消息位于DATA
行和逗点行（最后一行）之间。信封信息在MAIL FROM和RCPT TO行中传递。发送系统
的名称在HELO行中。实际的信封信息（带有“#”的行以上的部分）被忽略了，不一定要
出现。
      From foo!bar Sun Jan 12 23:59:00 1986 remote from seismo Date:
      Tue, 18 Feb 86 13:07:36 EST
      From: [e-mail]
      Message-Id: <8602181807.AA10228@[e-mail]> To:
      [e-mail]

      #HELO seismo.CSS.GOV
      #MAIL FROM:<[e-mail]>
      #RCPT TO:<[e-mail]>
      #DATA
      #Date: Tue, 18 Feb 86 13:07:36 EST
      #From: [e-mail]
      #Message-Id: <8602181807.AA10228@[e-mail]> #To:
      [e-mail]
      #
      #This is a sample message.
      #.
      #QUIT

2.4  信封（Envelope）
命令的标准输入应该以单独的一行：From domain!user date remote from system开始，后
面紧跟着RFC822格式的报头和消息主体。可能在该行前还有其他的FROM行——这些行
是可以增加的，消息途经的每个系统增加一行。“系统字段”也可能堆叠成单独一行，在
“user”字符串中包含许多“!”。“From”前面可能还会有“>”字符。一般说来，这些“信
封”信息应该与旧式的UUCP邮件一样遵从相同的约定。主要的区别是当系统名紧凑书写
时，如果旧式的写法是a!b!c!mysys!me，新的写法改为a!b!c!mysys!domain!me，其中“domain”
至少包含一个逗点符号，“mysys”通常是称为“domain”的系统的6字符UUCP名。如果
“domain!”是多余的，就可以在信封中——源路径或者目的地址——省略掉。
如果需要把信息包装成只有一个FROM行，接收系统可能会丢弃多余的“From_”行。
它把“path!domain!user”和“信封”信息——包括消息发送方的地址，可能还生成新的一
行如Received或Sent-By，其中保存着转发日期和转发系统——一起发送出去。（不建议使
用Received，因为这样的行可能在真正增加该行的系统之前被其他的系统添加，而其他的系