組織：中國互動(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-1
版權(quán)：本翻譯文檔可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及組織信息。


Network Working Group                                    Craig Partridge
Request for Comments: 974                 CSNET CIC BBN Laboratories Inc
                                                            January 1986

                  

郵件路由與域名系統(tǒng)
(RFC974  MAIL ROUTING AND THE DOMAIN SYSTEM)

備忘錄狀態(tài)
本RFC文檔描述了Internet上的郵件系統(tǒng)如何根據(jù)域名系統(tǒng)（參見RFC882、883和973）
的信息發(fā)送消息。本備忘錄的傳播不受限制。

簡介
本備忘錄的目的在于闡明郵寄方如何確定以給定的Internet域名為地址的消息的發(fā)送路
由。其中包括關(guān)于郵寄方如何解釋MX RR的討論，MX RR用于消息路由。注意，本備忘
錄沒有涉及郵寄方如何處理MB RR和MG RR的陳述，這兩者用于郵箱名的解釋。
RCF 882和RFC 883中關(guān)于郵件地址的一些設(shè)想已經(jīng)發(fā)生了變化?，F(xiàn)在一般可以認(rèn)為如
果消息的地址是一個(gè)信箱——比如LOKI.BBN.COM，只要打開一個(gè)對LOKI.BBN.COM的
SMTP連接向前發(fā)就可以了。這種系統(tǒng)不適用于某些特定的情況，比如沒有直接接入Internet
的特定的UUCP和CSNET主機(jī)，不過這些主機(jī)可以在配置文件中作為特殊情況處理（比如
大部分郵寄者都設(shè)定把發(fā)送給CSNET的郵件自動(dòng)轉(zhuǎn)發(fā)給CSNET-RELAY.ARPA）。
在域名系統(tǒng)中不能簡單地打開對LOKI.BBN.COM的連接，而必須向域名系統(tǒng)詢問發(fā)往
LOKI.BBN.COM的消息如何遞送。域名系統(tǒng)可能會(huì)指導(dǎo)郵寄者把消息傳遞到一個(gè)完全不同
的主機(jī)，譬如SH.CS.NET?；蛘咴诟訌?fù)雜的情形中，郵寄者可能得知它有一個(gè)到
LOKI.BBN.COM的路徑可以選擇。本備忘錄主要講述在這種更加復(fù)雜的情況下郵寄者如何
工作的一些指導(dǎo)原則。
希望讀者已經(jīng)熟悉了RFC 882、RFC 883和它們的更新版本（如RFC973）。







目錄
域服務(wù)器了解什么	2
路由原則概述	2
確定消息要發(fā)往哪兒	3
發(fā)出查詢	3
解釋MX資源記錄列表	3
次要的特殊問題	4
例子	5

域服務(wù)器了解什么
域名服務(wù)器把信息保存為一系列的資源記錄（resource record，RR），每個(gè)記錄包含有關(guān)
于某個(gè)域名（通常但不一定是一臺(tái)主機(jī)）的特定信息片段。可以簡單地把資源記錄想象為數(shù)
據(jù)的代表對，每個(gè)域名都與對應(yīng)的數(shù)據(jù)相匹配，還存儲(chǔ)有其他的類型信息以幫助系統(tǒng)確定何
時(shí)與資源記錄關(guān)聯(lián)。為了確定消息路由，系統(tǒng)存儲(chǔ)了稱為MX RR的資源記錄。每個(gè)MX都
一個(gè)域名相對應(yīng)，包含兩段數(shù)據(jù)：優(yōu)先值（16位無符號整數(shù)）和主機(jī)名。優(yōu)先值表示郵寄
者給MX主機(jī)傳遞消息的發(fā)送順序，編號最低的MX最先發(fā)送。允許多個(gè)MX擁有相同的
優(yōu)先值，此時(shí)它們具有相同的優(yōu)先級。
除了郵件信息，服務(wù)器還存儲(chǔ)有其他類型的資源記錄，郵寄者可能會(huì)遇到或者選擇使用
這些RR。其中包括：規(guī)范名資源記錄（CNAME），它表示查詢的域名實(shí)際上是另外一個(gè)域
名的別名，而CNAME才是嚴(yán)格的或者說規(guī)范的域名；知名服務(wù)資源記錄（Well Known 
Service，WKS），保存給定域名所支持的網(wǎng)絡(luò)服務(wù)（如SMTP）信息。

路由原則概述
在深入探討郵寄者如何選擇郵件路由之前，似乎有必要給出一個(gè)本備忘錄所討論的解決
路由選擇問題的簡要概述。
第一條主要的原則來自MX記錄中定義的優(yōu)先值字段，目的在于避免循環(huán)郵寄。如果郵
寄者的主機(jī)也列入目標(biāo)主機(jī)的MX，郵寄者只能給優(yōu)先值比自身主機(jī)低的MX傳送郵件。
路由信息過時(shí)或者不完全也可能造成循環(huán)郵寄。信息過時(shí)問題只有在域表改變時(shí)才會(huì)發(fā)
生，因?yàn)槟切┍挥绊懙闹鳈C(jī)只有在它們的分析器緩存超時(shí)后才會(huì)了解這些變化。只要不要求
郵寄者及其分析器必須向權(quán)威的服務(wù)器發(fā)出詢問而且絕不使用緩存中的數(shù)據(jù)，就無法保證不
會(huì)發(fā)生這樣的問題。而這種方法是不切實(shí)際的，因?yàn)槿サ舴治銎鞯木彺鏁?huì)導(dǎo)致郵件非常昂貴。
另外，只要在域表改變時(shí)刷新受影響主機(jī)的（MX列表中的那些）分析器緩存，就不會(huì)發(fā)生
資源記錄過時(shí)的問題。按句話說，只要有適當(dāng)?shù)念A(yù)防措施，域信息帶來的循環(huán)郵寄問題完全
可以避免，也不需要郵寄者查詢權(quán)威服務(wù)器。（適當(dāng)?shù)念A(yù)防措施是再把主機(jī)添加進(jìn)MX列表
前，由主機(jī)管理員進(jìn)行檢查。）
數(shù)據(jù)不完整的問題在處理域查詢時(shí)也需要注意。如果查詢的答復(fù)段不完整，可能會(huì)漏掉
關(guān)鍵的MX資源記錄。這樣可能造成循環(huán)郵寄，或者信息給錯(cuò)誤地貼上無法郵遞的標(biāo)簽。
因此，郵寄者只能接受那些提供完整答復(fù)段的域系統(tǒng)的響應(yīng)。注意，只要使用虛擬的查詢循
環(huán)就可以完全避免這個(gè)問題。不過由于這種情況很少發(fā)生，而且與域系統(tǒng)交互的首選方式是
數(shù)據(jù)報(bào)，因此應(yīng)用者可能只需要保證郵寄者使用虛擬循環(huán)反復(fù)重發(fā)查詢，直到獲取被截?cái)嗟?數(shù)據(jù)。
確定消息要發(fā)往哪兒

根據(jù)這樣的一個(gè)問題討論并說明郵寄者如何確定消息的路由：域名為LOCAL的主機(jī)上的郵
寄者試圖郵遞消息，消息的地址是域名REMOTE。假定LOCAL和REMOTE都是語法正確
的域名。另外，假設(shè)LOCAL是郵寄者所在主機(jī)的正式名稱（即不是一個(gè)別名）。

發(fā)出查詢
LOCAL郵寄者的第一步是查詢REMOTE的MX資源記錄。強(qiáng)烈要求郵寄者每次試圖發(fā)
送消息時(shí)都要執(zhí)行這一步。目的是保證郵寄者能夠及時(shí)地應(yīng)用域數(shù)據(jù)庫的變動(dòng)，這樣對于不
完備的主機(jī)，域管理員就可以通過簡單地修改其域數(shù)據(jù)庫為傳送的消息重新設(shè)置路由
（re-route）。
有幾種查詢響應(yīng)被認(rèn)為出錯(cuò)：
1．查詢無響應(yīng)。郵寄者查詢的域服務(wù)器沒有回復(fù)（與沒有查詢結(jié)果的回復(fù)不同，后
者不是錯(cuò)誤）。
2．得到設(shè)定了頭部截?cái)嘧侄蔚捻憫?yīng)。（回顧一下前面對不完全查詢的討論）。郵寄者
可能無法使用這樣的回復(fù)，應(yīng)使用虛擬循環(huán)而不是數(shù)據(jù)報(bào)反復(fù)查詢。
3．得到響應(yīng)碼非0的響應(yīng)。
郵寄者應(yīng)該合理地處理錯(cuò)誤。這里沒有指明如何處理各種類型的錯(cuò)誤，但是應(yīng)用者不同
類型的錯(cuò)誤可能需要區(qū)別對待。比如響應(yīng)碼“域不存在”可能需要把消息視為無效并返回發(fā)
送方，而響應(yīng)碼“服務(wù)器故障”則可能導(dǎo)致稍后重新發(fā)送消息。
還存在其它的特殊情況。如果響應(yīng)結(jié)果是一個(gè)CNAME資源記錄，這表明REMOTE實(shí)
際上是另外一個(gè)域名的別名，需要使用規(guī)范域名重新查詢。
如果響應(yīng)不包含錯(cuò)誤，也沒有別名，答復(fù)段（answer section）應(yīng)該是域名REMOTE（如
果REMOTE是別名就是它的真正的名稱）的（長度可能為0的）MX資源記錄列表。下一
節(jié)將說明該表的解釋。
解釋MX資源記錄列表
注意：本節(jié)只討論郵寄者如何從資源記錄列表中選擇傳遞消息的目的名，沒有討論郵寄
者如何真正地執(zhí)行郵遞。無論何時(shí)提及消息傳遞，都意味著郵寄者執(zhí)行必要的操作把消息發(fā)
往一個(gè)給定了域名的遠(yuǎn)程站點(diǎn)。（比如，SMTP郵寄者將首先試圖取得域名的地址，其中包
括對域系統(tǒng)進(jìn)行另外的查詢，然后如果得到了地址，就建立對SMTPTCP端口的連接）。通
過網(wǎng)絡(luò)把消息傳輸?shù)揭粋€(gè)與給定域名相關(guān)的地址的具體機(jī)制超出了本備忘錄的范圍。
查詢響應(yīng)中的MX列表有可能是空表，這是一種特殊情況。對此，郵寄者應(yīng)把空表視作包
含一條資源記錄，這條MX資源記錄的優(yōu)先值是0，主機(jī)名是REMOTE（就是說REMOTE
也是其自身唯一的MX）。另外，郵寄者也不需要進(jìn)一步處理資源記錄表，而應(yīng)直接把消息
遞送給REMOTE。這種考慮是為了在域無法提供主機(jī)名的任何信息的情況下，我們可以根
據(jù)猜測試著傳遞消息。
如果表不為空，郵寄者應(yīng)按照下面的步驟從列表中刪除無關(guān)的資源記錄，注意先后順序
很重要。
對于每個(gè)MX發(fā)送WKS查詢，看看列出的域名是否確實(shí)支持需要的郵件服務(wù)。域
名不支持該服務(wù)的MX資源記錄應(yīng)摒棄。這一步驟不是必需的，但強(qiáng)烈建議執(zhí)行。
如果域名LOCAL也被列為MX資源記錄，優(yōu)先值大于或等于LOCAL的優(yōu)先值的
所有MX資源記錄必須摒棄。
去除無關(guān)的資源記錄后列表可能又變空了。這種情況是發(fā)生了錯(cuò)誤，可能由幾種原因造
成。最簡單的情形是WKS查詢發(fā)現(xiàn)列出的主機(jī)都不支持需要的郵件服務(wù)。這樣就認(rèn)為消息
無法傳遞，不過一些非常穩(wěn)妥的郵件系統(tǒng)在返回這個(gè)消息前可能會(huì)首先試著傳送到
REMOTE的地址（如果存在這樣一個(gè)地址）。另外一種更加危險(xiǎn)的可能是域系統(tǒng)認(rèn)為LOCAL
在處理發(fā)往REMOTE的消息，而LOCAL上的郵寄者并沒有準(zhǔn)備處理發(fā)往REMOTE的郵
件。例如，如果域系統(tǒng)列出的REMOTE MX只有LOCAL一條記錄，LOCAL就會(huì)把列表清
空。但是LOCAL查詢域系統(tǒng)大概是因?yàn)樗恢廊绾翁幚淼刂窞镽EMOTE的消息。顯然
某些地方出了差錯(cuò)。郵寄者如何處理此類情況在一定程度上依賴于具體的實(shí)現(xiàn)，因此留給應(yīng)
用者來判斷。
如果MX資源記錄列表不為空，郵寄者將依序（優(yōu)先值低者優(yōu)先）試著把消息發(fā)往每個(gè)
MX。郵寄者被要求盡量傳送給優(yōu)先值最低的MX。鼓勵(lì)應(yīng)用者編制郵寄者對每個(gè)MX依序
試用，直到某個(gè)MX接收消息或者試過全部的MX為止。對于一些不過分苛求的系統(tǒng)，僅
僅試用一定數(shù)量的MX也是合理的。要注意可能有多個(gè)MX具有相同的優(yōu)先值。此時(shí)，必
須在試過具有該優(yōu)先值的所有的MX之后，才能繼續(xù)試用優(yōu)先值更高的MX。另外，特殊的
情況下可能會(huì)出現(xiàn)幾個(gè)MX都具有最低的優(yōu)先值，在確認(rèn)消息不可傳遞之前必須對它們?nèi)?部試用。
次要的特殊問題
為了避免復(fù)雜化，上一節(jié)的討論沒有牽扯兩個(gè)特殊的問題。在這里對它們的討論并沒有
特別的順序。
帶有字符“*”的通配符名也可能用于郵件路由。網(wǎng)絡(luò)上的服務(wù)器很可能簡單的規(guī)定發(fā)
往某個(gè)域的郵件都要經(jīng)過一個(gè)中繼轉(zhuǎn)發(fā)。例如，在本文檔寫作的時(shí)候，所有發(fā)往域IL主機(jī)
的郵件都經(jīng)過RELAY.CS.NET發(fā)送。這是通過建立一個(gè)帶有通配符的資源記錄實(shí)現(xiàn)的，該
記錄表明“*.IL”具有RELAY.CS.NET 的MX。這對郵寄者應(yīng)該保持透明，因?yàn)橛蚍?wù)器
會(huì)把匹配的通配符隱藏起來（比如HUJI.IL與*.IL匹配，域服務(wù)器返回的資源記錄將包括
HUJI.IL，而不是*.IL）。如果由于某種意外，郵寄者收到的資源記錄在域名或者數(shù)據(jù)段中包
含通配符，就應(yīng)該摒棄該項(xiàng)資源記錄。
需要注意的是，如果LOCAL有一個(gè)別名而且這個(gè)別名出現(xiàn)在REMOTE的MX記錄列
表中（比如REMOTE有一項(xiàng)MX稱為ALIAS，而ALIAS的CNAME是LOCAL），這會(huì)破
壞刪除無關(guān)資源記錄的算法。只要保證在MX資源記錄的數(shù)據(jù)段不使用別名就可以避免這
一問題。
應(yīng)用者應(yīng)該理解查詢以及對查詢的解釋只對REMOTE而言，不會(huì)對REMOTE列出的
MX資源記錄反復(fù)查詢。你不能試圖構(gòu)造一個(gè)MX鏈來支持更加復(fù)雜的郵件路由。（比如，
UNIX.BBN.COM是RELAY.CS.NET的一項(xiàng)MX，而RELAY.CS.NET又是.IL上所有主機(jī)的
MX，但這并不意味著UNIX.BBN.COM會(huì)承擔(dān)把郵件發(fā)往.IL的職責(zé)。）
最后要注意這是一個(gè)在Internet上選擇路由的標(biāo)準(zhǔn)。為分布在多個(gè)網(wǎng)絡(luò)上的主機(jī)服務(wù)的
郵寄者可能還必須就使用哪個(gè)網(wǎng)絡(luò)傳送做出決策。這樣的決策超出了本備忘錄的范圍，盡管
郵寄者也可以利用域系統(tǒng)幫助選擇。但是，只要郵寄者決定使用Internet遞送消息，就必須
根據(jù)這些原則選擇消息路由。
例子
作為上述討論的進(jìn)一步說明，這里舉3個(gè)郵寄者選擇消息路由的例子。這些例子都是用下面
的數(shù)據(jù)庫：

      A.EXAMPLE.ORG    IN    MX    10    A.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    MX    15    B.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    MX    20    C.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    WKS   10.0.0.1    TCP    SMTP

      B.EXAMPLE.ORG    IN    MX    0      B.EXAMPLE.ORG
      B.EXAMPLE.ORG    IN    MX    10     C.EXAMPLE.ORG
      B.EXAMPLE.ORG    IN    WKS   10.0.0.2    TCP    SMTP

      C.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
      C.EXAMPLE.ORG    IN    WKS   10.0.0.3    TCP    SMTP

      D.EXAMPLE.ORG    IN    MX    0     D.EXAMPLE.ORG
      D.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
      D.EXAMPLE.ORG    IN    WKS   10.0.0.4    TCP    SMTP

在第一個(gè)例子中，位于D.EXAMPLE.ORG 上的SMTP郵寄者試圖傳遞一個(gè)地址標(biāo)為
A.EXAMPLE.ORG 的消息。在查詢結(jié)果中，它了解到A.EXAMPLE.ORG有三個(gè)MX 資源
記錄。D.EXAMPLE.ORG不在這些MX資源記錄中，而且三個(gè)MX都支持SMTP郵件（取
決于WKS項(xiàng)），因此沒有排除一個(gè)MX。因?yàn)锳.EXAMPLE.ORG是優(yōu)先值最低的MX，郵
寄者被迫試圖發(fā)送到A.EXAMPLE.ORG。如果無法抵達(dá)A.EXAMPLE.ORG，可以（但不是
必須）再試一下B.EXAMPLE.ORG；如果B.EXAMPLE.ORG仍然沒有響應(yīng)，還可以再試
C.EXAMPLE.ORG。
在第二個(gè)例子中，郵寄者位于B.EXAMPLE.ORG上，同樣是要傳送地址標(biāo)為
A.EXAMPLE.ORG的消息。這一次A.EXAMPLE.ORG也有三個(gè)MX資源記錄，不同的是郵
寄者必須摒棄自身的MX資源記錄和C.EXAMPLE.ORG的資源記錄（因?yàn)?C.EXAMPLE.ORG MX資源記錄的優(yōu)先值比B.EXAMPLE.ORG高）。這樣A.EXAMPLE.ORG
只剩下一條資源記錄，只能試著傳遞給A.EXAMPLE.ORG。
在第三個(gè)例子中，考慮位于A.EXAMPLE.ORG上的郵寄者要給D.EXAMPLE.ORG傳遞
消息。這種情況下只有兩條MX資源記錄而且優(yōu)先值相同，每一個(gè)MX都可以為
D.EXAMPLE.ORG接收消息。郵寄者可以先試用一個(gè)（哪一個(gè)取決于郵寄者，不過
D.EXAMPLE.ORG似乎更加合理），如果傳送失敗再試另一個(gè)（如C.EXAMPLE.ORG）。
RFC 974 MAIL ROUTING AND THE DOMAIN SYSTEM                     郵件路由與域名系統(tǒng)		1/5


1
RFC 文檔中文翻譯計(jì)劃