建置高效能高穩定度的 E-mail 組合系統 陳昌盛 國立交通大學計算機與網路中心 新竹市大學路 1001 號 E-mail: [email protected] 摘要 E-mail 是網際網路上使用最頻繁的 應用之一¸ 多數上網的人都會用到。任何 一個連網單位每日 E-mail 的傳輸量¸ 長期 趨勢是往上增加。因此¸ 對於內部 E-mail 系統的規劃¸ 就必須兼顧 performance ¸ scalability ¸ reliability, availability ¸ security 等問題¸ 通盤加以考量。許多人 可能有經驗¸ 前一些時候(或許目前也一 樣) TANet 上¸ 許多傳統的應用¸ 諸如 DNS 查詢¸ E-mail 收送等¸ 經常會出現不 順暢的情形。有一些從國外寄來的信件¸ 可能會拖上一天以上才會送進來。同樣地 ¸往國外寄送的 E-mail 往往要經過好幾 個小時¸ 甚至好幾天才能送到國外目的 地。如果我們再深入分析¸ 就可以發現¸ 是有改善空間。本文的主題¸ 就是嘗試將 一些可行的做法¸ 整理出來¸ 介紹給大家 ¸ 當做實作上的參考。 期望多數的 TANet 連線單位¸ 能因此而得已建構起 來一套更完善的 E-mail 網路使用環境。 關鍵詞: DNS, mail,轉送,轉接,可靠度,使 用效能 壹. 背景說明: 近年來全球網際網路使用人數激增¸ 各種應用快速增加¸ 諸如 www 之類的 killer application ¸ 佔掉多數可用頻寬¸ 相 對而言¸ 造成許多傳統應用受到擠壓。 目前 TANet 對 Internet 的骨幹線路¸ 雖然已經提昇到 DS3 (44.5M bits)¸ 但因 為 TANet/I2 研究網路的分割頻寬要求¸ TANet 實際可用的部份¸ 大略只剩 24M [1]。再者¸ 各種應用最後還是必須連接到 使用者端, 因此網路應用的順暢與否¸ 一 定會受到各單位與 TANet 骨幹的連接狀 況所影響。所以根據網路發展的經驗¸ 我 們就必須要大量借助各種具有 caching ¸ relay ¸ proxy ¸ forwarding 等轉送/轉接功 能的輔助系統來幫忙¸ 才能讓各單位整體 的網路效能¸ 維持在一定的水準之上。基 於這樣的考量, 目前 TANet 骨幹可用頻 寬, 可以簡單地分為兩類: (1) 16M 專用頻寬, 由各區網中心協調 管理, 規劃與建置各種 server (proxy, mail relay, dns forwarder, …) , 提供 區域內的上網單位, 一起來使用。 (2) 8M 一般頻寬, 所有使用者各憑本事 來使用。 Mail 與 www 是最普遍的應用 根據統計, mail 與 www 是兩種最 頻繁的網路應用¸ 多數上網的使用者¸ 除 了使用 www 找一些有趣或有用的研究資 訊¸ 也一定會用到 Mail 做為與其他人員 或電腦系統的溝通工具。 根據教育部電算中心的 88 年 4 月網 路流量統計[2], 目前進入 TANet <==>Internet, 佔整個流量最高比率的是 www, 已經超過 90% 以上。探究其原因,
一部份是反應 www 使用的需求, 另一 個原因, 則是因為 TANet 骨幹有針對 www 使用, 規畫與建置很多的 proxy server, 是各地使用加總的結果。有趣的是, 當月的 E-mail 的流量, 以 bytes 數來計, 大約只佔整體的 1.15% 而已, 兩者的差 距, 相當懸殊。 相信許多人一定有經驗¸ 前一些時候 (甚至目前也一樣) TANet 上¸ 許多傳統 的應用¸ 諸如 DNS 查詢¸ E-mail 等¸ 經 常會出現不順暢的情形。例如¸有一些從國 外寄來的信件¸ 可能會拖上一天以上才會 送達¸ 甚至有部份國外地區¸ 根本就很難 送 E-mail 進 TANet 各單位(備註 1)。因此 ¸ 許多人有時候乾脆就轉用 FAX 之類的 應用¸ 暫時來替代 E-mail 溝通。類似的 情況¸ 許多人可能也會發現¸往國外寄送 的 E-mail 往往要經過好幾個小時¸ 甚至 好幾天才能送到國外目的地。這種情形¸ 在過去幾乎是無法想像¸ 是不太可能出現 的情況。 如果我們再深入分析¸ 就可以發現¸ 其實這一些狀況是可以大幅改善的。筆者 嘗試將這部份做法¸ 整理出來¸ 介紹給大 家當做實作上的參考。 備註 1: 從教育部電算中心的網路流量 Netflow/MRTG [3][4][5] 的統計資料¸ 以 及事後的查證¸ 每天早晨 4:00-6:00¸ 教 育部電算中心出國的路由器(router)¸ 都固 定將 www traffic 暫時擋掉。 因此¸ 許多 與國外互通的 E-mail traffic 是利用這個 空擋¸ 才得以順利進出 TANet 各連線單 位。 貳. 網路系統資源的基本限制 任一系統¸ 可用的資源¸ 基本上是有 限制的。因此¸ 能不能持續且順暢地提供 服務¸ 往往也取決於管理人員¸ 是不是真 正瞭解這一些限制的意義¸ 以及是不是懂 得如何來因應這一些系統資源的限制。 一般而言¸ 會影響電腦網路系統效能 的因素¸ 簡單來說¸ 可以分成硬體設備 與軟體程式兩類¸ 常見的包括: - 網路的可用(or 堪用)的頻寬, - 網路介面的處理速度, - CPU 計算能力, - 可用記憶體空間( memory size)的大小, - Disk I/O 的存取速度, - 系統所能同時執行的 process 數目, - Application Program 本身等 E-mail 系統的運作 [6] 從使用的方式來看¸ E-mail 可簡單分 成兩類 : (1) 一對一的傳送方式為主¸ (2) 一對多的傳送模式¸ 也就是常 用的 mailing list 之類的應用。 如果各位有機會去觀察一個使用頻繁 的 E-mail 系統¸ 應該不難發現, 由於上 述 E-mail 使用的特性¸ 經常會有在一段 時間內¸ 同時出現一大堆的 incoming/out-going e-mail 需要立即處理。 所以一個系統¸ 是不是能夠即時 fork 出 足夠的 process 來處理¸ 也是一個影響系 統 performance 的重要關鑑¸ 尤其如果該 系統¸ 要服務的使用者又特別多的話¸ 這 個問題就更明顯。 長遠來看¸憑一套單一 E-mail 系統¸ 要維持系統的順暢運作¸ 將會越來越困 難。為了順應大環境的變遷¸ 建構一個組 合系統是必然的走向。因此¸對於能否順利 建構這樣一套¸ 兼顧 performance ¸ scalability ¸ reliability, availability ¸ security 的 E-mail 組合系統¸ 我們就必 須再加計 “系統管理者¸ 能否將 Mail 與 DNS server 設定¸ 加以妥善搭配及運用”
這一項關鍵因素。 參. MTA 運作與 DNS 設定需密切配合 [7] 首先, 有一個關鍵問題¸ 必須確定大 家都弄清楚. Problem:一般如 sendmail 之類的
MTA (Mail Transfer Agent) ¸ 如果收 到一封 e-mail ¸ 經查證後¸ 發現最 後目的地¸ 並不是自己本身¸ 那麼 這個 MTA 是如何決定出¸ 要將這 一封 e-mail 往哪裏丟 ? 按照 DNS 與 SMTP [8]的理論設計¸ 任一封 E-mail 的交寄或轉送¸ 是以 DNS 系統上的 MX 這一種資料項目為依據。 在實作上¸ 有一套 3 步曲的運作法則。 底 下, 我們假設從系統 host-H¸ 寄一封信件 到 “[email protected]”為例¸ 來說明 sendmail 之類的 MTA¸ 是如何達成任務。 3.1 一般 MTA 的運作法則: (1) 查證有沒有對應的 MX RR ( Mail eXchange Resource Record )。
以這個例子¸ host-H 會經由 DNS 系統¸ 查證有沒有 cc.nctu.edu.tw 這個 MX RR。 如果沒有¸ 則繼續下一步。 如果有¸ 則 host-H 會進一步根據 所得到的 MX RR 來判斷¸ 要往 哪一個 host 連過去¸ 進行後續 的 e-mail 轉送或交寄的任務。 以 MX RR 優先權 (priority) 最高者 [數目字較小者]¸ 為 首先嘗試的連接對象。 如果 MX RR 的優先權相同¸ 則由 DNS 系統¸ 隨機分配 指派一個 MX host 做為 host-H 進一步連接的對象。 ( 本例中¸ 由 cc.NCTU.edu.tw 所在的 DNS server 指派¸ 其 他的 case 的情形¸ 可以準此 類推) 如果優先權較高者¸ 連不 上。 則 host-H 上的 MTA¸ 會依優先權順序¸ 依次改 試連接下一個 MX host。 萬一暫時¸ 所有定義的 MX host ¸ 都連不上¸ 則這 一個 MTA 會將該 E-mail 暫時儲存 (queue) 在自己 的系統上¸ 稍後再來嘗試 先前所有的連線動作。 整 個動作¸ 會持續到某一次 連線成功¸ 或者當整個連 線嘗試¸ 已經超過系統所 設定的時間(例如 3 天 或 5 天)¸ 系統將信件退回給 原寄件系統為止¸ 整個 E-mail transaction 流程到此 ¸ 告一個段落。 (2). 查證¸ 有沒有同名字串¸ 對應的 A RR ( Address Resource Record)。
以這個例子¸ host-H 就是查證有沒 有 cc.nctu.edu.tw 這個 A RR。 如果沒有¸ 則繼續下一步。 如果有¸ 則這個 A RR 會被當成 MX RR 來使用¸ 該 MTA 接下 來¸ 就會將連往該 A RR 所指的 一個(or 其中之一) mail host ¸ 將 該 e-mail 交給它¸ 然後結束這一 次 e-mail 轉送工作。 (3). 查證¸ 有沒有同一字串的¸ 萬用的 (wildcard) MX RR。 以這 DNS 個例子¸ host-H 就是查 證有沒有 cc.nctu.edu.tw 這個 wildcard MX RR。
如果有¸ 則這個 MTA 接下來 ¸ 就會將連往該 MX RR 所指 的另一個(or 其中之一) mail host ¸ 將該 e-mail 交給它¸ 然 後結束這一次 e-mail 轉送工 作。 如果上面的查證¸ 都失敗¸ 那 麼這個顯然是使用者寫錯(or typo 打錯字) 的 e-mail address ¸ 接下來的處理程序¸ 就是將信 退回給原寄件人。 3.2 一封 E-mail 的最終目的地 如果一個 host-B¸ 接收到其他網站的 MTA 轉寄過來的一封 e-mail ¸ 經 DNS 查證相關的 MX RR 之後¸ 發現 : 自己恰好就是這個 MX RR 的最高 優先權者。 沒有相關的 MX RR¸ 但自己恰好就 是這個 A RR。 這兩種情況¸ 就代表自己就是這一封 e-mail 的最終處理目的地¸ 接下來就必須 接著進行該信所附 user information 的查 證¸ 也就是看看 /etc/passwd 或者透過 NIS 之類的系統¸ 去 check 這個 user 帳 號是不是存在 : 如果沒有¸ 則退信給原件人¸ 告知 " 查無此 user". 如果有這個 user 帳號¸ 則進一步查 證¸ 該 user 有沒有需要進行特別處 理. 不需要¸ 則直接存入系統信箱區。 需要再處理¸ 則由 MTA 將接收到 的信件, 再轉交給相關的程式¸ 進 一步處理。 (如, virtual host mapping 或經過 procmail 之類的 filter 程 式加工處理.) 3.3 Relaying Host 如何運作 所謂的 relaying host 的基本定義¸ 就 是該 host 只是做為某一些 e-mail 的暫 時轉接站¸ 這一些 e-mail 還是會被再轉 送到他們最終的目的地。{如前一段} 基本上¸ 在 E-mail 系統的設計上¸ relaying hosts 的使用情況¸ 包括 : 網路條件不良的地方¸ 必須情商¸ 借 助其他網路條件比較優良的單位¸ 代 接 E-mail。 主要 E-mail 系統¸ 於局部時段內¸ 會 出現無法即時處理短時間內¸ 比較吃 重¸連續且大量的 E-mail traffic 情況。 為了避免網路資源的耗費¸ 尤其是跨 國界¸ 遠距離點對點的連線嘗試¸ 一 再的重覆¸ 因此希望透過¸ 這類備援 的 relaying host ¸ 即時代為接收該 E-mail。稍後¸ 再由 local 的 relaying host ¸ 選擇適當的時機¸ 將該類 E-mail 轉交到最終的目的地。如果 local 沒有設置 relaying hosts ¸ 則這類 的 E-mail ¸ 必須由 remote host 跨遠 距離¸ 自行再重覆傳送¸ 這樣一來對 整體的網路使用¸ 將造成更多不必要 的耗費。 許多使用 firewall 單位¸ 特別重 視 security 。主要的 E-mail 系統¸ 並不 直接與外界溝通¸ 外界要送 E-mail 進來¸ 通常必須先透過在 firewall 上 的 relaying host。 前面所描述的是一個普通的 host-H 上¸ MTA 如何決定 E-mail Transaction 連 接對項的工作原理。基本上¸ 這一個法則¸ 拿來套在 Relaying Hosts 的情形¸ 仍然適 用¸ 只是說明部份¸ 需要少部份的修正。 也就是¸ 當一個 relaying host 收到其它系 統¸ 轉來的一封 e-mail 時¸ 系統上的 MTA 程式¸ 首先會經由 DNS 的 MX RR 查詢¸ 發現還有其它優先權更高的 MX
RR host(s)¸ 因此¸ 這個 MTA 馬上就瞭解 自己只是中途代收站¸ 緊跟著就依 MX RR 優先次序¸ 嘗試將該信件轉往真正的 目的地。經過這樣¸ 一層一層往上轉¸ 所 有 relaying host 都只往優先權比自己高的 MX host 送¸ 最終必可順利將該信件送到 最終的目的地。 肆. E-mail 組合系統的規劃建議 關於 TANet 各單位 E-mail 的接收與 傳送¸ 實際改善的方案¸ 簡單來看¸ 可 分成兩個部份: (1) 善加搭配及運用¸ E-mail 與 DNS 系 統¸ 所提供的 E-mail 轉送(mail forwarding) 以及轉接( mail relaying) 功能。 建立階層分散式的運作體系¸ 以因應大環境的變遷。 (2) 妥善使用 TANet 骨幹的 server 專用 channel ( 163.28.0.0 這個 subnet)。 底下¸ 就以目前我們交通大學電算中 心的規劃¸ 以及與教育部電算中心搭配運 作的情況¸ 當做一個例子¸ 來說明如何透 過這兩類關鍵點¸ 將這樣一套完整的 forwarding / relaying 網路系統搭配組合 起來。 伍. 參考範例 從技術上來看¸ 由於 E-mail 的溝通¸ 通常是有來有往¸ 因此在 E-mail system 的設計與規劃上¸ 有很多情況下¸ 有時也 會將轉入( in-coming)部份與轉出 (out-going)部份¸ 兩者分開加以處理。 當 然¸ 實際環境下¸ 如果量不大, 也可以將 兩者合而為一。
5.1 In-coming mail 的處理 ( NCTU-CC 的 Mail Relay )
為了順利使用 mail relay 的功能¸ 我 們必須在相關的 Domain Zone 上建立對 應的 MX RR ( Mail eXchange Resource Record)¸ 底下是以交通大學電算中心¸ cc.nctu.edu.tw 這個 MX RR 為例. 其中的 mx.NCTU.edu.tw ¸ 以及 relay.edu.tw 是位 於 TANet server 專用 channel (163.28.0.0) 上面的 E-mail relay hosts。
5.1.1 DNS 系統上的 MX RR 設定 $Origin cc.nctu.edu.tw. cc.nctu.edu.tw. IN MX 0 ccserv2.cc.nctu.edu.tw. cc.nctu.edu.tw. IN MX 0 ccserv6.cc.nctu.edu.tw. cc.nctu.edu.tw. IN MX 20 mx.NCTU.edu.tw. cc.nctu.edu.tw. IN MX 30 relay.Edu.tw. 上面的例子¸ 代表所有最終的 E-mail 是希望送達 ccserv6.cc.nctu.edu.tw o 或者 ccserv2.cc.nctu.edu.tw 這兩套系統其中之 一。但是¸ 因為網路環境以及單一系統瞬 間處理能力可能遭遇瓶頸¸ 因此我們將整 套系統規劃成為階層(hierarchy)分散式的 運作方式。 上面這幾行設定代表的意思 是¸ 如果一個 MTA (如 sendmail 之類)¸ 收到一封給像 [email protected] 這 樣的 E-mail address ¸ 那麼這個 MTA 根 據 DNS 上 MX RR 查證的結果¸ 會根據 優先權順序¸ 選擇轉送對象。 進行的步驟 大致如下: (1) 連最高優先權者 "ccserv6.cc.nctu.edu.tw", 或另一台(兩者優 先權一樣). DNS 系統會視當時環境¸ 丟給 remote MTA ¸ 一個優先連接對象。 萬一連不上¸ 或剛好太忙¸ remote MTA 就馬上改試另一個。 如果都連不上¸ 再選 2.
(2) 連優先權次高的 mx.NCTU.edu.tw (共有兩個) 處理情況¸ 同上。 如果無法順利交 寄¸ 再試 3. (3) 優先權最低者 relay.edu.tw 處理情況¸ 同上。 如果無法順利交寄¸ 稍後再從步驟 1¸ 重頭再來。整個流程¸ 會重覆進 行¸ 一直到下列兩種情況一之出現 ¸ 才停止。 系統傳送成功為止。 整個流程¸ 超過原送件系統設 定的處理時間(視 remote 系統 而定¸ 如 3 天 or 5 天)。 5.1.2 相關的 system log 記錄片段: a).底下是其中一部 relay (newsgate)代接 自國外來的 e-mail¸ 再轉到
'cc.nctu.edu.tw' 的例子
Nov 20 12:54:22 newsgate sendmail[20217]: MAA20217: from=<[email protected]>, size=6114, class=0, pri=36114, nrcpts=1,
msgid=<[email protected]. com>, proto=ESMTP, relay=grape.ease.lsoft.com [209.119.1.39] Nov 20 12:54:23 newsgate sendmail[20219]: MAA20217: to=<[email protected]>, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, relay=cc.nctu.edu.tw. [140.113.6.2], stat=Sent (MAA10963 Message accepted for delivery) b).底下是經由 newsgate 將國外來的 e-mail¸ 再轉到 'cc.nctu.edu.tw' 的例子
Nov 20 12:56:24 ccserv2 sendmail[10963]: MAA10963:
from=<[email protected]>, size=6315, class=0, pri=36315, nrcpts=1,
msgid=<[email protected] step.com>, proto=ESMTP, [email protected] [163.28.64.246] Nov 20 12:57:33 ccserv2 sendmail[10964]: MAA10963: to=<[email protected]> ,delay=00:01:09, xdelay=00:01:09, mailer=local, stat=Sent 備註 2: 各 TANet 區域網路中心¸ 可參酌以 往共識¸ 設立這一類 relay host ¸ 安置於 server 專用 channel (163.28.0.0)上¸ 開放 給臨近單位¸ 做為 mail relaying 之用。 不過¸ 有一點必須提醒大家注意。 對 於 mail relaying ¸ 以往多數的 MTA¸ 基 本功能是來者不拒。不過¸ 由於 E-mail SPAM 的猖獗¸ 現今的 E-mail 系統¸ 有 越來越多啟動 anti-relaying 的自我保護功 能。舉最近的 sendmail 8.9.x 為例¸ 內定方 式是以 relay domain 為主¸ 系統建置起來 之後¸除了有事先設定的 domain zone hierarchy 之外¸ 對於其他外來的 E-mail 轉信¸ 一概拒絕, 以防堵這一些愛在網路 上亂送大量 junk message 的不速之客。因 此¸ 在經過是當設定之後¸ 前面的 mx.NCTU.edu.tw¸ 以及 relay.edu.tw 做為 relay host ¸ 都不會去擋網路上¸ 要透過他 們來轉給 [email protected] 這樣的 e-mail。 這裏¸ 要強調的另一個意義就是¸ 在 設定其他單位的 E-mail 系統¸ 做為我們 本單位的 relay host 時¸ 必須確定該 host 的管理者同意這個行為。
備註 3 : mail relay 的 sendmail.cf 設定 這裏我們以 sendmail 8.9.x 為例¸ 可 以有兩種作法:
(1) /etc/mail/relay-domains {粗略設定} 將允許經由這個 host 轉接的
domain hierarchy ¸ 定義在這一個 檔中¸ 是一個全體適用的做法。 例如¸ 我們在 mx.NCTU.edu.tw 上的 "/etc/mail/relay-domains" 的 內容如下: nctu.edu.tw (2) /etc/mail/access {dir¸pag; db} access 這個 database¸ 可以設定的 彈性更大。 可以設定 E-mail address¸ domain name¸ network(IP address) 等¸ 並有 OK¸ relay¸ reject¸ discard 等各種功能。 而且¸ 每一 種功能¸ 還可以對部份的 domain hierarchy 個別處理。 底下是一個 例子:"/etc/mail/access dialup.seed.net.tw REJECT ts.hinet.net REJECT et4.thit.edu.tw relay mail.NHCTC.edu.tw relay 備註 4 : {mx.NCTU.edu.tw} $Origin nctu.edu.tw. mx IN A 163.28.64.11 mx IN A 140.113.54.2 其中¸ mx.NCTU.edu.tw 這個 domain name entry ¸ 是代表兩個 IP address ¸ 事實 上是代表兩個不同 Host。也就是¸ 163.28.64.11 <==> mrelay.NCTU.edu.tw. 140.113.54.2 <==> wproxy2.NCTU.edu.tw. 這樣做的用意¸ 是由這兩個不同的 Host¸ 來共同負責 relaying (轉接/轉送)的 服務。至於某一個 transaction/connection 到底由哪一個 host 連上¸ 則完全取決於 當時的網路環境與狀況而定。包括: 哪一個 DNS server 被問到 ( round-robin 以及 Round-Trip-Time)。 被詢問的 DNS server¸ 丟出哪一個 IP entry ( round-robin ) 如果某一個 host 暫時無法連上¸ 諸 如網路斷線¸ 或該系統太忙¸ 無法進 一步 fork 出可用的 process ¸ 這時 remote 系統¸ 接下來就只好再連上¸ 另一個系統。
5.2 Out-going mail 的處理 ( Mail Forwarder )
因為網路條件有差距的關係¸ 為了順 利將 E-mail 往外送¸ 我們將許多個別系 統的 MTA( sendmail) 設定成¸ 所有外送 的 E-mail 都直接轉到位於 TANet server channel (163.28.0.0) 的 專用 mail forwarder ( mail-fwd.nctu.edu.tw)上。 也就 是¸ 這一些個別 E-mail server 並不會直 接去查詢 DNS 上的 MX RR¸ 不會嘗試 自己去送 E-mail ¸ 所有進一步的轉送工 作¸ 都交由這些 mail forwarder 來做。於 是¸ 為了兼顧 performance ¸ reliability 等 因素¸ 我們特別安排兩套 server host ¸ 透 過 DNS 系統¸ 在相關的 Domain Zone 上 設立兩個 mail-fwd.nctu.edu.tw 的 domain name entry。 至於個別系統到底經由哪一 forwarder 送出信件¸ 則視當時該系統查 詢 DNS 所得的結果而定。 因為 DNS server 有 round-robin 的功能¸ 因此除非
client host 有 DNS caching 功能¸ 基本上 兩者都有相當的機會¸ 被個別系統使用 到。 5.2.1 {mail –fwd.nctu.edu.tw} $Origin nctu.edu.tw. mail-fwd.nctu.edu.tw. IN A 163.28.64.11 mail-fwd.nctu.edu.tw. IN A 140.113.54.2 5.2.2 個別 MTA ( e.g. sendmail ) 的配
合設定 "/etc/mail/sendmail.cf ": # Smart forwarders DS mail-fwd.nctu.edu.tw 備註 6: 在這一些 163.28.0.0 的 relay server 上¸ 則不再另外設 mail forwarder. 也就是¸ 該系統上 sendmail.cf 的 DS 不 必定義。 由這一些 server 透過 DNS 中 MX RR 的查詢¸ 嘗試直接做最後的信 件轉送(如果不行的話¸ 則轉由 remote host 的 relaying host 代收)。
5.2.3 相關的 system log 記錄片段: a).底下是 ccserv6 經由 newsgate
(mail-fwd.nctu.edu.tw) 往外轉出去的 e-mail.
Nov 20 13:31:40 ccserv6 sendmail[14984]: NAA14984: from=<[email protected]>, size=1856, class=0, pri=31856, nrcpts=1, msgid=<[email protected] ctu.edu.tw>, bodytype=8BITMIME, proto=ESMTP, relay=Lawrence.Dorm3.NCTU.edu.tw [140.113.183.236] Nov 20 13:31:40 ccserv6 sendmail[14986]: NAA14984: to=<[email protected]>, ctladdr=<[email protected]> (20491/12), delay=00:00:01, xdelay=00:00:00, mailer=relay, relay=mail-fwd.nctu.edu.tw. [163.28.64.246], stat=Sent (NAA21415 Message accepted for delivery) b).經由 newsgate (mail-fwd.nctu.edu.tw) 往外轉出去的 e-mail.
Nov 20 13:29:39 newsgate sendmail[21415]: NAA21415:
from=<[email protected]>, size=2058, class=0, pri=32058, nrcpts=1, msgid=<[email protected] u.tw>, bodytype=8BITMIME, proto=ESMTP, relay=ccserv6.cc.nctu.edu.tw [140.113.6.6] Nov 20 13:29:44 newsgate sendmail[21417]: NAA21415: to=<[email protected]>, delay=00:00:05, xdelay=00:00:05, mailer=esmtp, relay=cc.ntnu.edu.tw. [140.122.65.9], stat=Sent (Mail accepted) 5.2.4 特別注意事項 : {關於 mail relay 與 mail forwarder 設定} 這裏必須要提醒一下¸ 如果某一系統 被當成 mail relaying host ¸ 則這個 host ¸ 就不能再另設 DNS forwarder, 將多數 mail 轉送出去。 或者說,不能隨意亂設 mail relay。因為¸ 這樣一不小心¸ 常會演 變成為 mail forwarding loop。 我們已經碰 過不少實際的情況。
底下是一個例子: { 假想的 } 問題 host 的 mail relay 的設定
( DNS )
$Origin NCTU.edu.tw.
tst.Nctu.edu.tw. IN 0 tst.Nctu.edu.tw. tst.Nctu.edu.tw. IN 20 ns1.nctu.edu.tw.
相關系統 mail forwarder 的設定 另一方面¸ ns1.NCTU.edu.tw 這一臺機 器¸ 因為不在 163.28.0.0 專用 channel 上, 所以目前都設定成將往外的信件, 轉送到 mail-fwd.NCTU.edu.tw. 上。 上面這樣的設定¸ 平常 tst.NCTU.edu.tw 連得上時¸ 看不出有什麼問題。但是¸ 一 旦 tst.NCTU.edu.tw 連不上¸ 問題就來了。 我們來看看¸ 實際的情況: (1) 某 remote host 經由 DNS MX RR 查 詢 tst.NCTU.edu.tw¸ 第一順位¸ 打算 將 mail 送 tst.NCTU.edu.tw. 但是¸ 一 連的結果¸ 發現連不上。 ( 例如¸ 停 電¸ 維修¸ 當機¸ …等原因¸ 暫時連不 上。) (2) 於是¸ 根據所得到的 MX RR¸ 接下來 就試連 ns1.NCTU.edu.tw 這個 relay host ¸ 也很幸運地順利連上了。 接下 來就將該 e-mail 交 ns1.NCTU.edu.tw. (3) 當 ns1.NCTU.edu.tw. 收到這樣 e-mail 之後¸ 由於預先設定成¸ 所有的 E-mail 都轉交由 mail-fwd.NCTU.edu.tw 進一步處理¸ 於是該 e-mail 接下來就被轉往 mail-fwd.NCTU.edu.tw. (4) 當 mail-fwd.NCTU.edu.tw. 收到這樣一 封 e-mail ¸ 根據 DNS 上的 MX RR 查詢¸ 接下來也會試著想直接連 tst.NCTU.edu.tw ¸ 但是就如同先前的 情況¸ 發現連不上。 (5) 於是¸ mail-fwd.NCTu.edu.tw 進一步再 試 ns1.NCTU.edu.tw. 這一個 relay host. 也順利連上¸ 於是該 e-mail 再 次被交回 ns1.NCTU.edu.tw。 (6) 如果 tst.NCTU.edu.tw 短時間內 (or 幾分終內)¸ 還是沒有恢復 (這樣的情 況¸ 在周末假日是常見的情況)¸ 於是 接下來的情況¸ 就是 ns1.NCTu.edu.tw. 和 mail-fwd.NCTU.edu.tw 這兩個機器 上的 MTA¸ 兩者會在步驟 3¸ 4¸ 5 之 間¸ 來回游走¸ 將該 e-mail 送來送去 ¸ 形成 mail forwarding loop。 這個情 況¸ 通常會持續到該 e-mail 超過 mail-fwd.NCTU.edu.tw 所設定的 mail hop 處理上限{一般的慣例大約是 17 站 ( e.g. hop count=17) }¸ 然後再由這 部 mail-fwd.NCTU.edu.tw 將該信件退 回給原寄件人¸ 結束這一筆糊塗帳。 所以說¸ 這樣一來¸ tst.NCTu.edu.tw. 管理者¸ 原先有設 MX RR 的用意¸ 完全 都白費了¸ 不但沒有 backup 的功能¸ 還 徒然造成 ns1.NCTU.edu.tw. 和 mail-fwd.NCTU.edu.tw 這兩系統¸ 以及所 在網路極大的負擔¸ 因為 sendmail process 的 priority 通常都相當高¸ 瞬間快速及連 續性的 disk I/O 以及網路成本¸ 很傷系統 資源。 因此¸ 如果瞭解這一些¸ 就應該知 道¸ mail relaying 可不是單方面¸ 在自己 管的 DNS domain zone 上¸ 隨便設設就好 了¸ 一不小心¸ 這裏所說的情況¸ 就弄出 來。 不可不慎 ! 陸. 結語 規劃建置具有 forwarding ¸ relaying ¸ caching 等功能的網路系統¸ 從網路發展 的歷史及長遠的觀點來看¸ 是非常自然且 必然的走向。目前¸ TANet 各單位對於 www proxy/caching server 的運用¸ 共識 已經相當清楚¸ 相關系統的建置也越來越 完備。然而¸ 其他諸如 E-mail ¸ DNS 等應 用¸ 有建置及使用這類轉接與轉送功能的 單位¸ 就少得很多。這方面所代表的意義¸ 可能是許多單位的網路系統管理者¸ 對這 一些功能設計¸ 還不夠熟悉。長期來看¸
任一連線單位的 E-mail 流量¸ 只會增加¸ 不會減少。如果儘憑一套單一的系統¸ 期 望能維持系統的順暢運作¸ 將會越來越困 難。所以¸ 為了順應大環境的變遷¸ 建構 一個組合系統是必然的走向。期望透過這 一些範例說明¸ 能夠幫助更多連線單位的 管理者¸ 深入瞭解這一些系統的運作¸ 繼 而能進一步協調 TANet 各區域網路中心 ¸ 再適當地安排規劃¸ 透過 server 專用 channel (163.28.0.0)¸ 以及妥善運用 DNS 的 MX RR 這兩項機置¸ 據此而得以建 構起一套能因應未來網路變遷¸ 更完善的 階層分散式 E-mail 使用環境。{ 全文 完 } 參考資料 (1) TANet 流量統計, 請參考 http://www.edu.tw/tanet/backbone/index.html (2) 教育部電子計算機中心簡訊, “TANe 全國 各單位與 Internet Traffic 統計”, 8805 期 (3) MRTG 即時流量統計, http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/m rtg.html (4) Cisco Netflow, 流量統計, 參見 http://www.cisco.com (5) 教育部電算中心 Netflow/MRTG 網路流 量統計系統, http://www.edu.tw:81/tanet/backbone/ (6) “Sendmail” 第 2 版, 作者 “ Bryan
Costales & Eric Allman” , O'Reilly & Associates (出版公司), January 1997 (7) “DNS and BIND” 第 3 版, 作者 ”Paul
Albitz and Cricket Liu”, O'Reilly & Associates (出版公司), September 1998. (8) RFC 1034, “Domain Names--Concepts
and Facilities” by P. Mockapetris, Nov-1987
