來源: 網中人 
時間: 2001年 6月 2日 周六 17時16分02秒 CST
標題: Re: 我們MIS和seednet互踢皮球 
論壇: tw.bbs.comp.network 


吹笛牧童  wrote in message
news:3gb0D0$L04@bbs.ntu.edu.tw...
> ==> Song.bbs@bbs.cynix.com.tw (Song) 提到:
> > ※ 引述《HuangJC.bbs@bbs.ntu.edu.tw (吹笛牧童)》之銘言:
> > > 你用什麼身份及立場和我說話!
> >     那麼請問,您又是用什麼身份,什麼立場在這裡說話 ??
> [全文刪]
>
> 關於這篇POST,我嘗試以私人信件回覆你
> 不過信件無法寄出
>
> 我不認為寫給你的信件應該出現在公開版面上,所以就此打住
> 至於你所有的回覆,我只能說:"如果讓你看了不舒服,對不起"
>

不知道閣下有什麼‘讓人看了不舒服’的話﹐在下不關心這個。只想大家從技術
層面去探討問題所在。

在閣下前面丟出來的退信﹐其中說得很明白﹕

Your message was rejected by mx.seed.net.tw for the following reason:
     rejected: cannot route to sender 

也就是說﹐拒絕的原因是 no route to sender﹐這裡的 route 通常是指 mail route
而非通常我們說的 ip route。那請您用 nslookup 或其它 DNS 工具來查查關於
machvision.com.tw 的 MX 記錄是怎麼的﹕

****************************
> server 139.175.10.20
Default Server:  ksdns.seed.net.tw
Address:  139.175.10.20
﹔先轉用 seednet 的 DNS 來進修查詢﹐因為收信主機也是 seednet﹐相信它們
使用的 DNS 記錄會比較接近。

> set q=mx
﹔然後將查詢類型設為 mx﹐也就是查 mail route 啦。

> machvision.com.tw
Server:  ksdns.seed.net.tw
Address:  139.175.10.20

Non-authoritative answer:
machvision.com.tw       preference = 10, mail exchanger =
sdns.machvision.com.tw
﹔不錯﹐我們可以查到郵件應該 route 到 sdns.machvision.com.tw 上面去。

Authoritative answers can be found from:
machvision.com.tw       nameserver = www.machvision.com.tw
machvision.com.tw       nameserver = machvision.com.tw
machvision.com.tw       nameserver = web.office.machvision.com.tw
sdns.machvision.com.tw  internet address = 211.21.176.34
www.machvision.com.tw   internet address = 211.21.176.34
machvision.com.tw       internet address = 211.21.176.34
web.office.machvision.com.tw    internet address = 211.21.176.35

> sdns.machvision.com.tw
; 那我們查查上個 mx 得到的主機﹐關於它自己的 mail route 到哪裡去吧﹖

Server:  ksdns.seed.net.tw
Address:  139.175.10.20

Authoritative answers can be found from:
machvision.com.tw
        origin = sdns.machvision.com.tw
        mail addr = administrator.machvision.com.tw
        serial = 583
        refresh = 900 (15M)
        retry   = 600 (10M)
        expire  = 86400 (1D)
        minimum ttl = 3600 (1H)
>
﹔什麼﹖﹗居然沒有﹖﹗誰設的啊﹖要不要考慮換人﹖

> server 211.21.176.34
﹔那... 我們就乾脆轉討該主機查查吧。

Default Server:  sdns.machvision.com.tw
Address:  211.21.176.34
﹔還好﹐有 ns 服務﹐雖然負責 machivsion.com.tw 這個 zone 的 ns 好像沒
包括 sdns﹐儘管 IP 一樣。

> sdns.machvision.com.tw
Server:  sdns.machvision.com.tw
Address:  211.21.176.34

machvision.com.tw
        origin = sdns.machvision.com.tw
        mail addr = administrator.machvision.com.tw
        serial = 583
        refresh = 900 (15M)
        retry   = 600 (10M)
        expire  = 86400 (1D)
        minimum ttl = 3600 (1H)
﹔幹﹗居然連它自己也沒有﹗(抱歉﹐認不住罵了一句髒話~~~)

****************************

看來﹐seednet 的 mail server 設定真夠規範﹐查不到 mail route 就擋﹗好樣的﹐如果
大家都這樣嚴格﹐相信網路上的白爛一早就怕怕了。而那些沒這麼嚴格的主機
呢﹐查不到 maio route 算了﹐反正能 resolve to sender 就好。只是﹐鬆了點的結果是﹐
讓一堆白爛胡亂設自己的 DNS。這能怪誰呢﹖還好﹐閣下的退信說得很明白﹕

Please reply to Postmaster@sdns.machvision.com.tw
if you feel this message to be in error.


所以﹐前面那位 song 兄好心叫你去學英文﹐居然回人家一些“讓人看了不舒服
”的話﹐請問閣下﹐有認真看 song 兄的最後一句嗎﹕
“問的客氣點,學學基本禮貌再來吧。”

p.s. 弟的信箱是 netman@study-area.net ﹐可以隨時來信指教﹗如果“ 讓人
看了不舒服”﹐那就免了﹐自己慢慢看吧。


-----------


來源: 薩米亞咚 
時間: 2001年 6月 5日 周二 13時49分19秒 CST
標題: Re: 我們MIS和seednet互踢皮球 
論壇: tw.bbs.comp.network 

==> 在 " 網中人"  的文章中提到:

> ; 那我們查查上個 mx 得到的主機﹐關於它自己的 mail route 到哪裡去吧﹖
> Server:  ksdns.seed.net.tw
> Address:  139.175.10.20
> Authoritative answers can be found from:
> machvision.com.tw
>         origin = sdns.machvision.com.tw
>         mail addr = administrator.machvision.com.tw
>         serial = 583
>         refresh = 900 (15M)
>         retry   = 600 (10M)
>         expire  = 86400 (1D)
>         minimum ttl = 3600 (1H)
> ﹔什麼﹖﹗居然沒有﹖﹗誰設的啊﹖要不要考慮換人﹖

這裡的觀念是錯的 , @machvision.com.tw 的MX為 sdns.machvision.com.tw
而sdns.machvision.com.tw 有A Record就夠了 , 不需要再有屬於
sdns.machvision.com.tw 的MX設定

 
--------


來源: 網中人 
時間: 2001年 6月 6日 周三 00時05分07秒 CST
標題: Re: 我們MIS和seednet互踢皮球 
論壇: tw.bbs.comp.network 


薩米亞咚  wrote in message
news:3gdI4W$VLl@bbs.cis.nctu.edu.tw...
> ==> 在 " 網中人"  的文章中提到:
> > ****************************
> > ; 那我們查查上個 mx 得到的主機﹐關於它自己的 mail route 到哪裡去吧
﹖
> > Server:  ksdns.seed.net.tw
> > Address:  139.175.10.20
> > Authoritative answers can be found from:
> > machvision.com.tw
> >         origin = sdns.machvision.com.tw
> >         mail addr = administrator.machvision.com.tw
> >         serial = 583
> >         refresh = 900 (15M)
> >         retry   = 600 (10M)
> >         expire  = 86400 (1D)
> >         minimum ttl = 3600 (1H)
> > ﹔什麼﹖﹗居然沒有﹖﹗誰設的啊﹖要不要考慮換人﹖
>
> 這裡的觀念是錯的 , @machvision.com.tw 的MX為 sdns.machvision.com.tw
> 而sdns.machvision.com.tw 有A Record就夠了 , 不需要再有屬於
> sdns.machvision.com.tw 的MX設定
>


唉~~~ 看到這裡﹐我只能嘆息﹗

沒錯﹐不設 MX 記錄也可以完成郵件傳遞﹐但有許多錯誤和浪費﹐就是斷送在這
種‘懶惰’之上﹐請自己翻書﹕

Sendmail﹐2nd Edition Revised & Updated, O'Reilly,
By Bryan Costales with Eric Allman,

Chapter 21: DNS and sendmail

********************************************************
21.3.6 Caching MX Records

Althoug you are not required to have MX records for all hosts, there is
good reason to consider doing so. To illustrate, consider the following
host that only has an A record:

    hostB    IN    A 123.45.67.8

When sendmail first looks up this host, it asks the local name server for
all records. Because there is only an A record, that is all it gets.

But note that asking for all records caused the lcoal name server to cache
the information. The next time sendmail looks up this same host, the lcoal
name server will return the A record from its cache. This is faster and
reduces Internet traffic. The cached information is "nonauthoritavie"
(because it is a copy) and includes no MX records (because there are none).

When sendmail gets a nonauthoritative reply that lacks MX records, it si
forced to do another DNS lookup. This time, it specificall asks for MX
records. In this case there are none, so it gets none.

Because hostB lacks an MX record, sendmail performs a DNS lookup each and
every time mails is sent to that host. If hostB were a major
mail-receriving site, its lack of an MX record would be causing many
sendmail programs, all over the world, to wast network bandwidth with
otherwise useless DNS lookups.

We strongly recommend taht every host on the Internet have at lest one MX
record. As a minimum, it can simply point to itself with a 0 cost (註一):

    hostB    IN    A    123.45.67.8
            IN    MX    0 hostB

This will not change how mail is routed to hostB but will reduce the number
of DNS lookups required.


註一﹕有次我幫一位仁兄設定 bind 9.x 的時候﹐發現用 0 做 preference 竟然有錯
誤﹐後來只好確定這個值為最小就是了。不知道設定過 bind 9.x 的朋友有沒遇
到同樣的事情呢﹖

********************************************************


好了﹐回到正題。為了不誤導讀者﹐我得承認只查 MX 而不查 A 是不對的﹐而且問題
是否真的由此引起﹐還有待更進一步的查詢。因為上次有點趕﹐而且在替 Song 兄不
值中﹐做得沒有很仔細。為此﹐還要向關心這個 treat 的讀者們道歉﹗

如果大家對郵件傳遞的一些問題不是清楚﹐可以用 nslookup﹐dig 等查詢程式協助﹐
不要光在上面亂喊亂罵。有興趣的﹐何不乾脆利用一下目前的這個‘上佳實例’來幫
助我們理清一下概念呢﹖

我想﹐目前這個 treat﹐爭論的重點似乎不在如何找出問題所在﹐反而是彼此的討論
態度而已﹐不是嗎﹖真正有心幫助別人的﹐請拿出誠意來﹗


下面是我剛纔再做一次查詢的結果﹐這次換成 dig 好了﹐希望對大家有點幫助﹕


===> 還是先用 seednet 的 DNS 查查﹐

 dig @139.175.10.20 machvision.com.tw mx IN

; <<>> DiG 8.3 <<>> @139.175.10.20 machvision.com.tw mx IN
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 4
;; QUERY SECTION:
;;      machvision.com.tw, type = MX, class = IN

;; ANSWER SECTION:
machvision.com.tw.      7m52s IN MX     10 sdns.machvision.com.tw.
machvision.com.tw.      7m52s IN MX     10 .

===> 請留意上兩句﹐竟然有兩個 MX 的 preference 是相同的﹐而且最後一個卻只有
一個 “.”﹐不知道 sendmail 會如何判斷要用哪個呢﹖可以請大家發揮一下
research 的能力嗎﹖(答案在最後面)

;; AUTHORITY SECTION:
machvision.com.tw.      19h47m31s IN NS  www.machvision.com.tw.
machvision.com.tw.      19h47m31s IN NS  machvision.com.tw.
machvision.com.tw.      19h47m31s IN NS  web.office.machvision.com.tw.

;; ADDITIONAL SECTION:
sdns.machvision.com.tw.  7m16s IN A  211.21.176.34
www.machvision.com.tw.  23h7m52s IN A   211.21.176.34
machvision.com.tw.      18h48m7s IN A   211.21.176.34
web.office.machvision.com.tw.  23h7m52s IN A  211.21.176.35

;; Total query time: 13 msec
;; FROM: chem86.twbbs.org to SERVER: 139.175.10.20
;; WHEN: Tue Jun  5 23:45:07 2001
;; MSG SIZE  sent: 35  rcvd: 192


===> 剛纔是用 seednet 的 DNS 來查﹐或許有人懷疑 seednet 可能故意搞鬼﹐那
好﹐我們換 hinet 的來查好了﹕

dig @168.95.1.1 machvision.com.tw mx IN

; <<>> DiG 8.3 <<>> @168.95.1.1 machvision.com.tw mx IN
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;;      machvision.com.tw, type = MX, class = IN

;; ANSWER SECTION:
machvision.com.tw.      1H IN MX        10 sdns.machvision.com.tw.
machvision.com.tw.      1H IN MX        10 .

===> 唉﹐竟然然 hinet 的也一樣﹗

;; ADDITIONAL SECTION:
sdns.machvision.com.tw.  1H IN A  211.21.176.34

;; Total query time: 80 msec
;; FROM: chem86.twbbs.org to SERVER: 168.95.1.1
;; WHEN: Tue Jun  5 23:45:51 2001
;; MSG SIZE  sent: 35  rcvd: 87


===> 這時候﹐或許還有人懷疑﹕他們都是 ISP﹐相互串通的﹗
那好﹐我們換成 A.ROOT-SERVERS.TW. 應該沒錯了吧﹖
twnic 要修改的東西都會在這上面呢~~

dig @140.111.1.2 machvision.com.tw mx IN

; <<>> DiG 8.3 <<>> @140.111.1.2 machvision.com.tw mx IN
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;;      machvision.com.tw, type = MX, class = IN

;; AUTHORITY SECTION:
machvision.com.tw.      1D IN NS        www.machvision.com.tw.
machvision.com.tw.      1D IN NS        machvision.com.tw.
machvision.com.tw.      1D IN NS        web.office.machvision.com.tw.


===> 哇咧~~﹗ 居然查不到﹖嘿﹐不是有人懷疑我故意刪除掉的吧﹖不信自己去
查好了~~

X.ROOT-SERVERS.TW. 的 DNS 一共有如下這些﹕
168.95.192.10
163.28.1.2
140.111.1.2
192.72.81.200
(可以用這個命令得到﹕dig @168.95.1.1 com.tw NS IN)


;; ADDITIONAL SECTION:
www.machvision.com.tw.  1D IN A         211.21.176.34
machvision.com.tw.      1D IN A         211.21.176.34
web.office.machvision.com.tw.  1D IN A  211.21.176.35

;; Total query time: 15 msec
;; FROM: chem86.twbbs.org to SERVER: 140.111.1.2
;; WHEN: Tue Jun  5 23:47:10 2001
;; MSG SIZE  sent: 35  rcvd: 140


===> 既然大家查到的 NS 結果都指向下面這兩台﹐那我們分別到上面查查好了﹕

dig @211.21.176.35 machvision.com.tw mx IN

; <<>> DiG 8.3 <<>> @211.21.176.35 machvision.com.tw mx IN
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;;      machvision.com.tw, type = MX, class = IN

;; ANSWER SECTION:
machvision.com.tw.      1H IN MX        10 sdns.machvision.com.tw.
machvision.com.tw.      1H IN MX        10 .

===> 結果還是一樣(其實是可以預料的)。

;; ADDITIONAL SECTION:
sdns.machvision.com.tw.  1H IN A  211.21.176.34

;; Total query time: 71 msec
;; FROM: chem86.twbbs.org to SERVER: 211.21.176.35
;; WHEN: Tue Jun  5 23:49:44 2001
;; MSG SIZE  sent: 35  rcvd: 87


===> 查它自己吧﹐最後一台了﹕

dig @211.21.176.34 machvision.com.tw mx IN

; <<>> DiG 8.3 <<>> @211.21.176.34 machvision.com.tw mx IN
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;;      machvision.com.tw, type = MX, class = IN

;; ANSWER SECTION:
machvision.com.tw.      1H IN MX        10 sdns.machvision.com.tw.
machvision.com.tw.      1H IN MX        10 .

===> 唉﹐那也沒法子囉~~~ :(

;; ADDITIONAL SECTION:
sdns.machvision.com.tw.  1H IN A  211.21.176.34

;; Total query time: 71 msec
;; FROM: chem86.twbbs.org to SERVER: 211.21.176.34
;; WHEN: Tue Jun  5 23:50:29 2001
;; MSG SIZE  sent: 35  rcvd: 87


好了﹐答案時間﹕

又是 O'Reilly 的那本 Sendmail ﹐(盡信書不如無書﹖)
第 316 頁﹕

Another reason sendmail refuse to follow MX records beyond the target host
is that costs in such a situation are undefined.



--------


來源: 口試過關的CAEer 
時間: 2001年 6月 6日 周三 12時47分45秒 CST
標題: Re: 我們MIS和seednet互踢皮球 
論壇: tw.bbs.comp.network 


※ 引述《Song.bbs@bbs.cynix.com.tw》之銘言:
: ※ 引述《netman@junk.com ( 網中人)》之銘言:
: > 唉~~~ 看到這裡﹐我只能嘆息﹗
: > 沒錯﹐不設 MX 記錄也可以完成郵件傳遞﹐但有許多錯誤和浪費﹐就是斷送
: > 在這種‘懶惰’之上﹐請自己翻書﹕
: > 註一﹕有次我幫一位仁兄設定 bind 9.x 的時候﹐發現用 0 做 preference 
: > 竟然有錯誤﹐後來只好確定這個值為最小就是了。不知道設定過 bind 9.x 的朋友有
: > 沒遇到同樣的事情呢﹖
: > ********************************************************
: > 好了﹐回到正題。為了不誤導讀者﹐我得承認只查 MX 而不查 A 是不對的
: > ﹐而且問題是否真的由此引起﹐還有待更進一步的查詢。因為上次有點趕﹐而且在替 Song 
: > 兄不值中﹐做得沒有很仔細。為此﹐還要向關心這個 treat 的讀者們道歉﹗
:     Netman 兄,小弟很感謝您的仗義執言。 :)
:     這裡應該也沒誤導觀眾吧?
:     寄信的話,目的端的主機只有 A 沒有 MX 的確是可以寄到,
:     但發信端的主機只有 A 沒有 MX ,目的端的主機收不收就值得商榷了。
:     以 sendmail 來說,如果目的端的主機設定 bestmx_is_local 的話,
:     這種發信端只有 A 沒有 MX 的主機,應該是都會被 reject 了吧?
:     所以,小弟認為您並沒有誤導觀眾,
:           而是被誤導以為誤導了觀眾了。 (繞口令 :P)
:     至於 seednet 是不是用 sendmail,
:     有沒有設定 bestmx_is_local ,或是只是 unresolvable_domains,
:     小弟是沒去確認 ... :P ( 這點熱心與您差太遠了 :P)
:     或許我們看到的反解也都是後來補上的,
:     說不定其反解補上後就正常了。(unresolvable_domains)
:     小弟真的太崇拜您了。 :)
: > 好了﹐答案時間﹕
: > 又是 O'Reilly 的那本 Sendmail ﹐(盡信書不如無書﹖)
: > 第 316 頁﹕
: > Another reason sendmail refuse to follow MX records beyond the target host
: > is that costs in such a situation are undefined.

"目的端的主機只有 A 沒有 MX 的確是可以寄到" 這定義在 RFC 974 裡面,
沒有 MX 的則把 A 當成唯一的 MX.

"發信端的主機只有 A 沒有 MX ,目的端的主機收不收就值得商榷", 這部分 RFC 裡面
沒有定義(如果有的話請跟我說一聲...), 看各家 MTA 怎麼實作.

Sendmail 之前某一版 (好像是 8.9 或 8.10) 會擋下 "只有 MX 沒有 A" 的發信人的信,
像是 @csie.ntu.edu.tw 這個樣子的信件, 但我從來沒有遇到過擋下 "只有 A 沒有 MX"
的發信人的信. 而且在新的版本 (8.11) 當中, 已經可以收下 "只有 MX 沒有 A" 的
發信人的信件了.

剛剛我測了一下, 我用 leeym@utopia.leeym.com (所謂的 "只有 A 沒有 MX") 當發信人
寄給自己的另一個信箱, 收發信件兩端都跑 sendmail, 送信過程沒有問題. 當然, 也許
多一個 DNS query, 但是不會退信.

machvision.com.tw 的 DNS 設定的亂七八糟, 對於送信的流程上來說一定會有負面影響,
但是單就這個例子而言, "發信端只有 A 沒有 MX 的主機,應該是都會被 reject",
這可不是定則, 況且這個例子中收信端和送信端兩邊跑的 MTA 都不是 Sendmail,
這個部分得看 MTA 的設定才對.

我也替 Song 兄抱不平, 也覺得這位 HuangJC 程度差態度更差,
但是說明的理論和例子不是很完整, 在此補充說明一下..

 
-----------



來源: 口試過關的CAEer 
時間: 2001年 6月 6日 周三 13時21分59秒 CST
標題: Re: 我們MIS和seednet互踢皮球 
論壇: tw.bbs.comp.network 


※ 引述《netman@junk.com》之銘言:
: 薩米亞咚  wrote in message
: news:3gdI4W$VLl@bbs.cis.nctu.edu.tw...
: > 這裡的觀念是錯的 , @machvision.com.tw 的MX為 sdns.machvision.com.tw
: > 而sdns.machvision.com.tw 有A Record就夠了 , 不需要再有屬於
: > sdns.machvision.com.tw 的MX設定
: 唉~~~ 看到這裡﹐我只能嘆息﹗
: 沒錯﹐不設 MX 記錄也可以完成郵件傳遞﹐但有許多錯誤和浪費﹐就是斷送在這種
: ‘懶惰’之上﹐請自己翻書﹕
: Sendmail﹐2nd Edition Revised & Updated, O'Reilly,
: By Bryan Costales with Eric Allman,
: Chapter 21: DNS and sendmail
[deleted]

基本上, 觀念真的有問題.

不設定 MX 的確會拖慢送信流程, 但是在這個例子中您拿來說明的文獻和理論並不正確,
收信端收到一封發信人為 @machvision.com.tw 的信件, 會先去查 machvision.com.tw
的 MX 在哪裡, 得到兩個 preference 皆為 0 的 RR, 一個是 sdns.machvision.com.tw,
另一個是 "." (超詭異的, NT 的 DNS 居然允許這樣的設定?!)

而實際上對於 username@machvision.com.tw 的送信流程而言, 只要 machvision.com.tw
本身有設定 MX 就可以了, 他的 MX (sdns.machvision.com.tw) 不需要再設定自己的 MX
否則會造成 MX loop.

舉個錯誤的例子, 這個例子在現實中不會發生, 純粹為了說明錯誤的理論.
A.test.net 的 MX 指向 B.test.net, 而 B.test.net 的 MX 指向 A.test.net
那一封寄給 username@A.test.net 的信件會由 A 還是 B 處理?
按照您的理論, 這裡會形成 MX loop, 但是實際上 MTA 只會查詢 A.test.net 的 MX,
發現 MX 在 B, 然後信件就送往 B.test.net 了, 不會再查詢 B.test.net 的 MX


: 好了﹐回到正題。為了不誤導讀者﹐我得承認只查 MX 而不查 A 是不對的﹐而且問題
: 是否真的由此引起﹐還有待更進一步的查詢。因為上次有點趕﹐而且在替 Song 兄不
: 值中﹐做得沒有很仔細。為此﹐還要向關心這個 treat 的讀者們道歉﹗
: 如果大家對郵件傳遞的一些問題不是清楚﹐可以用 nslookup﹐dig 等查詢程式協助﹐
: 不要光在上面亂喊亂罵。有興趣的﹐何不乾脆利用一下目前的這個‘上佳實例’來幫
: 助我們理清一下概念呢﹖
: 我想﹐目前這個 treat﹐爭論的重點似乎不在如何找出問題所在﹐反而是彼此的討論
: 態度而已﹐不是嗎﹖真正有心幫助別人的﹐請拿出誠意來﹗
        [deleted]

上面 dig 的過程列出了不少資訊, 但是您並沒有清楚的點出錯誤在哪裡.
造成退信的原因不是 MX 主機的 MX (因為 sdns.machvision.com.tw 無須再設定 MX),
而是那個莫名其妙的 "."

也就是說, 目前所有發信人為 @machvision.com.tw 或者收信人為 @machvision.com.tw
的信件, 有 50% 的機率會被退信, 因為兩個 preference 相同的 MX 有一個是錯誤的.

 
 ----------


 來源: 網中人 
時間: 2001年 6月 6日 周三 14時39分39秒 CST
標題: Re: 我們MIS和seednet互踢皮球 
論壇: tw.bbs.comp.network 

口試過關的CAEer  wrote in message
news:3ge6da$WXc@bbs.leeym.com...
> ※ 引述《netman@junk.com》之銘言:
> : 薩米亞咚  wrote in message
> : news:3gdI4W$VLl@bbs.cis.nctu.edu.tw...
> : > 這裡的觀念是錯的 , @machvision.com.tw 的MX為 sdns.machvision.com.tw
> : > 而sdns.machvision.com.tw 有A Record就夠了 , 不需要再有屬於
> : > sdns.machvision.com.tw 的MX設定
> : 唉~~~ 看到這裡﹐我只能嘆息﹗
> : 沒錯﹐不設 MX 記錄也可以完成郵件傳遞﹐但有許多錯誤和浪費﹐就是斷送
> : 在這種‘懶惰’之上﹐請自己翻書﹕
> : Sendmail﹐2nd Edition Revised & Updated, O'Reilly,
> : By Bryan Costales with Eric Allman,
> : Chapter 21: DNS and sendmail
> [deleted]
>
> 基本上, 觀念真的有問題.

李兄好﹗謝謝您﹐受教了﹗


>
> 不設定 MX 的確會拖慢送信流程, 但是在這個例子中您拿來說明的文獻和理論
> 並不正確,收信端收到一封發信人為 @machvision.com.tw 的信件, 會先去查
machvision.com.tw
> 的 MX 在哪裡, 得到兩個 preference 皆為 0 的 RR, 一個是
sdns.machvision.com.tw,
> 另一個是 "." (超詭異的, NT 的 DNS 居然允許這樣的設定?!)

這點弟應該已經指出了﹐可能閣下看得太快了吧。(另﹐我這邊查到的 prefercnece
為 10 ﹐怎麼您那邊會是 0﹖)

>
> 而實際上對於 username@machvision.com.tw 的送信流程而言, 只要
machvision.com.tw
> 本身有設定 MX 就可以了, 他的 MX (sdns.machvision.com.tw) 不需要再設
> 定自己的 MX 否則會造成 MX loop.

如果為 snds.machvision.com.tw 這個 record 設定一個最低 cost 的 MX 指向自
己﹐是絕對不會不會做成 looping 的。這點後面討論。

>
> 舉個錯誤的例子, 這個例子在現實中不會發生, 純粹為了說明錯誤的理論.
> A.test.net 的 MX 指向 B.test.net, 而 B.test.net 的 MX 指向 A.test.net
> 那一封寄給 username@A.test.net 的信件會由 A 還是 B 處理?
> 按照您的理論, 這裡會形成 MX loop, 但是實際上 MTA 只會查詢 A.test.net 
> 的MX,發現 MX 在 B, 然後信件就送往 B.test.net 了, 不會再查詢 B.test.net 的 MX

我的理論恐怕兄還沒仔細看﹐那我能說什麼﹖除了“唉~~ ”之外﹖

那就再把您遺忘的句子抄回來好了﹕

We strongly recommend taht every host on the Internet have at lest one MX
record. As a minimum, it can simply point to itself with a 0 cost.
(英文解釋﹕我們強烈建議為每一台連上 Internet 的主機﹐設定最少一個 MX 記錄。
起碼﹐可以簡單的以 0 cost 指向自己。)
.....
This will not change how mail is routed to hostB but will reduce the number
of DNS lookups required.
(英文解釋﹕這並不改變郵件如何送遞至 hostB﹐但卻可以減低所須的 DNS 查詢次
數。)
(如果翻譯不對﹐懇請指。謝謝﹗)


您的例子可以看得出﹐很明顯是人為設定失誤﹐不過略嫌簡單到不足以原諒。事實
上﹐sendmail 那本書已經提到過這個問題了﹐也是在 316 頁﹕
hostA    IN    MX    10 hostB
hostB    IN    MX    10 hostB
         IN    MX    20 hostC
hostC    IN    MX    10 hostA  <--  potential loop

這樣的失誤或許就不是那麼明顯了﹐只是考慮不周而已﹐因為這原本是設定為
disaster recovery 使用的﹐也就是當 hostB 掛掉了﹐其郵件會 queque 到 C 上。
如果您不為 hostB 設定指向自己的 MX﹐那麼﹐根本不能提供容錯能力﹐所以書本建
議修改如下﹔

hostA    IN    MX    10 hostB
         IN    MX    20 hostC
hostB    IN    MX    10 hostB
         IN    MX    20 hostC
(原造成 loop 的句子無論如何要拿掉)

好了﹐讓我們回到前面所討論的﹕
“如果為 snds.machvision.com.tw 這個 record 設定一個最低 cost 的 MX 指向自
己﹐會造成 mx loop﹖”

如果我們來假設 DNS 的設定是這樣的﹕

machvision.com.tw.          IN    MX    10    snds.machvision.com.tw. (別漏
了最後一點)
snds.machvision.com.tw.     IN    A     211.21.176.34
snds.machvision.com.tw.     IN    MX    10    snds.machvision.com.tw.

我們可以根據這樣的流程來看這個 mail route:

1) 所有以 @machvision.com.tw 結尾的郵件﹐都會送到 snds.machvision.com.tw 上面去。
2) 而這台主機的 IP 位址是﹕211.21.176.34。
3) 關於 snds.machvision.com.tw 的郵件主機是其自己 (itself)﹐也就是
snds.machvision.com.tw。

這樣的設計﹐無論如何是不會用 mx loop 產生的。但因為目前只有一個 MX 記錄﹐所
以﹐和查不到 MX 記錄而用 A 記錄代替的原則是一樣的。關於這點﹐李兄已經指出
了﹐RFC 我沒看過﹐但 sendmail 這本書也有指出就是了(在 312 頁)﹕

If no MX records are found, sendmail tries to deliver the message to the
single original host.

(更詳細的流程﹐請參考 312-313 頁的 21.2.4 The $[ and $] Operators)

>
>
> : 好了﹐回到正題。為了不誤導讀者﹐我得承認只查 MX 而不查 A 是不對的﹐而且
> :問題 是否真的由此引起﹐還有待更進一步的查詢。因為上次有點趕﹐而且在替 Song
> : 兄不值中﹐做得沒有很仔細。為此﹐還要向關心這個 treat 的讀者們道歉﹗
> : 如果大家對郵件傳遞的一些問題不是清楚﹐可以用 nslookup﹐dig 等查詢程式協
> : 助﹐不要光在上面亂喊亂罵。有興趣的﹐何不乾脆利用一下目前的這個‘上佳實例’來幫
> : 助我們理清一下概念呢﹖
> : 我想﹐目前這個 treat﹐爭論的重點似乎不在如何找出問題所在﹐反而是彼此的討論
> : 態度而已﹐不是嗎﹖真正有心幫助別人的﹐請拿出誠意來﹗
>         [deleted]
>
> 上面 dig 的過程列出了不少資訊, 但是您並沒有清楚的點出錯誤在哪裡.
> 造成退信的原因不是 MX 主機的 MX (因為 sdns.machvision.com.tw 無須再設定MX),
> 而是那個莫名其妙的 "."

首先﹐我已經為疏忽而向讀者們道歉了。不過﹐我認為閣下還沒搞清楚狀況﹐接下來
我認為已經指出錯誤了。只是﹐可能過高的估計了某些讀者的智慧而已﹕

***********************************

1) 我先在前面這樣說﹕
===> 請留意上兩句﹐竟然有兩個 MX 的 preference 是相同的﹐而且最後一個卻只有
一個 “.”﹐不知道 sendmail 會如何判斷要用哪個呢﹖可以請大家發揮一下
research 的能力嗎﹖(答案在最後面)

2) 然後在最後面這樣說﹕
好了﹐答案時間﹕
又是 O'Reilly 的那本 Sendmail ﹐(盡信書不如無書﹖)
第 316 頁﹕
Another reason sendmail refuse to follow MX records beyond the target host
is that costs in such a situation are undefined.

***********************************

這裡我不想翻譯了﹐引用 Song 兄的建議﹕補習英文吧。

>
> 也就是說, 目前所有發信人為 @machvision.com.tw 或者收信人為
@machvision.com.tw
> 的信件, 有 50% 的機率會被退信, 因為兩個 preference 相同的 MX 有一個是錯誤的.

不儘然﹐弟認為有超過 50% 的機會是錯誤的﹐先撇開前面的英文句子所揭示的意義不
談﹐光就 DNS 查詢結果來看﹐結果通常會是 last match 為準的﹐我們這裡看到的﹐
超過 50% 是以 “.” 為 last match 。
(我想﹐我這裡必須補充說明還要忽略 preference ﹐否則又要被人要求出來解釋一堆)。

當然﹐有許多東西﹐弟尚沒條件一一實作的﹐所以會引用書本上的教條。而至於引用
是否合適﹐或資料是否過時﹐懇請大家指正。謝謝﹗



-------


來源: 口試過關的CAEer 
時間: 2001年 6月 7日 周四 02時23分47秒 CST
標題: Re: 我們MIS和seednet互踢皮球 
論壇: tw.bbs.comp.network 

※ 引述《netman@junk.com》之銘言:
: 口試過關的CAEer  wrote in message
: news:3ge6da$WXc@bbs.leeym.com...
: > [deleted]
: > 基本上, 觀念真的有問題.
: 李兄好﹗謝謝您﹐受教了﹗
: > 不設定 MX 的確會拖慢送信流程, 但是在這個例子中您拿來說明的文獻和理論並不正確,
: > 收信端收到一封發信人為 @machvision.com.tw 的信件, 會先去查 machvision.com.tw
: > 的 MX 在哪裡, 得到兩個 preference 皆為 0 的 RR, 一個是 sdns.machvision.com.tw,
: > 另一個是 "." (超詭異的, NT 的 DNS 居然允許這樣的設定?!)
: 這點弟應該已經指出了﹐可能閣下看得太快了吧。(另﹐我這邊查到的 prefercnece
: 為 10 ﹐怎麼您那邊會是 0﹖)

你引的文章我全部看完了, 所以才知道你原來說的錯在哪裡.
另外, 這是我打錯了, prefercnece 的確是 10, 抱歉.

: > 而實際上對於 username@machvision.com.tw 的送信流程而言, 只要 machvision.com.tw
: > 本身有設定 MX 就可以了, 他的 MX (sdns.machvision.com.tw) 不需要再設定自己的 MX
: > 否則會造成 MX loop.
: 如果為 snds.machvision.com.tw 這個 record 設定一個最低 cost 的 MX 指向自
: 己﹐是絕對不會不會做成 looping 的。這點後面討論。

這個部分請參考 RFC 974 "MAIL ROUTING AND THE DOMAIN SYSTEM",
裡面有一段正是說明 MX 的處理, 以及不設 MX 的處理. 剪貼一段給你參考.

It is possible that the list of MXs in the response to the query will be
empty. This is a special case. If the list is empty, mailers should treat
it as if it contained one RR, an MX RR with a preference value of 0, and
a host name of REMOTE. (I.e., REMOTE is its only MX). In addition, the
mailer should do no further processing on the list, but should attempt to
deliver the message to REMOTE. The idea here is that if a domain fails to
advertise any information about a particular name we will give it the
benefit of the doubt and attempt delivery.

這裡提到了當沒有 MX 時, 則把主機自己當成唯一的, 且 preference 為 0 的 MX.
另外不應該再繼續對 MX 查詢 MX, 而直接將信件送出.

這就是你的理論中錯誤的地方.

: > 舉個錯誤的例子, 這個例子在現實中不會發生, 純粹為了說明錯誤的理論.
: > A.test.net 的 MX 指向 B.test.net, 而 B.test.net 的 MX 指向 A.test.net
: > 那一封寄給 username@A.test.net 的信件會由 A 還是 B 處理?
: > 按照您的理論, 這裡會形成 MX loop, 但是實際上 MTA 只會查詢 A.test.net 的 MX,
: > 發現 MX 在 B, 然後信件就送往 B.test.net 了, 不會再查詢 B.test.net 的 MX
: 我的理論恐怕兄還沒仔細看﹐那我能說什麼﹖除了“唉~~ ”之外﹖
: 那就再把您遺忘的句子抄回來好了﹕
: We strongly recommend taht every host on the Internet have at lest one MX
: record. As a minimum, it can simply point to itself with a 0 cost.
: (英文解釋﹕我們強烈建議為每一台連上 Internet 的主機﹐設定最少一個 MX 記錄。
: 起碼﹐可以簡單的以 0 cost 指向自己。)
: .....
: This will not change how mail is routed to hostB but will reduce the number
: of DNS lookups required.
: (英文解釋﹕這並不改變郵件如何送遞至 hostB﹐但卻可以減低所須的 DNS 查詢次數。)
: (如果翻譯不對﹐懇請指。謝謝﹗)
: 您的例子可以看得出﹐很明顯是人為設定失誤﹐不過略嫌簡單到不足以原諒。事實
: 上﹐sendmail 那本書已經提到過這個問題了﹐也是在 316 頁﹕
: hostA    IN    MX    10 hostB
: hostB    IN    MX    10 hostB
:          IN    MX    20 hostC
: hostC    IN    MX    10 hostA  <--  potential loop
: 這樣的失誤或許就不是那麼明顯了﹐只是考慮不周而已﹐因為這原本是設定為
: disaster recovery 使用的﹐也就是當 hostB 掛掉了﹐其郵件會 queque 到 C 上。
: 如果您不為 hostB 設定指向自己的 MX﹐那麼﹐根本不能提供容錯能力﹐所以書本建
: 議修改如下﹔
: hostA    IN    MX    10 hostB
:          IN    MX    20 hostC
: hostB    IN    MX    10 hostB
:          IN    MX    20 hostC
: (原造成 loop 的句子無論如何要拿掉)

建議你不要一直把 "唉.." 這類的口頭禪掛在嘴上, 這樣的態度對討論沒有幫助.

這個範例有問題, 我重複一下您想要描述的理論:
hostA 的 MX 為 hostB, hostB 的 MX 除了自己以外, 還有 hostC.
有一封信要送給 hostA, 這封信會由 hostB 處理, 但是 hostB 掛了, 所以這封
收信人為 hostA 的信件, 會由 hostB 的 MX, 也就是 hostC 所收下來.

這是錯的!!

hostB 的 MX 不會影響 hostA 的信件收發. 我原來的文章就提過.
所以這封寄給 hostA 的信在整個送信流程中只會查詢 "一個" MX, 就是 hostA 的 MX,
當 MTA 發現 hostA 的 MX 為 hostB 之後就開始送信, 不會再查詢 hostB 的 MX.

為了展示這個錯誤的範例, 我做了一組錯誤的設定.

在上面的例子中, hostA 為 mp8336.leeym.com, hostB 為 daniel.leeym.com,
而 hostC 為 bsd.leeym.com, mp8336 的 MX 為 daniel, 而 denial 的 MX 為 bsd.
其中 mp8336 為 Win2000 不開 smtp, denial 現在關機, bsd 上跑 sendmail.

我從某台跑了 sendmail 的主機寄給 leeym@mp8336.leeym.com, 這封信件只會不斷的
踹 denial.leeym.com, 並不會理會 denial 的 MX 為 bsd, 而 bsd 上的 sendmail
從頭到尾也不會收到將寄給 mp8336 的信件.

這個例子你可以踹踹看. 為了搭配你舉的文件, 我的 MTA 全部選用 sendmail.
不過實際上 qmail postfix exim 在這裡的實作上都一樣, 遵照 RFC 974 執行.

: 好了﹐讓我們回到前面所討論的﹕
: “如果為 snds.machvision.com.tw 這個 record 設定一個最低 cost 的 MX 指向自
: 己﹐會造成 mx loop﹖”
: 如果我們來假設 DNS 的設定是這樣的﹕
: machvision.com.tw.          IN    MX    10    snds.machvision.com.tw. (別漏
: 了最後一點)
: snds.machvision.com.tw.     IN    A     211.21.176.34
: snds.machvision.com.tw.     IN    MX    10    snds.machvision.com.tw.
: 我們可以根據這樣的流程來看這個 mail route:
: 1) 所有以 @machvision.com.tw 結尾的郵件﹐都會送到 snds.machvision.com.tw 上
: 面去。
: 2) 而這台主機的 IP 位址是﹕211.21.176.34。
: 3) 關於 snds.machvision.com.tw 的郵件主機是其自己 (itself)﹐也就是
: snds.machvision.com.tw。
: 這樣的設計﹐無論如何是不會用 mx loop 產生的。但因為目前只有一個 MX 記錄﹐所
: 以﹐和查不到 MX 記錄而用 A 記錄代替的原則是一樣的。關於這點﹐李兄已經指出
: 了﹐RFC 我沒看過﹐但 sendmail 這本書也有指出就是了(在 312 頁)﹕
: If no MX records are found, sendmail tries to deliver the message to the
: single original host.
: (更詳細的流程﹐請參考 312-313 頁的 21.2.4 The $[ and $] Operators)

上面三個步驟裡面, 第三步驟不會被執行.

因為要送給 @machvision.com.tw 的信件, 當發現 MX 為 snds.machvision.com.tw
而該 MX 的 IP 為 211.21.176.34, 接著就開始寄信至此 IP, 不會再查詢一次 MX.

建議你發一封信給 leeym@mp8336.leeym.com , 你就知道上面的理論錯在哪裡.

: > 上面 dig 的過程列出了不少資訊, 但是您並沒有清楚的點出錯誤在哪裡.
: > 造成退信的原因不是 MX 主機的 MX (因為 sdns.machvision.com.tw 無須再設定 MX),
: > 而是那個莫名其妙的 "."
: 首先﹐我已經為疏忽而向讀者們道歉了。不過﹐我認為閣下還沒搞清楚狀況﹐接下來
: 我認為已經指出錯誤了。只是﹐可能過高的估計了某些讀者的智慧而已﹕
: ***********************************
: 1) 我先在前面這樣說﹕
: ===> 請留意上兩句﹐竟然有兩個 MX 的 preference 是相同的﹐而且最後一個卻只有
: 一個 “.”﹐不知道 sendmail 會如何判斷要用哪個呢﹖可以請大家發揮一下
: research 的能力嗎﹖(答案在最後面)
: 2) 然後在最後面這樣說﹕
: 好了﹐答案時間﹕
: 又是 O'Reilly 的那本 Sendmail ﹐(盡信書不如無書﹖)
: 第 316 頁﹕
: Another reason sendmail refuse to follow MX records beyond the target host
: is that costs in such a situation are undefined.
: ***********************************
: 這裡我不想翻譯了﹐引用 Song 兄的建議﹕補習英文吧。
: > 也就是說, 目前所有發信人為 @machvision.com.tw 或者收信人為
: @machvision.com.tw
: > 的信件, 有 50% 的機率會被退信, 因為兩個 preference 相同的 MX 有一個是錯誤的.
: 不儘然﹐弟認為有超過 50% 的機會是錯誤的﹐先撇開前面的英文句子所揭示的意義不
: 談﹐光就 DNS 查詢結果來看﹐結果通常會是 last match 為準的﹐我們這裡看到的﹐
: 超過 50% 是以 “.” 為 last match 。
: (我想﹐我這裡必須補充說明還要忽略 preference ﹐否則又要被人要求出來解釋一堆)。
: 當然﹐有許多東西﹐弟尚沒條件一一實作的﹐所以會引用書本上的教條。而至於引用
: 是否合適﹐或資料是否過時﹐懇請大家指正。謝謝﹗

補習英文這類的建議還是留著吧, 我想大家看過的文件都不少, 只是不知道怎麼用而已.

這裡有另外一個錯誤, 相同 preference 的 MX 並不是 last match 為準的.
否則像是 microsoft.com 設定五組 MX, 只有最後一組有效, 豈不怪哉?

實際上多個相同 preference 的 MX 會以 round-robin 的方式輪流出現.
你可以對相同的 DNS query 重複執行幾次看看, 幾次之後就知道結果不同.

我要說的已經重複說了兩三次了, 不過你仍然不能接收這個理論, 多說無益.
實作一下, 看看 RFC, 追蹤一下 source code, 就知道信件傳送的流程怎麼跑的
了.

 

--------


來源: 網中人 
時間: 2001年 6月 7日 周四 16時25分34秒 CST
標題: Re: 我們MIS和seednet互踢皮球 
論壇: tw.bbs.comp.network 

口試過關的CAEer  wrote in message
news:3geRBa$WLZ@bbs.leeym.com...
> ※ 引述《netman@junk.com》之銘言:
> : 口試過關的CAEer  wrote in message
> : news:3ge6da$WXc@bbs.leeym.com...
> : > [deleted]
> : > 基本上, 觀念真的有問題.
> : 李兄好﹗謝謝您﹐受教了﹗
> : > 不設定 MX 的確會拖慢送信流程, 但是在這個例子中您拿來說明的文獻和理論
> : > 並不正確, 收信端收到一封發信人為 @machvision.com.tw 的信件, 會先去查
machvision.com.tw
> : > 的 MX 在哪裡, 得到兩個 preference 皆為 0 的 RR, 一個是
sdns.machvision.com.tw,
> : > 另一個是 "." (超詭異的, NT 的 DNS 居然允許這樣的設定?!)
> : 這點弟應該已經指出了﹐可能閣下看得太快了吧。(另﹐我這邊查到的 prefercnece
> : 為 10 ﹐怎麼您那邊會是 0﹖)
>
> 你引的文章我全部看完了, 所以才知道你原來說的錯在哪裡.

彥明兄﹐再次多謝您的指教﹗這是真心的﹐請不要懷疑。


> 另外, 這是我打錯了, prefercnece 的確是 10, 抱歉.
>
> : > 而實際上對於 username@machvision.com.tw 的送信流程而言, 只要
machvision.com.tw
> : > 本身有設定 MX 就可以了, 他的 MX (sdns.machvision.com.tw) 不需要再設定
> : > 自己的 MX 否則會造成 MX loop.
> : 如果為 snds.machvision.com.tw 這個 record 設定一個最低 cost 的 MX 指向自
> : 己﹐是絕對不會不會做成 looping 的。這點後面討論。
>
> 這個部分請參考 RFC 974 "MAIL ROUTING AND THE DOMAIN SYSTEM",
> 裡面有一段正是說明 MX 的處理, 以及不設 MX 的處理. 剪貼一段給你參考.
>
> It is possible that the list of MXs in the response to the query will be
> empty. This is a special case. If the list is empty, mailers should treat
> it as if it contained one RR, an MX RR with a preference value of 0, and
> a host name of REMOTE. (I.e., REMOTE is its only MX). In addition, the
> mailer should do no further processing on the list, but should attempt to
> deliver the message to REMOTE. The idea here is that if a domain fails to
> advertise any information about a particular name we will give it the
> benefit of the doubt and attempt delivery.
>
> 這裡提到了當沒有 MX 時, 則把主機自己當成唯一的, 且 preference 為 0 的 MX.
> 另外不應該再繼續對 MX 查詢 MX, 而直接將信件送出.
>
> 這就是你的理論中錯誤的地方.
>
> : > 舉個錯誤的例子, 這個例子在現實中不會發生, 純粹為了說明錯誤的理論.
> : > A.test.net 的 MX 指向 B.test.net, 而 B.test.net 的 MX 指向 A.test.net
> : > 那一封寄給 username@A.test.net 的信件會由 A 還是 B 處理?
> : > 按照您的理論, 這裡會形成 MX loop, 但是實際上 MTA 只會查詢 A.test.net 的 MX,
> : > 發現 MX 在 B, 然後信件就送往 B.test.net 了, 不會再查詢 B.test.net 的MX
> : 我的理論恐怕兄還沒仔細看﹐那我能說什麼﹖除了“唉~~ ”之外﹖
> : 那就再把您遺忘的句子抄回來好了﹕
> : We strongly recommend taht every host on the Internet have at lest one MX
> : record. As a minimum, it can simply point to itself with a 0 cost.
> : (英文解釋﹕我們強烈建議為每一台連上 Internet 的主機﹐設定最少一個 MX 記錄。
> : 起碼﹐可以簡單的以 0 cost 指向自己。)
> : .....
> : This will not change how mail is routed to hostB but will reduce the number
> : of DNS lookups required.
> : (英文解釋﹕這並不改變郵件如何送遞至 hostB﹐但卻可以減低所須的 DNS 查詢次
> : 數。)
> : (如果翻譯不對﹐懇請指。謝謝﹗)
> : 您的例子可以看得出﹐很明顯是人為設定失誤﹐不過略嫌簡單到不足以原諒。事實
> : 上﹐sendmail 那本書已經提到過這個問題了﹐也是在 316 頁﹕
> : hostA    IN    MX    10 hostB
> : hostB    IN    MX    10 hostB
> :          IN    MX    20 hostC
> : hostC    IN    MX    10 hostA  <--  potential loop
> : 這樣的失誤或許就不是那麼明顯了﹐只是考慮不周而已﹐因為這原本是設定為
> : disaster recovery 使用的﹐也就是當 hostB 掛掉了﹐其郵件會 queque 到 C 上。
> : 如果您不為 hostB 設定指向自己的 MX﹐那麼﹐根本不能提供容錯能力﹐所以書本建
> : 議修改如下﹔
> : hostA    IN    MX    10 hostB
> :          IN    MX    20 hostC
> : hostB    IN    MX    10 hostB
> :          IN    MX    20 hostC
> : (原造成 loop 的句子無論如何要拿掉)
>
> 建議你不要一直把 "唉.." 這類的口頭禪掛在嘴上, 這樣的態度對討論沒有幫助.

對不起﹗弟為這些嘆息抱歉﹗不過﹐請不要太過誤會﹐那嘆息大部份是對自己而發
的﹐因為實在沒時間詳細說明﹐有點累的感覺。假如因此另大家困惑了﹐再次道歉
﹗(事實上﹐這不應該是我的口頭禪才對﹐據我自己的統計﹐也僅是這三、四次用過而
已。了解我的朋友﹐應該知道這使用率極低。)

>
> 這個範例有問題, 我重複一下您想要描述的理論:
> hostA 的 MX 為 hostB, hostB 的 MX 除了自己以外, 還有 hostC.
> 有一封信要送給 hostA, 這封信會由 hostB 處理, 但是 hostB 掛了, 所以這封
> 收信人為 hostA 的信件, 會由 hostB 的 MX, 也就是 hostC 所收下來.
>
> 這是錯的!!
>
> hostB 的 MX 不會影響 hostA 的信件收發. 我原來的文章就提過.
> 所以這封寄給 hostA 的信在整個送信流程中只會查詢 "一個" MX, 就是 hostA 的MX,
> 當 MTA 發現 hostA 的 MX 為 hostB 之後就開始送信, 不會再查詢 hostB 的 MX.
>
> 為了展示這個錯誤的範例, 我做了一組錯誤的設定.
>
> 在上面的例子中, hostA 為 mp8336.leeym.com, hostB 為 daniel.leeym.com,
> 而 hostC 為 bsd.leeym.com, mp8336 的 MX 為 daniel, 而 denial 的 MX為 bsd.
> 其中 mp8336 為 Win2000 不開 smtp, denial 現在關機, bsd 上跑 sendmail.
>
> 我從某台跑了 sendmail 的主機寄給 leeym@mp8336.leeym.com, 這封信件只會不斷
> 的踹 denial.leeym.com, 並不會理會 denial 的 MX 為 bsd, 而 bsd 上的 sendmail
> 從頭到尾也不會收到將寄給 mp8336 的信件.
>
> 這個例子你可以踹踹看. 為了搭配你舉的文件, 我的 MTA 全部選用 sendmail.
> 不過實際上 qmail postfix exim 在這裡的實作上都一樣, 遵照 RFC 974 執行.
>


[ 餘下恕刪 ]

的確如此﹐我要承認所引用的錯誤設定例子不適當﹐事實上並沒有實作過。我希望自
己的錯誤能讓關心這個 treat 的朋友得到借鑒。謝謝李兄給我這個機會來認識自己的
錯誤觀念﹗

或許﹐可以歸納看看我們這裡的討論焦點好了﹐相信對大家都有所幫助﹕
1) 一開始﹐弟指出對方 mail server 沒有自己的 MX ﹐而沒進一步查證﹐是我的不
對﹐為此也向大家道歉了。
2) 接下來﹐李兄指出不能為 mail server 設定自己 MX﹐否則會造成 mx loop。這點
弟仍有所保留﹐可以參考後面的實作。
3) 為說明 mail server 設定自己 MX 不會做成 mx loop﹐弟引用了一些資料﹐但舉
證中卻有問題﹐這點很多謝李兄指正。(否則弟還一直不知道)
4) 現在李兄已經證明“整個送信流程中只會查詢 "一個" MX”這個論點﹐那麼﹐
論點2) 的問題就迎刃而解了﹐只是這是李兄自己證明出來推翻的﹐反而不是弟之能
力。

如下是實作過程﹕

1) 用 nslookup 確定 hosta 的 mx 到 hostb﹔然後 hsotb 的 mx 又回到 hosta
 去﹐(所謂的 mx loop)﹕

> set type=mx
> hosta.siyongc.domain
Server:  rh71.siyongc.domain
Address:  203.30.35.131
Aliases:  131.35.30.203.in-addr.arpa

hosta.siyongc.domain    preference = 10, mail exchanger =
hostb.siyongc.domain
siyongc.domain  nameserver = rh71.siyongc.domain
siyongc.domain  nameserver = linpus64.dmz.domain
hostb.siyongc.domain    internet address = 192.168.100.23
linpus64.dmz.domain     internet address = 203.30.35.130
> hostb.siyongc.domain
Server:  rh71.siyongc.domain
Address:  203.30.35.131
Aliases:  131.35.30.203.in-addr.arpa

hostb.siyongc.domain    preference = 10, mail exchanger =
hosta.siyongc.domain
siyongc.domain  nameserver = linpus64.dmz.domain
siyongc.domain  nameserver = rh71.siyongc.domain
hosta.siyongc.domain    internet address = 192.168.100.22
linpus64.dmz.domain     internet address = 203.30.35.130

2) 從另外一台機器發一封郵件到 hosta﹐另一封到 hostb﹕
[root@linpus64 /root]# date
Wed Feb 28 16:44:55 CST 2001
[root@linpus64 /root]# mail kenny@hosta.siyongc.domain
Subject: test01
test only.
..
Cc:
[root@linpus64 /root]# mail kenny@hostb.siyongc.domain
Subject: test02
test only.
..
Cc:

3) 然後檢查 maillog﹕
Feb 28 16:45:08 linpus64 sendmail[1845]: QAA01845: from=root, size=59,
class=0, pri=30059, nrcpts=1,
msgid=<200102280845.QAA01845@linpus64.dmz.domain>, relay=root@localhost
Feb 28 16:45:08 linpus64 sendmail[1847]: QAA01845:
to=kenny@hosta.siyongc.domain, ctladdr=root (0/0), delay=00:00:00,
xdelay=00:00:00, mailer=esmtp, relay=hostb.siyongc.domain.
[192.168.100.23], stat=Sent (2.0.0 f578GFr02506 Message accepted for
delivery)
Feb 28 16:45:23 linpus64 sendmail[1850]: QAA01850: from=root, size=59,
class=0, pri=30059, nrcpts=1,
msgid=<200102280845.QAA01850@linpus64.dmz.domain>, relay=root@localhost
Feb 28 16:46:38 linpus64 sendmail[1852]: QAA01850:
to=kenny@hostb.siyongc.domain, ctladdr=root (0/0), delay=00:01:15,
xdelay=00:01:15, mailer=esmtp, relay=hosta.siyongc.domain.
[192.168.100.22], stat=Sent (QAA01024 Message accepted for delivery)

4) 我們可以看到結果是﹕
給 hosta 的信﹐轉到 hostb 去了﹐
而給 hostb 的信﹐則轉到 hosta 上。

5) 結論﹕
既然 MX 只查一次﹐那麼我們以後都可以免除 mx loop 之苦了﹖不知道是否說得太早了﹖
(除非在 sendmail 上沒有適當設定 sendmail.cw 或 local-host-names)

************************************

為此﹐在下先多謝 彥明 兄的大力指點﹗接下來﹐還想談談自己的學習感想。

不管大家如何看待﹐事實上我是非常開心的﹐因為又在學習中前進了一小步 :) 那
麼﹐這個進步如何換來的﹐當然﹐沒有得到別人的指點是不可能的﹐但我覺得﹐和自
己的執著分不開。不管自己的論點是否站得住﹐總要找證據進行論證﹐進行推演﹔也
不管觀念是否正確﹐總要自己先表達出來﹐別人才能幫助。我這幾天來﹐的確從討論
中把好幾個錯誤觀念糾正過來了﹐說真的﹐沒人會比我更開心的啦﹗

至於這個 treat 的問題是否能夠解決(這也是弟當初加入討論的目的)﹐恐怕不是我們
所能控制的了。