Email邮件头揭密(二)

五、信封头  

上面关于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 aclearcase/" target="_blank" >ccepted 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: (这里你的地址被隐瞒以实现秘密邮件转发和骚扰)  
注意到"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:"头一般都很明显地是伪造的垃圾。

原文转自：http://www.ltesting.net