組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：王安鵬（anpengwang    anpengwang@263.net）
譯文發(fā)布時間：2001-5-24
版權：本中文翻譯文檔版權歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉載，但必須
保留本文檔的翻譯及版權信息。


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


UUCP郵件交換格式標準
（RFC976 UUCP Mail Interchange Format Standard）


備忘錄狀態(tài)
為了適應維護ARPA網(wǎng)上不同項目的狀態(tài)和進展的當前情況的要求，特為社區(qū)成員發(fā)布
本RFC。本文檔的內容截止到發(fā)布之日是精確的，但目的在于進一步改進。后續(xù)的RFC將
會反映這些改進。
   本文檔定義了UUCP項目中兩臺機器之間傳遞郵件消息的標準格式。本文沒有涉及單臺
機器上消息的存儲格式，也不包括一臺機器從另一臺機器上獲取數(shù)據(jù)的底層傳輸機制。本文
講述了UUCP區(qū)中的主機應遵循的標準。本備忘錄的分發(fā)不受限制。

目錄
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項目中主機之間傳遞郵件消息的標準格式，沒有討論消息在
一臺機器上的存儲格式，也不涉及一臺機器從另一臺機器上獲取數(shù)據(jù)的底層傳輸機制。我們
假定遠程執(zhí)行rmail（或者等價的）命令是UUCP網(wǎng)絡的基本操作。
一條基本法則是：如果我們試圖發(fā)明一種新的標準，通常無法與現(xiàn)有的系統(tǒng)兼容。世界
上已經(jīng)有太多的（互相矛盾的）標準，引起了混淆，比如a!b@c.d按照舊的UUCP標準被解
釋為a!(b@c.d)，而在Internet世界里則被解釋為(a!b)@c.d。（兩個標準都不支持括號，否則
就可以兼容了。外殼（shell）和UUCP傳輸機制同樣存在嚴重的問題）。
ARPA社區(qū)已經(jīng)定義了明確的、具有完善文檔的、可擴展的標準族，我們也選擇這些標
準應用于UUCP區(qū)。（UUCP區(qū)是使用UUCP連接并注冊到UUCP項目的社區(qū)的子集，代表
一個管理實體。）因為實際的傳輸機制取決于兩臺主機的安排，可能包括UUCP、SMTP、
NMDF或者其它工具，我們選用RFC920（域）和RFC822（郵件格式）作為UUCP區(qū)的標
準。所有系統(tǒng)間的郵件傳輸都應遵循這兩個標準。另外，如果ARPA社區(qū)在以后改變了他
們的標準，我們也將修改我們的標準以保證與之兼容，以便提供一個合理的軟件升級時間。
本文詳述了RFC822和RFC920在UUCP世界中的解釋，說明了如何對信封編碼以及在
混合實現(xiàn)環(huán)境中如何實現(xiàn)UUCP尋路。

2.  基礎
消息可以分為兩部分：信封和消息本身。信封包含郵件傳輸服務所需要的信息，消息包
含對收發(fā)方有用的信息。消息分為首部和主體。有時候中間主機會改變消息（如增加Received
行），但除非是網(wǎng)關需要改變傳輸格式，中間主機一般不得修改消息本身。在UUCP世界中，
信封包括“目的地址”（通常表現(xiàn)為rmail命令的參數(shù)）和“源地址”（通常由消息的第一行
或者最初幾行表示，以“From”或者“>From”開始，又稱為“From行”）。RFC32的報頭
行（包括“From：”和“To：”）作為消息的一部分是消息體本身的文本。
UUCP在運輸層及以下各層使用短主機名，如“ucbvax”。我們把這種短名稱為“6字符
名”，因為任何UUCP的實現(xiàn)都至少把前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”（域）語
法格式。大部分情況下都可以根據(jù)給定的地址判定地址的類型。但是對于@左側包含“a!”
的混合地址，如a!b@c就出現(xiàn)了混淆：即可以解釋為(a!b)@c.d，也可以解釋為a!(b@c.d)。這
兩種解釋都有意義，前者用于RFC822，后者是UUCP軟件事實上的標準。
由于混合地址帶來的混亂，我們建議所有的運輸層軟件在任何時候都應該避免使用混合
地址。純粹的完全地址語法可以用來澄清這種混淆，上例中的第一種解釋可以寫為“c.d!a!b”，
第二種解釋寫為“a!c.d!b”。我們建議所有的實現(xiàn)都是用這種“完全域”語法，除非他們確
實知道下一臺機器上運行什么。
按照RFC822和AT&T消息傳輸體系，我們建議所有允許混合地址的主機采用(a!b)@c.d
這種解釋。

2.2  傳輸
因為許多UUCP域不支持SMTP，我們把用于“遠程執(zhí)行”的方法定義在傳輸機制的
基礎上。要“遠程執(zhí)行”的命令與其標準輸出信息應一起讀作：rmail user@domain ...。參數(shù)
user@domain必須符合RFC920和RFC822。允許包含多個地址參數(shù)，這樣把同一個消息發(fā)
往多個接收方時可以節(jié)省傳輸時間。
另一種方式是“rmail domain!user”，其中“domain”至少包含一個逗點而且不含“!”。
這種表示可以被準確地解釋為user@domain，可以通過舊式的UUCP主機傳輸消息而無需擔
心地址被改變。“user”字符串可以包含除“@”之外的任意字符，禁止該字符是因為無法
確定中間主機如何處理它。（同樣建議避免使用“%”，有些主機把“%”視為“@”的同義
字。）不過，如果傳輸路徑包含不理解域的主機，下面的格式是可能的：
      rmail a!b!c!domain!user
域至少要包含一個逗點，因而可以與6字符的UUCP站點名區(qū)分開。（單層的域沒有逗
點，應在尾部增加額外的逗點，比如Mark.Horton@att 就成了“att.!Mark.Horton”。把!格式
改為@格式的解釋器應該刪除尾部逗點——如果有的話。）我們不希望發(fā)生此類情況，除非
本地網(wǎng)絡使用類似user@host的地址。
簡單的應用可以只使用domain!user語法（而不是user@domian），因為這種方式對3類
網(wǎng)關（參見節(jié)3.5）也是安全的。

2.3  批處理SMTP
符合標準的實現(xiàn)可能會選擇支持一種稱為“批處理SMTP”的協(xié)議。SMTP（簡單郵件
傳輸協(xié)議）是ARPA社區(qū)的標準郵件傳輸協(xié)議（RFC821），BITNET和Mailnet也使用該協(xié)
議。因為SMTP被設計為交互式的，把一系列命令組成以批發(fā)到遠程機器上成批執(zhí)行是可
能的。BSMTP的一個優(yōu)點是UNIX外殼不參與消息的解釋，因而電子信息中可以包含空格
和括號這樣的特殊字符（這些字符在X.400地址中將會非常普遍）。
為了使UNIX支持BSMTP，符合標準的主機應當把用戶的郵件命令“b-smtp”解釋為
批處理SMTP（我們使用“b-smtp”而不是“bsmtp”是因為后者與一個登錄名沖突）。因為
許多郵件系統(tǒng)把包含單個逗點一行當作“文件尾”的標志處理，而SMTP把逗點用作必需
的文件尾標志，為了區(qū)分出報頭，我們在BSMTP的每一行增加一個特殊的“#”。在郵件發(fā)
送系統(tǒng)中實現(xiàn)這一點的簡單方法是包括如下別名：
      b-smtp: "|egrep '^#' | sed 's/^#//' | /usr/lib/sendmail -bs"
這樣就可以把命令輸送給SMTP解釋器。更好的方案還要同時檢查錯誤并把錯誤信息反饋
給發(fā)送方。
下面的例子說明了一個從seismo.CSS.GOV發(fā)往cbosgd.ATT.COM的BSMTP消息。這
個例子是通過UUCP連接傳遞給命令“rmail b-smtp”的文件。注意RFC- 822 消息位于DATA
行和逗點行（最后一行）之間。信封信息在MAIL FROM和RCPT TO行中傳遞。發(fā)送系統(tǒng)
的名稱在HELO行中。實際的信封信息（帶有“#”的行以上的部分）被忽略了，不一定要
出現(xiàn)。
      From foo!bar Sun Jan 12 23:59:00 1986 remote from seismo Date:
      Tue, 18 Feb 86 13:07:36 EST
      From: mark@ucbvax.Berkeley.EDU
      Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU> To:
      b-smtp@cbosgd.ATT.COM

      #HELO seismo.CSS.GOV
      #MAIL FROM:<mark@ucbvax.Berkeley.EDU>
      #RCPT TO:<mark@cbosgd.ATT.COM>
      #DATA
      #Date: Tue, 18 Feb 86 13:07:36 EST
      #From: mark@ucbvax.Berkeley.EDU
      #Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU> #To:
      mark@cbosgd.ATT.COM
      #
      #This is a sample message.
      #.
      #QUIT

2.4  信封（Envelope）
命令的標準輸入應該以單獨的一行：From domain!user date remote from system開始，后
面緊跟著RFC822格式的報頭和消息主體。可能在該行前還有其他的FROM行——這些行
是可以增加的，消息途經(jīng)的每個系統(tǒng)增加一行。“系統(tǒng)字段”也可能堆疊成單獨一行，在
“user”字符串中包含許多“!”。“From”前面可能還會有“>”字符。一般說來，這些“信
封”信息應該與舊式的UUCP郵件一樣遵從相同的約定。主要的區(qū)別是當系統(tǒng)名緊湊書寫
時，如果舊式的寫法是a!b!c!mysys!me，新的寫法改為a!b!c!mysys!domain!me，其中“domain”
至少包含一個逗點符號，“mysys”通常是稱為“domain”的系統(tǒng)的6字符UUCP名。如果
“domain!”是多余的，就可以在信封中——源路徑或者目的地址——省略掉。
如果需要把信息包裝成只有一個FROM行，接收系統(tǒng)可能會丟棄多余的“From_”行。
它把“path!domain!user”和“信封”信息——包括消息發(fā)送方的地址，可能還生成新的一
行如Received或Sent-By，其中保存著轉發(fā)日期和轉發(fā)系統(tǒng)——一起發(fā)送出去。（不建議使
用Received，因為這樣的行可能在真正增加該行的系統(tǒng)之前被其他的系統(tǒng)添加，而其他的系