for more information.更多频道内容在这里查看
爱奇艺用户将能永久保存播放记录
过滤短视频
暂无长视频（电视剧、纪录片、动漫、综艺、电影）播放记录，
Ta还未创建任何播单～
正在加载中，请稍候...
没有更多内容了~
Copyright (C) 2017
All Rights Reserved[保留] MX记录的优先级问题 - ChinaUnix.net
[保留] MX记录的优先级问题
http://www.chinaunix.net 作者:&&发表于： 22:13:19
邮件服务器发送邮件时依靠DNS的MX记录，如果一个域名对应多个优先级不同的MX记录，有没人测过邮件服务器发送邮件前查找MX记录时，&DNS是一次返回所有MX记录，还是只返回优先级高的记录，失败后邮件服务器发送一条子令让DNS返回下个优先级的记录？
还有就是这个失败的判断标准是什么？是两台邮件服务器通讯物理上可达（仅保证链路是&通的），还是服务成功建立，并通讯成功（邮件发送成功）？
打个比方：A.com域服务器发送邮件到B.com服务器，B.com有多个MX记录&一条&优先级10;&一条&优先级20.&发送邮件到b.com时，和建立了会话，但由于某种原因，在发送过程中通讯失败，a.com是重试发往还是?
这方面的资料哪里可以查到？
& 回复于： 20:26:47
我觉得是一次返回所有的MX记录，
因为反正是一次DNS查询，返回优先级最高的邮件服务器和返回所有的邮件服务器在开销上没有区别。
而且还可以避免重复查询。
失败的判断标准这个应该是smtp协议的问题，你可以去看看
如果仅仅物理上通，那我一台邮件服务器的邮件服务down了，
机器还活着，岂不是有多少备用的邮件服务器都完了。。。
邮件服务器半死不活的状态，还是要根据smtp协议来看
协议应该规定了哪种情况叫邮件发送成功。哪种情况叫邮件发送失败
比如连接了多少次，没连上。建立了会话，但是通讯失败
这里只有两种状态，要么成功，要么失败。
即使是邮件服务器负载很高，快死的状态。
在失败的情况下就应该发往优先级低一点儿的邮件服务器。[&本帖最后由&tanyear&于&&20:28&编辑&]
& 回复于： 00:11:32
先连接优先级高的mx，失败后才去寻找优先级低的
& 回复于： 15:34:25
mx&記錄是一次返回的,實際狀況樓主只要用&dig/nslookup&就可以知道,
不然如何得知次之或更次之值呢&!
唯一有問題的是像&hotmail&(4mx,&每個&mx&4ip&,&mx&值皆相同)&,&這種狀況下到底如何傳送,
有什麼依據我看本版大概也沒有人知道&!
而像&&情況也類似,但它有一個&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,&對雙方恐怕都不是一件好事&!
& 回复于： 20:10:05
关键是5xx错误是不是在尝试了所有MX记录主机后返回的？还是只尝试优先级最高的，只要开始建立了连接，就不管会话是否成功结束，如果失败就直接回应5xx了？[&本帖最后由&arone&于&&20:15&编辑&]
& 回复于： 20:21:36
查看了一下日志，一天的日志够大的，好像只和一台服务器建立了连接就返回了5xx，那这个MX记录就只能避免邮件服务不正常，不能避免邮件服务器不健壮了。
& 回复于： 09:24:10
引用：原帖由&arone&于&&20:10&发表
关键是5xx错误是不是在尝试了所有MX记录主机后返回的？还是只尝试优先级最高的，只要开始建立了连接，就不管会话是否成功结束，如果失败就直接回应5xx了？&
您有這個想法代表您對&smtp&+&mx&的概念還不夠,
mx&嘗試主要由高優先向低優先選擇連接,若不能連接才試次高的,至於有任何帶值的回應,基本上就不會試次之的了
& 回复于： 11:53:20
引用：原帖由&abel&于&&15:34&发表
為什麼他們兩家最大的都只有&16&個&target&?&我想大概也沒有人想過為什麼&...
UDP有512字节的限制，是不是这个原因？
& 回复于： 12:13:11
引用：原帖由&r2007&于&&11:53&发表
UDP有512字节的限制，是不是这个原因？&
這句話有點正確又不大正確,
那一份標準說&udp&有&512&bytes&限制&?
udp&理論上最大&size&應該是&64K&才對&(65535&-&28)
不過您的***是很接近了,只是證明在哪&?&或文件在哪呢&?
& 回复于： 12:30:37
UDP的是不是有512字节的限制，我是外行，没有发言权。我之所以猜测是这个原因，是根据下面的测试
默认的查询
;&&&&&&DiG&9.2.2&&&&&&&mx
;;&global&options:&&printcmd
;;&Got&answer:
;;&-&&HEADER&&-&opcode:&QUERY,&status:&NOERROR,&id:&6543
;;&flags:&qr&rd&&QUERY:&1,&ANSWER:&4,&AUTHORITY:&5,&ADDITIONAL:&19
;;&QUESTION&SECTION:
;.&&&&&&&&&&&&&&&&&&&IN&&&&&&MX
;;&ANSWER&SECTION:
<.&&&&&&&&&&&&2023&&&&IN&&&&&&MX&&&&&&5&.
<.&&&&&&&&&&&&2023&&&&IN&&&&&&MX&&&&&&5&.
<.&&&&&&&&&&&&2023&&&&IN&&&&&&MX&&&&&&5&.
<.&&&&&&&&&&&&2023&&&&IN&&&&&&MX&&&&&&5&.
;;&AUTHORITY&SECTION:
<.&&&&&&&&&&&&20093&&&IN&&&&&&NS&&&&&&ns1.msft.net.
<.&&&&&&&&&&&&20093&&&IN&&&&&&NS&&&&&&ns2.msft.net.
<.&&&&&&&&&&&&20093&&&IN&&&&&&NS&&&&&&ns3.msft.net.
<.&&&&&&&&&&&&20093&&&IN&&&&&&NS&&&&&&ns4.msft.net.
<.&&&&&&&&&&&&20093&&&IN&&&&&&NS&&&&&&ns5.msft.net.
;;&ADDITIONAL&SECTION:
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&64.4.50.50
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.244.8
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.244.136
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.245.8
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.244.40
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.244.168
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.245.40
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.190.50
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&64.4.50.179
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.244.72
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.244.200
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.245.72
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.244.104
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.244.232
.&&&&&&&&2023&&&&IN&&&&&&A&&&&&&&65.54.245.104
.&&&&&&&&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&&&&&&&mx&+tcp
;;&global&options:&&printcmd
;;&Got&answer:
;;&-&&HEADER&&-&opcode:&QUERY,&status:&NOERROR,&id:&18461
;;&flags:&qr&rd&&QUERY:&1,&ANSWER:&4,&AUTHORITY:&5,&ADDITIONAL:&21
;;&QUESTION&SECTION:
;.&&&&&&&&&&&&&&&&&&&IN&&&&&&MX
;;&ANSWER&SECTION:
<.&&&&&&&&&&&&1965&&&&IN&&&&&&MX&&&&&&5&.
<.&&&&&&&&&&&&1965&&&&IN&&&&&&MX&&&&&&5&.
<.&&&&&&&&&&&&1965&&&&IN&&&&&&MX&&&&&&5&.
<.&&&&&&&&&&&&1965&&&&IN&&&&&&MX&&&&&&5&.
;;&AUTHORITY&SECTION:
<.&&&&&&&&&&&&20035&&&IN&&&&&&NS&&&&&&ns2.msft.net.
<.&&&&&&&&&&&&20035&&&IN&&&&&&NS&&&&&&ns3.msft.net.
<.&&&&&&&&&&&&20035&&&IN&&&&&&NS&&&&&&ns4.msft.net.
<.&&&&&&&&&&&&20035&&&IN&&&&&&NS&&&&&&ns5.msft.net.
<.&&&&&&&&&&&&20035&&&IN&&&&&&NS&&&&&&ns1.msft.net.
;;&ADDITIONAL&SECTION:
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.244.8
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.244.136
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.245.8
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&64.4.50.50
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.190.50
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.244.40
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.244.168
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.245.40
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.245.72
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&64.4.50.179
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.244.72
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.244.200
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.190.179
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.244.104
.&&&&&&&&1965&&&&IN&&&&&&A&&&&&&&65.54.244.232
.&&&&&&&&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字节的原由。还请明白的人解释一下。
& 回复于： 13:24:31
引用：原帖由&r2007&于&&12:30&发表
UDP的是不是有512字节的限制，我是外行，没有发言权。我之所以猜测是这个原因，是根据下面的测试
默认的查询
;&&&&&&DiG&9.2.2&&&&&&&mx
;;&global&options:&&pri&...&
r0007&是好學及實踐的人,
在&RFC&1035&中&(和&1034&合稱&DNS&最重要的基礎)
2.3.4.&Size&limits
Various&objects&and¶meters&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&就是&
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&于&&13:26&编辑&]
& 回复于： 14:03:43
长知识了:em02:
加问一句，假如我们进入了ipv6时代，那么这个限制（512）就会显得更加突出了，不知道(RFC&2671)是否能够彻底解决这个问题（刚知道有这个rfc，还没读，所以趁热再问一下），并成为Standard？
关于为何有mx值相同的记录，MTA是如何处理的？
试答一下（不怕笑话，欢迎拍砖）
记忆有点模糊，应该是在postfix文档中看到的，大体是这样描述的：具有相同MX值的记录，MTA任取一个，但要保证有一种机制使这些相同值的MX记录能够轮循使用。或由DNS实现，或由MTA实现。
& 回复于： 14:21:48
引用：原帖由&r2007&于&&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&于&&14:24&编辑&]
& 回复于： 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©&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¬&MTA&choose&the&order,
but&DNS&server&make&the&order,and&send&it&to&the&MTA[&本帖最后由&tanyear&于&&08:19&编辑&]
& 回复于： 23:29:59
这个文档的阐述感觉很有道理，楼上可以参考一下
/ns/downloads/Barracuda_WP_MX_Load_Balancing.pdf
& 回复于： 23:39:20
引用：原帖由&abel&于&&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¬&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.
& 回复于： 08:16:54
引用：原帖由&r2007&于&&23:29&发表
这个文档的阐述感觉很有道理，楼上可以参考一下
/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¬&his&job).
and&It&depends&on&DNS&server&if&there&is&one&domain&name&with&many&multiple&&record.[&本帖最后由&tanyear&于&&08:33&编辑&]
& 回复于： 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)&?
& 回复于： 16:47:49
真是精华。
& 回复于： 18:07:24
postfix&在&relay&時,若同一封信外寄有&1000&個人,&postfix&是如何處理的&?
值得探讨的问题，从文档的字面意义上看，postfix的处理过程是这样的：
对一个multiple&recipients&message,首先把收件人按不同的domain进行分组，如果同一domain的收件人数量超过最大值（具体参数名忘记了，如果此值设为1，那么就成了每一个收件人一组），就按最大值再次划分成若干组。寄信时每组一次会话，也就是每组一个信封，每封信内装相同的message。就知道这么多了。
但是又加问一个：当其中有一个收件人地址无法投递时，接收端会如何回应，发送端会如何处理，sender会得到什么样的反馈消息？postfix如何处理，其它MTA又是如何处理的呢？
BTW:我正在维护的是一个qmail服务器，目前正在考量postfix的功能，准备不久转到postfix，所以没有实际系统进行测试，希望明白的朋友能给个提示或***。
& 回复于： 10:10:10
引用：原帖由&r2007&于&&18:07&发表
postfix&在&relay&時,若同一封信外寄有&1000&個人,&postfix&是如何處理的&?
值得探讨的问题，从文档的字面意义上看，postfix的处理过程是这样的：
对一个multiple&recipients&message,首先把收件人按不同的doma&...&
嗯~這樣的處理流程和&sendmail&是相同的,&而在&sendmail&來看,若一個信封中有一個人無法
投送,那發信端就會收到一個退信,若同一個信封中有兩個無法投送,發信端也是收到一個退信,
但如果一封信有&1000&人,而依&100&人分成一封,&那最多可能是&100&個的退信訊息,一般而言,
信只要&RCPT&TO&的部份正確,即使100人中有1人無法投送,那其他99人要收還是沒有問題的
postfix/qmail&如何我就不清楚了
& 回复于： 10:25:20
引用：原帖由&abel&于&&10:10&发表
嗯~這樣的處理流程和&sendmail&是相同的,&而在&sendmail&來看,若一個信封中有一個人無法
投送,那發信端就會收到一個退信,若同一個信封中有兩個無法投送,發信端也是收到一個退信,
但如果一封信有&1000&人,而依&...&
和abel以及其他朋友的讨论感觉很愉快！
又问：如果一个有100个RCPT&TO的message，由于其中的一个或几个地址错误，那么退信中是否提示哪些成功，哪些没有成功呢？如果提示的话，是不是可以借此特性，利用穷举法探查这个domain内的有效账户呢？
& 回复于： 10:39:03
引用：原帖由&r2007&于&&10:25&发表
和abel以及其他朋友的讨论感觉很愉快！
又问：如果一个有100个RCPT&TO的message，由于其中的一个或几个地址错误，那么退信中是否提示哪些成功，哪些没有成功呢？如果提示的话，是不是可以借此特性，利用穷举法&...&
這是有可能的&,&不過這個問題過去曾在本版和其他版友討論過
http://bbs.chinaunix.net/viewthread.php?tid=637627&extra=page%3D1%26filter%3Ddigest
當然,看法有兩種,您可以自己酙酌&
就我們過去的經驗,連僅內部自己使用的&aliases&常達&15個字元的都會被&"穷举"&出來,
所以後來做了上面那個&link&我自己用的方法的翻修
& 回复于： 11:13:12
这个帖子的讨论很好，我要放到精华区。
& 回复于： 15:25:11
引用：原帖由&r2007&于&&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&于&&15:54&编辑&]
& 回复于： 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的裁减掉...
& 回复于： 23:33:37
在发信件过程中，始终连接高优先级别的MX服务器，如果高优先级别的服务器出问题了。信件会发给次优先级别的服务器，但这个时候信件用户是收不到的。因为次优先级的服务器在尝试连接最高优先级的SMTP服务器，如果最高优先级别的服务器正常了。次优先级别的服务器回把信件传递给它，然后由最高优先级别的服务器发送信件。这意味着你无论有多少台MX服务器，如果最高的那坏了。信件也是无法发送的。其他MX服务器的作用仅仅是保持信件不丢失而已。
& 回复于： 08:29:16
引用：原帖由&shiqiaoliang&于&&23:33&发表
在发信件过程中，始终连接高优先级别的MX服务器，如果高优先级别的服务器出问题了。信件会发给次优先级别的服务器，但这个时候信件用户是收不到的。因为次优先级的服务器在尝试连接最高优先级的SMTP服务器，如果最&...&
这个取决于系统的设置。标准无规定。完全可以设置的如果最高级别SERVER&DOWN，发到次高级别的信笺也能被用户收到。
& 回复于： 18:18:45
mx记录优先级数值小的&优先级好！&如果优先级高的mx记录忙碌，自动查找其他的mx记录。
& 回复于： 20:01:33
引用：原帖由&w_jia82102&于&&18:18&发表
mx记录优先级数值小的&优先级好！&如果优先级高的mx记录忙碌，自动查找其他的mx记录。&
"如果优先级高的mx记录忙碌，自动查找其他的mx记录。"
這句話顯然不對,發信端怎知收信端忙碌與否&?
& 回复于： 16:44:05
忙碌等价于连接失败.
感觉这个忙碌属于翻译上的误解,忙碌只是连接失败的情况之一.
& 回复于： 17:24:00
引用：原帖由&hrbwag&于&&16:44&发表
忙碌等价于连接失败.
感觉这个忙碌属于翻译上的误解,忙碌只是连接失败的情况之一.&
"忙碌等价于连接失败."&這句話恐怕未必吧&!
connetion&timeout&就是連不到,連個&Return&Code&都沒有,當然會試下一個&MX,
但是若你巳經連接了,但和你說&"Server&Busy"&,&那你可還會試下一個&MX&&?
更何況&connection&timeout&你怎知對方忙碌與否,自己多想想才是最重要的
& 回复于： 16:07:39
引用：原帖由&arone&于&&20:10&发表
关键是5xx错误是不是在尝试了所有MX记录主机后返回的？还是只尝试优先级最高的，只要开始建立了连接，就不管会话是否成功结束，如果失败就直接回应5xx了？&
5xx的返回概念为硬反弹，其含义是收件方MTA彻底拒绝接受邮件了。发件方收到这个返回码后，就不再发起SMTP连接了。和MX纪录有几条，没有关系。
& 回复于： 15:35:40
& 回复于： 23:16:29
& 回复于： 16:20:52
不错的帖子
& 回复于： 16:37:27
ding&学习啊
& 回复于： 17:18:54
这是个经典的讨论
我都看过好几遍了
确实非常好
& 回复于： 17:19:41
其实邮件系统的讨论
更多的应该在反垃圾邮件这块
& 回复于： 22:13:19
仔细看了一下
这个MX优先级的问题正是我疑惑的地方，不过看了一遍还是没有得出一个明确的结论，准备再好好看看，再去翻翻书&:mrgreen:
原文链接：
转载请注明作者名及原文出处
