今天在 车东 的 blog 上看到一篇说 关于邮件安全的文章，这里也说说我对这个问题的看法。

基于邮件的 XSS 问题其实是困扰 Webmail 供应商的一个很严重的问题。其实，未必是 XSS，有时可能是更简单的内存泄露问题。比较简单的是我 1999 年左右在某国内邮件服务提供商提供的邮件服务发现的一个问题，即，一方面我可以发脚本，获得 cookie；另一方面，我可以用 HTML 去构造一个特殊的 GET 请求（通过 IMG tag）来把这些cookie拿到。

接下来的故事就很简单了，攻击者通过在本地种这些 cookie，便可以访问收到并打开邮件的用户的邮件。严格地说，这甚至算不上一个跨站脚本攻击。解决方法也很简单，在服务器端的session中保存用户的登录 IP 地址。

然而，新一代的攻击变得越来越复杂了。一种典型的攻击是，发送垃圾邮件的人通过各种方法令你访问某个特定的 URL，并借此确认你的邮件地址有效。

这种攻击往往是采用这样的幌子：你中奖了、你收到一张来自朋友的贺卡，但是不告诉你谁发的，等等。等你点过去，发现出来的却是一个门户网站，很多粗心的用户，往往会忽略这一事实，以为是自己无意中打开的页面，殊不知，自己的邮件地址已经被人收集了。

另一种比较常用的办法，便是在邮件中嵌入一个图片。许多用户打开邮件时便会显示这个图片，当然，这个图片的 URL 是一个可以唯一区分的 URL，后面挂的程序，自然也是收集这些信息。

无论如何，让邮件程序，无论是一个邮件客户端，还是一个 Webmail 访问接口，在呈现邮件的时候以原样（如，经过渲染的 HTML）而不是纯文本方式显示邮件，都是非常危险的。原因很简单，没有任何证据能够证明这邮件真的是来自它声称的收件人，除非它经过了数字签名。

Yahoo! 提出了一项解决方案，即 DomainKey (TM)，具体原理是由邮件服务器对邮件进行签名；另一种方案是微软支持的 SenderID，或 SPF。这两种技术均试图改善发件人验证问题，然而由于普及率的原因，尽管它们都能起到一定的效果，但是我们并没有办法把它作为唯一的判断依据。

因此，在这个问题彻底解决之前，其实唯一可靠的办法，只有默认不信任任何来自电子邮件的数据，不将它们以已渲染的方式提供给用户。遗憾的是，多数用户并不理解这一问题的严重性，因此，邮件运营提供商也就必须为此而作出妥协了。毫无疑问，这场战争仍然会继续，这也是为什么，在目前阶段：

• 你不应该使用电子邮件附件功能发送超过100K的文件数据；如果需要，把东西放到服务器上让对方下载；
• 你应该对发出的电子邮件签名；
• 你应该鼓励周围的人尽可能使用纯文本的邮件格式；
• 你不应该发出 HTML 格式的邮件。