380    结果得我所愿。

381    正确地完成RFC822地址解析耗费了我很长时间，并不是因为它的某一部分很难，而是它牵扯了一堆相互关联的烦人细节。

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

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

384    加入集体收发的一个出乎意料的用途是让通过网络相连的客户端可以保存邮件列表和别名扩展。

385    也就是说，通过ISP上网的个人用户不需要持续访问ISP的别名文件就可以管理邮件列表了。

386    我的公测人员要求加入的另一个重要功能是支持8位的MIME（Multipurpose Internet Mail Extensions，多用途的网际邮件扩充协议）操作。

387    这很容易办到，因为我之前就很小心的保留了对代码的8位兼容性（就是，没有强迫ASCII字符集中未曾用到的第8比特位去携带程序信息）。

388    这并不是因为我有先见之明，而是遵循了另一个原则：

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

390    假设我不曾遵循这个原则，那么加入8位MIME支持就会很困难而且毛病多多。

391    事实上，我现在做的只是读一下MIME标准（RFC1652），然后加入一条小小的标头生成规则。

392    一些欧洲用户请求我加入了一个选项，来限制每次连接可下载的邮件数目（这样他们可以节流昂贵的电话上网费）。

393    我曾长时间抵触这种做法，就算现在也不是心甘情愿。

394    但是如果你是在为外界编写程序，那么你就必须听从你的客户即使他们不付钱也应如此。