18.2 剖析邮件消息

18.2  剖析邮件消息

在深入研究sendmail配置之前，我们必须理解邮件消息的3个不同部分：

信封（envelope）；
信头（header）；
消息主体（body of message）。

信封确定消息将投递到哪里，或者如果消息不能投递出去的话，应该把它返回给谁。对于单个收件人来说，信封地址通常与信头的From和To行一致，如果消息是发送给一个邮递列表的，那么就不一致了。地址是单独提供给MSA的。信封对用户不可见，它不是消息本身的一部分，它供sendmail在内部确定把这则消息发送到哪里。

信头是一组格式遵循RFC822的属性/值。它们记录与消息有关的各种信息，比如发送的日期和时间、它在旅程中经过哪些传输代理传递等。信头是邮件消息的一个真实部分，只不过用户代理向用户显示消息时通常会隐藏一些不太引人注意的项。

消息的主体是将要发送的实际内容。它必须由纯文本组成，虽然文本经常表示各种二进制内容，但此时采用了对邮件来说是安全的编码方式。
当我们在介绍配置的小节时，有时会谈到信封发件人和收件人，有时则会谈到信头发件人和收件人。我们总是试图在上下文中不能确定的地方指出我们正在谈论的是哪种地址。

18.2.1  邮件寻址

本地寻址很简单，因为用户的登录名就是一个唯一的标识符。Internet地址也很简单：user@host.domain或者user@domain。在电子邮件和Internet的早期时代，表18.3列出的地址形式是很常见的。

表18.3 过时的地址类型举例

sendmail配置中的复杂性大多源自早期对处理这样的地址的要求。这些寻址形式都依赖于中继转发（relaying），而幸亏有了发垃圾邮件的家伙（spammer），各站点逐渐关闭了中转功能。spammers企图隐藏自己的身份，或通过您的机器中转邮件，“百分号扩展（percent hack）”（表18.3中最后一行）是他们最喜欢的一种工具。如果您需要处理这里面的任何一种地址形式，请参考sendmail文档，寻求帮助。

18.2.2  阅读邮件信头

每一则邮件消息都从称为信头（header）的若干行开始，信头中包含着有关这则消息的信息。每个信头以一个关键字打头，比如To、From或Subject，后面跟着一个冒号和该信头的内容。标准信头的格式在RFC822中定义，不过，自定义信头也是允许的。任何以“X-”打头的信头都将被邮件系统忽略，但会随着消息传送。因此，您可以给电子邮件消息添加一个信头，比如X-Joke-of-the-Day，这不会干扰邮件系统发送它们的能力 。

有些信头是由用户代理添加的，另一些则是由传输代理添加的。有些信头会记录下消息通过邮件系统的路径。许多用户代理会对您隐藏这些“人们不感兴趣”的信头，但通常可以选择让代理把它们全部显示出来。当我们被垃圾邮件轰炸，而有时必须回溯一则消息的来源时，阅读信头就成为了一项重要的技巧。下面是来自一则简单消息的信头部分：

这则消息完全停留在本地计算机上，发件人是trent，而收件人是ned。第一个From行是由mail.local添加的，mail.local此时是本地投递代理。信头中的Subject和Cc两行是由trent的邮件用户代理加的，它可能还会加上信头中的To、From和Date行。如果MUA没有提供信头中的To、From和Date行的话，那么邮件传输代理sendmail会加上它们。每台接触到这则消息的机器（或者更精确地说，是每个MTA）都会添加一个Received信头。

邮件消息中的信头包含着有关这则消息到过哪里，它在那里停留了多长时间，以及它最终是何时投递到其目的地等大量信息。下面是通过Internet发送的一则邮件消息的更完整的剖析。其中穿插了注释，用来描述各种信头的用途并标识出添加它们的程序。左边的行号是为了方便在下面的讨论中引用，而并非消息的一¬部分。某些行折成了好几行，这是为了让例子能在一页里显示得下。

 1: From eric@knecht.sendmail.org

2:  Return-Path: eric@knecht.Neophilic.COM

 3:  Delivery-Date: Mon, 06 Aug  2001  14:31:07 –0600

第4~7行记录下这则消息在到用户邮箱的路上经过的各种系统的通道。每台处理邮件消息的机器都会在消息的信头中添加一个Received行。新的行添加在顶端，所以在阅读它们时，您是从收件人到发件人跟踪消息的。如果正在查看的消息是一则垃圾邮件，那么您真正可以相信的唯一一个Received行就是由您本地计算机生成的那行。

每个Received行包含发送它的机器的名称、接收它的机器的名称、接收机器上sendmail（或使用的任何传输代理）的版本、接收机器上这则消息的唯一标识号、收件人（如果只有一项的话）、日期和时间、最后是本地时区与UTC（Universal Coordinated Time，世界协调时间，以前叫做GMT，即Greenwich Mean Time，格林威治标准时间）的偏移量。这一数据是从sendmail的内部宏变量那里收集的。在接下来的几段中，我们将从发件人到收件人跟踪这则消息（从信头行的角度说，就是反过来看）。

第7行说明这则消息从knecht的localhost接口（Eric[译者注：这是sendmail的作者Eric Allman]写的特殊邮件用户代理选择这个接口用于其初始连接）通过内核的伪设备loopback到达knecht的外部接口。第6行记录的是：knecht随后将这则消息发向mroe.cs.colorado.edu，虽然消息的地址是evi@anchor.cs.colorado.edu（请参见信头第9行）。用nslookup或dig快速检查一下可以看到，主机anchor有一个MX记录指向mroe，正是它使得投递被转了方向。knecht这台机器正在运行的sendmail版本是8.12.0Beta16。有关MX记录的更多信息请参考15.7.6节。

机器mroe运行sendmail的版本是8.10.1，当消息位于队列中时，这则消息用队列标识ID号f76KV5Q17625标识出来。随后mroe把这则消息按地址（第5行）转发给anchor.cs.colorado.edu，这可能看上去显得有点儿意外。由于MX记录的缘故，原来knecht发出要到anchor的邮件，却转到了mroe。之所以出现这种明显不一致的现象，原因是cs.colorado.edu这个域使用了“分离式DNS（split DNS）”的配置。从外界能够看到的anchor的MX记录指向了内部的邮件主控机（mroe）。不过，在cs.colorado.edu域的内部看到的则是不同的一个记录。内部版本的记录首先指向anchor自己，然后把mroe作为一个备份。

一旦邮件到达了anchor，它就立即被再次转发，这一次是转发给rupertsberg。这一跳的原因是别名机制，这种处理邮件的功能将在18.4节详细介绍。

在邮件的传输过程中，别名扮演了一个重要的角色。一个别名将一个用户名映射到别的名字上，例如，映射到另一台机器上的同一个用户，映射到一组用户，甚至映射到这个用户的名字的另一种拼写上。您不能只研究例子中的信头就能确定消息为什么发生转向。和MX记录一样，您必须寻找外部的信息源。

第5和第6的Received行包含了“for <evi@anchor.cs.colorado.edu>”这一段，它标明了在邮件到达本地站点时是怎样寻址的。当您试图取消订阅邮递列表，而它要求您要么从订阅邮递列表（有时可能是好几年前）的那台主机上发送取消订阅的消息，要么知道哪个地址，在您取消订阅的消息里把它当作个参数来用，这时候有这样的信息就有很大帮助。

最后一个Received行（第4行）显示“for <evi@mroe.cs.colorado.edu”，sendmail的目的地址宏的值已经被机器anchor上查找到的别名给修改了。rupertsberg上的本地邮件投递代理将邮件发进Evi的邮箱。

 8:  Message-Id: <200108062030.f76KUufp084340@knecht.Neophilic.COM>

第9、10、12、13和14行是标准的。虽然可以不用Subject信头，但是大多数用户代理都包含它。To行包含主要收件人或所有收件人的地址。From行列出的发送方是eric@sendmail.org，不过，Received行列出的发送方机器是位于neophilic.com 这个域内—除了sendmail.org之外，Eric的机器knecht还绑定了几个虚拟域名。

Date行显示消息发送时的日期和时间。在本例中，发送时间与Received行中的日期很接近，尽管它们两者是用不同的时钟测量的。

第11行列出了Eric主页的URL。注意，它以一个X开头，说明这一行不是正式的信头内容。在首次确定邮件的时候，没有Web地址或者URL这样的内容。

Received行通常由传输代理添加（除非它们是伪造的），其他信头由用户代理添加。某些用户代理功能不完整，无法添加正确的信头，此时，sendmail会插手帮助添加丢失的信头。

第一个添加的Received行（通常是在发送机器上，当邮件发送到待发接口时添加）有时会包含一个给出发件人登录名的“indent”子句。它应该与From行上的名字相同，但如果From行是伪造的，那么就会不一样。在我们举的例子里，Eric的机器knecht没有运行实现这一功能（identd）的守护进程，所以没有列出发件人登录名。

图18.2图解说明了这则消息通过邮件系统的旅程。它显示了采取哪些处理动作、处理是在哪里发生的、以及是由什么程序执行它们的。

图18.2  来自Eric的一则消息