[轉貼] 何謂 Mail eXchanger（MX）？
版面規則
p.s. 如果無法順利開啟媒體，那麼建議改用 IE 瀏覽器試試。
p.s. 如果無法順利開啟媒體，那麼建議改用 IE 瀏覽器試試。
[轉貼] 何謂 Mail eXchanger（MX）？
Mail eXchanger 簡稱 MX，定義於 IETF 的RFC 1035 中。主要用途在於使用郵件主機時，作為信件的轉遞站，用於一般主機是沒有多大的用途，但是對於 mail server 則有相當重要的影響。
談到 MX，就不得不談到 Email。Email 郵件其實是一個包含了 mail envelope 與 mail content 的訊息，整個 Email 訊息的架構如下所示：
而收發 Email 則是靠下面兩種軟體：
參考下面範例：
主機A在有信件送往主機 C 時，會先到 DNS 伺服器查詢主機 C 的 MX 記錄，當主機 A 找到主機 B 和主機 D 這兩個 mail exchanger 時，會先嘗試透過優先權較高（數值較小）的主機 B 送信件，若主機 B 當掉或無反應時，主機 A 會改透過主機 D 去送信，但是當主機D要這封信送往主機 C 時，一樣會到 DNS 查詢主機 C 的 MX 記錄，把信件轉往比自己優先權高的主機 B。此時若主機 B 依然當掉或無反應，那麼信件將會被放在主機 D 的郵件佇列（mail queue）中，等待時間再送往主機 B。因此雖然收信人的 Email 地址是user2@主機C，主機 A 還是會將信件送往主機 B 去。而主機 B 在收到這封信件後，發現收信地址主機是主機 C 而不是自己，它會將信件再轉往主機 C。
在上例中，主機 B 接受主機 A 轉來，但目的地卻是主機 C 的信件，並將之送往主機 C，我們稱主機 B 這個動作叫 Relay。
透過上面的說明可以瞭解 MX 在整個 Email 的傳遞過程中所扮演的角色，也因此 DNS 伺服器除了我們所知的 URL 與 IP 的對映外，同時也因為有包含 MX 記錄而有解析 Email 地址中的主機名稱的功能。
MX 記錄除了在 Email 傳遞扮演著重要的角色外，也應用在攔截垃圾郵件以及病毒的攻擊。在病毒的攻擊中，某些病毒本身程式具備著 SMTP 的功能，會利用自身攜帶的 SMTP 郵件引擎，以電子郵件方式將病毒散佈到每一個地址，它會以受感染電腦預設的 DNS 伺服器執一個 MX (mail exchanger) 查詢，以便為每一個收件者的郵件位址找尋合適的郵件伺服器。目前已知會利用此方式的病毒如：Atak.K 及其變種等一些透過電子郵件方式散佈的病毒。
而攔阻垃圾郵件的部分，隨著電子郵件的廣泛使用，垃圾郵件的問題愈發顯得日益嚴重。在對抗垃圾郵件上，雖然各廠商有不同的解決案，但目前仍未制定出統一的標準。以目前最常見的過濾方法是透過郵件過濾軟體，在伺服器端及用戶端進行垃圾郵件過濾，只是過濾只是其中一種作法而已，對郵件使用者並無多大助益。
而目前引發熱烈討論的解決方案為在伺服器層級針對 SMTP session 以及 mail header 做檢查及驗證，如此可以有效在伺服器就攔截下所有可疑的訊息，減少 mail 傳送到使用者並且又不須檢查郵件內容，不至於造成個人隱私權的問題。
由於垃圾郵件、病毒等郵件主要是以偽造寄件者身份來達成其目的，而現有的驗證方法如 PGP（Pretty Good Privacy）等，只包含了信件內容的驗證，對於 header 欄位如寄件者，並無法確保其真實性。因此，在伺服器端驗證的機制如 AOL 的 SPF（Sender Permitted From），主要目的在找出真正的寄件者身份。
AOL 的 SPF 方案，相當於是在網域伺服器反查 MX 記錄，一般的 MX 紀錄所儲存的是這個網域有哪些合法的收件 MTA，而 SPF 則可以讓網域管理者用來指定哪些 IP address 才是該網域合法的寄件 MTA。當收到一封新信件時，mail 伺服器經由 DNS 查詢即可得知該信件是否確實由信件中所宣稱的網域寄出而達到攔阻的效果。由此，MX 紀錄除了可視為「郵件路由」外，未來在防毒與 Spam 上也將是不可或缺的要素。
--
資料來源：
http://www.synnex.com.tw/asp/fae_qaDeta ... eqno=17451
談到 MX，就不得不談到 Email。Email 郵件其實是一個包含了 mail envelope 與 mail content 的訊息，整個 Email 訊息的架構如下所示：
- UA（User Agent）：用戶端的郵件收發程式。
常見的如 Outlook、Outlook Express 等收發 Email 軟體。 - MTA（Message Transfer Agent）：伺服端的郵件伺服器軟體。
如 Exchange、Post office 等郵件伺服器軟體。
- 當寫好信件內容按下傳送後，用戶端的 UA 便透過 SMTP 的通訊協定，將 Email 送給用戶端指定的郵件傳送伺服器做進一步處理（此處的郵件傳送伺服器為 send.com）。
- 收到信件的郵件傳送伺服器，如發現是給本地用戶（即xxx@send.com），就會直接傳送到此用戶的 mail spool 中儲存起來，等待用戶收信。如果收件人不在同一郵件伺服器內，則 MTA 會把這訊息轉送給其他的 MTA，每個彼此連接的 MTA 都必須提供一些儲存空間來暫存這些已接收但尚未傳送出去的訊息。
- MTA 如何將訊息轉到其他地方呢？首先 MTA 會向 DNS 查詢 recive.com 的 MX 紀錄，並嘗試與優先值（preference number）較低的 MTA 主機建立連線，如果連線失敗便會向 MX 中優先值次低的 MTA 主機進行連結，一旦連結成功便將訊息傳送過去。如果目的主機沒 MX 紀錄，MTA 便嘗試直接傳送 E-mail 訊息給目的主機。
- 當信件到達目的 MTA 後，如果有 E-mail 的別名會先做轉換（例如給 user2@recive.com 的信，其實都轉給 admin@recive.com），再送到收件人信箱。
- user2@recive.com 這個使用者再透過 UA 軟體，到信件最後到達的 E-mail 信箱收信或看信。若是 UNIX 系統 user2 可以使用 telnet 的方式登入到 MTA 上，使用 pine 或 elm 看信。但非 UNIX 的 MTA 而言，使用者可以把自己在 Mail Server 上的 E-mail 訊息下載回硬碟(此時 UA 採用 POP 協定或 IMAP 溝通)，然後離線慢慢閱讀。
- 主機C IN MX 50 主機B.test.com
主機C IN MX 100 主機D.test.com
參考下面範例：
- MX_02.jpg (18.59 KiB) 已瀏覽 432 次
在上例中，主機 B 接受主機 A 轉來，但目的地卻是主機 C 的信件，並將之送往主機 C，我們稱主機 B 這個動作叫 Relay。
透過上面的說明可以瞭解 MX 在整個 Email 的傳遞過程中所扮演的角色，也因此 DNS 伺服器除了我們所知的 URL 與 IP 的對映外，同時也因為有包含 MX 記錄而有解析 Email 地址中的主機名稱的功能。
MX 記錄除了在 Email 傳遞扮演著重要的角色外，也應用在攔截垃圾郵件以及病毒的攻擊。在病毒的攻擊中，某些病毒本身程式具備著 SMTP 的功能，會利用自身攜帶的 SMTP 郵件引擎，以電子郵件方式將病毒散佈到每一個地址，它會以受感染電腦預設的 DNS 伺服器執一個 MX (mail exchanger) 查詢，以便為每一個收件者的郵件位址找尋合適的郵件伺服器。目前已知會利用此方式的病毒如：Atak.K 及其變種等一些透過電子郵件方式散佈的病毒。
而攔阻垃圾郵件的部分，隨著電子郵件的廣泛使用，垃圾郵件的問題愈發顯得日益嚴重。在對抗垃圾郵件上，雖然各廠商有不同的解決案，但目前仍未制定出統一的標準。以目前最常見的過濾方法是透過郵件過濾軟體，在伺服器端及用戶端進行垃圾郵件過濾，只是過濾只是其中一種作法而已，對郵件使用者並無多大助益。
而目前引發熱烈討論的解決方案為在伺服器層級針對 SMTP session 以及 mail header 做檢查及驗證，如此可以有效在伺服器就攔截下所有可疑的訊息，減少 mail 傳送到使用者並且又不須檢查郵件內容，不至於造成個人隱私權的問題。
由於垃圾郵件、病毒等郵件主要是以偽造寄件者身份來達成其目的，而現有的驗證方法如 PGP（Pretty Good Privacy）等，只包含了信件內容的驗證，對於 header 欄位如寄件者，並無法確保其真實性。因此，在伺服器端驗證的機制如 AOL 的 SPF（Sender Permitted From），主要目的在找出真正的寄件者身份。
AOL 的 SPF 方案，相當於是在網域伺服器反查 MX 記錄，一般的 MX 紀錄所儲存的是這個網域有哪些合法的收件 MTA，而 SPF 則可以讓網域管理者用來指定哪些 IP address 才是該網域合法的寄件 MTA。當收到一封新信件時，mail 伺服器經由 DNS 查詢即可得知該信件是否確實由信件中所宣稱的網域寄出而達到攔阻的效果。由此，MX 紀錄除了可視為「郵件路由」外，未來在防毒與 Spam 上也將是不可或缺的要素。
--
資料來源：
http://www.synnex.com.tw/asp/fae_qaDeta ... eqno=17451