中国的网民数量已突破1 亿，每年电子邮件发送量达500 亿封，但是这样的数据却并不能令我们惊喜，因为在这500 亿封电子邮件中，有将近60%也就是有300 亿封是垃圾邮件。垃圾邮件已经成为一个综合性的社会问题，要想从根本上杜绝垃圾邮件的泛滥，必须采取全民总动员的方式。由政府出面组织立法，行业制订规则、积极协调，邮件服务商则提供技术，用户积极参与、协同合作。只有这样，形成一个大众化的反垃圾邮件联盟，才能从根本上取得显著成效。
反垃圾邮件技术之 密径寻源
滥用SMTP
垃圾邮件泛滥的今天，如果收到了垃圾邮件，你可能会根据邮件的提示采用取消订阅的操作，而这些取消订阅的方法根本就是一种伪装，几乎没有一个是有效的。相反，邮件的发起者却根据你的反馈信息，将你的邮件地址纳入有效投递用户数据库，得不偿失。追其原因，主要和商业利益以及SMTP协议的安全机制不健全有关。
SMTP
协议对我们来说，应该是再熟悉不过的了，但是，这个协议在创建的时候并没有考虑到未来的邮件会成为垃圾，因此安全性很差（人们还是以RFC524为基础来执行SMTP的），邮件头可以任意创建、伪造和修改。邮件服务器一般不检查发送者的内容，而只关心接收者，这就给了垃圾邮件发送者可乘之机。互联网上的SMTP认证是针对无限制转发采取的措施。所谓无限制转发，就是任何人都可以使用你的服务器发送邮件，一方面降低了投入成本，另一方面隐藏了真实的来源。隐藏真实地址的原因主要是因为垃圾邮件发送在许多国家属于违法行为，另外，垃圾邮件发送者（spammer）都明白垃圾邮件是不受欢迎的，通过伪造发送者地址，就可能减少这种反应。早在2002年的时候，欧美的一些IT技术论坛上，关于因为大量的垃圾邮件引起了西方ISP屏蔽中国邮件服务器的“热潮”，就曾经广为部署过。当时，中国电信的202.96.0.0—202.111.255.255范围内的全部地址都被屏蔽，这都是垃圾邮件惹的祸。服务器被中继（Open Relay）的现象不但阻止垃圾邮件的首要任务，而且也是病毒邮件泛滥的罪魁祸首。
解读信头
追踪邮件将很大程度依靠对邮件头的分析，RFC2076 列出了多数通用的消息头，此外也可以参考RFC2822。比如在Outlook Express中，我们可以通过点击邮件的高级属性打开邮件头部的信息（图1），一个邮件头中常用于分析的项目如下：
1.
Return-Path
: [email]eberlyolabode@domian1.net[/email]
；回复时发送的地址。很容易被伪造，但常常提供线索，比如有些垃圾邮件经常用该域指向一个合法的邮件地址，以便spammer能够接收到回复的邮件；
2.
Delivered-To
: [email]nospammer@mymail.com[/email]
；和后面的“To”相同，收信人地址；
3.
Received
: from mail.domian1.net (unknown [192.168.x.148])
by mail.domain2.com (Postfix) with ESMTP id 66B
1612191F
for <nospammer% mymail.com @domian2.net >; Mon, 24 Jul 2006 05:11:54 +0800 (CST)
邮件头中最可信部分。一般会有几条，形成站点列表，这些信息表明达到目的地过程中邮件所经过的服务器，域名都是邮件服务器自动插入的，spammer 可以伪造，但是在被伪造以后经过的域名是可信的。这个列表从下往上表明了服务器路径，最上面的一条Received是最终目的邮件服务器，也就是自己要接收邮件的服务器，除非它也出现了问题。Receive 语句的基本表达格式是：from Server A by Server B，Server A 为发送服务器, Server B 为接收服务器。ESMTP ID 表示
4.
Message-ID
: <
000001c
6ae
9c
$a
563a
520$a4e
8a
8c
0@saj61>
，邮件系统在创建邮件时的唯一标记（参考RFC822、RFC1036）。也经常被伪造，但如果是正常的，那么Message-ID:也通常能确定发送者所登录的系统，而不仅仅是邮件被创建的系统。Message-ID 的结构同邮件服务器程序有直接关系，不同的邮件服务器的ID也不相同，但区别于ESMTP ID；
5.
服务器产生的ID 也不一样，有时相同邮件服务器的不同处理也会产生不一样的ID
6.
Reply-To
: "Olabode Eberly" <[email]eberlyolabode@domian1.net[/email]>
回复地址，被伪造；
7.
From
: "Olabode Eberly" <[email]eberlyolabode@domian1.net[/email]>
发信人地址，被伪造；
8.
To
: nospammer@ mymail.com
判别源头的要点
一个完整的邮件传输过程如下：“邮件发送者→ MUA → MTA → 网络传输→MTA → MDA→ 可能会有的邮件过滤 →MUA → 邮件接收者”。通过邮件传输原理，就可以将每个环节的不同特征拿出来，这为我们判别垃圾邮件带来帮助（图2）。
l
MUA
(Mail User Agent)
Mail Client
端的软件，它帮我们传送与接受Mail，使用者通过它来跟 Mail Server 沟通，最常见的 MUA 有 Outlook Express和Fox Mail等
l
MTA (Mail Transfer Agent)
它的作用是帮助我们把Mail传送给其它Mail Serve，同时接受外部主机寄来的信件，所有的 SMTP servers 都可称为MTA。
l
MDA (Mail Delivery Agent)
这项服务是用来把 MTA 所接受的Mail传递至使用者 Mailbox（收信箱）里面，部分SMTP Servers 也兼顾这MDA的角色。
l
收信、发信人地址
在我们收到的垃圾邮件中经常遇到发信人是我们自己的名字，或者收信人根本是与自己毫无关系的名字。这是因为收信人的
MUA
会从邮件中提取，
From
、
To
、
Date
字段，如果发信人的
MUA
不是按照正常的逻辑工作的，或者发信人有意的使用垃圾邮件发送软件，那么就会变更
MAIL FROM
和
RCPT TO
的值，使其拥有了不同的邮件地址。这个时候，
MAIL FROM
的值绝对是不可信的，而发信者为了得到收信人的反馈信息，所有我们可以通过
RCPT TO
中的域名地址来定位来源。
l
非法中继
如果发信人使用的不是自己所拥有的邮件服务器，在传输过程中使用互联网上带有
Open Relay
漏洞的服务器，这就为判别邮件的真实来源带来的困难。在
Received
字段中如果包含了既不是发信人，又不是收信人域名的邮件服务器，这就很有可能是被非法中继的服务器，我们可是使用TELNET等工具测试这台服务器是否具有
Open Relay
漏洞。
l
反向解析不同
如果发信人的域名为
sender.com
，但他在
SMTP
对话中的
HELO
命令后冒充另外一个域名是，比如
HELO testname.org
，此时信件的
Received
字段很有可能是如下形式：Received: from testname.org (sender.com [192.168.100.100]) by……, 我们通过对testname.org进行反向地址查询后，就能发现IP地址信息与这个域名地址不符。
l
查找伪造的Received
由于怕暴露自己的真实信息，垃圾邮件的发送者经常在邮件头中插入大量的Received行。如果你的邮件头中存在大量的Received字段，最后几行一般是被插入的，因为信件一旦离开主机后，发信人是无法进行控制的，所经过的邮件服器将自动将信息加入到信头顶部。从上到下追踪From和by的信息，以及IP的路由信息，是可以判别那些行是被伪造的。
评论：
通过上述内容我们有可能查找出邮件的真实发送IP，将其屏蔽，但如果发信方采用拨号的方式进行发送，或者机场经常更换地址，这就增加了判别正确的可信度。早在 1999 年，垃圾邮件与病毒邮件还未成为全球IT业关注议题时，制定因特网与电子邮件相关标准的 IETF/IRTF等单位就提交文件 RFC 2505， 针对反制垃圾邮件的 SMTP MTA 主机设计提出规划建议：需要SMTP MTA 主机应针对邮件发送来源进行通透解析，判定是否具匿名、伪造、滥发等非法行为，以采取退件或延迟反制机制；RFC 2505 更提出技术洞见，预言具弹性辨识机制、精良设计的 MTA 才能时时因应垃圾滥发者的反制手法。深度垃圾邮件行为解析必需在 MTA 阶段执行，以邮件传输值追踪技术、邮件通讯行为解析技术与预设滥发者类型Pattern，追踪、验证并判断来信是否为垃圾邮件。绝非浅层邮件行为解析如联机次数分析、发送 IP 地址、发送时间、发送频率、收件者数目、浅层电子邮件标头检查、发送行为侦测与检验Handshaking 联机阶段等信息可判断
本文转自张琦51CTO博客，原文链接：http://blog.51cto.com/zhangqi/33834，如需转载请自行联系原作
![[Web安全]信息收集（上）](https://ucc.alicdn.com/pic/developer-ecology/52af5ed1baef4e4aad3e9549695f39fa.png?x-oss-process=image/resize,h_160,m_lfit)
![[Web安全]信息收集（下）](https://ucc.alicdn.com/pic/developer-ecology/156c4fc347424ff9a5afd33f0e952a9e.png?x-oss-process=image/resize,h_160,m_lfit)