郵件路由與域名系統

域服務器了解什么
域名服務器把信息保存為一系列的資源記錄（resourcerecord，RR），每個記錄包含有關
于某個域名（通常但不一定是一臺主機）的特定信息片段?？梢院唵蔚匕奄Y源記錄想象為數
據的代表對，每個域名都與對應的數據相匹配，還存儲有其他的類型信息以幫助系統確定何
時與資源記錄關聯。為了確定消息路由，系統存儲了稱為MXRR的資源記錄。每個MX都
一個域名相對應，包含兩段數據：優先值（16位無符號整數）和主機名。優先值表示郵寄
者給MX主機傳遞消息的發送順序，編號最低的MX最先發送。允許多個MX擁有相同的
優先值，此時它們具有相同的優先級。
除了郵件信息，服務器還存儲有其他類型的資源記錄，郵寄者可能會遇到或者選擇使用
這些RR。其中包括：規范名資源記錄（CNAME），它表示查詢的域名實際上是另外一個域
名的別名，而CNAME才是嚴格的或者說規范的域名；知名服務資源記錄（WellKnown
Service，WKS），保存給定域名所支持的網絡服務（如SMTP）信息。

路由原則概述
在深入探討郵寄者如何選擇郵件路由之前，似乎有必要給出一個本備忘錄所討論的解決
路由選擇問題的簡要概述。
第一條主要的原則來自MX記錄中定義的優先值字段，目的在于避免循環郵寄。如果郵
寄者的主機也列入目標主機的MX，郵寄者只能給優先值比自身主機低的MX傳送郵件。
路由信息過時或者不完全也可能造成循環郵寄。信息過時問題只有在域表改變時才會發
生，因為那些被影響的主機只有在它們的分析器緩存超時后才會了解這些變化。只要不要求
郵寄者及其分析器必須向權威的服務器發出詢問而且絕不使用緩存中的數據，就無法保證不
會發生這樣的問題。而這種方法是不切實際的，因為去掉分析器的緩存會導致郵件非常昂貴。
另外，只要在域表改變時刷新受影響主機的（MX列表中的那些）分析器緩存，就不會發生
資源記錄過時的問題。按句話說，只要有適當的預防措施，域信息帶來的循環郵寄問題完全
可以避免，也不需要郵寄者查詢權威服務器。（適當的預防措施是再把主機添加進MX列表
前，由主機管理員進行檢查。）
數據不完整的問題在處理域查詢時也需要注意。如果查詢的答復段不完整，可能會漏掉
關鍵的MX資源記錄。這樣可能造成循環郵寄，或者信息給錯誤地貼上無法郵遞的標簽。
因此，郵寄者只能接受那些提供完整答復段的域系統的響應。注意，只要使用虛擬的查詢循
環就可以完全避免這個問題。不過由于這種情況很少發生，而且與域系統交互的首選方式是
數據報，因此應用者可能只需要保證郵寄者使用虛擬循環反復重發查詢，直到獲取被截斷的
數據。
確定消息要發往哪兒

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

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

A.EXAMPLE.ORGINMX10A.EXAMPLE.ORG
A.EXAMPLE.ORGINMX15B.EXAMPLE.ORG
A.EXAMPLE.ORGINMX20C.EXAMPLE.ORG
A.EXAMPLE.ORGINWKS10.0.0.1TCPSMTP

B.EXAMPLE.ORGINMX0B.EXAMPLE.ORG
B.EXAMPLE.ORGINMX10C.EXAMPLE.ORG
B.EXAMPLE.ORGINWKS10.0.0.2TCPSMTP

C.EXAMPLE.ORGINMX0C.EXAMPLE.ORG
C.EXAMPLE.ORGINWKS10.0.0.3TCPSMTP

D.EXAMPLE.ORGINMX0D.EXAMPLE.ORG
D.EXAMPLE.ORGINMX0C.EXAMPLE.ORG
D.EXAMPLE.ORGINWKS10.0.0.4TCPSMTP

在第一個例子中，位于D.EXAMPLE.ORG上的SMTP郵寄者試圖傳遞一個地址標為
A.EXAMPLE.ORG的消息。在查詢結果中，它了解到A.EXAMPLE.ORG有三個MX資源
記錄。D.EXAMPLE.ORG不在這些MX資源記錄中，而且三個MX都支持SMTP郵件（取
決于WKS項），因此沒有排除一個MX。因為A.EXAMPLE.ORG是優先值最低的MX，郵
寄者被迫試圖發送到A.EXAMPLE.ORG。如果無法抵達A.EXAMPLE.ORG，可以（但不是
必須）再試一下B.EXAMPLE.ORG；如果B.EXAMPLE.ORG仍然沒有響應，還可以再試
C.EXAMPLE.ORG。
在第二個例子中，郵寄者位于B.EXAMPLE.ORG上，同樣是要傳送地址標為
A.EXAMPLE.ORG的消息。這一次A.EXAMPLE.ORG也有三個MX資源記錄，不同的是郵
寄者必須摒棄自身的MX資源記錄和C.EXAMPLE.ORG的資源記錄（因為
C.EXAMPLE.ORGMX資源記錄的優先值比B.EXAMPLE.ORG高）。這樣A.EXAMPLE.ORG
只剩下一條資源記錄，只能試著傳遞給A.EXAMPLE.ORG。
在第三個例子中，考慮位于A.EXAMPLE.ORG上的郵寄者要給D.EXAMPLE.ORG傳遞
消息。這種情況下只有兩條MX資源記錄而且優先值相同，每一個MX都可以為
D.EXAMPLE.ORG接收消息。郵寄者可以先試用一個（哪一個取決于郵寄者，不過
D.EXAMPLE.ORG似乎更加合理），如果傳送失敗再試另一個（如C.EXAMPLE.ORG）。