邮件发送者HELO命令用来标识自己的身份。HELO mail.zky.ac.cn可以被解读为"嗨，我是mail.zky.ac.cn"。当然这里发送者可能会撒谎，但是没有任何机制能防止发送者mail.zky.ac.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.zky.ac.cn (8.8.5) id 004B32 for <lisi@zky.ac.cn>; Wed, Jul 30 1997 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 1997 19:36:28 -0500 (EST)
From: Anonymous Spammer <junkmail@linuxaid.com.cn>
To: (recipient list suppressed)
Message-Id: <w45qxz23-34ls5@unwilling.intermedia.com>
X-Mailer: Massive Annoyance
Subject: WANT TO MAKE ALOT OF MONEY???
这个邮件头和以前的不同之处可能会令你认为这是一封垃圾邮件，但是这里引起你的怀疑的是"Received:"头。从"Received:"头看来，邮件是来自linuxaid.com.cn，然后从这里传输给unwilling.intermedia.com，然后从这里再次传输到最终目的地址：mail.zky.ac.cn。从"Received:"头看来事情就是这样的，但是中间为什么会出现unwilling.intermedia.com呢？因为它和发送者和接收者都没有直接的关系。
要理解原因需要对SMTP协议进行一些了解。本质上来讲，传输过程是这样的：linuxaid.com.cn连接unwilling.intermedia.com的SMTP端口。告诉它“请发送这封邮件到rth@zky.ac.cn。它可能是以最直接的方法来实现：RCPT TO: rth@zky.ac.cn。到现在为止，unwilling.intermedia.com接管对该邮件的处理。因为它被告知将该信件转发给其他一个域：zky.ac.cn，它就查找对于域名zky.ac.cn的邮件服务器然后将邮件转发给zky.ac.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.zky.ac.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: lisi@zky.ac.cn
250 lisi@zky.ac.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.zky.ac.cn (8.8.5) for <tmh@zky.ac.cn>...
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance)
注意到"envelope From"的内容和消息From:的内容和消息To:的内容都是发送者指定的，因此他们都是不可靠的。这个例子说明了为什么信封From、消息From:及消息To:在可能是伪造的邮件中是不可靠的，因为它们太容易伪造了。
"Received:"头的重要性
在上面的例子中我们已经看到，"Received:"头提供了详细的消息传输历史记录，因此即使在其他邮件头是被伪造的情况下也可能根据"Received:"头得到某些关于该信件原始出处和传输过程的结论。这部分将详细探讨某些和异常的重要消息头相关的问题，特别是如何挫败那些常见的伪造技术。
毫无疑问的是，在"Received:"头中唯一重要且有价值的伪造防护就是由接收服务器记录的那些信息。前面提到发送者能伪造自己的身份(通过在HELO命令中报告错误的身份)。幸运的是现代邮件服务器程序都可以检测到这种错误信息并加以修正。
如果服务器linuxaid.com.cn的真实IP地址是202.99.11.120，发送邮件给mail.zky.ac.cn，但是使用HELO galangal.org命令来伪造自己的身份，则对应该次传输的"Received:"可能如下所示：
Received: from galangal.org ([202.99.11.120]) by mail.zky.ac.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.zky.ac.cn使用这种软件，则"Received:"头则变为
Received: from galangal.org (linuxaid.com.cn [202.99.11.120]) by mail.zky.ac.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.zky.ac.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.zky.ac.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:"头一般都很明显地是伪造的垃圾。.
分页: [1] [2]
- 上一篇:Linux邮件系统软件介绍
- 下一篇:邮件身份验证机制分析