2.2.4、FairUCE技术FairUCE由IBM开发，该技术使用网络领域的内置身份管理工具，通过分析电子邮件域名过滤并封锁lj邮件。FairUCE把收到的邮件同其源头的IP地址相链接--在电子邮件地址、电子邮件域和发送邮件的计算机之间建立起一种联系，以确定电子邮件的合法性。比如采用SPF或者其他方法。如果，能够找到关系，那么检查接受方的黑白名单，以及域名名声，以此决定对该邮件的操作，比如接收、拒绝等。FairUCE还有一个功能，就是通过溯源找到lj邮件的发送源头，并且将那些传递过来的lj邮件再转回给发送源头，以此来打击lj邮件发送者。这种做法利弊都有。好处就是能够影响lj邮件发送源头的性能，坏处就是可能打击倒正常的服务器（比如被利用的）的正常工作，同时该功能又复制了大量lj流量。2.2.5、局限性和缺点这些解决方案都具有一定的可用性，但是也存在一些缺点：**非主机或空的域名反向查询方法要求邮件来自已知的并且信任的邮件服务器，而且对应合理IP地址（反向MX纪录）。但是，多数的域名实际上并不同完全静态的IP地址对应。通常情况下，个人和小公司也希望拥有自己的域名，但是，这并不能提供足够的IP地址来满足要求。DNS注册主机，比如GoDaddy，向那些没有主机或只有空域名的人提供免费邮件转发服务。尽管这种邮件转发服务只能管理接收的邮件，而不能提供邮件发送服务。反向查询解决方案对这些没有主机或者只有空域名的用户造成一些问题：·没有反向MX记录。这些用户现在可以配置邮件客户端就可以用自己注册的域名能发送邮件。但是，要反向查询发送者域名的IP地址就根本找不到。特别是对于那些移动的、拨号的和其他会频繁改变自己IP地址的用户。·不能发送邮件。要解决上面的问题，一个办法就是通过ISP的服务器来转发邮件，这样就可以提供一个反向MX纪录，但是，只要发送者的域名和ISP的域名不一样的时候，ISP现在是不会允许转发邮件的。这两种情况下，这些用户都会被反向查询系统拦截掉。**合法域名能验证身份，并不一定就是合法的身份，比如：lj邮件发送者可以通过注册廉价的域名来发送lj邮件，从技术的角度来看，一切都是符合规范的；还有，目前很多lj邮件发送者可以通过别人的邮件服务器漏洞进入合法邮件系统来转发其lj邮件，这些问题对于验证查询来说还无法解决。2.3、挑战lj邮件发送者使用一些自动邮件发送软件每天可以产生数百万的邮件。挑战的技术通过延缓邮件处理过程，将可以阻碍大量邮件发送者。那些只发送少量邮件的正常用户不会受到明显的影响。但是，挑战的技术只在很少人使用的情况下获得了成功。如果在更普及的情况下，可能人们更关心的是是否会影响到邮件传递而不是会阻碍lj邮件。这里介绍两种主要的挑战形式：挑战-响应，和 计算性挑战
2.3.1 挑战-响应挑战-响应（Challenge-Response：CR）系统保留着许可发送者的列表。一个新的邮件发送者发送的邮件将被临时保留下来而不立即被传递。然后向这个邮件发送者返回一封包含挑战的邮件（挑战可以是连接URL或者是要求回复）。当完成挑战后，新的发送者则被加入到许可发送者列表中。对于那些使用假邮件地址的lj邮件来说，它们不可能接收到挑战，而如果使用真实邮件地址的话，又不可能回复所有的挑战。但是，CR系统还是有许多局限性：CR死锁。假如Alice告诉Bill要给朋友Charlie发送邮件。Bill发送一个邮件给Charlie，Charlie的CR系统临时中断邮件并发送给Bill一个挑战。但是Bill的CR系统又会中断Charlie这里发送出来的挑战邮件，并发送自己的挑战。因此，结果就是，用户都没有接收到挑战，而且用户也无法回复邮件。而且用户也无法知道，在挑战过程中发生了问题。因此，如果双方都使用CR系统的话，他们就可能根本无法进行沟通。自动系统问题。邮件列表或者那些自动系统，比如一些网站的"发送给朋友……"功能，就不可能回应挑战。解释挑战。许多CR系统都执行解释性挑战。这些复杂的CR系统包含了字符识别和参数匹配，但是即便如此，还是能够进行自动化操作。比如，Yahoo的CR系统在创建新邮件账号的时候，对于那些有简单智能字符分析的系统是存在漏洞的。Hushmail的邮件CR系统要求从蓝背景图片中找出指定的图形（分析背景，找出图形，提交坐标，这是可能的）这些在市场宣传神化中强调了两点：1、人们必须得提供挑战，2、这些问题都非常复杂而不太可能自动化操作。但是实际上，多数的lj邮件发送者完全不理睬了这些CR系统，因为他们主要是担心没有大量的接收者，而不是担心挑战太复杂。许多lj邮件发送者也使用有效的邮件地址。当CR系统会干扰lj邮件的时候，那些发送者也会找出自动化搞定这些挑战的办法的。2.3.2、计算性挑战现在也提出了一些计算性挑战方案Computational Challenge (CC)，如，通过增加发送邮件的"费用"。多数CC系统使用复杂的算法来有意拖延时间。对于单个用户来说，这种拖延很难被察觉，但是对于发送大量邮件的lj邮件发送者来说，这就意味着要花费很多时间了。CC系统的实例，但是，即便如此，CC系统还是会影响快速通讯而不仅仅影响lj邮件。这些局限包括：·不平等影响。计算性挑战是以CPU、内存和网络为基础的，比如，在1Ghz计算机上挑战可能花费10秒，但是在500Mhz上就需要花费20秒了。·邮件列表。许多邮件列表都有数千，甚至数百万的接受者。比如BugTraq，就可能会被看作lj邮件了。CC系统来处理邮件列表是不现实的。如果lj邮件发送有办法通过合法的邮件列表来绕过挑战，那么他们也就有办法绕过其他的挑战了。·机器人程序。Sobig或者其他象lj邮件一样的bd，能让lj邮件发送者控制大量的机器。这就让他们能够用大量的系统来均衡"费用"了。·合法的机器人程序。lj邮件发送者发送lj邮件是因为会给他们带来收入。如果这些人联合起来，就可能提供大量的系统来分担"费用"，这完全是合法的，而且不需要通过bd了。当前，计算性挑战还没有广泛应用，因为这种技术还不能解决spam问题，反而可能干扰正常用户。2.4、密码术现在提出了一些采用密码技术来验证邮件发送者的方案。从本质上来说，这些系统采用证书方式来提供证明。没有适当的证书，伪造的邮件就很容易被识别出来，目前的邮件协议（SMTP）不能直接支持加密验证。研究中的解决方案扩展了SMTP，还有一些其他的则打算代替现在的邮件体系，比如MTP。有趣的是，MTP的作者说到："SMTP已经有20多年历史了，然而近代的一些需求则在过去5到10年内发展起来。许多扩展都是针对SMTP的语句和语义，纯粹的SMTP不能满足这些需求，如果不改变SMTP的语句，是很难有所突破的。"但是，很多的扩展的SMTP实例恰恰表明了SMTP的可变性，而不是不变性，完全创造一个新的邮件传输协议并不是必须的。在采用证书的时候，比如X.509或TLS，某些证书管理机构必须得可用，但是，如果证书存储在DNS，那么私钥必须得在验证的时候可用。（换句话说，如果lj邮件发送者可以访问这些私钥，那么他们就可以产生有效的公钥）。另一方面，也要用到主要的证书管理机构（CA），但是，邮件是一种分布式系统，没有人希望所有的邮件都由单独的CA来控制。一些解决办法因此允许多个CA系统，比如，X.509就会确定可用的CA服务器。这种扩展性也导致lj邮件发送者也可以运行着私有的CA服务器。如果没有证书管理机构，就需要其他的途径在发送者和接收者之间来分发密钥。比如，PGP，就可以预先共享公钥。在未连接网络或者比较封闭的群组中，这种办法是可行的，但是在大量个体使用的时候，就不是太适合，特别是对于需要建立新的联系的情况下。从本质上来说，预先共享密钥有些类似白名单的过滤器：只有彼此知道的人才能发送邮件。不幸的是，这些加密解决方案还不能阻止lj邮件，比如，假设其中的一种加密方案广泛被接受了。这些办法都不能确认邮件地址是真实的，而只是可以确认发送者有邮件的正确密钥。缺点就是：·滥用自动化工具。如果在广大范围内被应用，就需要有一种办法为所有用户产生证书或者密钥（包括邮件服务器端，邮件客户端，依赖与相应的解决办法）系统很可能通过一种自动化的方法来提供密钥。可是，可以相信lj邮件发送者也会滥用任何自动化系统，并且用来发送经认证的lj邮件。·可用性问题。这也有一些可用性的争论。比如，如果CA服务器不可用怎么办？邮件被挂起？退票？还是依然可用？lj邮件发送者近来对一半以上的提供黑名单网站进行了拒绝服务攻击，并导致这些网站都无法访问。显然，这些lj邮件发送者想阻止别人更新黑名单。对于单一的CA服务器，很显然也无法避免这样的命运。3、总结上面介绍了一些反lj邮件的技术，其实，现在很多反lj邮件方案所采用的都不会只是一种技术，而是多种多类技术的综合体。lj邮件的危害现在已经深入人心，反lj邮件也取得越来越多的成绩，比如，Scott Richter向微软赔款700万。不少国家也在为反lj邮件进行立法，以便能够得到法律上的支持。但从技术上来说，这跟反攻击一样，是一个正反双方的博弈过程，一种新的反lj邮件技术必然会出现一种对应得lj邮件技术，况且，任何一种技术，还没有办法去解决所有问题，技术的发展也将延续下去。