电子邮件头全揭密邮件中继 中继
这个邮件头和以前的不同之处可能会令你认为这是一封垃圾邮件，但是这里引起你的怀疑的是'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，则需要在信封中添加如下内容：
如果从邮局工作人员的角度来考虑，这种模型是非常有用的。在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:。 为了从实际中理解这个概念，看看下面这样的邮件传输：
下面是对应的邮件头：
更多相关文章
|
推荐文章
精彩文章
|
