反lj邮件技术解析-2

2.1.6 局限性和缺点
现行的很多采用过滤器技术的反lj邮件产品通常都采用了多种过滤器技术,以便使产品更为有效。过滤器通过他们的误报和漏报来分等级。漏报就是指lj邮件绕过了过滤器的过滤。而误报则是将正常的邮件判断为了lj邮件。完美的过滤器系统应该是不存在漏报和误报的,但是这是理想情况。
一些基于过滤器原理的反lj邮件系统通常有下面的三种局限性:
·可能被绕过。lj邮件发送者和他们用的发送工具也不是静态的,他们也会很快适应过滤器。比如,针对关键字列表,他们可以随机更改一些单词的拼写。当前普遍使用的贝叶斯过滤器可以通过插入随机单词或句子来绕过。多数过滤器都最多只能在少数几周才最有效,为了保持反lj邮件系统的实用性,过滤器规则就必须不断更新,比如每天或者每周更新。
·误报问题。最头痛的问题就是将正常邮件判断为lj邮件。比如,一封包含单词sample的正常邮件可能因此被判断为lj邮件。某些正常服务器不幸包含在不负责任的组织发布的block list对某个网段进行屏蔽中,而不是因为发送了lj邮件。但是,如果要减少误报问题,就可能造成严重的漏报问题了。
·过滤器复查。由于误报问题的存在,通常被标记为lj邮件的消息一般不会被立刻删除,而是被放置到lj邮件箱里面,以便日后检查。不幸的是,这也意味着用户仍然必须花费时间去察看lj邮件,即便仅仅只针对邮件标题。
目前更严重的问题是,人们依然认为过滤器能有效阻止lj邮件。实际上,lj邮件过滤器并不能有效阻止lj邮件,在多数案例中,lj邮件依然存在,依然穿过了网络,并且依然被传播。除非用户不介意存在被误报的邮件,不介意依然会浏览lj邮件。过滤器可以帮助我们来组织并分隔邮件为lj邮件和正常邮件,但是过滤器技术并不能阻止lj邮件,实际上只是在"处理"lj邮件。
尽管过滤器技术存在局限,但是,这是目前最为广泛使用的反lj邮件技术。
2.2、验证查询
SMTP在设计的时候并没有考虑到安全问题。在1973年,计算机安全还没有什么意义,那个时候能够有一个可执行的邮件协议已经很了不起了。比如,RFC524描述将SMTP作为独立协议的一些情况:
"虽然人们可以或者可能可以,以本文档为基础设计软件,但请恰如其分地进行批注。请提出建议和问题。我坚信协议中依然存在问题,我希望读者能够阅读RFC的时候能够将它们都指出来。"
尽管SMTP的命令组已经发展了很长时间,但是人们还是以RFC524为基础来执行SMTP的,而且还都假定问题(比如安全问题)都会在以后被解决。因此直到2004年,源自RFC524中的错误还是依然存在,这个时候SMTP已经变得非常广泛而很难简单被代替。lj邮件就是一个滥用SMTP协议的例子,多数lj邮件工具都可以伪造邮件头,伪造发送者,或者隐藏源头。
lj邮件一般都是使用的伪造的发送者地址,极少数的lj邮件才会用真实地址。lj邮件发送者伪造邮件有下面的几个原因:
*因为是违法的。在多个国家内,发送lj邮件都是违法行为,通过伪造发送地址,发送者就可能避免被起诉。
*因为不受欢迎。lj邮件发送者都明白lj邮件是不受欢迎的。通过伪造发送者地址,就可能减少这种反应。
*受到ISP的限制。多数ISP都有防止lj邮件的服务条款,通过伪造发送者地址,他们可以减少被ISP禁止网络访问的可能性。
因此,如果我们能够采用类似黑白名单一样,能够更智能地识别哪些是伪造的邮件,哪些是合法的邮件,那么就能从很大程度上解决lj邮件问题,验证查询技术正是基于这样的出发点而产生的。以下还会解析一些主要的反lj邮件技术,比如Yahoo!、微软、IBM等所倡导和主持的反lj邮件技术,把它们划分在反向验证查询技术中并不是很恰当,但是,从某种角度来说,这些技术都是更复杂的验证查询。
2.2.1、反向查询技术
lj邮件的伪造角度来说,能够解决邮件的伪造问题,就可以避免大量lj邮件的产生。为了限制伪造发送者地址,一些系统要求验证发送者邮件地址,这些系统包括:
反向邮件交换这些技术都比较相近。DNS是全球互联网服务来处理IP地址和域名之间的转化。在1986年,DNS扩展,并有了邮件交换纪录(MX),当发送邮件的时候,邮件服务器通过查询MX纪录来对应接收者的域名。
类似于MX纪录,反向查询解决方案就是定义反向的MX纪录,用来判断是否邮件的指定域名和IP地址是完全对应的。基本原因就是伪造邮件的地址是不会真实来自RMX地址,因此可以判断是否伪造。
2.2.2 DKIM技术
DKIM技术基于雅虎的验证技术和思科的Internet Identified Mail
雅虎的DomainKeys利用公共密钥密码术验证电子邮件发件人。发送系统生成一个签名并把签名插入电子邮件标题,而接收系统利用DNS发布的一个公共密钥验证这个签名。 思科的验证技术也利用密码术,但它把签名和电子邮件消息本身关联。发送服务器为电子邮件消息签名并把签名和用于生成签名的公共密钥插入一个新标题。而接收系统验证这个用于为电子邮件消息签名的公共密钥是授权给这个发件地址使用的。 
DKIM将把这两个验证系统整合起来。它将以和DomainKeys相同的方式用DNS发布的公共密钥验证签名,它也将利用思科的标题签名技术确保一致性。
DKIM给邮件提供一种机制来同时验证每个域邮件发送者和消息的完整性。一旦域能被验证,就用来同邮件中的发送者地址作比较检测伪造。如果是伪造,那么可能是spam或者是欺骗邮件,就可以被丢弃。如果不是伪造的,并且域是已知的,可为其建立起良好的声誉,并绑定到反lj邮件策略系统中,也可以在服务提供商之间共享,甚至直接提供给用户。
对于知名公司来说,通常需要发送各种业务邮件给客户、银行等,这样,邮件的确认就显得很重要。可以保护避免受到phishing攻击。
发送服务器经过两步:
1、建立。域所有者需要产生一对公/私钥用于标记所有发出的邮件(允许多对密钥),公钥在DNS中公开,私钥在使用DomainKey的邮件服务器上。
2、签名。当每个用户发送邮件的时候,邮件系统自动使用存储的私钥来产生签名。签名作为邮件头的一部分,然后邮件被传递到接收服务器上。
接收服务器通过三步来验证签名邮件:
1、准备。接收服务器从邮件头提取出签名和发送域(From:)然后从DNS获得相应的公钥。
2、验证。接收服务器用从DNS获得的公钥来验证用私钥产生的签名。这保证邮件真实发送并且没有被修改过。
3、传递。接收服务器使用本地策略来作出最后结果,如果域被验证了,而且其他的反lj邮件测试也没有决定,那么邮件就被传递到用户的收件箱中,否则,邮件可以被抛弃、隔离等。
2.2.3SenderID技术
2004年,Gates曾信誓旦旦地预言微软能够在未来消灭lj邮件,他所期望的就是Sender ID技术,但是,最近他则收回了他的预言。这也就是标准之争,微软希望IETF能够采用Sender ID技术作为标准,并且得到了大量支持,也包括后来又倒戈的AOL的支持,但是在开源社区,微软一直没有得到足够的支持,IETF最终否决了微软的提议。
SenderID技术主要包括两个方面:发送邮件方的支持和接收邮件方的支持。其中发送邮件方的支持主要有三个部分:发信人需要修改邮件服务器的DNS,增加特定的SPF记录以表明其发信身份;在可选情况下,发信人的MTA支持在其外发邮件的发信通信协议中增加SUBMITTER等扩展,并在其邮件中增加Resent-SenderResent-FromSender等信头。
接收邮件方的支持有:收信人的邮件服务器必须采用SenderID检查技术,对收到的邮件检查PRAMAILFROM,查询发件者DNSSPF纪录,并以此验证发件者身份。
因此,采用Sender ID技术,其整个过程为:
第一步,发件人撰写邮件并发送;
第二步,邮件转移到接收邮件服务器;
第三步,接收邮件服务器通过SenderID技术对发件人所声称的身份进行检查(该检查通过DNS的特定查询进行);
第四步,如果发现发信人所声称的身份和其发信地址相匹配,那么接收该邮件,否则对该邮件采取特定操作,比如直接拒收该邮件,或者作为lj邮件。
Sender ID技术实际上并不是根除lj邮件的法宝,它只是一个解决lj邮件发送源的技术,从本质上来说,并不能鉴定一个邮件是否是lj邮件。比如,lj邮件发送者可以通过注册廉价的域名来发送lj邮件,从技术的角度来看,一切都是符合规范的;还有,lj邮件发送者还可以通过别人的邮件服务器的漏洞转发其lj邮件,这同样是SenderID技术所不能解决的。

你可能感兴趣的:(反lj邮件技术解析-2)