統可能事實上也包括一個Received行。Sent-By行與Received行類似，但日期不需要改為
RFC822格式，而且不主張由名稱被提及的系統提前增加該行。）
如果接收系統繼續把消息轉發給另一個系統，它就會在前面增加一個FROM行，給處于
發送方相同的user@domain地址并加上自身的系統名。如果接收系統把消息保存到本地的信
箱內，建議僅在消息前生成一個FROM行并保存日期（使用相同的格式，因為有些郵件閱
讀程序對這種格式是敏感的），而不是用“remote from system”語法格式。
注意：如果中間系統在user@domain語法格式地址——無論是信封還是消息體中——前
面增加文本如“system!”，都是不符合本標準和RFC822規范的。

2.5  郵件路由
為了正確地發送郵件，有時候需要了解目的系統或者中間系統運行了什么軟件或者遵從
什么樣的約定。我們曾經試圖盡量減少必要的信息量，但是對子域的支持可能需要在不同條
件下使用不同的方法。為了預報其他系統的行為方式，我們把主機分為三類。這三類包括：

一類 僅使用舊式的UUCP“!”路徑。我們設想主機理解本地用戶名：“rmail user”和完
全路徑“rmail host1!host2!user”，但我們不對主機做更多的假定。如果沒有關于某
臺主機的任何信息，我們可以毫無問題地把它作為第一類處理，因為我們沒有對
其如何處理混合地址作任何假設。

   二類 舊式的UUCP“!”路徑和4.2BSD格式的域解析。我們假設除了具有一類主機的功
能外，還能夠理解“rmail user@domain”，其中“domain”位于UUCP區之外但主
機可以識別。二類主機不必理解“domain!user”，也不需要路由器。符合RFC920
標準的非UUCP域中的主機被認為是二類主機，即使也可能識別“host!user”。

   三類 具有一類和二類主機的全部功能。另外，三類主機還能夠為相距較遠的主機發送
UUCP郵件，并且能夠理解如前所述的語法“ramil domain!user”。所有連接到UUCP
的網關必須是第三類。
本文檔描述了三類主機必須具有的功能。一類和二類主機已經存在，并將繼續存在相當
長的一段時間，但被視為“過時的系統”并最終將升級到3類主機的狀態。

3.  算法
通過UUCP連接傳遞消息給地址user@domain的算法可以概述如下：

      a.  如果地址的實際格式是@domain1:user@domain2，就把“domain1”而不是
“domain2”保留下來作為“doamin”，完整的格式讀為“domain1!domain2!user”。
      b.  確定本地可以識別的“domain”中的最明確的部分，記作“d:”，該部分應該是
“domain”的后綴。這項工作可以通過掃描一個表來完成，表項按照從特殊到一
般的順序排列，比較表項與“domain”檢查該表項是否與“domain”的尾部匹配。
例如，對于地址mark@osgd.cb.att.com，如果本地主機能夠識別“uucp”和“att.com”，
那么d就應該是“att.com”。表的最后一項是空字符串，與完全無法識別的域匹配。
      c.  查看基本表項（found table entry），尋找網關名（g:）和通往g的UUCP“!”格
式的路徑“r:”。G不一定要與本地主機直接相連，但應視作連接域d的網關。（對
于給定的d，在不同的主機上g和r可能具有不同的值，不過g通常是一樣的） 
      d.  根據r的開始部分查找“下一跳”的主機n，n總是直接與本地主機相連。
      e.  如果可能則確定g和n的類型。
      f.  建立n能夠解釋的適當的目標字符串s（見下面）。
g.	把消息及目標信息s傳遞給n。
如果環境中包括其它類型的不使用UUCP“!”解析的網絡，表中可能還會有附加的
信息，如使用的連接類型。路徑信息在其他的環境中可能被替換為那個網絡的特殊信
息。
上述第二步（b）中提到的表中的第一項一般是非常精確的，能夠直接構造知名的路徑
而無需通過域樹尋路。域樹僅保留用于下列情況：沒有更詳盡多的信息；信息量很少；默認
路徑是最佳的選擇。如果存在更好的路徑就可以把該信息寫入表中。如果主機有大量的信息
傳送給第二個主機，一般希望在兩臺主機之間建立直接的UUCP連接并為它們建立相應的
表項以便直接傳遞郵件，即使兩臺主機位于不同的域中。路徑表的構造應該為最大的通信量
保持最短最便宜的路徑。
這里對目標字符串n（上述第六步f）的構造提供幾點提示。如果發送站點確定下一跳是
三類主機，那么“envelope recipient”信息（rmail的s參數）既可以使用域“!”格式
（host.com!user），也可以采用域“@”格式（user@host.com）。如果下一跳步不是三類主機，
或者發送站點不能確定，那么應盡可能使用“!”格式，因為無法預知下一跳會如何處理混
合地址。
如果已知網關是第三類，可以使用域“!”格式，但是如果發送站點不能確定其類型，或
者查找中目標字符串完全匹配（而不是與某個父域匹配），則應使用6字符“!”格式“r!user”，
如“dumbhost!host!user”。如果網關看來實際上是一個子域的網關，即與一個父域匹配（如
地址user@host.gateway.com，表中沒有找到host.gateway.com但發現了gateway.com），可以
把它假定為第三類。這樣在一定程度上可以安全使用如
dumbhost!domain!host.domain.com!user之類的路徑。如果存在到目標主機的直接連接，可以
使用user@domain或者domain!user兩種語法格式。
符合本標準的主機是三類主機，所有的子域網關必須是三類主機。

4.  例子
假設主機A.D.COM 向主機C.D.COM發送郵件。設兩臺主機的6字符名分別為aname
和dname，途徑中間主機bname。
   主機A的用戶輸入：   mail user@c.d.com
   用戶界面生成一個文件并使用命令（如sendmail user@c.d.com < file）把它傳遞給傳輸機
制，文件內容如下：
      Date:  9 Jan 1985   8:39 EST
      From: myname@A.D.COM (My Name)
      Subject: sample message
      To: user@c.d.com

      This is a sample message
傳輸機制查找到c.d.com的路徑，但在數據庫中沒有找到；于是尋找d.com，發現其路
徑是bname!dname!%s，而且發現c.cd.com是三類主機。然后加入c.d.com!user，就得到了路
徑bname!dname!c.d.com!user。（如果發現c.d.com的路徑是bname!cname!%s，結果路徑
bname!cname!user中的域將被忽略，因為無法確認目標主機屬于哪一類。）
傳輸機制預備一個FROM行并把它傳遞給uux： uux - bname!rmail dname!c.d.com!user < 
file2，file2的內容包括：
      From A.D.COM!user Wed Jan  9 12:43:35 1985 remote from aname Date:
      9 Jan 1985   8:39 EST
      From: myname@A.D.COM (My Name)
      Subject: sample message
      To: user@c.d.com

      This is a sample message

   (注意消息尾部的空行——至少需要一個空行。)這將導致B主機執行命令：rmail 
dname!c.d.com!user。B預備了它自己的FROM行并繼續轉發郵件：uux - dname!rmail 
c.d.com!user < file3，file3的內容包括：

      From nuucp Wed Jan  9 12:43:35 1985 remote from bname >From
      A.D.COM!user Wed Jan  9 11:21:48 1985 remote from aname Date:  9
      Jan 1985   8:39 EST
      From: myname@A.D.COM (My Name)
      Subject: sample message
      To: user@c.d.com

      This is a sample message
    C主機執行命令：rmail c.d.com!user并壓縮FROM行，然后把消息保存到本地——可能
使用相同的格式：

      From bname!aname!A.D.COM!user Wed Jan  9 12:43:35 1985 Date:  9
      Jan 1985   8:39 EST
      From: myname@A.D.COM (My Name)
      Subject: sample message
      To: user@c.d.com

      This is a sample message

5.  結論
    符合本標準的主機可以接受如下所有的格式：

      rmail localuser               (user中不含“!”、“%”、“@”)
      rmail hosta!hostb!user         (user中不含“!”、“%”、“@”)
      rmail user@domain           (域中只有逗點“.”)
      rmail domain!user            (域中至少包含一個逗點“.”)
      rmail domain.!user            (域中沒有圓點的情形)
    消息的信封部分（FROM行）應遵循現有的約定使用“!”路徑。消息的首部（Word:
行，如Date:、From:、To:和Subject:）必須符合RFC822規范。所有首部地址必須采用@格
式。原始站點應確保地址符合RFC822，不能要求轉發站點或者網關把地址轉換為合法的
RFC822地址。（同樣轉發站點或者網關也不得把合法的RFC822地址user@domain轉化成不
符合RFC822的地址gateway!user@domain，即使要轉發給一類UUCP主機。）

6.  參考

   [1]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,
        USC/Information Sciences Institute, August, 1982.

   [2]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", RFC-822, Department of Electrical Engineering,
        University of Delaware, August, 1982.

   [3]  Postel, J., and J. K. Reynolds, "Domain Requirements", RFC-920,
        USC/Information Sciences Institute, October, 1984.

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


1
RFC文檔中文翻譯計劃