Linux网络管理员手册(13) 第十三章 电子邮件

Linux网络管理员手册(13) 2000-07-30 20:06

发布者：netbull 阅读次数：1143

翻译：赵炯 gohigh@shtdu.edu.cn 第十三章 电子邮件 自从第一个网络被设计出来，连网最显著的用途之一就是电子邮件（eletronic mail）。它是从将一个文件从一台机器拷贝到另一台机器的简单服务开始的，并将该拷贝的文件添加到接收者的mailbox文件中。本质上来说，这仍然是email所做的全部工作，尽管不断增长的网络及其复杂的路由需求以及它的不断增大的消息负载量已经促使要求更加精心制作的方案。 已设计出了各种邮件交换的标准。Internet上的站点始终坚持RFC 822中的设计，并被描述与机器无关的传输特殊字符方法的某些RFC所扩充，等等。对于“多媒体邮件”的更多思考目前也已作出，这涉及到有关在邮件消息中包含图形和声音。另一个标准，X.400，也已被CCITT定义。 有许多UN*X系统的邮件传输程序被实现。其中最为著名的是Berkeley大学的sendmail，它被用于很多平台上。最初的作者是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中指定的头[标题]格式。它的最初目的是在ARPANET上的使用指定一个标准，但是由于它被设计成是与任何环境都独立的，它很容易地被其它网络采纳，包括许多基于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.com (ruby.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），也即，附带某些出错信息返回给发送者。 对于远程投递操作，所用的传输软件依赖于链接的属性。如果一个邮件必须在使用TCP/IP的网络上投递的话，常常会使用SMTP。SMTP表示简单邮件传输协议（Simple Mail Transfer 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.domain这样的表示法，这里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一致的方法指定路由：<@hostA,@hostB:user@hostC>表示在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地址确定）的主要任务是由IP的网络层来完成的，而在UUCP区中，路由必须由用户来提供，或者是由邮件传输代理生成的。 13.4.1 Internet上的邮件路由选择 在Internet上，它完全依赖于目的主机是否要执行任何特定的邮件路由选择。默认的是通过查找目的主机的IP地址，直接将消息投递到目的主机去，而将实际数据的路由选择工作给IP传输层去做。 许多站点通常会想要指引所有入站的邮件到一个高效稳定的邮件服务器中，这个服务器能够处理所有这些数据流量，并让它在本地分发邮件。为了宣告这种服务，站点在DNS数据库中为它们的本地域公布一个所谓的MX记录。MX代表邮件交换器（Mail Exchanger）基本的意思是表明服务器主机很愿意为本域中的所有机器充当一邮件转发器。MX记录也可以用于处理自己没有连接到Internet上的主机的交通流量，比如UUCP网络，或者是携带着机密信息的公司网络上的主机。 MX记录也有一个与之相关的优先权（preference）。这是一个正整数。对于一台主机如果存在几个邮件交换器的话，那么邮件传输代理将会试图把消息传输到具有最低优先权值交换器上，仅当这样做失败时才会尝试一台具有高一级优先权值的主机。如果本地主机本身就是目的地址的一个邮件交换器，它就不必将消息转发到优先权值比自己高的任何主机去；这是避免邮件循环（loops）的一个安全方法。 假设有一个叫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 Mapping 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。注意，它们非常巨大。

来源： Linux自由鸽