有幾種查詢響應被認為出錯：
1．查詢無響應 。郵寄者查詢的域服務器沒有回復（與沒有查詢結(jié)果的回復不同，后
者不是錯誤） 。
2．得到設定了頭部截斷字段的響應 。（回顧一下前面對不完全查詢的討論） 。郵寄者
可能無法使用這樣的回復，應使用虛擬循環(huán)而不是數(shù)據(jù)報反復查詢 。
3．得到響應碼非0的響應 。
郵寄者應該合理地處理錯誤 。這里沒有指明如何處理各種類型的錯誤，但是應用者不同
類型的錯誤可能需要區(qū)別對待 。比如響應碼“域不存在”可能需要把消息視為無效并返回發(fā)
送方，而響應碼“服務器故障”則可能導致稍后重新發(fā)送消息 。
還存在其它的非凡情況 。假如響應結(jié)果是一個CNAME資源記錄，這表明REMOTE實
際上是另外一個域名的別名，需要使用規(guī)范域名重新查詢 。
假如響應不包含錯誤，也沒有別名，答復段（answersection）應該是域名REMOTE（如
果REMOTE是別名就是它的真正的名稱）的（長度可能為0的）MX資源記錄列表 。下一
節(jié)將說明該表的解釋 。
解釋MX資源記錄列表
注重：本節(jié)只討論郵寄者如何從資源記錄列表中選擇傳遞消息的目的名，沒有討論郵寄
者如何真正地執(zhí)行郵遞 。無論何時提及消息傳遞，都意味著郵寄者執(zhí)行必要的操作把消息發(fā)
往一個給定了域名的遠程站點 。（比如，SMTP郵寄者將首先試圖取得域名的地址，其中包
括對域系統(tǒng)進行另外的查詢，然后假如得到了地址，就建立對SMTPTCP端口的連接） 。通
過網(wǎng)絡把消息傳輸?shù)揭粋€與給定域名相關(guān)的地址的具體機制超出了本備忘錄的范圍 。
查詢響應中的MX列表有可能是空表，這是一種非凡情況 。對此，郵寄者應把空表視作包
含一條資源記錄，這條MX資源記錄的優(yōu)先值是0，主機名是REMOTE（就是說REMOTE
也是其自身唯一的MX） 。另外，郵寄者也不需要進一步處理資源記錄表，而應直接把消息
遞送給REMOTE 。這種考慮是為了在域無法提供主機名的任何信息的情況下，我們可以根
據(jù)猜測試著傳遞消息 。
假如表不為空，郵寄者應按照下面的步驟從列表中刪除無關(guān)的資源記錄，注重先后順序
很重要 。
對于每個MX發(fā)送WKS查詢，看看列出的域名是否確實支持需要的郵件服務 。域
名不支持該服務的MX資源記錄應摒棄 。這一步驟不是必需的，但強烈建議執(zhí)行 。
假如域名LOCAL也被列為MX資源記錄，優(yōu)先值大于或等于LOCAL的優(yōu)先值的
所有MX資源記錄必須摒棄 。
去除無關(guān)的資源記錄后列表可能又變空了 。這種情況是發(fā)生了錯誤，可能由幾種原因造
成 。最簡單的情形是WKS查詢發(fā)現(xiàn)列出的主機都不支持需要的郵件服務 。這樣就認為消息
無法傳遞，不過一些非常穩(wěn)妥的郵件系統(tǒng)在返回這個消息前可能會首先試著傳送到
REMOTE的地址（假如存在這樣一個地址） 。另外一種更加危險的可能是域系統(tǒng)認為LOCAL
在處理發(fā)往REMOTE的消息，而LOCAL上的郵寄者并沒有預備處理發(fā)往REMOTE的郵
件 。例如，假如域系統(tǒng)列出的REMOTEMX只有LOCAL一條記錄，LOCAL就會把列表清
空 。但是LOCAL查詢域系統(tǒng)大概是因為它不知道如何處理地址為REMOTE的消息 。顯然
某些地方出了差錯 。郵寄者如何處理此類情況在一定程度上依靠于具體的實現(xiàn)，因此留給應
用者來判定 。
假如MX資源記錄列表不為空，郵寄者將依序（優(yōu)先值低者優(yōu)先）試著把消息發(fā)往每個
MX 。郵寄者被要求盡量傳送給優(yōu)先值最低的MX 。鼓勵應用者編制郵寄者對每個MX依序
推薦閱讀
- IPv4組播路由MIB
- 黑米與血糯米有什么區(qū)別 黑米與血糯米有哪些區(qū)別
- 蒸南瓜蒸多久 蒸南瓜蒸多久能蒸熟
- 朗訊科技與TELEFONICA簽署戰(zhàn)略協(xié)議，支持IPTV業(yè)務
- 組播協(xié)議和組播路由介紹
- 協(xié)調(diào)人與自然關(guān)系,要以什么為引領(lǐng)
- 郵箱如何收發(fā)郵件
- 如何區(qū)分玩忽職守與濫用職權(quán)
- 價值投資與技術(shù)投資有哪些區(qū)別
- 創(chuàng)造與魔法哪里黏土多