Question

现在我有了一个简洁和新颖的设计，由于我自己每天都用，我知道代码还不错，并且有了一个不断繁荣的 beta 列表，我逐渐明白我不再仅仅是做一些微不足道的个人编程，做出来的东西也不再只是对少数几人有用。我现在做的程序，是每一个使用 UNIX 和 SLIP/PPP 收发邮件的黑客都需要的。

有了 SMTP 转发功能，它远远地走在了其他竞争对手的前面，并逐渐成为这个领域内的杀手应用，由于它在同类程序中如此优秀，以至于其他对手不仅被抛弃，而且几乎都被遗忘了。

不过，你一定不要一开始就设定这样的目标和结果。你必须要有一个非常强大的设计创意并完全投入，以至于这个结果就像是不可避免、自然而然和预先设定的。要做到这一点，唯一的途径是你有很多创意——或者有一种采纳别人好主意的工程上的决策力，并将这些创意发展到超越其作者所能想象的地步。

Andrew Tanenbaum 写了一个简单的用于 IBM PC 的原生 UNIX，其原意是将其用做教学工具（他称之为 Minix）。Linus Torvalds 将 Minix 的概念发展到 Andrew 可能无法想象的地步——并成长为让人赞叹不已的产物。同样（尽管规模较小），我吸收并努力推进 Carl Harris 和 Harry Hochheiser 的创意。我们都不是那种有浪漫原创精神的天才式人物，但是，大多数科学、工程以及软件开发都不是天才完成的，在青史上留名的往往是黑客。

取得这样的结果真是让人感觉太好了——事实上，这正是黑客们所追求的成功！这意味着我必须要把标准设置得更高一些。现在看来，为了让 fetchmail 有更好的发展，我不应该只是为了自己的需求而写程序，而应该加入和支持一些他人需要的特性，同时还要让程序保持它的简单性和健壮性。

意识到这点以后，我发现首先要实现的最为重要的特性是对集体邮箱(multidrop) 的支持，即有能力从集体邮箱（这里保存着一组用户的邮件）中把邮件取出来，然后将其路由到相应的收件人那里。

我之所以决定增加集体邮箱支持，部分原因是一些用户一直在强烈要求，但更主要的原因是，这可以强迫我以一种完全通用的方式去处理邮件地址，从而借此机会清除掉单邮箱实现中的一些 bug，事实上这的确奏效了。弄明白 RFC 822（http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt）中描述的邮件地址解析规则着实花了我很长时间，不是因为其中有什么地方很难懂，而是里面牵扯了太多相互关联而又繁琐的细节。

从结果看，对集体邮箱的支持是一个很英明的决定。因为：

14.任何工具都应具备预期内的功能，但一个伟大的工具能给你带来预期外的功能。

fetchmail 的集体邮箱模式就有一个用户预期外的功能：它能在客户端（译者注：指连往 ISP 邮件服务器的终端）上保存地址列表并实现别名扩展，这意味着用户只要有一台个人电脑和一个 ISP 账号，就能够维护一个邮件列表，而无需总是读写 ISP 端的别名文件。

我的 beta 测试者们要求的另一个重要改动是支持 8 位 MIME（多用途 Internet 邮件扩展）操作。这很容易做到，因为我已经很小心地保持着第 8 位的纯洁（也就是说，没有染指 ASCII 字符集中没用的第 8 位去让它携带程序信息），并不是我预先想到会有人提这个需求，而是我遵从了另一个规则：

15.写网关类软件时，尽可能不要干扰数据流，而且绝不要扔掉信息，除非接收方强迫你这么做。

如果我没有遵循这条规则，对 8 位 MIME 的支持就会变得困难且容易出错。现在，我要做的只是阅读 MIME 标准（RFC 1652,http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt），并稍稍增加一些邮件头部生成的逻辑。

一些欧洲用户一直要求我增加一个选项限制每次连接取回的邮件数（以便他们控制昂贵的拨号上网费用）。我抵制了很长时间，而且直到现在对此也不太开心。但如果你是为大家写程序，你就不得不倾听客户意见——虽然他们并不付钱给你。