邮件服务器发送邮件时依靠DNS的MX记录，如果一个域名对应多个优先级不同的MX记录，有没人测过邮件服务器发送邮件前查找MX记录时， DNS是一次返回所有MX记录，还是只返回优先级高的记录，失败后邮件服务器发送一条子令让DNS返回下个优先级的记录？
还有就是这个失败的判断标准是什么？是两台邮件服务器通讯物理上可达（仅保证链路是 通的），还是服务成功建立，并通讯成功（邮件发送成功）？
打个比方：A.com域服务器发送邮件到B.com服务器，B.com有多个MX记录 一条mail1.b.com 优先级10; 一条mail2.b.com 优先级20. A.com发送邮件到b.com时，mail.a.com和mail1.b.com建立了会话，但由于某种原因，在发送过程中通讯失败，a.com是重试发往mail1.b.com还是mail2.b.com?
这方面的资料哪里可以查到？
tanyear 回复于：2005-12-30 20:26:47
我觉得是一次返回所有的MX记录，
因为反正是一次DNS查询，返回优先级最高的邮件服务器和返回所有的邮件服务器在开销上没有区别。
而且还可以避免重复查询。
失败的判断标准这个应该是smtp协议的问题，你可以去看看
如果仅仅物理上通，那我一台邮件服务器的邮件服务down了，
机器还活着，岂不是有多少备用的邮件服务器都完了。。。
邮件服务器半死不活的状态，还是要根据smtp协议来看
协议应该规定了哪种情况叫邮件发送成功。哪种情况叫邮件发送失败
比如连接了多少次，没连上。建立了会话，但是通讯失败
这里只有两种状态，要么成功，要么失败。
即使是邮件服务器负载很高，快死的状态。
在失败的情况下就应该发往优先级低一点儿的邮件服务器。
[ 本帖最后由 tanyear 于 2005-12-30 20:28 编辑 ]
cuci 回复于：2005-12-31 00:11:32
先连接优先级高的mx，失败后才去寻找优先级低的
abel 回复于：2005-12-31 15:34:25
mx 記錄是一次返回的,實際狀況樓主只要用 dig/nslookup 就可以知道,
不然如何得知次之或更次之值呢 !
唯一有問題的是像 hotmail (4mx, 每個 mx 4ip , mx 值皆相同) , 這種狀況下到底如何傳送,
有什麼依據我看本版大概也沒有人知道 !
而像 yahoo.com 情況也類似,但它有一個 mx 不同,這種情況下有如何傳送 !?
為什麼他們兩家最大的都只有 16 個 target ? 我想大概也沒有人想過為什麼 ...
只要是連接的 Server 不能連接, MTA 就要改選下一級的 mx,
若是連接的 Server 有回應,並在協議的過程中即使用回的值不是 250
(smtp return code 250視為成功,220為 extentsion訊息 ,4xx,5xx 各有意義...)
連算是連接成功了,即使此時回應 4xx 暫時性的問題(try later,temp fail,rate limits,load average issue...),
都不會改選下一個 mx ,而 5xx 的失敗,更是直接說明失敗,這封發信端就不會
再試了(4xx 會再試)
即使有 N 個不同級別,原理也都像上面那樣 !
所以思考一個狀況就是有人用 iptables 或其他的方法來封 smtp in 時,
此時若對方是一個 MTA , 那根據對方的 MTA retry 定義,它肯定在時限內
會一直 retry, 對雙方恐怕都不是一件好事 !
arone 回复于：2005-12-31 20:10:05
关键是5xx错误是不是在尝试了所有MX记录主机后返回的？还是只尝试优先级最高的，只要开始建立了连接，就不管会话是否成功结束，如果失败就直接回应5xx了？
[ 本帖最后由 arone 于 2005-12-31 20:15 编辑 ]
arone 回复于：2005-12-31 20:21:36
查看了一下日志，一天的日志够大的，好像只和一台服务器建立了连接就返回了5xx，那这个MX记录就只能避免邮件服务不正常，不能避免邮件服务器不健壮了。
abel 回复于：2006-01-02 09:24:10
引用：原帖由 arone 于 2005-12-31 20:10 发表
关键是5xx错误是不是在尝试了所有MX记录主机后返回的？还是只尝试优先级最高的，只要开始建立了连接，就不管会话是否成功结束，如果失败就直接回应5xx了？
您有這個想法代表您對 smtp + mx 的概念還不夠,
mx 嘗試主要由高優先向低優先選擇連接,若不能連接才試次高的,至於有任何帶值的回應,基本上就不會試次之的了
r2007 回复于：2006-01-02 11:53:20
引用：原帖由 abel 于 2005-12-31 15:34 发表
為什麼他們兩家最大的都只有 16 個 target ? 我想大概也沒有人想過為什麼 ...
UDP有512字节的限制，是不是这个原因？
abel 回复于：2006-01-02 12:13:11
引用：原帖由 r2007 于 2006-1-2 11:53 发表
UDP有512字节的限制，是不是这个原因？
這句話有點正確又不大正確,
那一份標準說 udp 有 512 bytes 限制 ?
udp 理論上最大 size 應該是 64K 才對 (65535 - 28)
不過您的答案是很接近了,只是證明在哪 ? 或文件在哪呢 ?
r2007 回复于：2006-01-02 12:30:37
UDP的是不是有512字节的限制，我是外行，没有发言权。我之所以猜测是这个原因，是根据下面的测试
默认的查询
; <<>> DiG 9.2.2 <<>> hotmail.com mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6543
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 19
;; QUESTION SECTION:
;hotmail.com. IN MX
;; ANSWER SECTION:
hotmail.com. 2023 IN MX 5 mx2.hotmail.com.
hotmail.com. 2023 IN MX 5 mx3.hotmail.com.
hotmail.com. 2023 IN MX 5 mx4.hotmail.com.
hotmail.com. 2023 IN MX 5 mx1.hotmail.com.
;; AUTHORITY SECTION:
hotmail.com. 20093 IN NS ns1.msft.net.
hotmail.com. 20093 IN NS ns2.msft.net.
hotmail.com. 20093 IN NS ns3.msft.net.
hotmail.com. 20093 IN NS ns4.msft.net.
hotmail.com. 20093 IN NS ns5.msft.net.
;; ADDITIONAL SECTION:
mx1.hotmail.com. 2023 IN A 64.4.50.50
mx1.hotmail.com. 2023 IN A 65.54.244.8
mx1.hotmail.com. 2023 IN A 65.54.244.136
mx1.hotmail.com. 2023 IN A 65.54.245.8
mx2.hotmail.com. 2023 IN A 65.54.244.40
mx2.hotmail.com. 2023 IN A 65.54.244.168
mx2.hotmail.com. 2023 IN A 65.54.245.40
mx2.hotmail.com. 2023 IN A 65.54.190.50
mx3.hotmail.com. 2023 IN A 64.4.50.179
mx3.hotmail.com. 2023 IN A 65.54.244.72
mx3.hotmail.com. 2023 IN A 65.54.244.200
mx3.hotmail.com. 2023 IN A 65.54.245.72
mx4.hotmail.com. 2023 IN A 65.54.244.104
mx4.hotmail.com. 2023 IN A 65.54.244.232
mx4.hotmail.com. 2023 IN A 65.54.245.104
mx4.hotmail.com. 2023 IN A 65.54.190.179
ns1.msft.net. 60875 IN A 207.46.245.230
ns2.msft.net. 60875 IN A 64.4.25.30
ns3.msft.net. 60875 IN A 213.199.144.151
;; Query time: 57 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 2 11:56:09 2006
;; MSG SIZE rcvd: 511
强制使用TCP协议的查询
; <<>> DiG 9.2.2 <<>> hotmail.com mx +tcp
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18461
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 21
;; QUESTION SECTION:
;hotmail.com. IN MX
;; ANSWER SECTION:
hotmail.com. 1965 IN MX 5 mx3.hotmail.com.
hotmail.com. 1965 IN MX 5 mx4.hotmail.com.
hotmail.com. 1965 IN MX 5 mx1.hotmail.com.
hotmail.com. 1965 IN MX 5 mx2.hotmail.com.
;; AUTHORITY SECTION:
hotmail.com. 20035 IN NS ns2.msft.net.
hotmail.com. 20035 IN NS ns3.msft.net.
hotmail.com. 20035 IN NS ns4.msft.net.
hotmail.com. 20035 IN NS ns5.msft.net.
hotmail.com. 20035 IN NS ns1.msft.net.
;; ADDITIONAL SECTION:
mx1.hotmail.com. 1965 IN A 65.54.244.8
mx1.hotmail.com. 1965 IN A 65.54.244.136
mx1.hotmail.com. 1965 IN A 65.54.245.8
mx1.hotmail.com. 1965 IN A 64.4.50.50
mx2.hotmail.com. 1965 IN A 65.54.190.50
mx2.hotmail.com. 1965 IN A 65.54.244.40
mx2.hotmail.com. 1965 IN A 65.54.244.168
mx2.hotmail.com. 1965 IN A 65.54.245.40
mx3.hotmail.com. 1965 IN A 65.54.245.72
mx3.hotmail.com. 1965 IN A 64.4.50.179
mx3.hotmail.com. 1965 IN A 65.54.244.72
mx3.hotmail.com. 1965 IN A 65.54.244.200
mx4.hotmail.com. 1965 IN A 65.54.190.179
mx4.hotmail.com. 1965 IN A 65.54.244.104
mx4.hotmail.com. 1965 IN A 65.54.244.232
mx4.hotmail.com. 1965 IN A 65.54.245.104
ns1.msft.net. 60817 IN A 207.46.245.230
ns2.msft.net. 60817 IN A 64.4.25.30
ns3.msft.net. 60817 IN A 213.199.144.151
ns4.msft.net. 60817 IN A 207.46.66.75
ns5.msft.net. 60817 IN A 207.46.138.20
;; Query time: 18 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 2 11:57:07 2006
;; MSG SIZE rcvd: 543
从上面看第一次查询，MSG SIZE rcvd: 511，而第二次查询则是MSG SIZE rcvd: 543，从表面现象上看，似乎DNS在使用UDP协议时仅仅用了512字节。
一时找不到UDP的权威资料，但我相信abel的说法是正确的，但为什么dns查询会截取到512呢？这正是导致我错误地判断udp包的大小为512字节的原由。还请明白的人解释一下。
abel 回复于：2006-01-02 13:24:31
引用：原帖由 r2007 于 2006-1-2 12:30 发表
UDP的是不是有512字节的限制，我是外行，没有发言权。我之所以猜测是这个原因，是根据下面的测试
默认的查询
; <<>> DiG 9.2.2 <<>> hotmail.com mx
;; global options: pri ...
r0007 是好學及實踐的人,
在 RFC 1035 中 (和 1034 合稱 DNS 最重要的基礎)
2.3.4. Size limits
Various objects and parameters in the DNS have size limits. They are
listed below. Some could be easily changed, others are more
fundamental.
labels 63 octets or less
names 255 octets or less
TTL positive values of a signed 32 bit number.
UDP messages 512 octets or less
lables 就是 hotmail (lable) , 或 com (lable)
names 就是 hotmail.com
ttl 是cache 時間
udp messages 就是我們兩個討論的問題所在,
這個 udp 512 上限原因即在於此,這是用 dns 做 load balance 不能不注意的地方,
而這個東西在限制在 dns 通常稱為 "basic query" , 因為當年 (你可以看看 RFC 右上角的年份
這個年份我才初一)
並沒有考慮到這麼多,且以當年看 udp 512 巳經算是有一定的 size 了
不過隨著演進,終於證明在 DNS 新的應用上, udp 512 是不夠的,
而為應付 basic query 的不足,所以有了 edns 的提出 (RFC 2671)
不過這是題外話了,感佩 r20007 的經神,特此告知
mx 的選擇問題看來還是沒有人了解或一知半解 ...
[ 本帖最后由 abel 于 2006-1-2 13:26 编辑 ]
r2007 回复于：2006-01-02 14:03:43
长知识了:em02:
加问一句，假如我们进入了ipv6时代，那么这个限制（512）就会显得更加突出了，不知道(RFC 2671)是否能够彻底解决这个问题（刚知道有这个rfc，还没读，所以趁热再问一下），并成为Standard？
关于为何有mx值相同的记录，MTA是如何处理的？
试答一下（不怕笑话，欢迎拍砖）
记忆有点模糊，应该是在postfix文档中看到的，大体是这样描述的：具有相同MX值的记录，MTA任取一个，但要保证有一种机制使这些相同值的MX记录能够轮循使用。或由DNS实现，或由MTA实现。
abel 回复于：2006-01-02 14:21:48
引用：原帖由 r2007 于 2006-1-2 14:03 发表
长知识了:em02:
加问一句，假如我们进入了ipv6时代，那么这个限制（512）就会显得更加突出了，不知道(RFC 2671)是否能够彻底解决这个问题（刚知道有这个rfc，还没读，所以趁热再问一下），并成为Standard？
关于 ...
是的 , ipv6 可能對 DNS payload size 會造成壓力, 至於 edns 是否能完全解決這個問題,在技術面是沒有問題
的,不過好的技術不見得被人使用,所以至於未來實情如何,恐怕只有天知道了,不過可以肯定的是像 dns 的 naptr
記錄 (RFC 2916) 更是龐大,而就 ietf 的 working group 都是建議要使用 edns , 而不使用 dns trancated
狀態
mx 問題您回答的好 ! 做學問就是要到深處去,一理通則萬理通 ! hotmail 皆為同一級別 mx , 所以 mx1-4 中是
ramdom 的,而每次 ramdom 到 mx1(or mx2/3/4) 時,再取四個 IP 中之一,所以輪詢結果為
mx1-1
mx2-1
mx3-1
mx4-1
mx1-2
mx2-2
....
如果其 mx1 若為 5 個 ip , 那 mx1 中任一 IP 要被選到的機率就只有 5% (100/4=25,25/5=5), 而其他
(mx2~mx4, per mx 4ip) 的每部機率則各為 6.25% (100/4=25, 25/4=6.25)
postfix 這樣做, sendmail 也是這樣做的 ! 至於其他的 MTA 就不知了,如果不是這樣做恐怕和
DNS 的概念是稍有不同的 !
[ 本帖最后由 abel 于 2006-1-2 14:24 编辑 ]
tanyear 回复于：2006-01-02 22:48:17
just piont out a spelling mistake.hehe
random?
when the preference value is the equal,The records are given out in round robin order, by default,as abel said
All modern name servers give out resource records in round robin order by default.
"DNS and BIND cookbook"
引用：3.19.3 Discussion
BIND 9 doesn't support true round robin, in which the name server tracks the order in which it gives out the records in an answer. Instead, it randomly chooses a starting point in the list of records and then places the remaining records into the response as though the first record had rotated to the beginning. For example, say www.foo.example had the following three A records:
www.foo.example. IN A 10.0.0.1
IN A 10.0.0.2
IN A 10.0.0.3
A BIND 9 name server might choose the third A record as the starting point, and then would insert the next two A records (10.0.0.3 [u]maybe this is 10.0.0.2,I only copy and paste[/u] and 10.0.0.1) to produce a response in the following order:
www.foo.example. IN A 10.0.0.3
IN A 10.0.0.1
IN A 10.0.0.2
I got a question.from above information,It looks like that not MTA choose the order,
but DNS server make the order,and send it to the MTA
[ 本帖最后由 tanyear 于 2006-1-3 08:19 编辑 ]
r2007 回复于：2006-01-02 23:29:59
这个文档的阐述感觉很有道理，楼上可以参考一下
http://www.barracudanetworks.com/ns/downloads/Barracuda_WP_MX_Load_Balancing.pdf
r2007 回复于：2006-01-02 23:39:20
引用：原帖由 abel 于 2005-12-31 15:34 发表
即使此時回應 4xx 暫時性的問題(try later,temp fail,rate limits,load average issue...),
都不會改選下一個 mx ,而 5xx 的失敗,更是直接說明失敗,這封發信端就不會
再試了(4xx 會再試)
http://www.postfix.org/postconf.5.html
中提到这样两个参数，看来postfix的最新版本已经注意到了这个问题。
引用：smtp_skip_4xx_greeting (default: yes)
Skip SMTP servers that greet with a 4XX status code (go away, try again later).
By default, Postfix moves on the next mail exchanger. Specify "smtp_skip_4xx_greeting = no" if Postfix should defer delivery immediately.
This feature is available in Postfix 2.0 and earlier. Later Postfix versions always skip SMTP servers that greet with a 4XX status code.
smtp_skip_5xx_greeting (default: yes)
Skip SMTP servers that greet with a 5XX status code (go away, do not try again later).
By default, the Postfix SMTP client moves on the next mail exchanger. Specify "smtp_skip_5xx_greeting = no" if Postfix should bounce the mail immediately. The default setting is incorrect, but it is what a lot of people expect to happen.
tanyear 回复于：2006-01-03 08:16:54
引用：原帖由 r2007 于 2006-1-2 23:29 发表
这个文档的阐述感觉很有道理，楼上可以参考一下
http://www.barracudanetworks.com/ns/downloads/Barracuda_WP_MX_Load_Balancing.pdf
the paper is useful!
It seems both DNS server and MTA will choose the order by 'random',if the preference value is equal.the latter is better,because DNS server never consider the load balance(It's not his job).
and It depends on DNS server if there is one domain name with many multiple record.
[ 本帖最后由 tanyear 于 2006-1-3 08:33 编辑 ]
abel 回复于：2006-01-03 13:59:23
r2007 真是棒 !
我個人沒有用過 postfix 的,而只是根據 DNS 的經驗及對 sendmail 的經驗來說明這樣的狀況,
只要懂原理,用什麼 MTA 是無所謂的,與您這樣的人討論是愉快的事情 ~
另外想請教 r2007 兄二個主題外問題:
1. postfix 在 relay 時,若同一封信外寄有 1000 個人, postfix 是如何處理的 ?
2. postfix 在 relay 時,若外寄有 user1@domain1 user2@domain1 user3@domain1 user4@domain2 user5@domain2 , postfix 實寄封是幾封(5個收件人,二個 Domain) ?
arone 回复于：2006-01-03 16:47:49
真是精华。
r2007 回复于：2006-01-03 18:07:24
postfix 在 relay 時,若同一封信外寄有 1000 個人, postfix 是如何處理的 ?
值得探讨的问题，从文档的字面意义上看，postfix的处理过程是这样的：
对一个multiple recipients message,首先把收件人按不同的domain进行分组，如果同一domain的收件人数量超过最大值（具体参数名忘记了，如果此值设为1，那么就成了每一个收件人一组），就按最大值再次划分成若干组。寄信时每组一次会话，也就是每组一个信封，每封信内装相同的message。就知道这么多了。
但是又加问一个：当其中有一个收件人地址无法投递时，接收端会如何回应，发送端会如何处理，sender会得到什么样的反馈消息？postfix如何处理，其它MTA又是如何处理的呢？
BTW:我正在维护的是一个qmail服务器，目前正在考量postfix的功能，准备不久转到postfix，所以没有实际系统进行测试，希望明白的朋友能给个提示或答案。
abel 回复于：2006-01-04 10:10:10
引用：原帖由 r2007 于 2006-1-3 18:07 发表
postfix 在 relay 時,若同一封信外寄有 1000 個人, postfix 是如何處理的 ?
值得探讨的问题，从文档的字面意义上看，postfix的处理过程是这样的：
对一个multiple recipients message,首先把收件人按不同的doma ...
嗯~這樣的處理流程和 sendmail 是相同的, 而在 sendmail 來看,若一個信封中有一個人無法
投送,那發信端就會收到一個退信,若同一個信封中有兩個無法投送,發信端也是收到一個退信,
但如果一封信有 1000 人,而依 100 人分成一封, 那最多可能是 100 個的退信訊息,一般而言,
信只要 RCPT TO 的部份正確,即使100人中有1人無法投送,那其他99人要收還是沒有問題的
postfix/qmail 如何我就不清楚了
r2007 回复于：2006-01-04 10:25:20
引用：原帖由 abel 于 2006-1-4 10:10 发表
嗯~這樣的處理流程和 sendmail 是相同的, 而在 sendmail 來看,若一個信封中有一個人無法
投送,那發信端就會收到一個退信,若同一個信封中有兩個無法投送,發信端也是收到一個退信,
但如果一封信有 1000 人,而依 ...
和abel以及其他朋友的讨论感觉很愉快！
又问：如果一个有100个RCPT TO的message，由于其中的一个或几个地址错误，那么退信中是否提示哪些成功，哪些没有成功呢？如果提示的话，是不是可以借此特性，利用穷举法探查这个domain内的有效账户呢？
abel 回复于：2006-01-04 10:39:03
引用：原帖由 r2007 于 2006-1-4 10:25 发表
和abel以及其他朋友的讨论感觉很愉快！
又问：如果一个有100个RCPT TO的message，由于其中的一个或几个地址错误，那么退信中是否提示哪些成功，哪些没有成功呢？如果提示的话，是不是可以借此特性，利用穷举法 ...
這是有可能的 , 不過這個問題過去曾在本版和其他版友討論過
http://bbs.chinaunix.net/viewthread.php?tid=637627&extra=page%3D1%26filter%3Ddigest
當然,看法有兩種,您可以自己酙酌
就我們過去的經驗,連僅內部自己使用的 aliases 常達 15個字元的都會被 "穷举" 出來,
所以後來做了上面那個 link 我自己用的方法的翻修
思一克 回复于：2006-01-04 11:13:12
这个帖子的讨论很好，我要放到精华区。
skylove 回复于：2006-01-04 15:25:11
引用：原帖由 r2007 于 2006-1-2 14:03 发表
长知识了:em02:
加问一句，假如我们进入了ipv6时代，那么这个限制（512）就会显得更加突出了，不知道(RFC 2671)是否能够彻底解决这个问题（刚知道有这个rfc，还没读，所以趁热再问一下），并成为Standard？
关于 ...
ipv6 由于每个ip地址需要更多的存储空间,因此甚至还无法达到目前的样子.
至于udp对dns查询的限制,在tcp/ip第一卷 协议 的dns章节中说明
我以前看的时候,曾做下以下的笔记说明
世界上目前有13个root server,就是解析.开始的域名的,其中每个root server其实都是由数十个不同的镜象所组成,那么为什么是13个呢?可以不可以是14个,15个呢???那是因为普通的查询是走udp53口出去,而udp有限制每个封包为512bytes,则把包头等其他部分一排除,则大抵只能容纳13个root srever的ip了....如果到了ipv6,则理论上能容纳的root server反而会减少,因为一个ipv6地址占用16bytes
512bytes的来历我也忘记了，但是肯定是从那书上看来的.
以上简单的笔记在 http://skylove.study-area.org/bbs/read.php?tid=46 这里有原文
[ 本帖最后由 skylove 于 2006-1-4 15:54 编辑 ]
skylove 回复于：2006-01-04 16:04:58
刚查阅了一下,在卷一的 p156 ,有提到, 当发起查询请求,并将返回响应中的tc标志(删除标志)的比特设置为1,则如响应长途超过了512字节,就只返回前512byte. 而在次情形下,解析器就使用tcp协议重新朝dns服务器的53口发请求,tcp协议返回的响应允许超过512bytes的.
并且在该书的 119页有提到,ip协议最大长度报文 65535bytes,ip首用20,udp首用8,剩下65507可给udp用.但由于原来各类操作系统彼此互相通信的原因,有可能ip数据报文最大只能用32767.. 而由于规定必须接受最短长度为576bytes的报文,所以很多程序就取的是这个最小值的8的倍数...512bytes...比如dns,tftp,bootp,snmp都有取512bytes 限制...
因此上面的dns 里有了个标志是超过512bytes的裁减掉...
shiqiaoliang 回复于：2006-01-04 23:33:37
在发信件过程中，始终连接高优先级别的MX服务器，如果高优先级别的服务器出问题了。信件会发给次优先级别的服务器，但这个时候信件用户是收不到的。因为次优先级的服务器在尝试连接最高优先级的SMTP服务器，如果最高优先级别的服务器正常了。次优先级别的服务器回把信件传递给它，然后由最高优先级别的服务器发送信件。这意味着你无论有多少台MX服务器，如果最高的那坏了。信件也是无法发送的。其他MX服务器的作用仅仅是保持信件不丢失而已。
思一克 回复于：2006-01-05 08:29:16
引用：原帖由 shiqiaoliang 于 2006-1-4 23:33 发表
在发信件过程中，始终连接高优先级别的MX服务器，如果高优先级别的服务器出问题了。信件会发给次优先级别的服务器，但这个时候信件用户是收不到的。因为次优先级的服务器在尝试连接最高优先级的SMTP服务器，如果最 ...
这个取决于系统的设置。标准无规定。完全可以设置的如果最高级别SERVER DOWN，发到次高级别的信笺也能被用户收到。
w_jia82102 回复于：2006-01-05 18:18:45
mx记录优先级数值小的 优先级好！ 如果优先级高的mx记录忙碌，自动查找其他的mx记录。
abel 回复于：2006-01-05 20:01:33
引用：原帖由 w_jia82102 于 2006-1-5 18:18 发表
mx记录优先级数值小的 优先级好！ 如果优先级高的mx记录忙碌，自动查找其他的mx记录。
"如果优先级高的mx记录忙碌，自动查找其他的mx记录。"
這句話顯然不對,發信端怎知收信端忙碌與否 ?
hrbwag 回复于：2006-01-24 16:44:05
忙碌等价于连接失败.
感觉这个忙碌属于翻译上的误解,忙碌只是连接失败的情况之一.
abel 回复于：2006-01-24 17:24:00
引用：原帖由 hrbwag 于 2006-1-24 16:44 发表
忙碌等价于连接失败.
感觉这个忙碌属于翻译上的误解,忙碌只是连接失败的情况之一.
"忙碌等价于连接失败." 這句話恐怕未必吧 !
connetion timeout 就是連不到,連個 Return Code 都沒有,當然會試下一個 MX,
但是若你巳經連接了,但和你說 "Server Busy" , 那你可還會試下一個 MX ?
更何況 connection timeout 你怎知對方忙碌與否,自己多想想才是最重要的
laowu99 回复于：2006-04-05 16:07:39
引用：原帖由 arone 于 2005-12-31 20:10 发表
关键是5xx错误是不是在尝试了所有MX记录主机后返回的？还是只尝试优先级最高的，只要开始建立了连接，就不管会话是否成功结束，如果失败就直接回应5xx了？
5xx的返回概念为硬反弹，其含义是收件方MTA彻底拒绝接受邮件了。发件方收到这个返回码后，就不再发起SMTP连接了。和MX纪录有几条，没有关系。
werich 回复于：2006-04-17 15:35:40
好贴
|
