感謝我的導師錢飛教授(http://come.or.jp/~fei/)多年來對大工校園網建設的無私幫
助及對我的熱心指導，在他的幫助下，大工校園網建設取得了一定的成績，我也從他那學
到了很多，不僅是專業方面的知識，更多的是如何待人，如何作人。
--------------------------------------------------------------------------------
電子郵件管理
電子郵件是系統管理中最復雜的一項任務，但也是最為重要的一項任務，因為用戶使用
較多，作何一個改動都會對所有用戶帶來影響。同時大多數用戶認為電子郵件是UNIX中最有
價值的服務，尤其是在與Internet相連的系統上，電子郵件更為重要。
本文主要介紹如下內容：電子郵件是如何工作的，電子郵件相關術語，從何處得到更多
的信息，最給出配置sendmail的實例。
本文不介紹過復雜的郵件配置如多協議MAIL HUB(將郵件從Internet上轉發給UUCP或
DecNET)等。
一、電子郵件概述
1. Email環境的關鍵 -- sendmail
說明：
本部分內容摘自我的導師錢飛教授大規模計算機網絡主要服務之管理方法中之電子郵件
環境的生成方法。
用戶在實際利用Email時, 所要用到的命令一般為mail命令,或一些其他專用命 令.這些
直接與用戶有關的,用收發Mail的命令,或程序一般統稱為MUA(Mail User Agent).通
常,MUA的使用程序有恨多.例如,MH,MNEWS,ELM等等.
相對此,將來自MUA的信件轉發給指定的用戶的程序一般被稱之為 MTA (Mail
Transfer Agent). 在UNIX系統上,最名的MTA既是sendamil程序.sendmail是美國 加
州大學勃克利分校以Allman先生為中心的研究組所開發研制的優秀無償軟件.
sendmail(/usr/lib/sendmail)從各種MUA程序接收信件, 按照自身的控制格 式文件
(/etc/sendmail.cf)中所描述的規則向外界轉發信件. 因此,Email環境的成 敗將取決
sendmail.cf的設定是否合適.
MUA MTA
+---------------+
| /bin/mail |--->|
+---------------+ |
+---------------+ s +----------------------+
| /usr/ucb/mail |--->e ---->| /var/spool/mail/$usr |
+---------------+ n +----------------------
+---------------+ d +----------------------+
| MH |--->m ---->| /usr/bin/uux |
+---------------+ a +----------------------+
+---------------+ i +----------------------+
| mnews |--->l ---->| workstation |
+---------------+ | smtp +----------------------+
+---------------+ |
| elm |--->|
+---------------+
(圖1. Email系統的基本結構)
圖1中給出了Email系統的基本結構圖. Email系統看上去非常簡單,實際上卻非 常復雜.
首先,用戶需要利用mail等MUA程序編輯並發出信件. mail命令將為用戶所編輯 的信件
追加一些相應的信息(mail head,稱之為信件頭),然將該信件轉交給sendm ail程序處
理.sendmail對信件頭進行解析,調查該信件之轉發方法及信件接收地址.
如果信件接收地址為本地計算機之用戶地址,則將該信件追加到/var/spool/ma il目錄
下之相應用戶(與用戶名同名)文件中. 如果件接收地址為UUCP線路之另一側 之用戶地
址,則起動/usr/bin/uux經由UUCP轉發信件. 如果線路為TCP/IP線路,則利 用SMTP協議
與sendmail進行通信轉發信件.
2. Email環境的設計
在設計Email環境時,一般應遵循以下規則.
(1)Email服務器的集中
在多機網絡環境中應注意Email環境的統一配置,同一組織內的Email服務器不宜 過多.
否則,將增加管理負荷.
(2)共享信件緩沖池時,需要考慮資源競爭問題
在小規模網絡中,為了實現Email之共享環境, 管理人員一般利用NFS將各台UNIX 工作站
之信件緩沖池(/var/spool/mail)mount到Email服務器上.這時,需要注意 的是,信件系
統是一種典型的分布處理環境, 對共享文件如果文件自瑣(lock) 問題處理不夠得當,
有時將會引起重大事故(輕則丟失信件,重則損壞整個硬盤系 統).
(3)統一信件代碼
在傳統的UUCP中繼網絡上,網絡上各個主要Email中繼站上一般採用"7位通"(7位 代碼)
之傳遞方式. 因此,要透過廣域網傳遞多字節文字(中日文等)信件時,必須 進行適當的
代碼轉換.在日本,網絡上的省缺規定為7位JIS代碼. 這就是說,用戶 利用MUA發送信件
時,必須將信件文本轉換成JIS代碼文本,或利用專用JIS代碼視 窗,或編輯器來直接編輯
JIS碼文件.
近年來,隨著廣域網技術之發展,sendmail(V8)等MTA之改進,在點對點(point to point)
之TCP/IP線路上已經可以實現直接"8位通"之信件傳遞. 筆者在日常工作 中也常常與中
國國內網友直接交換GB代碼信件.但是,需要注意的是,在一些站點 上,由MTA版本過
陳舊, 經由這些站點轉發的8位碼會被自動過濾成7位碼(丟 掉高位碼),造成亂碼.因此,
這時,有必要確認接收側之MTA版本.可以相信在不遠 的將來,廣域網上之工作站都將陸
續切換成新的MTA(sendmail V8以上).
(4)不斷更新sendmail版本
sendmail作為無償軟件尚在不斷地進行著本本更新,以排除安全性問題.眾所周 知,利用
sendmail所存在著的一些漏洞來進行網絡非法侵入的hacking活動仍很盛行. 為了保護
您的系統避免外侵,建議各個網絡管理者跟蹤sendmail之版本,盡可能地採 用最新版.目
前的最新版本為sendmail.8.9.3.tar.gz.
(5)確定自己的郵件地址表現
各入網單位必須採用INTERNIC所指定的正式域名. 然根據自己所在域來確定 郵件地
址形式.
(6)確定線路類型
電子郵件系統的虛擬配信線路大致有以下4種.
a.機內直接配信
本地郵件傳送方式.本地計算機內的用戶向本地其他用戶傳遞信件.
b.UUCP線路配信
經由UUCP線路向其他計算機上的用戶傳遞信件.
c.SMTP配信
利用SMTP協議經由TCP/IP線路向其他計算機上的用戶傳遞信件.
d.域名服務器下SMTP配信
發送信件時用域名服務器來查尋收方地址,利用域名服務器所提示的MX記錄 來確定
接收側地址, 然用SMTP(或ESMTP)協議經由TCP/IP線路向其他計算 機上的用戶傳
遞信件.
二、電子郵件系統相關術語
電子郵件是從MUA(Mail User Agent)如mailx/Netscape Mail/Eudora開始的，在寫
完信件之MUA把信件轉發給郵件路由如sendmail, 郵件路由然將信息發送給MTA(Mail
Trasfer Agent);然此信件通過多個主機或網絡到達最終的投遞代理，由投遞代理將
郵件信息追加到接收者的郵箱文件中。
MUA：郵件閱讀或發送程序，如SVR4 mailx,elm, pine, 在郵件系統中用戶只MUA
打交道，MUA將郵件系統的復雜性與用戶隔離開。
Mail Router: 程序，從用戶處接收郵件並決定其目的地址以及如何到達目的地。
比如根據接收者的地址不同，電子郵件可能通過TCP/IP網絡發送，或者通過
UUCP或FAX發送。郵件路由使用接收者地址及其內部的配置信息來選擇一個最
好的MTA，然將郵信件轉給此MTA。
MTA(Mail Transport agent): 一個專用程序，其作用類似郵局，用在兩個機器
之間發送郵件。通常，一個機器上只有一個MTA。sendmail程序就是一個MTA，此
外還有其他MTA，如MMDF,Smail 3.x, qmail以及zmailer等。
MTA能夠理解特定網絡的EMAIL協議並通過網絡傳輸信件，如UUCP可通過UUCP連接
發送信件，但無法處理SMTP信件。
Delivery Agent(投遞代理):sendmail自己並不完成最終的郵件發送，它要調作其他
的程序來完成最的投遞服務。在SVR4系統中一般是/bin/mail.
實際情況是MTA，MUA以及Mail Router之間的區別往往比較模糊，如sendmail是一個
主要的Mail Router, 但同時又可以作為MTA，因為sendmail含有SMTP功能，可以在TCP/IP
網絡上傳送郵件，而在郵件接收端同樣也是由sendmail來完成最終郵件發送之前的準備工
作；此外一些MUA自帶一定的郵件路由功能，如Netscape Mail可以進行SMTP對話, 因此可
以實現對SMTP電子郵件的發送。
1、不同的MUA
mail: 用戶郵件目錄 /var/spool/mail/$USER, 變量: $MAIL
用戶轉發文件 $HOME/.forward
elm: 菜單驅動
pine: 字符界面的全屏幕操作MUA，應用較為廣泛，功能較elm強大。
Netscape Mail
Microsoft Outlook Express
2. 背景資料及其它相關資源
RFC 821 STMP
RFC 822 EMAIL格式規范
RFC 1425 ESMTP
RFC 1123 對主機的要求及對前面的RFC的一些修改
sendmail文檔
SIOG: Sendmail Installation and Operation Guide
建議仔細閱讀，重要指南
Sendmail: An Internet Mail Router
Mail System and Address in 4.2BSD
以上文檔sendmail源代碼包中自帶，由sendmail作者Eric Allmen編寫。
Sendmail, Second Edition, O'Reilly
By Bryan Costales with Eric Allman
UNIX Unleashed, System Administrator Edition,
Chapter 24: Mail Administratin
http://www.sendmail.org/
Sendmail FAQ
3. Internet的郵件協議
為了解sendmail所完成的不同工作,需要了解一些Internet協議,協議是軟件及硬件
進行通訊時所要遵守的標準.
一般來說協議是分層的,上一層協議使用底層協議作為基礎,如ip協議不需要進行
端到端的連接即可以進行數據傳送,而smtp或其他高層協議則要進行端到端的連接,
tcp建立在ip層之上,向telnet及smtp等提供面向連接的服務.總的來說,TCP/IP提供
Internet上的基本網絡服務,ftp/smtp各種應用層協議則是建立在TCP/IP基礎上的.分
層帶來的好處是諸如smtp/ftp高層應用程序無需處理數據包的傳輸與其他主機的連接
等底層任務,它們只需使用TCP/IP所提供的相應服務.
smtp定義如何在Internet上交換email信息,對smtp來說,只要兩端的程序(smtp
Server)能夠正常完成SMTP功能,就可以進行郵件交換,而不論服務器的軟硬件環境是否
相同.
sendmail完成smtp任務示例:
[hbwork@helius mirror]$ /usr/sbin/sendmail -v hbwork@dlut.edu.cn <
../.pinerc
hbwork@dlut.edu.cn... Connecting to gingko.dlut.edu.cn. via esmtp...
220 gingko.dlut.edu.cn ESMTP Sendmail 8.9.3/8.9.3; Thu, 10 Jun 1999
10:34:48 +09
00 (CDT)
>>> EHLO helius.dlut.edu.cn
250-gingko.dlut.edu.cn Hello helius.dlut.edu.cn [202.118.66.81], pleased
to meet
you
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
>>> MAIL From: SIZE=11795
250 ... Sender ok
>>> RCPT To:
250 ... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 KAA13174 Message accepted for delivery
hbwork@dlut.edu.cn... Sent (KAA13174 Message accepted for delivery)
Closing connection to gingko.dlut.edu.cn.
>>> QUIT
221 gingko.dlut.edu.cn closing connection
了解SMTP協議之實現, 請參考RFC 821.
三. DNS與Email之關系
1. 概述
計算機之間通訊使用IP地址,而用戶為了使用方便通常使用主機名,DNS則提供
主機名與IP之間的相互解釋及其他重要信息.
DNS: 分布式管理系統,將主機的命名及編號分發給各個自治區,如dlut.edu.cn
域只負責維護自己域內的所有主機的信息,當hosta.dlut.edu.cn要向
hostb.dlut.edu.cn發信或telnet時,只需查詢大工的dns服務器,dns服務器會將
hostb.dlut.edu.cn的ip地址返回給主機hosta,並且由edu.cn已經將dlut.edu.cn
域的管理授權給大工,大工的dns服務器為dlut.edu.cn之授權服務器,因此它可以回答
所有關dlut.edu.cn域的dns查詢,而不管查詢請求來自本域還是域外的主機.
當兩個域之間的主機發送電子郵件時情況如何呢? 比gingko.dlut.edu.cn上的
一個用戶向user@pub.dl.lnpta.net.cn發送郵件,大工的dns服務器對域
dl.lnpta.net.cn沒有任何了解,但它知道如何找到答案. 當域名服務器收到對非本域
內主機的請求時,將會向根域名服務器(root domain nameserver)請求對應域的授權
服務器的ip地址,如:
cn:
cn nameserver = NS.UU.NET
cn nameserver = IRAUN1.IRA.UKA.DE
cn nameserver = NS.EU.NET
cn nameserver = NS.SESQUI.NET
cn nameserver = NS.CNC.AC.cn
cn nameserver = DNS.EDU.cn
cn nameserver = NS.CN.NET
Authoritative answers can be found from:
NS.UU.NET internet address = 137.39.1.3
IRAUN1.IRA.UKA.DE internet address = 129.13.10.90
NS.EU.NET internet address = 192.16.202.11
NS.SESQUI.NET internet address = 128.241.0.84
NS.CNC.AC.cn internet address = 159.226.1.1
DNS.EDU.cn internet address = 202.112.0.35
NS.CN.NET internet address = 202.97.16.195
net.cn:
Server: helius.dlut.edu.cn
Address: 202.118.66.81
Non-authoritative answer:
net.cn nameserver = ns.cnc.ac.cn
net.cn nameserver = ns.cn.net
net.cn nameserver = ns.bta.net.cn
Authoritative answers can be found from:
ns.cnc.ac.cn internet address = 159.226.1.1
ns.cn.net internet address = 202.97.16.195
ns.bta.net.cn internet address = 202.96.0.133
lnpta.net.cn:
Non-authoritative answer:
lnpta.net.cn nameserver = ns.dcb.ln.cn
lnpta.net.cn nameserver = ns.lnsyptt.net.cn
Authoritative answers can be found from:
ns.dcb.ln.cn internet address = 202.96.75.68
ns.lnsyptt.net.cn internet address = 202.96.64.68
dl.lnpta.net.cn:
dl.lnpta.net.cn nameserver = ns.lnpta.net.cn
ns.lnpta.net.cn internet address = 202.96.64.68
pub.dl.lnpta.net.cn
Name: pub.dl.lnpta.net.cn
Address: 202.96.69.81
由上可以看出,dns是一個大的,分布式的數據庫;此數據庫含有主機到ip的映
射關系,此外DNS還含有其他信息,當sendmail發送郵件時,必須將接收者的主機名
翻譯為IP地址,這個由DNS中的A記錄實現,A記錄是關主機的最基礎數據;每二個
主機信息則是MX記錄, MX記錄指出願意為相應主機接收郵件的一個或多個郵件主
機列表.
2.郵件交換(MX, Mail Exchange)記錄
MX記錄的意義及用處是什?主機處理自己的郵件其不足是什?沒有mx記錄
豈不是更簡單一些? 事實剛好相反, 雖然郵件管理員的日常工作相當復雜,當MX
記錄可提供如下功能, 從而將郵件管理的工作簡單化:
. 對未連接Internet的主機(如UUCP Only Host)可以指明一個Internet主機
為其接收郵件,如同具有一個Internet地址一樣. 如主機hosta.dlut.edu.cn
與cerius.dlut.edu.cn具有uucp連接,如果者被定義為前者的MX, 則其他
Internet主機仍可向hosta.dlut.edu.cn發信,當ceruis.dlut.edu.cn收到對
hosta.dlut.edu.cn的信件時,會保持到與hosta建立連接,然通過UUCP將信
件轉發給hosta.
. 如UNIX主機pcsvr.dlut.edu.cn是一組PC的文件服務器,pc上有集成了SMTP客
戶端的MUA, 可以向外發信,但不能收信.如果此時發出的信件中的回信地址是
user@pc1.dlut.edu.cn,接收者如何回信? 這時可以將pcsvr.dlut.edu.cn作為
這些PC的MX.
. 主機因為各種原因而不能正常連接到網絡上,比如光纜損壞,當主機與Internet
的連接斷開,網絡上其他主機到此主機的郵件將存在郵件隊列中,如果指定時
時間內郵件未能發送,則郵件信息將返回給發送者. 此時如果設置一個MX主機
作為中間環節,MX主機將暫時接收對此主機的郵件,並在相應主機恢復正常之
將重新發送到你的主機, 這些MX主機可以在你的網域內或域外,或二者均有,當
然者要更好一些,因為當你的主幹網(WAN)損壞之域內的主機均不能正常工作.
. MX記錄隱藏了一部分的細節信息,允許以更為靈活的方式重新配置你的本地網.
如所有的人均知道我的郵件地址為hbwork@dlut.edu.cn, 不論那一台機器接收
對域dlut.edu.cn的信件都是一樣的,即使更改為主機名也無所謂;發信者感覺
不到有任何區別.
. 郵件發送及MX記錄
當一個SMTP Client向主機發送信件時,需要作的工作不僅是將主機名翻譯為ip
地址,它首先要查看相目標主機有無MX記錄,如果有MX記錄的話,將根據記錄中所
給出的權值對其進行排序,比如dns記錄如下:
dlut.edu.cn. IN MX 0 gingko.dlut.edu.cn.
IN MX 10 hazel.dlut.edu.cn.
IN MX 20 saint.synet.edu.cn.
SMTP Client先試權值較小者,如果失敗再試同網域內的備份MX,不行再試域外的
備份MX主機,這種設置能夠保証EMAIL正常運轉,即使外界連接不正常.
在收集並對MX記錄排序之,SMTP Client將取得MX記錄的IP地址,並按其優先級高
低進行郵件發送,這一點必須記住! 因為對user@domain.com來說,並不意味著有
一台主機domain.com,即使有也不一定是接收郵件的主機.
3. sendmail如何利用DNS
Sendmail如通過以下4個方面使用DNS
. 啟動時sendmail要通過dns來得到本地的正式主機名,然將此值賦值給宏$j(The
canonical hostname),如果dns還返回了其他名字,則這些別名將賦值給類(class)
$=w(sendmail所有版本均支持此類,list of our other names).
. 當另外一台主機連接到本機傳輸郵件時,本機的sendmail將通過DNS查詢對方主機
的正式名稱(FQDN).
. 當通過網絡發送SMTP郵件時,sendmail通過DNS查詢目標主機的主機地址(也可能是
多個地址).
. 當sendmail對每個規則RHS(右邊的規則)的$[和$]進行擴展時,需要查詢$[和$]之間
的主機名或IP地址.
(1)取得本地主機的正式名稱(FQDN)
所有版本的sendmail取得本地主機的正式名稱所採用的方法基本相同,首先是調作
gethostname(3)取得本地主機名,其返回值根據在/etc/hosts中的每一項是FQDN
還是短主機名而返回相應值.如果gethostname(3)調作失敗, 則本地主機名設置
為localhost; 然再調用gethostbyname(3)以獲得本地主機的正式名稱以及別名.
如果機器上沒有Bind Library, 或者暫時無法編譯或安裝新版本的sendmail,可以
修改sendmail.cf文件定義變量$j
Dmyour.domain.com
Dj$w.$m
(2)查詢遠程主機名
當sendmail開始作為daemon運行時,sendmail創建一個 ,並將自己bind到此socket上,
監聽進入的SMTP連接,當遠程主機連接到本地主機時,sendmail再使用accept(2)庫
程序來接收連接. accept過程向sendmail提供遠程主機的IP地址,sendmail然通過
gethostbyaddr(2)將IP地址轉化為對方的正式主機名.
由如下原因,sendmail需要知道對方主機的正式名稱:
. 將遠程主機名與本地主機名進行比較,以防止sendmaill連接到自己
. 在 HELP SMTP行中遠程主機所宣稱的主機名要與查詢得到的主機名相比較,如果二
者不同可以採取一定的處理,如拒收對方的郵件,這樣可以防止郵件炸彈.
. 將此值賦值給宏$s(Send host's name)
. 在很多log信息中(由loglevel(L)選項確定)及Received:頭中要包括有關遠程主機
的信息.
(3) 查詢目標地址
當sendmail準備連接到遠程主機進行郵件傳送時,它首先要進行一系列的檢查,所檢查
的項目因版本不同而有所差別.
從sendmail 8.1開始, sendmail檢查地址中的主機部分是否包括了方括號,如果有方
括號將忽略MX記錄的查詢.
從v8.8開始, sendmail首先檢查所選定的發送代理是否設置了F=0標志,如果設置了
此標志,則忽略對MX記錄的查詢.
通常F=0用Null Client配置,如下mc示例:
define('SMTP_MAILER_FLAGS','0')
FEATURE('nullclient','mail.dlut.edu.cn');
如果sendmail被允許進行MX查找(由sendmail.cf確定), 則sendmail使用res_search()
bind庫查找所對應的MX記錄,對這些MX記錄進行排隊,並選擇值最小的主機,如果V8找到
兩個同值的MX記錄,在排隊時會進行隨機排序. 在找到所有的MX記錄或根本沒有MX記錄
時,sendmail加入由FullBackMxHost(v)所指定的主機.
然sendmail會依次向MX主機表中的每個主機發送信息,一次一個主機,直到有一個成
功或全部失敗. 從sendmail V8.8開始,當此列表中的任一個主機返回5xx STMP代碼(永
久性錯誤), sendmail會對其進行特殊處理.
如果未找到MX記錄,則sendmail向指定的主機發送信息,如果均失敗,sendmail會試
圖向FallBackMxHost選項中所指定的主機發送信息.
不管有無MX記錄,sendmail通過gethostbyname(2)得到相應主機的網絡地址.
(4)設置MX記錄
MX記錄只是DNS中將一個主機的郵件轉到另外其他機器上的一種方法,具體各項含義請
參考DNS配置部分,其一般形式如下:
hostA IN MX 10 hostB
或:
hostA IN MX 10 hostA
IN MX 20 hostB
應該說明的是者中的第一條記錄並非多余,這種設置方法有其特定的作用.
記錄MX記錄所應注意的問題:
. MX記錄必須指向一個A(地址)記錄
hostA IN MX 10 hostB ; 錯誤設置!
IN MX 20 hostC
hostB IN MX 10 hostC
hostC IN A 1.2.3.4
. MX記錄指向CNAME記錄會引起額外的dns查找
hostA IN MX 0 mailHub
mailHub IN CNAME nfsmast
nfsmast IN CNAME hostB
hostB IN A 123.45.67.89
. MX記錄是非遞歸的
hostA IN MX 0 hostB
hostB IN MX 0 hostB
IN MX 10 hostC
如上示例中如hostA/hostB全部down掉時,hostA的信件不會發送到hostC上去,
否則會引起MX記錄的循環,如上面的配置加上 hostC IN MX 10 hostA.
因此如果hostC作HostA和HostB的MX,可配置dns如下:
hostA IN MX 0 hostB
IN MX 10 HostC
hostB IN MX 0 HostB
IN MX 10 HostC
. 廣義符MX記錄
*.dom.com. IN MX 10 hostA
不建議使用,因為容易引起混亂:
;domain is domain.com
*.domain.com. IN MX 10 hostB
hostA IN MX 10 hostC
hostC IN A 123.45.67.89
在Internet上廣義符MX記錄基本上沒有任何作用.
(5) MX記錄之緩存作用
雖然並不要求所有的主機均需要指定MX記錄，但最好對每個主機指定一個MX記錄。
假設有下面這樣一個DNS記錄(只有A記錄):
HostA IN A 123.45.67.89
當sendmail第一次查找此主機時，它將會查詢本地的DNS服務器以得到HostA的所
有記錄，由只有一個A記錄，sendmail只得到HostA的主機地址。
但是應該知道的是請求所有的記錄會使本地DNS服務器將這些信息cache起來，當
下一次sendmail查詢同一主機時，DNS將從其cache中返回一個A記錄，這要比重新查找
快並且能夠減少Internet上的網絡流量。這個cache信息是一個非權威(noauthoritative)
數據，因為它只是一個拷貝，並且不包含任何MX記錄。
當sendmail接收到一個沒有MX記錄的非權威數據時，sendmail會強制進行一次DNS
查找，這次它指定查找MX記錄，此時仍然沒有MX記錄，因此sendmail也得不到相應的
MX記錄。
由HostA沒有MX記錄，每當向此主機發送信件時都需要進行一次DNS查找，如果
HostA是一個郵件任務非常繁忙的郵件主機，由沒有DNS數據中的MX記錄，在Internet
上會導致很多sendmail因為請求這種無意義的MX查詢而浪費很多帶寬。
因此強烈建議對Internet上的每個郵件主機(最好所有主機)至少有一個MX記錄，
這時你可以將MX記錄指向主機本身，如：
HostA IN A 123.45.67.89
IN MX 0 HostA
上面的配置不會影響HostA的郵件接收，但可以減少DNS的查詢數量。
(6)含糊的MX記錄(RFC974)
對如下DNS配置：
foo IN MX 10 HostA
IN MX 20 HostB
IN MX 30 HostC
如果主機B向foo發信時，將會丟棄DNS記錄中所有權值等或大自身權值的MX記錄，
也就是說信件將發信較HostB的權值小的主機， 這樣可以防止HostB錯誤的將信件發送
給自己。
可以配置HostB將foo作為本地主機的一個別名，但這種配置會導致HostB對foo將不
作任何MX記錄的查找，因為它認為到foo的郵件是本地郵件。
問題是如果HostB的配置認為foo為非本地郵件時，如果存在如下DNS配置：
;<- no HostA
IN MX 20 HostB ;<- Mail from HostB to foo
IN MX 30 HostC
按照RFC974的解釋，這時將會出現問題，因為沒有MX記錄，sendmail對此可以使用
選項TryNullMXList(w)進行控制(具體說明略).
4. 郵件頭地址(Head Address)和信封(envelope)地址
二者的區分相當重要，因為Mail Router對其處理不同，這與郵局對普通信件的處
理很相似，郵局只關心信封上的地址，而不管信封內復印件中的標頭地址。
在這一點上SMTP Client與郵局工作極為相似。示例如下：
To: betty@gznet.edu.cn, webmaster@sun.com
發信時只復制一個地址到信封，而不是二者均復制；否則會造成重復發送
(gznet.edu.cn會發送一份到sun.com).
解決方法：
在郵件信封中只列出一個主機的接收者地址，如同郵局寄信一樣，一封信可以寄
給一個辦公室的兩個人，但接收者收到的郵件頭中會列出所有收信人的地址，但MTA
不對其作任何處理。
此外郵件別名的使用也是影響對兩個地址分別處理的一個原因，假如aliasuser含有
4個用戶: user1, user2,user3,user4, 向aliasuser發信時sendmail會將此別名進行展
開，並建立一個包含所有接收者的信封。根據這些名字是否還是別名或者是否有可能在
其他主機上，原始信息可能展開為4個不同的信封並發往4個不同的主機，而每個信封只
含有接收者名字，但原始信息將沒有任何變化，含有aliasuser(當然，為了能夠正確回
信，郵件地址改為aliasuser@your.dost.domain）。
下面的一個示例將以另一種方式顯示信封地址可能與信件頭地址不同，sendmail
允許你在命令行上指定接收者地址，假設有如下信息內容：
$cat letter
To: null recipient <>
Subject: Head and Envelope address
Testing
通過如下命令發送此郵件(請使用自己的真實login).
$sendmail hbwork < letter
這時雖然在郵件頭中沒有收信人地址，但你同樣可以收到信件，因為在信封上含有
你的地址，除非你使用了-t標志，sendmail將用你在命令行上指定的地址構造信封。
信封地址與郵件頭地址不一定要完全一樣。
四. sendmail所完成的工作
為了更好地理解如何設置sendmail, 需要搞清楚sendmail所完成的各種任務,以
及sendmail是如何與其他MUA一起協調工作的.(MUA,MTA,Mail Router, Delivery Agent,
SMTP Client, SMTP Server). sendmail可以作為一個Mail Router, SMTP Client以及
SMPT Server, 但並不完成最的郵件發送.
1. sendmail作為郵件路由(Mail Router)
首先, sendmail是一個Mail Router, 完成郵件收集,檢查收信人地址,並確定發送的
最佳方式. sendmail是通過如下方式完成這一工作的:
sendmail自身可以得到一些它所需要的信息,比如當前時間以及它所運行的主機名,
但大多數信息則需要由管理員提供;這些信息主要是通過其配置文件sendmail.cf文件
提供. sendmail.cf文件的使用使得對sendmail的配置極為靈活,同時也具有了相當強
大的功能,但sendmail.cf文件對大多數用戶而言相當難懂, 格式及其復雜.此文件
描述了如何對各種郵件進行處理, 從sendmail v8開始,其源代碼發行中包含了一些
低層的模塊化配置文件,用戶可以通過這些模塊化的配置文件較為方便的定制自己的
sendmail.cf.
大多數情況下可以利用sendmail所提供的模塊化配置很容易地建立自己的配置
文件; 同時sendmail.cf也提供了很多示例文件,在進行sendmail配置時完全可以在
這些示例文件的基礎上完成.
對絕大多數管理員而言,從頭開始寫自己的sendmail.cf文件是幾乎不可能實現也
是一件非常可怕的任務,應盡可能避免這種情況.
2. sendmail作為MTA - 客戶端(發送者)和服務器(接收者)
郵sendmail能夠處理SMTP(V8同時可以處理ESMTP),因此它可以作為MTA. 由SMTP
是一個面向連接的協議,因此總是由客戶端和服務器組成(與就是一個發送者和一個接收
者). SMTP Client向SMTP Server發送郵件,SMTP Server不斷地監聽相應主機的SMTP
端口. sendmail可以作為SMTP Client和SMTP Server,當作為MUA運行時, sendmail
成為一個SMPT Client, 可以和SMTP Server(運行的不一定是sendmail)進行SMTP對話.
當系統啟動時sendmail以守護進程啟動,保持連續運行,監聽SMTP端口以接收進行
的郵件,這時sendmail成為SMTP Server.
3.sendmail不是最終的發送代理
sendmail並不完成最終的投遞工作, sendmail會很聰明地將這些任務留給其他程序
去完成.作為一個龐大而又復雜的程序,為了完成對所有用戶的郵件發送,sendmail通常
需要以root身份運行,在一定程度上這會給系統的安全帶來威脅(事實上sendmail過去
一直存在安全方面的問題),如果最的郵件發送也由sendmail完成的話,將會額外增加
sendmail的復雜性及安全問題.
五. sendmail的其他輔助文件
sendmail依靠多個輔助文件來完成其工作,最重要的是配置文件sendmail.cf和別名
文件aliases; 統計文件sendmail.st可有可無, 當然這取決你是否需要這些統計資料;
sendmail.hf是SMTP幫助文件,當sendmail作為SMTP Server時需要這個文件(大多數站點
也確實是這樣作的).當然此外還有其他一些輔助文件,具體請參考SIOG.下面我們對別名
文件和sendmail.cf文件進行討論.
1. 別名文件
sendmail在進行郵件發送之前首先檢查接收者地址是否為別名,如每個Internet站點
應該有一個郵件管理員postmaster,以方便在郵件故障時與其聯系,但實際上大多數站點
上並沒有postmaster這個用戶帳號,而是將postmaster的信件轉給郵件管理員個人,比如
albin與hbwork兩個個負責管理Email,則在別名文件中應含有如下一行:
postmaster: albin,hbwork
事實上別名文件可以嵌套,sendmail在進行別名替換時會重復處理直到找到最的接
收者.
在別名文件中,左邊必須是本地上的郵件別名,因此不能使用@主機,只能列出帳號,
右邊則可以使用完全的郵件地址.
此外郵件別名文件中可以包含另外一個文件,如:
alises::include:/etc/mail/filealiases
文件/etc/mail/filealiases中每行為一個郵件地址. 通常文件用保存經常變化
的郵件列表用戶,可者是其他管理所管理的帳號.
其他兩種郵件別名記錄:
使用管道將郵件轉到其他程序處理:
list-request:|/usr/local/bin/auto_reply
轉到其他文件:
nobody: /dev/null
相關命令:
更改別名文件使用newaliases或sendmail -bi建立郵件別名文件的二進制數
據文件.
2. 本地主機名文件
定義類$w,即本主機所要接收郵件的主機名列表,如希望郵件服務器接收如下形式的
郵件:user@hosta.dlut.edu.cn, user@dlut.edu.cn, user@dlrin.edu.cn, 則類$w應該
包包含hosta.dlut.edu.cn, dlut.edu.cn, dlrin.edu.cn, 通常此文件名為
sendmail.cw,可通過如下查找:
$egrep "^Fw" sendmail.cf
Fw/etc/mail/sendmail.cw
如上所述情況的sendmail.cw文件內容如下(每行一個記錄):
hosta.dlut.edu.cn
dlut.edu.cn
dlrin.edu.cn
3. 郵件服務器允許中斷的域或主機(hosts that will permit relaying).
從sendmail 8.9開始加強了對出件中繼的控制,默認情況下不對第三方進行郵件轉發,
需要指定服務器所接受的客戶端(PC?)域名或ip地址,以允許本網內的其他用戶通過此
郵件服務器向外發信.
$egrep "^FR" /etc/mail/sendmail.cf
FR-o /etc/mail/relay-domains
此文件內容為郵件服務器同意對其進行郵件轉發的主機地址或域名,如同一局域網內
的用戶或同網域內的用戶通過此郵件服務器向外發信(Netscape Mail/Microsoft Outlook
Express 配置中的SMTP Server), 則在此文件中應該加入本網絡用戶的域名或IP地址,
如:
dlut.edu.cn
202.118.66
具體說明請參考sendmail SIOG.
4.常用文件及目錄屬性
從sendmail 8.9以對目錄的權限檢查更為嚴格,下面是常見目錄的屬性:
路徑 類型 Owner Group Mode
/ 目錄 root root 0755
/etc 目錄 root root 0755
/etc/mail 目錄 root root 0755
/etc/mail/sendmail.cf 文件 root root 0644 or 0640
OS/etc/mail/sendmail.st 文件 root root 0644
OH/etc/sendmail.hf 文件 root root 0444
OA/etc/mail/aliases 文件 root root 0644
/etc/mail/aliases.* 文件 root root 0644
F/path 目錄 root root 0755
F/path/file 文件 n/a n/a 0444 or 0644
/var 目錄 root root 0755
/var/spool 目錄 root root 0755
OQ/var/spool/mqueue 目錄 root root 0700
:include:/path 目錄 root root 0755
:include:/path/list 文件 n/a n/a 0644
(http://www.fanqiang.com)
進入【UNIX論壇】
|
![[ 永遠的UNIX::UNIX技術資料的寶庫 ]](/images/title.gif)