邮件头大揭秘

邮件头大揭秘

一、简介

本文将详细讨论email头的方方面面。主要为用户架设邮件服务器提供理论基础并为管理员在出现电子邮件垃圾骚扰时提供发现垃圾邮件的真正源头。根据邮件头的知识有助于发现伪造的邮件。对于希望了解邮件是如何在网络中传输的用户同样会有帮助。文章有若干虚构的域名和随意分配的IP地址作为示例使用。

二、Email的传输过程

这部分包含一个简单的对一个电子邮件生命周期的分析。这对于理解邮件头能为你提供哪些信息是非常重要的背景信息。

从表面上看来邮件似乎是直接从发送者机器传递到接收者地址，但通常情况下事情并不是这样。一个典型的电子邮件在其生命周期中至少要经过四台计算机。

这是因为大多数企业或组织都有一个被称为“邮件服务器”专用服务器来处理电子邮件，而这一般并不是用户阅读邮件的计算机。对于ISP来说，用户从家里面的计算机拨号接入ISP网络，这里将用户家中的计算机称为客户机，而将ISP专门处理邮件的计算机称为邮件服务器。当一个用户发送邮件，他一般是在自己的计算机上编辑邮件，然后将邮件发送到ISP的邮件服务器上。客户机就此已经完成了自己的工作，而后面的工作则由ISP的邮件服务器来完成。首先ISP邮件服务器查找接收者指定的邮件服务器的IP地址，然后将邮件发送给该目的服务器。现在邮件则存储在接收者邮件服务器上等待接收者收取。当接收者从接受邮件服务器取得发送给他的邮件到自己的PC机以后，通常该邮件将被删除。

假设有以下用户和。betty 是 sina.com 的免费邮件用户。使用 outook express 这个邮件客户程序收发邮件。tom 是中科院的一个邮件用户，他使用个人电脑通过单位局域网连接进入互联网。

如果 tom 想给 betty 发送邮件，他在个人电脑(假设名字为 tom-pc.alpha.com.cn )上编辑邮件，编辑好的信件从个人电脑发送到中科院的邮件服务器：mail.alpha.com.cn。一旦信件被发送到 mail.alpha.com.cn，以后的信件发送过程就和 tom 没有关系了。中科院的邮件服务器发现这是发送给 sina.com 的某个用户的信件，则和 sina.com 的邮件服务器－比如说是mail.sina.com－通信，并将邮件传送给它。现在邮件则被存储在 mail.sina.com 之上直到 betty 在自己的PC机上拨号上网并连接到 sina.com 邮件系统察看并收取信件，这时 mail.sina.com 将存储的邮件传送到 betty 的个人电脑上。

在这个过程中，邮件头将三次被加到邮件中：在编辑时由邮件客户程序加入；当邮件传输到 mail.alpha.com.cn 时被 mail.alpha.com.cn 加入；当从 mail.alpha.com.cn 传送到 mail.sina.com 时被 mail.sina.com 加入；通常来说客户收取信件时并不添加邮件头。下面我们就仔细看看这些邮件头是如何产生的。

当 tom 的邮件客户程序编辑邮件并将其发送给 mail.alpha.com.cn 时，邮件内容如下。这些内容都是由邮件编辑程序 (outlook express)添加的：

From: tom@alpha.com.cn (Tom Lee)
To: betty@sina.com
Date: Tue, Mar 18 2003 14:36:14 PST
X-Mailer: Outlook Express 6.0
Subject: 明天放假？

当邮件从 mail.alpha.com.cn 传送到 mail.sina.com 后，邮件内容变为(新添加的内容是由 mail.alpha.com.cn )：

Received: from tom-pc.alpha.com.cn (tom-pc.alpha.com.cn [124.211.3.11]) by mail.alpha.com.cn (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
From: tom@alpha.com.cn (Tom Lee)
To: betty@sina.com
Date: Tue, Mar 18 2003 14:36:14 PST
Message-Id:
X-Mailer: Outlook Express 6.0
Subject: 明天放假?

当 mail.sina.com 收到信件并存储等待 betty 收取时，邮件内容变为，(新添加的内容是由 mail.sina.com 添加的)：

Received: from mail.alpha.com.cn (mail.alpha.com.cn [124.211.3.78]) by mail.sina.com (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Tue, 18 Mar 2003 14:39:24 -0800 (PST)
Received: from tom-pc.alpha.com.cn (tom.alpha.com.cn [124.211.3.11]) by mail.alpha.com.cn (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
From: tom@alpha.com.cn (Tom Lee)
To: betty@sina.com
Date: Tue, Mar 18 2003 14:36:14 PST
Message-Id:
X-Mailer: Outlook Express 6.0
Subject: 明天放假?

最后这封信的内容才是 betty 收取并阅读的内容。下面是对其中内容的详细分析：
Received: from mail.alpha.com.cn
上面的内容表示该邮件是来自于自称是 mail.alpha.com.cn 的服务器。
(mail.alpha.com.cn [124.211.3.78])
这句话表示该服务器的真实名字的确是 mail.alpha.com.cn，也就是说它自称的身份是正确的，其IP地址为 124.211.3.78。
by mail.sina.com (8.8.5/8.7.2)
接收这封邮件的机器是 mail.sina.com。其运行的邮件程序为 sendmail，版本为8.8.5/8.7.2。
with ESMTP id LAA20869
接收邮件的服务器为该邮件赋有ID号LAA20869(通常该号码是邮件服务器内部使用的，但是管理员可以根据该ID号在log文件中查找关于该信件的相关信息，但是通常该号都是没有意义的) 。

for ;
该邮件是发送给地址 betty@sina.com 的。可以看到该邮件头没有To:相关内容。

Tue, 18 Mar 2003 14:39:24 -0800 (PST)

这次邮件传输发生时间为：太平洋时间Tuesday, March 18, 2003, at 14:39:24(太平洋时间，因为它比格林威治时间晚8个小时，因此是"-0800")。

Received: from tom-pc.alpha.com.cn (tom-pc.alpha.com.cn [124.211.3.11]) by mail.alpha.com.cn (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
该邮件头记录了邮件是从 tom-pc.alpha.com.cn(tom的个人电脑)传送到到邮件服务器 mail.alpha.com.cn 的。传送发生在太平洋时间14:36:17。发送计算机自称是 tom-pc.alpha.com.cn，其真实名经dns查询的确是 tom-pc.alpha.com.cn，其IP地址为 124.211.3.11，邮件服务器软件为 sendmail v8.8.5。该信件被邮件服务器的 mail.alpha.com.cn 赋给的ID号为004A21。

From: tom@alpha.com.cn (Tom Lee)
该邮件是由 tom@alpha.com.cn 发送的，其名字为 Tom Lee。

To: betty@sina.com
邮件目的地址为：betty@sina.com。　

Date: Tue, Mar 18 2003 14:36:14 PST
邮件编辑时间为14:36:14 Pacific Standard Time on Tuesday, March 18, 2003。

Message-Id:
mail.alpha.com.cn 给该邮件分配了这个号码来标识它。它和Received头中的SMTP机ESMTP ID号是不一样的。因为该号码是一直伴随整个邮件的。而其它ID则仅仅在特定的邮件服务器上的邮件传输阶段相关联。因此该机器ID号对其它机器来说没有任何意义。有时候Message-ID包含了发送者邮件地址在其中。

X-Mailer: Outlook Express 6.0
该消息是使用 Outlook Express 发送的，版本号为 6.0。

Subject: 明天放假?
邮件标题。

三、邮件协议

这部分内容相对其它部分来说具有更多原理性内容，主要讨论邮件是如何从一点传输到另外一点的细节。你不需要理解每一句话，但是熟悉这方面的内容有助于在邮件传输出现奇怪现象时弄明白问题所在。由于垃圾电子邮件发送者常常故意制造一些奇怪的情况以掩饰自己的身份，因此能理解这些奇怪的现象对对付这些家伙是非常有用的。

为了在网络上传输数据，计算机网络协议使用了称为端口的访问入口，你可以将端口看做是一个通道，通过它计算机可以监听网络通信以提供服务。为了同时监听多个通信，计算机需要有使用端口号码标识多个不同的端口以区别这些通信。而和电子邮件传输相关的端口是25。

正常情况

让我们重新讨论上面的例子，但是这次我们仅仅关心 mail.alpha.com.cn 到 mail.sina.com 之间的通信过程。首先 mail.alpha.com.cn 打开一个到 mail.sina.com 的25号端口的连接，然后通过该连接发送邮件，当然在发送邮件过程中会有一些管理命令交互过程。交互中的命令和相应都或多或少的是可读的。命令是SMTP协议规定的。如果监听两者之间的通信，可能有以下内容：(粗体部分是 mail.alpha.com.cn 发出的)
mail.alpha.com.cn发给betty@sina.com

220 mail.sina.com ESMTP Sendmail 8.8.5/1.4/8.7.2/1.13; Tue, Mar 18 2003 14:38:58 -0800 (PST)
HELO mail.alpha.com.cn
250 mail.sina.com Hello mail.alpha.com.cn [124.211.3.78], pleased to meet you
MAIL FROM: tom@alpha.com.cn
250 tom@alpha.com.cn… Sender ok
RCPT TO: betty@sina.com
250 betty@sina.com… Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Received: from tom-pc.alpha.com.cn (tom-pc.alpha.com.cn [124.211.3.11]) by mail.alpha.com.cn (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
From: tom@alpha.com.cn (Tom Lee)
To: betty@sina.com
Date: Tue, Mar 18 2003 14:36:14 PST
Message-Id:
X-Mailer: Outlook Express 6.0
Subject: 明天放假?
Do you have time to meet for lunch?
–Tom Lee .
250 LAA20869 Message accepted for delivery
QUIT
221 mail.sina.com closing connection

整个传输依赖于五个SMTP核心命令(当然SMTP还有一些其它命令，但是它们并不是用来完成真正的邮件传输)：HELO，MAIL FROM，RCPT TO，DATA 和 QUIT。

邮件发送者 HELO 命令用来标识自己的身份。HELO mail.alpha.com.cn 可以被解读为"嗨，我是 mail.alpha.com.cn"。当然这里发送者可能会撒谎，但是没有任何机制能防止发送者 mail.alpha.com.cn 说"嗨，我是 mail.xxx.com"或是"嗨，我是mail.yyy.com"。然而在大多数情况下接收者都有一些方法来确认发送者的真实身份。

MAIL FROM 命令标识开始邮件传输，含义是"我有从某人发送来的邮件"，该命令后跟的地址就是所谓的“信封地址”(在后面我们将深入讨论)，信封 from 地址不一定是发送者自己的地址。这个明显的安全漏洞是不可避免的(因为接收者并不知道发送者机器上有哪些地址)，但是在特定的情况下这又是一个有用处的特色。

RCPT TO 和 MAIL FROM 是相辅相成的。其指定邮件接收者。通过多个 RCPT TO 命令一个邮件可以被发送给多个接收者。(在后面的邮件中继部分将解释该特色可能针对某些不安全的系统滥用)。该命令后跟的地址称为"envelope to"地址。其指定了邮件将被投递给哪些用户，而和信件中的To:指定的地址没有关系。

DATA 命令指示开始实际的邮件内容传输。DATA 命令后输入的任何内容都被看做是邮件的一部分。而格式并没有任何限制。以一个英文单词加冒号开始的行一般被邮件程序看做是邮件头。以英文句号符号(.)开始的行被认为是邮件内容结束。

QUIT 命令终止连接。

SMTP 协议规范定义在 RFC 821 中。

非正常情况

上面的例子有些过于简单。上面的例子有一个假设前提：两个组织的邮件服务器相互之间能直接访问，而不需要经过代理、防火墙等安全设备。这在当前Internet环境下情况往往是这样的。但由于安全对于某些组织来说非常重要，而且网络或组织可能变得越来越庞大，情况就不那么简单了。对于具有代理型防火墙系统的邮件传输来说，区别就在于在邮件的头中多了一次转发过程的记录，也就是邮件首先从发送者邮件服务器发送到防火墙上，然后再从防火墙发送到目的邮件服务器。

四、邮件中继

对于某些具有特殊的“生命”周期的邮件头可能和前面讨论的情况完全不同：

Received: from unwilling.intermedia.com (unwilling.intermedia.com [98.134.11.32]) by mail.alpha.com.cn (8.8.5) id 004B32 for ; Wed, Jul 30 2003 16:39:50 -0800 (PST)
Received: from linuxaid.com.cn ([202.99.11.120]) by unwilling.intermedia.com (8.6.5/8.5.8) with SMTP id LAA12741; Wed, Jul 30 2003 19:36:28 -0500 (EST)
From: Anonymous Spammer
To: (recipient list suppressed)
Message-Id:
X-Mailer: Massive Annoyance
Subject: WANT TO MAKE ALOT OF MONEY???

这个邮件头和以前的不同之处可能会令你认为这是一封垃圾邮件，但是这里引起你的怀疑的是"Received:"头。从"Received:"头看来，邮件是来自linuxaid.com.cn，然后从这里传输给unwilling.intermedia.com，然后从这里再次传输到最终目的地址：mail.alpha.com.cn。从"Received:"头看来事情就是这样的，但是中间为什么会出现unwilling.intermedia.com呢？因为它和发送者和接收者都没有直接的关系。

要理解原因需要对SMTP协议进行一些了解。本质上来讲，传输过程是这样的：linuxaid.com.cn 连接 unwilling.intermedia.com 的 SMTP 端口。告诉它“请发送这封邮件到 tom@alpha.com.cn。它可能是以最直接的方法来实现：RCPT TO:tom@alpha.com.cn。到现在为止，unwilling.intermedia.com 接管对该邮件的处理。因为它被告知将该信件转发给其他一个域：alpha.com.cn，它就查找对于域名alpha.com.cn 的邮件服务器然后将邮件转发给 alpha.com.cn。这个过程通常被称作邮件中继(mail relaying)。

出现邮件中继是由于历史的原因，使用邮件中继是有它的好处的。到八十年代末期，很多网络中的计算机都不是直接通信来传输邮件。而是通过邮件路由来传递邮件，通过邮件路由服务器一步一步地进行邮件传输。这样做是非常麻烦的，发送者往往需要手工指定一封邮件需要经过哪些邮件路由服务器，比如需要从 San Francisco 发送一封邮件到 New York，则需要在信封中添加如下内容：

San Francisco, Sacramento, Reno, Salt Lake City, Rock Springs, Laramie, North Platte, Lincoln, Omaha, Des Moines, Cedar Rapids, Dubuque, Rockford, Chicago, Gary, Elkhart, Fort Wayne, Toledo, Cleveland, Erie, Elmira, Williamsport, Newark, New York City, Greenwich Village, #12 Desolation Row, Apt. #35, R.A. Zimmermann

如果从邮局工作人员的角度来考虑，这种模型是非常有用的。在Gary的邮局只需要知道如何和临近的邮局 Chicago 和 Elkhart 通信，而无需消耗资源计算如何将邮件发送到 New York (这时候就很清楚为什么这种模式对于邮件发送者来说非常糟糕，为什么这种方法被抛弃了)。但是这就是邮件被传输的过程。因此服务器具有这样的中继的能力在那时是很重要的。
而现在中继通常被用作不道德的广告商用来隐藏它们的原始地址，将埋怨转嫁给被用来中继的服务器而不是其所在ISP的技术。同样通过中继可以实现将发送信件的负载转移到中继服务器上，从而实现盗用中继服务器的服务资源。在这里最重要的一点是理解邮件内容是在发送点 linuxaid.com.cn 被编辑。中间的服务器 unwilling.intermedia.com 只是参加了中间的传输工作，它并不能对发送者有任何的约束力。

在上面的例子中应该注意的另外一点是"Message-Id:"并不是由发送者服务器(linuxaid.com.cn)而是中继计算机(unwilling.intermedia. com)填写的。这是被中继的邮件的一个典型特性，该特性反映了发送服务器并没有提供 Message-Id 的事实。

上面关于SMTP的讨论部分提到了“消息”头和“信封”头的不同之处。这种区别和导致的后果将在这里详细地讨论。

简单地说，“信封”头实际上是由接收消息的邮件服务器产生的，而不是发送者服务器。按照这个定义，“Received:”头是信封头，而一般来说常常使用"envelope From"和"envelope To"来指示它们。

"envelope From"头是从 MAIL FROM 命令得到的。如发送者邮件服务器发出命令 MAIL FROM: ideal@linuxaid.com.cn，则接收者服务器则产生一个"envelope From"头：>From ideal@linuxaid.com.cn。

注意这里少了一个冒号—"From"而不是"From:"。也就是说信封头在其后没有冒号。当然这个惯例并不是标准，但是这时一个值得注意的惯例。

对应的是"envelope To"同样来自于RCPT TO命令。如果发送者服务器发出命令RCPT TO: ideal@btamail.net.cn。则"envelope To"为 ideal@btamail.net.cn。一般来说实际上并没有这样一个邮件头，它常常是包含在Received:头中。

存在信封信息的一个重要结果就是消息 From: 和 To: 变得毫无意义。From: 头是由发送者提供的，同样 To: 也是由发送者提供的。因此邮件仅仅基于"envelope To"来进行转发路由，而不是基于消息To:。

为了从实际中理解这个概念，看看下面这样的邮件传输：

HELO galangal.org
250 mail.alpha.com.cn Hello linuxaid.com.cn [202.99.11.120], pleased to meet you
MAIL FROM: forged-address@galangal.org
250 forged-address@galangal.org… Sender ok
RCPT TO: tom@alpha.com.cn
250 tom@alpha.com.cn… Recipient OK
DATA
354 Enter mail, end with "." on a line by itself
From: another-forged-address@lemongrass.org
To: (这里你的地址被隐瞒以实现秘密邮件转发和骚扰)
.
250 OAA08757 Message accepted for delivery

下面是对应的邮件头：

>From forged-address@galangal.org
Received: from galangal.org ([202.99.11.120]) by mail.alpha.com.cn (8.8.5) for …
From: another-forged-address@lemongrass.org
To: (这里你的地址被隐瞒以实现秘密邮件转发和骚扰)
注意到"envelope From"的内容和消息 From: 的内容和消息 To: 的内容都是发送者指定的，因此他们都是不可靠的。这个例子说明了为什么信封From、消息 From: 及消息 To: 在可能是伪造的邮件中是不可靠的，因为它们太容易伪造了。

"Received:"头的重要性

在上面的例子中我们已经看到，"Received:"头提供了详细的消息传输历史记录，因此即使在其他邮件头是被伪造的情况下也可能根据"Received:"头得到某些关于该信件原始出处和传输过程的结论。这部分将详细探讨某些和异常的重要消息头相关的问题，特别是如何挫败那些常见的伪造技术。

毫无疑问的是，在"Received:"头中唯一重要且有价值的伪造防护就是由接收服务器记录的那些信息。前面提到发送者能伪造自己的身份( 通过在HELO命令中报告错误的身份)。幸运的是现代邮件服务器程序都可以检测到这种错误信息并加以修正。

如果服务器 linuxaid.com.cn 的真实IP地址是 202.99.11.120，发送邮件给 mail.alpha.com.cn，但是使用HELO galangal.org命令来伪造自己的身份，则对应该次传输的"Received:"可能如下所示：

Received: from galangal.org ([202.99.11.120]) by mail.alpha.com.cn (8.8.5)…
(后面的其他信息被省略以更加清晰)。注意虽然zky.ac.cn没有明确地说galangal.org不是发送者的真实身份，但是它记录了发送者正确的IP地址。如果某接收者认为消息头中的galangal.org是伪造者伪造的身份，他可以查看IP地址 202.99.11.120 来得到对应的正确域名是linuxaid.com.cn，而不是 galangal.org。也就是说记录发送服务器的IP地址提供了足够的信息来确认可以的伪造行为。
很多现代邮件程序实际上将根据IP查看对应域名的过程自动化了。(这种查看过程被称为反向DNS解析)。如果 mail.alpha.com.cn 使用这种软件，则"Received:"头则变为

Received: from galangal.org (linuxaid.com.cn [202.99.11.120]) by mail.alpha.com.cn…

从这里可以清楚地看到伪造行为。这个消息头明确地说 linuxaid.com.cn 的IP地址是202.99.11.120，但是却宣称自己的身份为galangal.org。这样的信息对于对于验证和追踪伪造信件是非常有用的。(因此，垃圾邮件发送者往往避免使用那些记录发送者地址的邮件服务器进行垃圾邮件转发。有时候它们可以找到不记录发送者服务器，但是现在网络上这样的服务器已经很少了)
伪造者伪造邮件的另外一个日益常见的技巧是在发送垃圾邮件以前添加伪造的"Received:"头。这意味着从 linuxaid.com.cn 发送的假设的邮件的"Received:"头的内容可能为：

Received: from galangal.org ([202.99.11.120]) by mail.alpha.com.cn (8.8.5)…
Received: from nowhere by fictitious-site (8.8.3/8.7.2)…
Received: No Information Here, Go Away!

很明显，最后两行内容完全是毫无疑义的，是由发送者编写并在发送以前附在邮件中的。由于一旦邮件离开 linuxaid.com.cn，发送者对邮件完全失去了控制。而且新的"Received:"头总是出现添加在消息的头部，因此伪造的"Received:"头总是出现在"Received:"头列表的尾部。这意味着任何人从头到尾读取"Received:"头列表，追踪邮件传输历史，都能安全地剔除在第一个伪造头以后的内容。即使"Received:"头看上去似乎是真实的，但是实际上都是伪造的。
当然，发送者不一定会用明显的垃圾信息来迷惑你，一个处心积虑的伪造者可能创建如下所示的看似真实的"Received:"头列表：

Received: from galangal.org ([202.99.11.120]) by mail.alpha.com.cn (8.8.5)…
Received: from lemongrass.org by galangal.org (8.7.3/8.5.1)…
Received: from graprao.com by lemongrass.org (8.6.4)…

这里泄漏伪造问题的唯一地方是第一个"Received:"头中的 galangal.org 的IP地址。如果伪造者这里填写了lemongrass.org 和graprao.com 的真实IP地址，则这样的伪造伪造仍然非常难以检测。但是第一个"Received:"头中的域名和IP的不匹配仍然揭露了消息是伪造的，并且该邮件是有网络中地址为 202.99.11.120 的服务器注入到网络中。然而大多数邮件头伪造者一般都没有这么狡猾，一般额外添加的"Received:"头一般都很明显地是伪造的垃圾。