Linux網路管理員手冊(13) 第十三章 電子郵件 (轉)

Linux網路管理員手冊(13) 第十三章 電子郵件 (轉)[@more@]管理員手冊(13)
2000-07-30 20:06
釋出者：tobull@21cn.com">netbull 閱讀次數：1143 翻譯：趙炯
gohigh@shtdu.edu.cn


第十三章 電子

自從第一個網路被設計出來，連網最顯著的用途之一就是電子郵件（eletronic mail）。它是從將一個從一臺機器複製到另一臺機器的簡單服務開始的，並將該複製的檔案新增到接收者的mailbox檔案中。本質上來說，這仍然是所做的全部工作，儘管不斷增長的網路及其複雜的需求以及它的不斷增大的訊息負載量已經促使要求更加精心製作的方案。
已設計出了各種郵件的標準。Internet上的站點始終堅持 822中的設計，並被描述與機器無關的傳輸特殊字元方法的某些RFC所擴充，等等。對於“多郵件”的更多思考目前也已作出，這涉及到有關在郵件訊息中包含圖形和。另一個標準，X.400，也已被CCITT定義。
有許多UN*X的郵件傳輸被實現。其中最為著名的是Berkeley大學的，它被用於很多平臺上。最初的作者是Eric Allman，他現在又再次積極地工作於sendmail小組中。有兩個sendmail-5.56c的Linux移植版本，其中之一將在第15章中討論。目前正在開發的sendmail版本是8.6.5。
Linux最常用的郵件程式是smail-3.1.28，是由Curt Landon Noll和Ronald S.Karr編寫和版權所有。在大多數Linux發行版中都包含這個程式。下面，我們將簡稱它為smail，儘管它還有其它完全不同的版本，但我們在這裡並不討論它們。
與sendmail相比，smail就顯得非常簡單。當對於一個沒有複雜路由要求的小站點處理郵件時，這兩者的就非常相近。然而，對於大型站點，sendmail總能高出一籌，因為它的方案是非常靈活的。
smail和sendmail兩者夠支援一族配置檔案，它們都需要進行自定義（定製）。除了郵件子系統執行所必要的資訊以外（比如象本地主機名），還有許多引數需要調整。Sendmail的主要配置檔案開始是非常難理解的。它看上去就好象你的貓在按下了shift鍵的鍵盤上打過盹。smail的配置檔案就非常結構化並且比sendmail的容易理解，但沒有給予很強的調整郵件箱效能的能力。然而，對於小型的UUCP或Internet站點，它們的配置所需要的工作基本上是一樣的。
在本章中，我們將討論什麼是郵件以及作為一個管理員你要涉及什麼問題。第14章和第15章將對第一次設定smail和sendmail給出指導。那裡所提供的資訊已足夠讓一個小型站點工作起來，但是還有許多的選項，你可以在你的旁花費很多快樂的時間來配置這些奇妙的特性。
在本章的最後，我們將概要地討論elm的設定，這是一個許多UN*X系統（包括Linux）非常通用的郵件使用者代理程式。
有關Linux上電子郵件方面問題的更多資訊，請參考Vince Skahan的Electronic Mail HOWTO，這是定期投遞到comp.os.linux.announce上的。Elm、smail和sendmail的源程式發行版同樣也包含了非常廣的文件資料，能夠解答設定它們時所遇到的大多數問題。如果你在尋找有關電子郵件的一般性資訊，有許多RFC涉及這個方面。它們列於本書後的參考書目中。

13.1 什麼是郵件訊息？
一個郵件訊息是由訊息體—它是傳送者所寫的文字、以及指明收信者的特定資料、傳輸介質等等組成，非常象信封上所見的資訊。
這些管理用的資料可以分成兩類；第一類是與特定傳輸介質相關的資料，就象發信者和收信者的地址。因此它們被稱為envelope。在訊息傳輸途徑中，它們可能會被轉換。
第二類是處理郵件訊息所需的任何資料，它們並不是針對任何傳輸機制的，比如訊息的主題行（subject line）、所有接收者列表、以及訊息傳送的日期。在許多網路中，將這些資料添置到郵件訊息中已成為了標準，形成所謂的郵件頭（mail header）。它與郵件體（mail body）之間相隔一空行。[1]
UN*X世界中的很多郵件傳輸使用一個RFC 822中指定的頭[標題]格式。它的最初目的是在ANET上的使用指定一個標準，但是由於它被設計成是與任何環境都獨立的，它很容易地被其它網路採納，包括許多基於UUCP的網路。
然而，RFC 822僅是最偉大的公共奠基石。現有更多的標準已被構想出來以應付不斷增長的需求，比如，資料、國際字符集的支援、以及多媒體郵件擴充套件（MIME）。
在所有這些標準中，標題[頭]由幾行組成，並由換行符來分割。每行是由從第一列開始的欄位名、和由一個冒號和一個空格分割的欄位本身組成。每個欄位的格式和語義是隨欄位名的不同而有變化的。如果下一行是以一個TAB開始的，表示是標題欄位的續行。各欄位的順序是隨意的。
一個典型的郵件標題看上去象這樣的：

From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994
Return-Path:
Received: from brewhq.swb.de by monad.swb.de with uucp
(Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 MET DST
Received: from ora.(.ora.com) by brewhq.swb.de with smtp
(Smail3.1.28.1 #28.6) id ; Tue, 12 Apr 94 21:47 MEST
Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Arp 94 15:56 –0400
Date: Tue, 12 Apr 1994 15:56:49 –0400
Message-Id: 199404121956.PAA07787@ruby
From: andyo@ora.com (Andy Oram)
To: okir@monad.swb.de
Subject: Re: Your RPC section

通常，所有所需的標題欄位都是由你所使用的郵件程式介面產生，象elm、pine、much或mailx。然而有些欄位是可選的，可以由使用者自己加上去。例如，elm允許你編輯部分訊息頭[標題]。而其它的則是由郵件傳輸軟體加上去的。常用的標題欄位以及它們的含義如下所示：

From: 含有傳送者的email地址，以及可能還有“真實名字”。這裡使用了一個格式的完整zoo。

To: 這是接收者的地址。

Subject: 用幾個詞描述郵件的內容。起碼這是應該做的。

Date: 郵件傳送的日期。

Reply-To: 傳送者指定接收者回信所發往的地址。對於你有幾個帳號，但是隻想在你常用的帳號下接收大量的郵件，此時這個欄位是很有用的。該欄位是可選的。

Organization: 產生郵件的機器所屬的組織。如果你的機器是屬於你個人的，你可以空著該欄位，或者插入“個人”（“private”）或某些完全無意義的東西。這個欄位是可選欄位。

Message-ID: 產生郵件的系統的郵件傳輸程式生成的字串。對於這條訊息來講是唯一的。

Received: 處理你的郵件的每一個站點（包括髮送者和接收者的機器）在標題中插入的欄位，給出它的站點名稱、一個訊息id、收到該訊息的時間和日期、從哪個站點來的以及使用了哪個傳輸軟體。根據此，你可以跟蹤訊息走過的路由，並且如果出了差錯你可以抱怨的負有責任的相關人士。

X-anything: 以X-開頭的標題行對任何郵件相關的程式都是不起作用的。它是用於實現還沒有寫入或不可能寫入RFC的額外的特性的。例如，它用於Linux Activists郵件列表中，其中，是用X-Mn-Key: 標題欄位 來選擇頻道的。

這個結構的一個例外是最開頭的一行。它以關鍵字From開始，緊接著是一個空格而是一個冒號。為了與普通的From:欄位相區別，它通常被引用為From_。它包含訊息所參與的UUCP大宗路徑形式（下面將作解釋）的路由、最後一臺接收訊息的機器處理訊息的時間和日期以及一指明從哪臺主機接收來的可選部分。由於每個處理過這個訊息的系統都會生成這個欄位，所以它通常包括在信封資料下。
因此From_欄位與某些老式的郵件程式是向後相容的，但已不再經常使用，除了郵件使用者介面程式還要依靠它來確定使用者郵件箱中一個訊息的開始處。也是為了消除以“From ”開始的訊息體中的行所帶來的潛在問題，在它之前放置“>”以避免任何這樣的現象出現，這已經成為一標準方法。

13.2 郵件是如何投遞的？
一般來講，你要使用一個郵件介面程式象mail或mailx來編寫郵件；或者使用更為複雜的象elm、mush或pine。這些程式統稱為郵件使用者代理（mail user agents），或簡稱MUA。如果你發出了一個郵件訊息，那麼在大多數情況下介面（介面）程式會將它傳遞給另一個程式去進行投遞。這個程式稱為郵件傳輸代理（mail transport agent），或簡稱MTA。在某些系統中，對於本地的和的投遞有不同的郵件傳輸代理程式；在其它系統上，僅有一個。遠端投遞的命令通常稱為rmail，其它的稱為lmail（如果存在的話）。
當然，本地郵件的投遞僅僅是將進來的訊息附加到接收者的郵件箱裡。通常，本地MTA是懂得別名（將接收者的地址設定成指向其它的地址），和轉發的（將使用者的郵件重定向到某個其它的目的地）。同樣，不能投遞的訊息通常必須反彈回來（bounced），也即，附帶某些出錯資訊返回給傳送者。
對於遠端投遞操作，所用的傳輸軟體依賴於連結的屬性。如果一個郵件必須在使用的網路上投遞的話，常常會使用SMTP。SMTP表示簡單郵件傳輸（Simple Mail Traner Protocol），是在RFC 788和RFC 821中定義的。SMTP通常直接連線至接收者的機器上，與遠端的SMTP後臺程式（daemon）協商訊息的傳輸。
在UUCP網路中，郵件通常不是直接投遞的，而是透過一系列的中間系統轉發到目的主機上的。為了在UUCP連結上傳送一個訊息，傳送MTA通常將使用uux在轉發的系統上rmail，並且將訊息在標準輸入上喂信給轉發系統。
由於這是對每個訊息分別操作的，這將在主要的郵件hub上產生可觀的工作負載，以及耗費不成比例的大量空間的數百個小檔案構成的混亂的UUCP假離線佇列。[2] 因此某些MTA允許你以一個批處理檔案從遠端系統收集幾個訊息。如果使用了直接SMTP連線，那麼這個批處理檔案通常含有本地主機要發出的SMTP命令。這稱為BSMTP，或batched SMTP。此時這個批處理會被髮送給遠端系統中的rsmtp或bsmtp程式，遠端系統將如正常的SMTP連線一樣來處理輸入。

13.3 Email地址
對於電子郵件，地址起碼是由處理該人郵件的機器的名字，和這個系統能夠識別的使用者的代號組成。這可以是接收者的登入名，但也可以是任何別的代號。其它的郵件地址方案，象X.400，使用一個更為一般的“屬性”集，用於在一個X.500目錄中查詢接收者的主機。
一個機器名字被解釋的方法，也即，在哪個站點你的訊息將最終結束，以及如何將這個名字與接收者的使用者名稱結合在一起，這很大程度上依賴於你上的網路。
Internet站點是符合RFC 822標準的，它需要user@host.ain這樣的表示法，這裡host.domain上主機的全資域名（fully qualified domain name）。當中的符號稱作為“在”（“at”）符號。因為這個表示法不包含有到目的主機的路由，而是給出了（唯一的）主機名，這稱為一絕對（absolute）地址。
在初始的UUCP環境中，流行的形式是path!host!user，這裡path描述了在到達目的host之前訊息經過的一系列的主機。這種結構稱為bang path表示法，因為一個感嘆號近似地被稱為一個“bang”。今天，許多基於UUCP的網路已經採用了RFC 822，並且能夠理解這種地址型別。
如今，這兩種地址型別還不能很好地融合在一起。假設有一個地址hostA!user@hostB。這並不清楚在這個路徑上‘@’符號是否是優先的；是否我們必須將訊息傳送到hostB，再郵遞到hostA!user，還是先傳送到hostA，再轉發到user@hostB？
然而，存在一種以RFC 822一致的方法指定路由：表示在hostC上user的地址，這裡hostC將經過hostA和hostB到達（以這個次序）。這種地址型別常常稱為route-addr地址。
而且，還有一個‘%’地址運算子：user%hostB@hostA將首先傳送到hostA，它將最右邊的（僅在這裡的情況下）百分符號擴充套件成為一個‘@’符號。現在這個地址成為了user@hostB，郵件程式將很順利地將你的訊息轉發到hostB，再而投遞給user。這種型別的地址有時被稱為“Ye Olde ARPANET Kludge”，它的使用是不贊成的。然而，許多郵件傳輸代理產生這種地址型別。
其它的網路還有不同的地址方案。例如，基於DECnet的網路使用兩個冒號作為地址的分割符，產生一個host::user地址。[3] 最後，X.400標準使用了一個完全不同的方案，透過使用一族屬性-值對描述一個接收者，就象國家和組織一樣。
在FidoNet上，每個使用者的確定是用一個程式碼象2;320/204.9，由四個數字組成，表示區zone（2表示歐洲）、網路net（320代表巴黎和郊區）、節點node（本地hub）和點point（個人的使用者PC）。FidoNet的地址可以被對映到RFC 822上；上面的地址可以寫成Thomas.Quinot@p9.f204.n320.z2.fidonet.org。現在我沒有說過域名好記吧？
使用這些不同的地址型別有某些隱含方面，這將在以下幾節中討論。然而，在一個RFC 822環境中，除了象user@host.domain這樣的絕對地址，你很少會用到其它的地址型別。

13.4 郵件路由是如何工作的？
定向一個訊息到接收者主機的過程稱為路由選擇（routing）。除了尋找到一條從傳送站點到目的地的路徑以外，它還包括錯誤檢測以及速度和代價。
UUCP站點處理路由選擇的方法與Internet站點的有很大的不同。在Internet上，定向資料到接收者的主機（由它的確定）的主要任務是由IP的網路層來完成的，而在UUCP區中，路由必須由使用者來提供，或者是由郵件傳輸代理生成的。

13.4.1 Internet上的郵件路由選擇
在Internet上，它完全依賴於目的主機是否要執行任何特定的郵件路由選擇。預設的是透過查詢目的主機的IP地址，直接將訊息投遞到目的主機去，而將實際資料的路由選擇工作給IP傳輸層去做。
許多站點通常會想要指引所有入站的郵件到一個高效穩定的中，這個伺服器能夠處理所有這些資料流量，並讓它在本地分發郵件。為了宣告這種服務，站點在中為它們的本地域公佈一個所謂的MX記錄。MX代表郵件交換器（Mail r）基本的意思是表明伺服器主機很願意為本域中的所有機器充當一郵件轉發器。MX記錄也可以用於處理自己沒有連線到Internet上的主機的交通流量，比如UUCP網路，或者是攜帶著機密資訊的公司網路上的主機。
MX記錄也有一個與之相關的優先權（preference）。這是一個正整數。對於一臺主機如果存在幾個郵件交換器的話，那麼郵件傳輸代理將會試圖把訊息傳輸到具有最低優先權值交換器上，僅當這樣做失敗時才會嘗試一臺具有高一級優先權值的主機。如果本地主機本身就是目的地址的一個郵件交換器，它就不必將訊息轉發到優先權值比自己高的任何主機去；這是避免郵件迴圈（ls）的一個方法。
假設有一個叫Foobar Inc.的公司，想要他們所有的郵件由他們的稱為mailhub的機器來處理。那麼他們就應該在DNS資料庫中有一個象這樣的MX記錄：

foobar.com IN MX 5 mailhub.foobar.com

這宣告了mailhub.foobar.com是一個foobar.com上的有優先權值5的郵件交換器。一個希望把訊息投遞到joe@greenhouse.foobar.com的主機將檢查foobar.com的DNS，會發現MX記錄指向mailhub。如果此時沒有優先權值小於5的其它MX存在，這個訊息將被投遞到mailhub，然後被分發給greenhouse。
上面實際上僅是MX記錄如何工作的一個輪廓。有關Internet上郵件路由選擇的更多資訊，請參考RFC 974。

13.4.2 UUCP世界中的郵件路由選擇
UUCP網路上的郵件路由選擇就比Internet上的複雜得多，因為傳輸軟體本身不執行任何的路由選擇功能。在早期，所有的郵件得用bang paths來定址。Bang paths指定了一張主機的列表，各主機名用感嘆號分開，透過這些主機來轉發訊息，後接使用者名稱。為了將一封信定址到名為moria的機器上的Janet使用者，你就得使用路徑eek!swim!moria!janet。這將會把郵件從你的主機傳送到eek，再從eek傳送到swim最後到moria。
這種技術明顯的不足之處是它需要你記住很多有關網路拓撲的細節、連結等等。更糟的是，網路拓撲的變化—象連結被刪除了或主機被移走了—可能導致訊息傳輸的失敗，簡單的原因只是由於你不知道網路結構變化了。還有，如果你移到了不同的地方，你很可能就要所有這些路由了。
然而，還有一件事使得源路由選擇成為必需的是不明確的（多義的）主機名的存在：例如，假設有兩個站點名字都叫moria，一個在U.S.，另一個在法國。那麼moria!janet指的是哪一個呢？這可以透過指明到達moria的路徑弄清楚。
消除多義主機名的第一步是UUCP對映計劃組（The UUCP Map Project）的成立。它位於Rutgers大學，對所有官方的[正式]的UUCP主機進行登記註冊，並記錄下他們的UUCP鄰居和他們的地理位置，確信沒有那個主機名被使用了兩次。由對映計劃組收集的資訊作為Usenet Maps公佈出來，它會定期地透過Usenet進行釋出。[4] Map中一個典型的系統條目看上去象這樣的（在刪除了註釋語句之後）。

Moria
bert(DAILY/2),
swim(WEEKLY)

這個條目說明moria有一個至bert的連線--moria每天對它呼叫兩次、和一個到swim的連線—moria每星期對它呼叫一次。下面我們將更詳細地討論對映檔案的格式。
使用對映檔案中提供的連線資訊，你可以自動地生成從你的主機到達任何目的站點的全路徑。這個資訊一般在paths檔案中，有時也被稱為路徑別名資料庫（pathalias database）。假設對映表明你可以透過ernie到達bert，那麼從上述對映中為moria生成路徑別名條目看上去象這樣的：

moria ernie!bert!moria%s

如果你現在給出一個目的地址janet@moria.uucp，你的MTA就會取得上面的路由，並將訊息用bert!moria!janet作為信封地址傳送到ernie。
然而，從完整的Usenet影射來建立一個paths檔案並不是一個好主意。其所提供的資訊通常是有誤導的，而且有時是過時的。因此，只有很少幾個主要的主機使用完整的UUCP世界對映來建立它們的paths檔案。大多數的站點僅僅維護著它們周鄰站點的路由選擇資訊，並將需要傳送到它們資料庫中找不到的站點的任何郵件發到一個有更多完整路由選擇資訊的靈敏主機上。這種方案被稱作靈敏-主機路由選擇（smart-host routing）。只有一個UUCP郵件連線的主機（即所謂的頁站點（leaf sites））本身不做任何的路由選擇；它們完全依賴於它們的靈敏-主機。

13.4.3 混合UUCP和RFC 822
至今為止針對UUCP網路郵件路由選擇問題最好的解決方案是在UUCP網路中採用域名系統。當然，你不能在UUCP上查詢一個名字伺服器。然而，許多UUCP站點已經在自己內部組成了與路由選擇相協調的小型域。在對映中，這些域宣稱一臺或兩臺主機作為他們的郵件閘道器，所以在域中不需要對每臺主機都有一個對映條目。閘道器將處理所有流入和流出域的郵件。在域中的路由選擇方案對於外界世界來說是完全看不見的。
這個方法與上述的靈敏-主機路由選擇方案配合的很好。全域性路由選擇資訊僅由閘道器來維護；一個有很少主機的域將只有一個很小的手寫paths檔案，其中列出了他們域內部的路由，以及到郵件hub的路由。即使是郵件閘道器也不再需要有世界上每一臺UUCP主機的路由選擇資訊，除了他們所服務的域的完整路由選擇資訊以外，現在僅需要在它們的資料庫中含有至整個域的路由。例如，下面所示的路徑別名條目（pathalias entry）將會把sub.org域中的所有站點的郵件路由到smurf：

.sub.org swim!smurf!%s

任何定址到claire@jones.sub.org的郵件將被用smurf!jones!claire作為信封地址傳送到swim。
域名空間的層次化組織結構允許郵件伺服器將非常特定的路由與一般的路由相混合。例如，一個在法國的系統可能有一個對fr子域的特定路由，但是將會把us域中任何主機的郵件路由到U.S.中的某個系統上。用這種方法，基於域的路由選擇（就如這種技術所稱的）大大地減小了路由選擇資料庫的大小和所需的管理負擔。
然而，在UUCP環境中使用域名的主要好處是與RFC 822的相容性使得UUCP網路和Internet之間的閘道器變得簡單。現今許多UUCP域與Internet閘道器都有一個連結以作為它們的靈敏-主機。透過Internet傳送訊息更快，路由選擇資訊也更可靠，因為Internet主機能夠使用DNS而不是Usenet對映。
為了從Internet能夠傳過來，基於UUCP的域通常有自己的Internet閘道器宣告了一個MX記錄（上面已對MX作過討論）。例如，假設moria屬於orcnet.org域。gcc2.groucho.edu作為他們的Internet閘道器。因而moria使用gcc2作為它的靈敏-主機，所以發往外部域的所有郵件都透過Internet投遞了出去。另一方面，gcc2會為orcnet.org宣告一個MX記錄，並將進入orcnet站點的所有入站郵件投遞到moria。
還有一個僅剩的問題是UUCP傳輸程式不能處理全資域名。大多數UUCP站點設計成應付多至八個字元的站點名，有些則更少，而使用非字母數字的字元比如象點（dot）則完全不可能了。
因此，就需要RFC 822名稱與UUCP主機名之間的某些對映。對映的方法完全依賴於實現。對映FQDN到UUCP名字的一個常用方法是使用路徑別名：

moria.orcnet.org ernie!bert!moria!%s

這將從指明一全資域名的地址中產生一個純UUCP風格的bang path。有些郵件程式為此提供了一個特殊的檔案；例如，sendmail為此使用了uucpxtable。
當需要從UUCP網路傳送郵件到Internet時，有時就需要反向轉換（通俗地稱為域名化）。由於郵件傳送程式在目的地址中使用了全資域名，在轉發訊息給靈敏-主機時，透過不從信封地址上刪除域名就可以避免這個問題。然而，仍有某些UUCP站點不屬於任何域。它們通常透過附加偽域（pseudo-domain）uucp來進行域名化。

13.5 路徑別名和對映檔案格式
路徑別名資料庫在基於UUCP的網路中提供了主要路由選擇資訊。一個典型的條目看上去象這樣（站點名和路徑用製表符分開）：

moria.orcnet.org ernie!bert!moria!%s
moria ernie!bert!moria!%s

這使得到moria的任何訊息被透過ernie和bert進行投遞。如果郵件程式沒有在這些名字之間對映的獨立方法，moria的全資名稱和它的UUCP名字就都必須給出。
如果你想把發到某個域中主機的所有訊息定向到它的郵件中繼，你也需在路徑別名資料庫中指定一個路徑，給出域名作為目標，域名前放置一個點。例如，如果在sub.org中的所有主機可以透過swim!smurf到達，那麼路徑別名就看上去象這樣：

.sub.org swim!smurf!%s

僅當你執行的是一個沒有很多路由選擇的站點時，編寫一個路徑別名檔案才是可行的。如果你要為大量的主機進行路由選擇的話，那麼更好的方法是使用pathalias命令從對映檔案中建立這個檔案。對映能夠很容易地維護，因為透過編輯系統的對映條目，你可以很容易地加入和移去一個系統，並重新建立對映檔案。儘管由Usenet Mapping Project釋出的對映不再用於路由選擇，更小的UUCP網路仍可以在他們自己的對映集中提供路由選擇資訊。
一個對映檔案主要是由站點的列表組成，列出每個系統查詢和被查詢的站點。系統名字從第一列開始，後跟用逗號分開的連結列表。列表可以跨行繼續如果下一行以一個製表符開始。每個連結由站點名後跟一個用括號括住的代價組成。代價是一個算術，由數字和符號代價構成。以hash符號開始的行將被忽略。
作為一個例子，考慮moria，它每天查詢swim.twobirds.com兩次，每星期查詢bert.sesame.com一次。更有甚者，到bert的連結只使用一個低速2400bps的modem。Moria會釋出下面的對映條目：

moria.orcnet.org
bert.sesame.com(DAILY/2),
swim.twobirds.com(WEEKLY+LOW)

moria.orcnet.org = moria

最後一行也使得它在它的UUCP名字下已知。注意，它必須是DAILY/2，因為每天呼叫兩次實際上將這個連線的代價減半。
使用pathalias這樣的對映檔案中的資訊可以計算出到達列於路徑檔案中任何目的站點的最佳化路徑，併產生一個路徑別名資料庫，然後這個資料庫可以用於到這些站點的路由選擇。
pathalias還提供了象站點隱藏（也即，讓站點只能透過閘道器來訪問）等幾個特性。詳細資訊和連結代價列表請參見pathalias手冊頁。
對映檔案中的註釋通常含有所描述站點的額外資訊。註釋有一固定的格式，所以這些資訊可以從對映檔案中抽取出來。例如，一個稱為uuwho的程式使用從對映檔案建立的資料庫用精細格式化的方式來顯示這些資訊。
當你在會給自己的會員釋出對映檔案的組織登記你的站點時，通常你要填寫這樣一個對映條目。
下面是一個對映條目的樣本（實際上，它是我的站點）：

#N monad, monad.swb.de, monad.swb.sub.org
#S AT 486DX50; Linux 0.99
#O private
#C Olaf Kirch
#E okir@monad.swb.de
#P Kattreinstr. 38, D-64295 Darmstadt, FRG
#L 49 52 03 N / 08 38 40 E
#U brewhq
#W okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993
#
monad brewhq(DALLY/2)
# Domains
monad = monad.swb.de
monad = monad.swb.sub.org

在頭兩個字元後面的空間是個製表符TAB。大多數字段的意思都是很顯然的；你會從你註冊的域那裡收到詳細的說明。L欄位是非常有趣的：它以經緯度給出了你的地理位置用於畫出顯示每個國家所有站點的地圖以及全世界的地圖來。[5]

13.6 配置elm
elm代表“電子郵件”（“electronic mail”）的意思，是非常合理命名的UN*X工具之一。它提供了一個全螢幕介面並有一個很好的幫助特性。這裡我們不討論如何使用elm，而是詳細敘述它的配置選項。
理論上講，無須配置你就可以執行elm，並且樣樣工作的都很好 --- 如果你幸運的話。但是有幾個選項是必須配置的，儘管只是有必要而已。
當elm開始執行時，它從/usr/lib/elm/中的elm.rc檔案裡讀取一族配置變數。然後，它將試圖在你的主目錄中讀取檔案.elm/elmrc。這個檔案一般不是你自己寫的。它是當你從elm的選項選單中選擇了“save options”時被建立的。
私有elmrc檔案的選項集也存在於全域性elm.rc檔案中。你的私有elmrc檔案中的許多選項將覆蓋全域性檔案中對應的選項。

13.6.1 全域性elm選項
在全域性elm.rc檔案中，你必須設定屬於你的主機名的選項。例如，在虛擬釀酒廠，vlager的這個檔案將含有下面資訊：

#
# The local hostname
hostname = vlager
#
# Domain name
hostdomain = .vbrew.com
#
# Full quallified domain name
hostfullname = vlager.vbrew.com

這些選項設定elm的本地主機名的概念。儘管這個資訊很少用到，但是你應該設定這些選項。注意，這些選項只有在全域性配置檔案中才有效；當存在於私有的elmrc中時，它們將被忽略掉。

13.6.2 國家字符集
近來，已有提議對RFC 822標準進行修正以支援各種型別的報文，比如無格式文字（plain text）、二進位制資料、Postscript檔案等等。有關這些方面的標準集和RFCs通常稱為MIME，或多用途互連網郵件擴充套件（Multipurpose Internet Mail Extensions）。在其它方面，這也使得接收者在寫報文時知道是否使用了非標準ASCII碼，例如，使用法語重音符或德語變音符號。elm在某些程度上支援這些擴充套件。
Linux內部用來表示字元所使用的字符集通常稱為ISO-8859-1，這是它所遵守的標準的名字。它也以Latin-1知名。任何使用這個字符集的報文應該在標題部分有下面這一行：

Content-Type: text/plain; charset=iso-8859-1

接收系統會識別出這個欄位並在顯示資訊時採取一定的措施。text/plain資訊的預設值是一個值為us-ascii的charset。
為了顯示非ASCII字符集的資訊，elm必須知道如何列印這些字元。預設地，當elm接收到charset欄位為非us-ascii（或者conten type不是text/plain）的資訊時，它試著使用稱為metamail的命令來顯示資訊。需要使用metamail來顯示的資訊在觀察視窗的第一列顯示一個‘M’。
由於Linux的本身的字符集是ISO-8859-1，metamail使用這個字符集來顯示資訊是不必要的。如果elm被告知顯示能夠理解ISO-8859-1，它就不會使用metamail，而是直接顯示資訊。這可以透過在全域性elm.rc中設定下面選項來做到：

displaycharset = iso-8859-1

注意，即使當你從不會傳送和接收含有任何非ASCII的資訊，你也應該設定這個選項。這是因為人們確實傳送這樣的資訊時通常會配置他們的郵件程式將適當的Content-Type:欄位預設地放入郵件的標題中，而不管他們是否只傳送ASCII資訊。
然而，在elm.rc中設定這個選項還不夠。問題是當用它內建的分頁程式顯示資訊時，elm針對每個字元呼叫一庫來確定該字元是否可列印的。預設地，這個函式將只能識別ASCII字元為可列印字元，並將所有其它字元顯示為“^?”。你可以透過設定環境變數LC_CTYPE為ISO-8859-1來克服這個問題，該變數告知庫函式接受Latin-1字元為可列印的。庫從libc-4.5.8起支援這個和其它特性。
當傳送含有ISO-8859-1中特殊字元的資訊時，你應該確信在elm.rc檔案中設定了起碼兩個變數：

charset = iso-8859-1
textencoding = 8bit

這使得elm在郵件標題中報告字符集是ISO-8859-1，並將它作為8位元值來傳送（預設的是將所有字元剝成7位元）。
當然，這些選項中的任何一個除了可以在全域性elm.rc檔案中設定以外，都可以在私有elmrc檔案中設定。




註釋
[1] 通常習慣上會給郵件訊息附加上一個簽名（signature）或.sig，通常包含有關作者的資訊，以及一個或者一座右銘。它與郵件訊息之間相隔一含有“--”的一行。
[2] 這是因為磁碟空間的分配通常是以1024位元組的塊為單位的。所以，即使一個最多400位元組的訊息也要吃掉整整一KB的空間。
[3] 當從一個RFC 822環境試圖到達一個DECnet地址時，你可以使用“host::user”@relay，這裡relay是一個已知的Internet-DECnet中繼。
[4] 在UUCP對映計劃登記的站點的對映是透過新聞組comp.mail.maps釋出的；其他的組織也會公佈他們網路的對映。
[5] 它們定期地投遞到news.lists.ps-maps。注意，它們非常巨大。

來源：