既然我們討論了設置，安裝，和測試一個 sendmail+IDA 系統的理論,讓我們花一些時間調查習慣性地發生在一個郵件主管上的事情。
遠程系統有時暫停。調制解調器或電話線失敗, DNS 定義由人的錯誤而不正確地被設置。網絡出人意料地下沉。在如此的情況中，郵件主管需要知道怎快速地，有效地，並且安全地讓郵件通過交替的線路流動，直到遠程系統或服務供應商能恢復正常的服務。
這章余下的部分打算向你提供最經常遇見了“電子的郵件緊急情況”的解決方法。
--------------------------------------------------------------------------------
把郵件提交給一位繼電器主機
為一台特別的主機或域提交郵件到一指定繼電器系統,你通常使用 mailertable 。
例如,為 backwood.org 提交郵件到他們的 UUCP 網關系統門,你將把下列入口放進 mailertable ：
--------------------------------------------------------------------------------
強迫郵件進入 Misconfigured 遠程地點
經常,因特網主機對把郵件放進 misconfigured 遠程地點有點困難。有幾種這個問題變體，但是一般的症狀是,郵件被遠程系統彈回或根本不到那裡。
因為你的用戶通常不在乎你不親自管理每一個系統范圍，這些問題能使本地的系統主管處一個壞位置(或知道怎讓遠程主管解決這個問題)。他們就知道他們的郵件沒有通過希望的接收器到達其他終端,並且你可能是有抱怨。
一個遠程地點的配置是他們的問題,不你的問題。在所有的情況中，確保不打破你的地點以便與一個 misconfigured遠程地點聯系。如果你不能在遠程地點上與 Postmaster 聯系讓他們用一種及時的方式修理他們的配置，你有兩個選擇。
成功地強迫郵件進入遠程系統，通常是可能的,盡管遙遠的系統是 misconfigured ，在遠程終端上的答復可能不工作...但是那是遠程主管的問題。
你只能修改你即將發出信息信封上的信頭,使用一個為他們的host/domain的domaintable入口,這導致發自你的地點的郵件中的錯誤信息正在被改正：
經常, misconfigured 地點“彈起”郵件寄回到發送的系統,並且有效地說“那個郵件不適合這個地點",因為他們沒有 PSEUDONYMNS 或在他們的配置中等價的設置。完全刪去從你的地點發送到他們的信息中的主機名和域信息,是可能的。
The！在下列 mailertable 把郵件發送到他們的遠程地點,使它在他們的 sendmail 上看來好像它局部地發自他們的系統。注意到,這僅僅改變信封地址,因此,合適的返回地址將仍然在信息上面顯示出。
不考慮,就算你把郵件裝入他們的系統，不保証他們能答復給你信息(他們被打破,記得...)但是然他們的用戶在他們的主管而上大叫,非你的用戶叫喊你。
--------------------------------------------------------------------------------
強迫郵件經由 UUCP 被轉移
在理想的世界(從因特網前景),所有的主機在域名服務中有記錄( DNS )並且將用充分合格的域名發送郵件。
如果你碰巧經由 UUCP 談話到如此的一個地點，你能強迫郵件通過點對點的 UUCP 連接，而非通過實質上通過 uucpxtable 的“undomainizing"它們的主機名的你的缺省郵件發送程序。
迫使UUCP發送sesame.com，你將把下列各項放在你的 uucpxtable中 ：
結果是，然 sendmail 將決定(經由在 sendmail.m4 文件的 UUCPNODES )你直接被連結到遠程系統並且將為用 UUCP發送的郵件排隊。
--------------------------------------------------------------------------------
經由 UUCP阻止郵件發送
相反的狀況也會發生。經常,系統可以有不經常被使用的直接的UUCP連接，或不作為可靠的並且總是作為缺省郵件或繼電器主機可獲得的直接的UUCP連接。
例如,在西雅圖區域有很多系統，它們當分區被釋放時，經由匿名的 UUCP 交換各種各樣的分區。這些系統僅僅在必要時談論 UUCP ,因此通過多重很可靠的跳躍和普通(並且總是可得到)中繼主機發送郵件通常更快並且更可靠。
阻止UUCP發送郵件到你直接被連結的一個主機，是可能的。如果遠程系統有充分合格的域名，你能象這一樣增加一個入口到 domaintable ：
這將與 FQDN 代替 UUCP 名字的任何出現，並且這樣在 sendmail.m4 文件由 UUCPNODES 行阻止一個匹配。結果通常是郵件將經由 RELAY_MAILER 和 RELAY_HOST發送(或 DEFAULT_MAILER )。
--------------------------------------------------------------------------------
在需求上運行Sendmail 排隊
很快地處理排隊的信息,僅敲打'/usr/lib/runq'。這與適當的選擇調用 sendmail，引起 sendmail 很快地運行過未解決的工作的排隊，而非等待下一個安排的運行。
--------------------------------------------------------------------------------
報導郵件統計
許多地點主管(以及他們為之工作的人)對過去到的郵件的體積、格式、及通過本地地點感興趣。有很多方法量化郵件通信量。
Sendmail 處理一個被稱為mailstats的實用程序，它讀一個叫 /usr/local/lib/mail/sendmail.st 的文件，並且報導信息的數字和使用 sendmail.cf 文件中的每個郵件發送程序所轉移了的字節的數字。這個文件必須被本地的主管手動地創建，從而為 sendmail記錄去發生。運行的總數被移動和再創造 sendmail.st 文件而清除。一種方法做下列事情：
可能最好的方法是，做一份關誰使用郵件和多少體積傳送過去，格式，以及通過本地的系統用syslogd（8）打開郵件調試的報告。通常,這意味著，從你的系統開始文件運行/etc/syslogd台程序(不論怎樣你應該正在做它),並且把行加到 /etc/syslog.conf ( 5 )看起來象下面這樣：
如果你使用 mail.debug 並且得到任何媒介到高郵件體積, syslog 輸出能變得相當大。從 syslogd 的輸出文件通常需要從 crond 在一個例程基礎上被旋轉或清除( 8 )。
有很多通常可得到的實用程序能總結從 syslogd 中記載的郵件的產量。眾所周知的實用程序之一是 syslog-stat.pl ,一個 perl 手跡，與 sendmail+IDA 來源散布了。
(http://www.fanqiang.com)
進入【UNIX論壇】
|
![[ 永遠的UNIX::UNIX技術資料的寶庫 ]](/images/title.gif)