给该邮件分配了这个号码来标识它。
它和Received头中的SMTP机ESMTPID号是不一样的。
因为该号码是一直伴随整个邮件的。
而其它ID则仅仅在特定的邮件服务器上的邮件传输阶段相关联。
因此该机器ID号对其它机器来说没有任 何意义。
有时候Message-ID包含了发送者邮件地址在其中。
X-Mailer:
OutlookExpress6.0
该消息是使用 OutlookExpress 发送的，版本号为 6.0。
Subject:
明天放假?
邮件标题。
三、邮件协议
这部分内容相对其它部分来说具有更多原理性内容，主要讨论邮件是如何从一点传输到另外一点的细节。
你不需要理解每一句话， 但是熟悉这方面的内容有助于在邮件传输出现奇怪现象时弄明白问题所在。
由于垃圾电子邮件发送者常常故意制造一些奇怪的情况以掩饰自己的身份，因此能理解这 些奇怪的现象对对付这些家伙是非常有用的。
为了在网络上传输数据，计算机网络协议使用了称为端口的访问入口，你可以将端口看做是一个通道，通过它计算机可以监听网络通信以提供服务。
为了同时监听多个通信，计算机需要有使用端口号码标识多个不同的端口以区别这些通信。
而和电子邮件传输相关的端口是25。
正常情况
让 我们重新讨论上面的例子，但是这次我们仅仅关心 到 之间的通信过程。
首先 打开一个到 的25号端口的连接，然后通过该连接发送邮件，当然在发送邮件过程中会有一些管理命令交互过程。
交互中的命令和相应都或多或少的是可读的。
命令是SMTP 协议规定的。
如果监听两者之间的通信，可能有以下内容：
（粗体部分是 发出的）
220ESMTPSendmail8.8.5/1.4/8.7.2/1.13;Tue,Mar18200314:
38:
58-0800（PST）
HELO
250Hello[124.211.3.78],pleasedtomeetyou
MAILFROM:
tom@
250tom@...Senderok
RCPTTO:
betty@
250betty@...Recipientok
DATA
354Entermail,endwith"."onalinebyitself
Received:
fromtom-（tom-[124.211.3.11]）by（8.8.5）id004A21;Tue,Mar18200314:
36:
17-0800（PST）
From:
tom@（TomLee）
To:
betty@
Date:
Tue,Mar18200314:
36:
14PST
Message-Id:
X-Mailer:
OutlookExpress6.0
Subject:
明天放假?
Doyouhavetimetomeetforlunch?
--TomLee
.
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,Jul30200316:
39:
50-0800（PST）
Received:
from（[202.99.11.120]）by（8.6.5/8.5.8）withSMTPidLAA12741;Wed,Jul30200319:
36:
28-0500（EST）
From:
AnonymousSpammer
To:
（recipientlistsuppressed）
Message-Id:
X-Mailer:
MassiveAnnoyance
Subject:
WANTTOMAKEALOTOFMONEY?
?
?
这 个邮件头和以前的不同之处可能会令你认为这是一封垃圾邮件，但是这里引起你的怀疑的是"Received:
"头。
从"Received:
"头看来，邮件是 来自，然后从这里传输给，然后从这里再次传输到最终目的地 址：
。
从"Received:
"头看来事情就是这样的，但是中间为什么会出现呢？
因为它和发送者和接收者都没有直接的关系。
要理解原因需要对SMTP协议进行 一些了解。
本质上来讲，传输过程是这样的：
连接 的 SMTP 端口。
告诉它“请发送这封邮件到 tom@。
它可能是以最直接的方法来实现：
RCPTTO:
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的技术。
同 样通过中继可以实现将发送信件的负载转移到中继服务器上，从而实现盗用中继服务器的服务资源。
在这里最重要的一点是理解邮件内容是在发送点 被编辑。
中间的服务器 只是参加了中间的传输工作，它并不能对发送者有任何的约束力。
在上面的例子中应该注意的另外一点是"Message-Id:
"并不是 由发送者服务器（）而是中继计算机（unwilling.intermedia.com）填写的。
这是被中继的邮件的一个典型特性，该特性反映了发送服务器并没有提供 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],pleasedtomeetyou
升级会员 