第八章 Fetchmail成熟了

现在有了一个简洁新颖的设计，我确信代码运行稳定，因为我每天都在用，公测名单也枝繁叶茂。我逐渐发现，我不再只是研发一个可能只有少数人才会用到的琐碎的个人软件了。而是在主持一个所有使用SLIP/PPP邮件接口的Unix用户都切实需要的软件。

凭借SMTP转发功能，fetchmail把竞争对手远远的甩在了后面，成了一个潜在的“领域杀手”。一个在同领域鹤立鸡群的杀手，它让对手们不但被抛弃而且被遗忘。

这种结果是可遇而不可求的。一个卓有建树的设计构想会把你顺理成章，甚至命中注定地推向成功。而找到这类构想的方法无非是拥有很多值得尝试的创意——或者能用工程的眼光把其他人的创意发挥到令原作者都难以想像的境地。

安迪·塔能鲍姆[1]首先为IBM PC机开发了一个简单的原生Unix系统，他的本意是把它作为一个教学工具（他称之为Minix）。李纳斯则把Minix的概念推臻至安迪想像不到的境地，让它成了这个奇妙的玩意。类似的（只是规模小些），我从卡尔·哈里斯和哈利·豪切斯那里借得创意并把它们深化。我们都不是“原创”——那种人们浪漫想像中的天才。话说回来，大多数科学、工程和软件的成果都不是来自原创天才，恰恰相反，是锐意进取铸就了神话。

这两个项目（指Linux和fetchmail——译者按）都成果斐然——事实上，这正是每个黑客毕生求索的成功！这同样意味着我不得不加高要求自己的标准。为了让fetchmail达到预期的目标，我不仅要为自己编程，还要额外地加入别人需要的功能。与此同时，还必须保证程序的简洁和健硕。

意识到这点之后，我加入的第一个也是至关重要的功能就是“集体收发”——从一组用户的邮箱中收取邮件，之后在分发给不同的收件人。

我添加集体收发功能不仅是因为很多用户吵着要用，更主要的是我觉得通过这个方法可以迫使我更全面的处理地址问题，从而摆脱单信投寄中的缺陷。结果得我所愿。正确地完成RFC822[2]地址解析耗费了我很长时间，并不是因为它的某一部分很难，而是它牵扯了一堆相互关联的烦人细节。

添加集体收发成为了一项杰出的设计决策，只因为：

 

14.任何工具都应该起到预期的作用，而一个真正杰出的工具会带来出乎意料的用途。

Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

 

加入集体收发的一个出乎意料的用途是让通过网络相连的客户端可以保存邮件列表和别名扩展。也就是说，通过ISP上网的个人用户不需要持续访问ISP的别名文件就可以管理邮件列表了。

我的公测人员要求加入的另一个重要功能是支持8位的MIME（Multipurpose Internet Mail Extensions，多用途的网际邮件扩充协议）操作。这很容易办到，因为我之前就很小心的保留了对代码的8位兼容性（就是，没有强迫ASCII字符集中未曾用到的第8比特位去携带程序信息）。这并不是因为我有先见之明，而是遵循了另一个原则：

 

15.在写任何网关软件的时候，都该花点功夫尽可能不去干扰数据流——除非用户强迫你，否则永远不要抛弃任何信息！

When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!

 

假设我不曾遵循这个原则，那么加入8位MIME支持就会很困难而且毛病多多。事实上，我现在做的只是读一下MIME标准（RFC1652）[3]，然后加入一条小小的标头生成规则。

一些欧洲用户请求我加入了一个选项，来限制每次连接可下载的邮件数目（这样他们可以节流昂贵的电话上网费）。我曾长时间抵触这种做法，就算现在也不是心甘情愿。但是如果你是在为外界编写程序，那么你就必须听从你的客户——即使他们不付钱也应如此。

 

 

 

 

 

译者按：

1.安迪·塔能鲍姆：安德鲁·斯图尔特·塔能鲍姆（Andrew Stuart Tanenbaum）昵称安迪（Andy）美国计算机学家，现定居荷兰。

2.RFC822：Standard for the format of ARPA Internet text messages，标准ARPA 互联网文本消息格式。

3.SMTP Service Extension for 8bit-MIMEtransport，SMTP 8bit-MIME传输服务扩展。