电子邮件头全揭密资料.docx

电子邮件头全揭密资料.docx

《电子邮件头全揭密资料.docx》由会员分享，可在线阅读，更多相关《电子邮件头全揭密资料.docx（9页珍藏版）》请在冰豆网上搜索。

电子邮件头全揭密资料

电子邮件头全揭密

这一部分内容将详细讨论email头的方方面面。

主要为用户架设邮件服务器提供理论基础并为管理员在出现电子邮件垃圾骚扰时提供发现垃圾邮件的真正源头。

根据邮件头的知识有助于发现伪造的邮件。

对于希望了解邮件是如何在网络中传输的用户同样会有帮助。

虽然在讨论中尽量有意避免如何伪造一封邮件的讨论，但是在讨论中的内容可能被恶意读者用作创建伪造邮件的基础。

因为要在文章中举例说明，因此在文章中有若干虚构的域名和随意分配的IP地址作为示例使用。

这些域名和IP都是任意任意选择和伪造的，和Internet上真实的域名和IP没有任何关系。

二、Email的传输过程

这部分包含一个简单的对一个电子邮件生命周期的分析。

这对于理解邮件头能为你提供哪些信息是非常重要的背景信息。

从表面上看来邮件似乎是直接从发送者机器传递到接收者地址，但通常情况下事情并不是这样。

一个典型的电子邮件在其生命周期中至少要经过四台计算机。

这是因为大多数企业或组织都有一个被称为“邮件服务器”专用服务器来处理电子邮件，而这一般并不是用户阅读邮件的计算机。

对于ISP来说，用户从家里面的计算机拨号接入ISP网络，这里将用户家中的计算机称为客户机，而将ISP专门处理邮件的计算机称为邮件服务器。

当一个用户发送邮件，他一般是在自己的计算机上编辑邮件，然后将邮件发送到ISP的邮件服务器上。

客户机就此已经完成了自己的工作，而后面的工作则由ISP的邮件服务器来完成。

首先ISP邮件服务器查找接收者指定的邮件服务器的IP地址，然后将邮件发送给该目的服务器。

现在邮件则存储在接收者邮件服务器上等待接收者收取。

当接收者从接受邮件服务器取得发送给他的邮件到自己的PC机以后，通常该邮件将被删除。

假设若干个虚构的用户和。

zhangsan是263这个ISP的拨号用户。

使用outookexpress这个邮件客户程序收发邮件。

lisi是中科院的一个虚构用户，他使用工作站通过单位局域网连接进入互联网。

如果lisi想给zhangsan发送邮件，他在工作站（假设名字为）上编辑邮件，编辑好的信件从工作站发送到中科院的邮件服务器：

。

一旦信件被发送到，以后的信件发送过程就和zhangsan没有关系了。

中科院的邮件服务器发现这是发送给的某个用户的信件，则和263的邮件服务器-比如说是－通信，并将邮件传送给它。

现在邮件则被存储在之上直到zhangsan在自己的PC机上拨号连接到263网络察看并收取信件，这时将存储的邮件传送到zhangsan的个人PC机上。

在这个过程中，邮件头将三次被加到邮件中：

在编辑时由邮件客户程序加入；当邮件传输到时被加入；当从传送到时被加入；通常来说客户收取信件时并不添加邮件头。

下面我们就仔细看看这些邮件头是如何产生的。

当lisi的邮件客户程序编辑邮件并将其发送给时，邮件内容如下.这些内容都是由邮件编辑程序（outlookexpress）添加的：

From:

lisi@（LiSi）

To:

zhangsan@

Date:

Tue,Mar18199714:

36:

14PST

X-Mailer:

OutlookExpress5.5

Subject:

中午搓饭？

当邮件从传送到后，邮件内容变为（新添加的内容是由）：

Received:

from（[124.211.3.11]）by

（8.8.5）id004A21;Tue,Mar18199714:

36:

17-0800（PST）

From:

lisi@（LiSi）

To:

zhangsan@

Date:

Tue,Mar18199714:

36:

14PST

Message-Id:

X-Mailer:

OutlookExpress5.5

Subject:

中午搓饭?

当收到信件并存储等待zhangsan收取时，邮件内容变为，（新添加的内容是由添加的）：

Received:

from（[124.211.3.78]）by

（8.8.5/8.7.2）withESMTPidLAA20869for;

Tue,18Mar199714:

39:

24-0800（PST）

Received:

from（[124.211.3.11]）by

（8.8.5）id004A21;Tue,Mar18199714:

36:

17-0800（PST）

From:

lisi@（LiSi）

To:

zhangsan@

Date:

Tue,Mar18199714:

36:

14PST

Message-Id:

X-Mailer:

OutlookExpress5.5

Subject:

中午搓饭?

最后这封信的内容才是zhangsan收取并阅读的内容。

下面是对其中内容的详细分析：

Received:

from

上面的内容表示该邮件是来自于自称是的服务器。

（[124.211.3.78]）

这句话表示该服务器的真实名字的确是，也就是说它自称的身份是正确的，其IP地址为24.211.3.78。

by（8.8.5/8.7.2）

接收这封邮件的机器是。

其运行的邮件程序为sendmail，版本为8.8.5/8.7.2。

withESMTPidLAA20869

接收邮件的服务器为该邮件赋有ID号LAA20869（通常该号码是邮件服务器内部使用的，但是管理员可以根据该ID号在log文件中查找关于该信件的相关信息，但是通常该号都是没有意义的）。

for;

该邮件是发送给地址zhangsan@的。

可以看到该邮件头没有To：

相关内容。

Tue,18Mar199714:

39:

24-0800（PST）

这次邮件传输发生时间为：

太平洋时间Tuesday,March18,1997,at14:

39:

24（太平洋时间，因为它比格林威治时间晚8个小时，因此是"-0800"）。

Received:

from（[124.211.3.11]）by

（8.8.5）id004A21;Tue,Mar18199714:

36:

17-0800（PST）

该邮件头记录了邮件是从（lisi的工作站）传送到到邮件服务器的。

传送发生在太平洋时间14:

36:

17。

发送计算机自称是，其真实名经dns查询的确是，其IP地址为124.211.3.11，邮件服务器软件为sendmailv8.8.5。

该信件被邮件服务器的赋给的ID号为004A21。

From:

lisi@（LiSi）

该邮件是由lis@发送的，其名字为LiSi。

To:

zhangsan@

邮件目的地址为：

zhangsan@。

Date:

Tue,Mar18199714:

36:

14PST

邮件编辑时间为14:

36:

14PacificStandardTimeonTuesday,March18,1997。

Message-Id:

给该邮件分配了这个号码来标识它。

它和Received头中的SMTP机ESMTPID号是不一样的。

因为该号码是一直伴随整个邮件的。

而其它ID则仅仅在特定的邮件服务器上的邮件传输阶段相关联。

因此该机器ID号对其它机器来说没有任何意义。

有时候Message-ID包含了发送者邮件地址在其中。

X-Mailer:

OutlookExpress5.5

该消息是使用OutlookExpress发送的，版本号为5.5。

Subject:

中午搓饭?

邮件标题。

邮件协议

这部分内容相对其它部分来说具有更多原理性内容，主要讨论邮件是如何从一点传输到另外一点的细节。

你不需要理解每一句话，但是熟悉这方面的内容有助于在邮件传输出现奇怪现象时弄明白问题所在。

由于垃圾电子邮件发送者常常故意制造一些奇怪的情况以掩饰自己的身份，因此能理解这些奇怪的现象对对付这些家伙是非常有用的。

为了在网络上传输数据，计算机网络协议使用了称为端口的访问入口，你可以将端口看做是一个通道，通过它计算机可以监听网络通信以提供服务。

为了同时监听多个通信，计算机需要有使用端口号码标识多个不同的端口以区别这些通信。

而和电子邮件传输相关的端口是25。

正常情况

让我们重新讨论上面的例子，但是这次我们仅仅关心到之间的通信过程。

首先mail.zky.edu.c打开一个到的25号端口的连接，然后通过该连接发送邮件，当然在发送邮件过程中会有一些管理命令交互过程。

交互中的命令和相应都或多或少的是可读的。

命令是SMTP协议规定的。

如果监听两者之间的通信，可能有以下内容：

（粗体部分是发出的）

220ESMTPSendmail8.8.5/1.4/8.7.2/1.13;Tue,Mar181997

14:

38:

58-0800（PST）

HELO

250Hello[124.211.3.78],pleasedtomeetyou

MAILFROM:

lisi@

250lisi@...Senderok

RCPTTO:

zhangsan@

250zhangsan@...Recipientok

DATA

354Entermail,endwith"."onalinebyitself

Received:

from（[124.211.3.11]）by

（8.8.5）id004A21;Tue,Mar18199714:

36:

17-0800（PST）

From:

lisi@（R.T.Hood）

To:

zhangsan@

Date:

Tue,Mar18199714:

36:

14PST

Message-Id:

X-Mailer:

OutlookExpress5.5

Subject:

中午搓饭?

Doyouhavetimetomeetforlunch?

--lisi

.

250LAA20869Messageacceptedfordelivery

QUIT

221closingconnection

整个传输依赖于五个SMTP核心命令（当然SMTP还有一些其它命令，但是它们并不是用来完成真正的邮件传输）：

HELO，MAILFROM，RCPTTO，DATA和QUIT。

邮件发送者HELO命令用来标识自己的身份。

HELO可以被解读为"嗨，我是"。

当然这里发送者可能会撒谎，但是没有任何机制能防止发送者说"嗨，我是"或是"嗨，我是"。

然而在大多数情况下接收者都有一些方法来确认发送者的真实身份。

MAILFROM命令标识开始邮件传输，含义是"我有从某人发送来的邮件"，该命令后跟的地址就是所谓的“信封地址”（在后面我们将深入讨论），信封from地址不一定是发送者自己的地址。

这个明显的安全漏洞是不可避免的（因为接收者并不知道发送者机器上有哪些地址），但是在特定的情况下这又是一个有用处的特色。

RCPTTO和MAILFROM是相辅相成的。

其指定邮件接收者。

通过多个RCPTTO命令一个邮件可以被发送给多个接收者。

（在后面的邮件中继部分将解释该特色可能针对某些不安全的系统滥用）。

该命令后跟的地址称为"envelopeto"地址。

其指定了邮件将被投递给哪些用户，而和信件中的To:

指定的地址没有关系。

DATA命令指示开始实际的邮件内容传输。

DATA命令后输入的任何内容都被看做是邮件的一部分。

而格式并没有任何限制。

以一个英文单词加冒号开始的行一般被邮件程序看做是邮件头。

以英文句号符号（.）开始的行被认为是邮件内容结束。

QUIT命令终止连接。

SMTP协议规范定义在RFC821中。

非正常情况

上面的例子有些过于简单。

上面的例子有一个假设前提：

两个组织的邮件服务器相互之间能直接访问，而不需要经过代理、防火墙等安全设备。

这在当前Internet环境下情况往往是这样的。

但由于安全对于某些组织来说非常重要，而且网络或组织可能变得越来越庞大，情况就不那么简单了。

对于具有代理型防火墙系统的邮件传输来说，区别就在于在邮件的头中多了一次转发过程的记录，也就是邮件首先从发送者邮件服务器发送到

防火墙上，然后再从防火墙发送到目的邮件服务器。

邮件中继

中继

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

Received:

from（

[98.134.11.32]）by（8.8.5）id004B32for;

Wed,Jul30199716:

39:

50-0800（PST）

Received:

from（[202.99.11.120]）by

（8.6.5/8.5.8）withSMTPidLAA12741;Wed,Jul30199719:

36:

28-0500（EST）

From:

AnonymousSpammer

To:

（recipientlistsuppressed）

Message-Id:

X-Mailer:

MassiveAnnoyance

Subject:

WANTTOMAKEALOTOFMONEY?

?

?

这个邮件头和以前的不同之处可能会令你认为这是一封垃圾邮件，但是这里引起你的怀疑的是"Received:

"头。

从"Received:

"头看来，邮件是来自，然后从这里传输给，然后从这里再次传输到最终目的地址：

。

从"Received:

"头看来事情就是这样的，但是中间为什么会出现呢？

因为它和发送者和接收者都没有直接的关系。

要理解原因需要对SMTP协议进行一些了解。

本质上来讲，传输过程是这样的：

连接的SMTP端口。

告诉它“请发送这封邮件到rth@。

它可能是以最直接的方法来实现：

RCPTTO:

rth@。

到现在为止，接管对该邮件的处理。

因为它被告知将该信件转发给其他一个域：

，它就查找对于域名的邮件服务器然后将邮件转发给。

这个过程通常被称作邮件中继（mailrelaying）。

出现邮件中继是由于历史的原因，使用邮件中继是有它的好处的。

到八十年代末期，很多网络中的计算机都不是直接通信来传输邮件。

而是通过邮件路由来传递邮件，通过邮件路由服务器一步一步地进行邮件传输。

这样做是非常麻烦的，发送者往往需要手工指定一封邮件需要经过哪些邮件路由服务器，比如需要从SanFrancisco发送一封邮件到NewYork，则需要在信封中添加如下内容：

SanFrancisco,Sacramento,Reno,SaltLakeCity,RockSprings,Laramie,

NorthPlatte,Lincoln,Omaha,DesMoines,CedarRapids,Dubuque,Rockford,

Chicago,Gary,Elkhart,FortWayne,Toledo,Cleveland,Erie,Elmira,

Williamsport,Newark,NewYorkCity,GreenwichVillage,#12DesolationRow,

Apt.#35,R.A.Zimmermann

如果从邮局工作人员的角度来考虑，这种模型是非常有用的。

在Gary的邮局只需要知道如何和临近的邮局Chicago和Elkhart通信，而无需消耗资源计算如何将邮件发送到NewYork（这时候就很清楚为什么这种模式对于邮件发送者来说非常糟糕，为什么这种方法被抛弃了）。

但是这就是邮件被传输的过程。

因此服务器具有这样的中继的能力在那时是很重要的。

而现在中继通常被用作不道德的广告商用来隐藏它们的原始地址，将埋怨转嫁给被用来中继的服务器而不是其所在ISP的技术。

同样通过中继可以实现将发送信件的负载转移到中继服务器上，从而实现盗用中继服务器的服务资源。

在这里最重要的一点是理解邮件内容是在发送点被编辑。

中间的服务器只是参加了中间的传输工作，它并不能对发送者有任何的约束力。

在上面的例子中应该注意的另外一点是"Message-Id:

"并不是由发送者服务器（）而是中继计算机（）填写的。

这是被中继的邮件的一个典型特性，该特性反映了发送服务器并没有提供Message-Id的事实。

信封头

上面关于SMTP的讨论部分提到了“消息”头和“信封”头的不同之处。

这种区别和导致的后果将在这里详细地讨论。

简单地说，“信封”头实际上是由接收消息的邮件服务器产生的，而不是发送者服务器。

按照这个定义，“Received:

”头是信封头，而一般来说常常使用"envelopeFrom"和"envelopeTo"来指示它们。

"envelopeFrom"头是从MAILFROM命令得到的。

如发送者邮件服务器发出命令MAILFROM:

ideal@，则接收者服务器则产生一个"envelopeFrom"头：

>Fromideal@。

注意这里少了一个冒号-"From"而不是"From:

"。

也就是说信封头在其后没有冒号。

当然这个惯例并不是标准，但是这时一个值得注意的惯例。

对应的是"envelopeTo"同样来自于RCPTTO命令。

如果发送者服务器发出命令RCPTTO:

ideal@。

则"envelopeTo"为ideal@。

一般来说实际上并没有这样一个邮件头，它常常是包含在Received:

头中。

存在信封信息的一个重要结果就是消息From:

和To:

变得毫无意义。

From:

头是由发送者提供的，同样To:

也是由发送者提供的。

因此邮件仅仅基于"envelopeTo"来进行转发路由，而不是基于消息To:

。

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

HELOgalangal.org

250Hello[202.99.11.120],pleasedtomeet

you

MAILFROM:

forged-address@galangal.org

250forged-address@galangal.org...Senderok

RCPTTO:

lisi@

250lisi@...RecipientOK

DATA

354Entermail,endwith"."onalinebyitself

From:

another-forged-address@lemongrass.org

To:

（这里你的地址被隐瞒以实现秘密邮件转发和骚扰）

.

250OAA08757Messageacceptedfordelivery

下面是对应的邮件头：

>Fromforged-address@galangal.org

Received:

fromgalangal.org（[202.99.11.120]）by（8.8.5）for

...

From:

another-forged-address@lemongrass.org

To:

（youraddresssuppressedforstealthmailingandannoyance）

注意到"envelopeFrom"的内容和消息From:

的内容和消息To:

的内容都是发送者指定的，因此他们都是不可靠的。

这个例子说明了为什么信封From、消息From:

及消息To:

在可能是伪造的邮件中是不可靠的，因为它们太容易伪造了。

"Received:

"头的重要性

在上面的例子中我们已经看到，"Received:

"头提供了详细的消息传输历史记录，因此即使在其他邮件头是被伪造的情况下也可能根据"Received:

"头得到某些关于该信件原始出处和传输过程的结论。

这部分将详细探讨某些和异常的重要消息头相关的问题，特别是如何挫败那些常见的伪造技术。

毫无疑问的是，在"Received:

"头中唯一重要且有价值的伪造防护就是由接收服务器记录的那些信息。

前面提到发送者能伪造自己的身份（通过在HELO命令中报告错误的身份）。

幸运的是现代邮件服务器程序都可以检测到这种错误信息并加以修正。

如果服务器的真实IP地址是202.99.11.120