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


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


UUCP郵件交換格式標(biāo)準(zhǔn)
（RFC976 UUCP Mail Interchange Format Standard）


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

目錄
1.  簡(jiǎn)介	1
2.  基礎(chǔ)	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.  結(jié)論	7
6.  參考	8

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

2.  基礎(chǔ)
消息可以分為兩部分：信封和消息本身。信封包含郵件傳輸服務(wù)所需要的信息，消息包
含對(duì)收發(fā)方有用的信息。消息分為首部和主體。有時(shí)候中間主機(jī)會(huì)改變消息（如增加Received
行），但除非是網(wǎng)關(guān)需要改變傳輸格式，中間主機(jī)一般不得修改消息本身。在UUCP世界中，
信封包括“目的地址”（通常表現(xiàn)為rmail命令的參數(shù)）和“源地址”（通常由消息的第一行
或者最初幾行表示，以“From”或者“>From”開(kāi)始，又稱(chēng)為“From行”）。RFC32的報(bào)頭
行（包括“From：”和“To：”）作為消息的一部分是消息體本身的文本。
UUCP在運(yùn)輸層及以下各層使用短主機(jī)名，如“ucbvax”。我們把這種短名稱(chēng)為“6字符
名”，因?yàn)槿魏蜺UCP的實(shí)現(xiàn)都至少把前6個(gè)字符視為有效的。（有一些把前7個(gè)或者前14
個(gè)字符視為有效，但我們必須使用最低的通用標(biāo)準(zhǔn)。）UUCP名可以長(zhǎng)于6個(gè)字符，但其前
6個(gè)必須各不相同。RFC920域的名稱(chēng)，如“ucbvax Berkeley.EDU”稱(chēng)為“域名”。這兩個(gè)名
是不同的。大小寫(xiě)對(duì)于6字符名被認(rèn)為是不同的，但對(duì)于域名則認(rèn)為是相同的。6字符名后
加上“.UUCP”，如“ubcvax.UUCP”在過(guò)去作為對(duì)使用6字符名的主機(jī)的域格式的引用。
隨著對(duì)組織化的域名如“ucbvax.Berkelry.EDU”的支持，這一類(lèi)名稱(chēng)正在逐步淘汰。
2.1  混合地址（Hybrid Addresses）
在UUCP世界中主要使用兩種郵件地址語(yǔ)法：舊式UUCP軟件使用的“a!b!c!user”（完
全路徑）格式指明了傳送郵件到目的地址的路線；遵循RFC822的“user@domain”（域）語(yǔ)
法格式。大部分情況下都可以根據(jù)給定的地址判定地址的類(lèi)型。但是對(duì)于@左側(cè)包含“a!”
的混合地址，如a!b@c就出現(xiàn)了混淆：即可以解釋為(a!b)@c.d，也可以解釋為a!(b@c.d)。這
兩種解釋都有意義，前者用于RFC822，后者是UUCP軟件事實(shí)上的標(biāo)準(zhǔn)。
由于混合地址帶來(lái)的混亂，我們建議所有的運(yùn)輸層軟件在任何時(shí)候都應(yīng)該避免使用混合
地址。純粹的完全地址語(yǔ)法可以用來(lái)澄清這種混淆，上例中的第一種解釋可以寫(xiě)為“c.d!a!b”，
第二種解釋寫(xiě)為“a!c.d!b”。我們建議所有的實(shí)現(xiàn)都是用這種“完全域”語(yǔ)法，除非他們確
實(shí)知道下一臺(tái)機(jī)器上運(yùn)行什么。
按照RFC822和AT&T消息傳輸體系，我們建議所有允許混合地址的主機(jī)采用(a!b)@c.d
這種解釋。

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

2.3  批處理SMTP
符合標(biāo)準(zhǔn)的實(shí)現(xiàn)可能會(huì)選擇支持一種稱(chēng)為“批處理SMTP”的協(xié)議。SMTP（簡(jiǎn)單郵件
傳輸協(xié)議）是ARPA社區(qū)的標(biāo)準(zhǔn)郵件傳輸協(xié)議（RFC821），BITNET和Mailnet也使用該協(xié)
議。因?yàn)镾MTP被設(shè)計(jì)為交互式的，把一系列命令組成以批發(fā)到遠(yuǎn)程機(jī)器上成批執(zhí)行是可
能的。BSMTP的一個(gè)優(yōu)點(diǎn)是UNIX外殼不參與消息的解釋?zhuān)蚨娮有畔⒅锌梢园崭?和括號(hào)這樣的特殊字符（這些字符在X.400地址中將會(huì)非常普遍）。
為了使UNIX支持BSMTP，符合標(biāo)準(zhǔn)的主機(jī)應(yīng)當(dāng)把用戶(hù)的郵件命令“b-smtp”解釋為
批處理SMTP（我們使用“b-smtp”而不是“bsmtp”是因?yàn)楹笳吲c一個(gè)登錄名沖突）。因?yàn)?許多郵件系統(tǒng)把包含單個(gè)逗點(diǎn)一行當(dāng)作“文件尾”的標(biāo)志處理，而SMTP把逗點(diǎn)用作必需
的文件尾標(biāo)志，為了區(qū)分出報(bào)頭，我們?cè)贐SMTP的每一行增加一個(gè)特殊的“#”。在郵件發(fā)
送系統(tǒng)中實(shí)現(xiàn)這一點(diǎn)的簡(jiǎn)單方法是包括如下別名：
      b-smtp: "|egrep '^#' | sed 's/^#//' | /usr/lib/sendmail -bs"
這樣就可以把命令輸送給SMTP解釋器。更好的方案還要同時(shí)檢查錯(cuò)誤并把錯(cuò)誤信息反饋
給發(fā)送方。
下面的例子說(shuō)明了一個(gè)從seismo.CSS.GOV發(fā)往cbosgd.ATT.COM的BSMTP消息。這
個(gè)例子是通過(guò)UUCP連接傳遞給命令“rmail b-smtp”的文件。注意RFC- 822 消息位于DATA
行和逗點(diǎn)行（最后一行）之間。信封信息在MAIL FROM和RCPT TO行中傳遞。發(fā)送系統(tǒng)
的名稱(chēng)在HELO行中。實(shí)際的信封信息（帶有“#”的行以上的部分）被忽略了，不一定要
出現(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）
命令的標(biāo)準(zhǔn)輸入應(yīng)該以單獨(dú)的一行：From domain!user date remote from system開(kāi)始，后
面緊跟著RFC822格式的報(bào)頭和消息主體。可能在該行前還有其他的FROM行——這些行
是可以增加的，消息途經(jīng)的每個(gè)系統(tǒng)增加一行。“系統(tǒng)字段”也可能堆疊成單獨(dú)一行，在
“user”字符串中包含許多“!”。“From”前面可能還會(huì)有“>”字符。一般說(shuō)來(lái)，這些“信
封”信息應(yīng)該與舊式的UUCP郵件一樣遵從相同的約定。主要的區(qū)別是當(dāng)系統(tǒng)名緊湊書(shū)寫(xiě)
時(shí)，如果舊式的寫(xiě)法是a!b!c!mysys!me，新的寫(xiě)法改為a!b!c!mysys!domain!me，其中“domain”
至少包含一個(gè)逗點(diǎn)符號(hào)，“mysys”通常是稱(chēng)為“domain”的系統(tǒng)的6字符UUCP名。如果
“domain!”是多余的，就可以在信封中——源路徑或者目的地址——省略掉。
如果需要把信息包裝成只有一個(gè)FROM行，接收系統(tǒng)可能會(huì)丟棄多余的“From_”行。
它把“path!domain!user”和“信封”信息——包括消息發(fā)送方的地址，可能還生成新的一
行如Received或Sent-By，其中保存著轉(zhuǎn)發(fā)日期和轉(zhuǎn)發(fā)系統(tǒng)——一起發(fā)送出去。（不建議使
用Received，因?yàn)檫@樣的行可能在真正增加該行的系統(tǒng)之前被其他的系統(tǒng)添加，而其他的系