Email邮件头详解Word下载.docx
《Email邮件头详解Word下载.docx》由会员分享，可在线阅读，更多相关《Email邮件头详解Word下载.docx（11页珍藏版）》请在冰豆网上搜索。
。
betty
是
的免费邮件用户。
使用
outookexpress
这个邮件客户程序收发邮件。
tom
是中科院的一个邮件用户，他使用个人电脑通过单位局域网连接进入互联网。
如果
想给
发送邮件，他在个人电脑（假设名字为
tom-）上编辑邮件，编辑好的信件从个人电脑发送到中科院的邮件服务器：
一旦信件被发送到
，以后的信件发送过程就和
没有关系了。
中科院的邮件服务器发现这是发送给
的某个用户的信件，则和
的邮件服务器－比如说是－通信，并将邮件传送给它。
现在邮件则被存储在
之上直到
在自己的PC机上拨号上网并连接到
邮件系统察看并收取信件，这时
将存储的邮件传送到
的个人电脑上。
在这个过程中，邮件头将三次被加到邮件中：
在编辑时由
邮件客户程序加入；
当邮件传输到
时被
加入；
当从
传送到
通常来说客户收取信件时并不添加邮件头。
下面我们就仔细看看这些邮件头是如何产生的。
当
的邮件客户程序编辑邮件并将其发送给
时，邮件内容如下。
这些内容都是由邮件编辑程序
（outlookexpress）添加的：
From:
tom@（TomLee）
To:
betty@
Date:
Tue,Mar18200314:
36:
14PST
X-Mailer:
OutlookExpress6.0
Subject:
明天放假？
当邮件从
后，邮件内容变为（新添加的内容是由
）：
Received:
fromtom-（tom-[124.211.3.11]）by（8.8.5）id004A21;
17-0800（PST）
Message-Id:
<
tom031897143614-00000298@>
明天放假?
收到信件并存储等待
收取时，邮件内容变为，（新添加的内容是由
添加的）：
from（[124.211.3.78]）by（8.8.5/8.7.2）withESMTPidLAA20869for<
demo@hotmail>
;
Tue,18Mar200314:
39:
24-0800（PST）
fromtom-（[124.211.3.11]）by（8.8.5）id004A21;
最后这封信的内容才是
收取并阅读的内容。
下面是对其中内容的详细分析：
from
上面的内容表示该邮件是来自于自称是
的服务器。
（[124.211.3.78]）
这句话表示该服务器的真实名字的确是
，也就是说它自称的身份是正确的，其IP地址为
124.211.3.78。
by（8.8.5/8.7.2）
接收这封邮件的机器是
其运行的邮件程序为
sendmail，版本为8.8.5/8.7.2。
withESMTPidLAA20869
接收邮件的服务器为该邮件赋有ID号LAA20869（通常该号码是邮件服务器内部使用的，但是管理员可以根据该ID号在log文件中查找关于该信件的相关信息，但是通常该号都是没有意义的）
for<
该邮件是发送给地址
betty@
的。
可以看到该邮件头没有To:
相关内容。
Tue,18Mar200314:
这次邮件传输发生时间为：
太平洋时间Tuesday,March18,2003,at14:
24（太平洋时间，因为它比格林威治时间晚8个小时，因此是"
-0800"
）。
该邮件头记录了邮件是从
tom-（tom的个人电脑）传送到到邮件服务器
传送发生在太平洋时间14:
17。
发送计算机自称是
tom-，其真实名经dns查询的确是
tom-，其IP地址为
124.211.3.11，邮件服务器软件为
sendmailv8.8.5。
该信件被邮件服务器的
赋给的ID号为004A21。
该邮件是由
tom@
发送的，其名字为
TomLee。
邮件目的地址为：
betty@。
邮件编辑时间为14:
14PacificStandardTimeonTuesday,March18,2003。
tom031897143614-00000298@
给该邮件分配了这个号码来标识它。
它和Received头中的SMTP机ESMTPID号是不一样的。
因为该号码是一直伴随整个邮件的。
而其它ID则仅仅在特定的邮件服务器上的邮件传输阶段相关联。
因此该机器ID号对其它机器来说没有任
何意义。
有时候Message-ID包含了发送者邮件地址在其中。
该消息是使用
OutlookExpress
发送的，版本号为
6.0。
邮件标题。
三、邮件协议
这部分内容相对其它部分来说具有更多原理性内容，主要讨论邮件是如何从一点传输到另外一点的细节。
你不需要理解每一句话，
但是熟悉这方面的内容有助于在邮件传输出现奇怪现象时弄明白问题所在。
由于垃圾电子邮件发送者常常故意制造一些奇怪的情况以掩饰自己的身份，因此能理解这
些奇怪的现象对对付这些家伙是非常有用的。
为了在网络上传输数据，计算机网络协议使用了称为端口的访问入口，你可以将端口看做是一个通道，通过它计算机可以监听网络通信以提供服务。
为了同时监听多个通信，计算机需要有使用端口号码标识多个不同的端口以区别这些通信。
而和电子邮件传输相关的端口是25。
正常情况
让
我们重新讨论上面的例子，但是这次我们仅仅关心
到
之间的通信过程。
首先
打开一个到
的25号端口的连接，然后通过该连接发送邮件，当然在发送邮件过程中会有一些管理命令交互过程。
交互中的命令和相应都或多或少的是可读的。
命令是SMTP
协议规定的。
如果监听两者之间的通信，可能有以下内容：
（粗体部分是
发出的）
220ESMTPSendmail8.8.5/1.4/8.7.2/1.13;
38:
58-0800（PST）
HELO
250Hello[124.211.3.78],pleasedtomeetyou
MAILFROM:
tom@
250tom@...Senderok
RCPTTO:
250betty@...Recipientok
DATA
354Entermail,endwith"
."
onalinebyitself
Doyouhavetimetomeetforlunch?
--TomLee
.
250LAA20869Messageacceptedfordelivery
QUIT
221closingconnection
整个传输依赖于五个SMTP核心命令（当然SMTP还有一些其它命令，但是它们并不是用来完成真正的邮件传输）：
HELO，MAILFROM，RCPTTO，DATA
和
QUIT。
邮
件发送者
HELO
命令用来标识自己的身份。
HELO
可以被解读为"
嗨，我是
"
当然这里发送者可能会撒谎，但是没有任何机制能防止发送者
说"
或是"
嗨，我是"
然而在大多数情况下接收者都有一些方法来确认发送者的真实身份。
MAILFROM
命令标识开始邮件传输，含义是"
我有从某人发送来的邮件"
，该命令后跟的地址就是所谓的“信封地址”（在后面我们将深入讨论），信封
from
地址不一定是发送者自己的地址。
这个明显的安全漏洞是不可避免的（因为接收者并不知道发送者机器上有哪些地址），但是在特定的情况下这又是一个有用处的特
色。
RCPTTO
是相辅相成的。
其指定邮件接收者。
通过多个
命令一个邮件可以被发送给多个接收者。
（在后面的邮件中继部分将解释该特色可能针对某些不安全的系统滥用）。
该命令后跟的地址称为"
envelopeto"
地址。
其指定了邮件将被投递给哪些用户，而和信件中的To:
指定的地址没有关系。
DATA
命令指示开始实际的邮件内容传输。
命令后输入的任何内容都被看做是邮件的一部分。
而格式并没有任何限制。
以一个英文单词加冒号开始的行一般被邮件程序看做是邮件头。
以英文句号符号（.）开始的行被认为是邮件内容结束。
QUIT
命令终止连接。
SMTP
协议规范定义在
RFC821
中。
非正常情况
上
面的例子有些过于简单。
上面的例子有一个假设前提：
两个组织的邮件服务器相互之间能直接访问，而不需要经过代理、防火墙等安全设备。
这在当前
Internet环境下情况往往是这样的。
但由于安全对于某些组织来说非常重要，而且网络或组织可能变得越来越庞大，情况就不那么简单了。
对于具有代理型
防火墙系统的邮件传输来说，区别就在于在邮件的头中多了一次转发过程的记录，也就是邮件首先从发送者邮件服务器发送到防火墙上，然后再从防火墙发送到目的
邮件服务器。
四、邮件中继
对于某些具有特殊的“生命”周期的邮件头可能和前面讨论的情况完全不同：
from（[98.134.11.32]）by（8.8.5）id004B32for<
Wed,Jul30200316:
50-0800（PST）
from（[202.99.11.120]）by（8.6.5/8.5.8）withSMTPidLAA12741;
Wed,Jul30200319:
28-0500（EST）
AnonymousSpammer<
junkmail@>
（recipientlistsuppressed）
w45qxz23-34ls5@>
MassiveAnnoyance
WANTTOMAKEALOTOFMONEY?
?
个邮件头和以前的不同之处可能会令你认为这是一封垃圾邮件，但是这里引起你的怀疑的是"
头。
从"
头看来，邮件是
来自，然后从这里传输给，然后从这里再次传输到最终目的地
址：
头看来事情就是这样的，但是中间为什么会出现呢？
因为它和发送者和接收者都没有直接的关系。
要理解原因需要对SMTP协议进行
一些了解。
本质上来讲，传输过程是这样的：
连接
的
端口。
告诉它“请发送这封邮件到
tom@。
它可能是以最直接的方法来实现：
到现在为止，
接管对该邮件的处理。
因为它被告知将该信件转发给其他一个域：
，它就查找对于域名
的邮件服务器然后将邮件转发给
这个过程通常被称作邮件中继（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的技术。
同
样通过中继可以实现将发送信件的负载转移到中继服务器上，从而实现盗用中继服务器的服务资源。
在这里最重要的一点是理解邮件内容是在发送点
被编辑。
中间的服务器
只是参加了中间的传输工作，它并不能对发送者有任何的约束力。
在上面的例子中应该注意的另外一点是"
并不是
由发送者服务器（）而是中继计算机（unwilling.intermedia.com）填写的。
这是被中继的邮件的一个典型特性，该特性反映了发送服务器并没有提供
Message-Id
的事实。
上面关于SMTP的讨论部分提到了“消息”头和“信封”头的不同之处。
这种区别和导致的后果将在这里详细地讨论。
简单地说，“信封”头实际上是由接收消息的邮件服务器产生的，而不是发送者服务器。
按照这个定义，“Received:
”头是信封头，而一般来说常常使用"
envelopeFrom"
和"
envelopeTo"
来指示它们。
头是从
命令得到的。
如发送者邮件服务器发出命令
ideal@，则接收者服务器则产生一个"
头：
>
Fromideal@。
注意这里少了一个冒号—"
From"
而不是"
也就是说信封头在其后没有冒号。
当然这个惯例并不是标准，但是这时一个值得注意的惯例。
对
应的是"
同样来自于RCPTTO命令。
如果发送者服务器发出命令RCPTTO:
ideal@。
则"
为
ideal@。
一般来说实际上并没有这样一个邮件头，它常常是包含在Received:
头中。
存在信封信息的一个重要结果就是消息
变得毫无意义。
头是由发送者提供的，同样
也是由发送者提供的。
因此邮件仅仅基于"
来进行转发路由，而不是基于消息To:
为了从实际中理解这个概念，看看下面这样的邮件传输：
HELOgalangal.org
250Hello[202.99.11.120],pleasedtomeetyou
升级会员 