微软Sender ID遭到尴尬 两大团体不支持(spf-DomainKeys)

tdk

原文地址http://anti-spam.org.cn/AID/197

微软Sender ID遭到尴尬 两大团体不支持
--------------------------------------------------------------------------------
作者：本站 2006-03-09 00:00:00
日经BP社报道 9月4日，Debian Project发表声明，宣布不支持电子邮件发信人认证技术规格――“Sender ID”。这是继9月2日Apache软件基金会（ASF）宣布不支持该技术后又一组织公开表态。Debian Project和ASF均为开放源码软件推动团体。作为不支持的原因，两组织均指出美国微软的授权条款与该团体的宗旨相违。

Sender ID是由微软“Caller ID for E-mail”与另一项认证技术“SPF（Sender Policy Framework）”组合而成的。微软于6月份向互联网技术标准化团体IETF提交了技术标准，目前正处于公开审议阶段。此声明就是在此阶段向IETF发出的。Sender ID有望成为给电子邮件带来重大变革的技术规格，因此在业界引起了很大反响。

■开放源码团体对授权与专利心存疑虑

Debian Project与ASF表示担心的问题有2个。

第一个问题是微软的授权协议“Royalty-Free Sender ID Patent License Agreement”。根据该协议，开放源码开发人员将不能自由使用或转让Sender ID技术。此外，所有授权都必须与微软直接签署授权合同。据OSI（Open Source Initiative，开放源码促进协会）的Lawrence Rosen在ASF网站上刊登的电子邮件称，“微软的授权如同为开发人员设定了最终用户的使用限制”。

在开发源码团体内部，大家相互提供技术，转让也是免费的。全世界的开发人员互相提供劳动、经验和知识。同时谁都可以自由下载和使用。而接受微软的授权，这些自由将会受到约束。

Debian Project还在声明中表示，“微软的授权中规定，不能自由使用、发布、修改Sender ID技术。这不符合Debian Project组织的宗旨。不能发布采用Sender ID技术的Debian软件，自然也就无法支持Sender ID”（摘自Debian 网页）。

另一个问题就是专利。

微软在今年3月发表了Caller ID for E-mail，当时就有人提出了专利问题。微软尽管为Caller ID for E-mail的相关技术申请了专利，但并未宣布其适用范围。也就是说，在专利获得通过，对内容进行公布时，其范围也许会非常大。即使是与SPF整合成Sender ID后的今天，微软的方针仍旧未变。正是由于这种担心，导致开放源码团体至今无法采用Sender ID。

■Sender ID不是消除垃圾邮件的万能药

此前业界一直认为Sender ID可能会快速普及。理由是容易安装，标准化作业进展顺利。但近来给人的感觉是其前景开始阴云笼罩。最近经常会在美国媒体上看到此类报道。

例如，美国CNET News.com网站上刊出了一篇美国MX Logic公司实话的调查结果。根据此调查结果，该公司最近利用过滤技术发现并清除了1000万封垃圾邮件，而其中1/6的垃圾邮件使用了SPF（Sender ID的基本技术之一）（参见原文）。还有报告称，在经SPF认证的邮件中，垃圾邮件竟比合法邮件还要多34（美国CipherTrust的调查）。

这是因为垃圾邮件发送者导入了Sender ID／SPF，不必对发件地址进行伪装，而Sender ID／SPF只检测发信人服务器的IP地址与域名的结果。可以说如果只是发信人认证，只能对假冒邮件有效，并非消除垃圾邮件的万能药。

尽管从一开始就明白这个道理，但微软却仍将Sender ID作为反垃圾邮件技术而大肆宣传，让人觉得吹得有些过头。

■DomainKeys虽然引人注意

美国媒体报导认为，人们寄托了相当高的希望，但接连不断的报告却让人们对Sender ID实际功效丧失了信心。

例如，IRTF（Internet Research Task Force，互联网研究任务组）属下的反垃圾邮件研究小组（Anti-Spam Research Group）成员John Levine提出：“再加上此次授权问题的影响，各企业是不是应当关注一下类似美国雅虎提出的DomainKeys等其他技术呢。”

实际上DomainKeys与Sender ID一样也是采取发信人认证，不同的是需要使用数字签名。具体步骤如下：（1）发送方预先在DNS服务器上输入公共密钥，在发送邮件时使用私人密钥对邮件进行数字签名。（2）收件方向DNS服务器申请公共密钥。（3）利用得到的公共密钥解读邮件的数字签名。

也就是说，在使用DNS服务器方面与Sender ID是一样的，但DomainKeys还必须进行加密与解密处理，这样就加重了SMTP服务器的负担。此外在导入时也不如Sender ID方便。

这样看来，最有望早日普及的还是Sender ID。但微软所面临的问题却非常严峻。前面提到的John Levine表示，开放源码阵营甚至已经放出话来：“我们为什么要按微软的要求去做，难道必须将灵魂出卖给这帮家伙吗？”


关键词 SenderID  SPF  DomainKeys