摘要

  • RFC 1429 记载，BITNET LISTSERV 的 DISTRIBUTE 服务在掌握拓扑时，让一份邮件先穿过繁忙链路，再到接近收件人的地方拆分。作者称当时系统每天处理 200 万至 600 万封邮件。
  • 接入前必须看服务器的真实线路、邮件兼容性与主节点文件的日期；文件不能老于两个月。每天超过一万名收件人的工作量，还应先取得该站管理员同意。

一张过期的地图，足以让一套“少送副本”的系统把邮件送上错误的路。1993 年 2 月的 RFC 1429 把这种风险写成操作清单：选一个靠近收件人的 DISTRIBUTE 站点，核对它连接 BITNET 的能力，再确认 Master nodes file 不超过两个月。Eric Thomas 特别提到，有些站点因人员不足一直不更新表。那不是文档卫生问题；分发决策就靠这张表。

这套服务原本解决一个很贵的重复动作。大型邮件列表若从本地逐一寄给成千上万地址，拥挤链路上会反复运同一内容。DISTRIBUTE 接收整封邮件和收件人表，在拓扑允许时先用一份副本穿过繁忙链路，到了目标群附近再分流。Thomas 称系统当时每天运送 200 万至 600 万封邮件，并把连接较好的 BITNET 收件人典型周转时间写为 5 至 15 分钟。这些是原作者对当时服务的报告数字。

入口选错，节省会先被绕路吃掉。RFC 举了一个刻薄而准确的例子：大部分读者在美国，却从加利福尼亚把任务送到瑞典服务器。它也提醒，某站点即便有 T1 IP 接入，BITNET 一侧仍可能只是一条 9.6 千比特租线。应用看到的是一个服务器地址，运营者必须看到它背后的另一条慢线。

还有人必须接这笔账。若预计每天投递给超过一万名收件人，RFC 要求事先向所选 LISTSERV 站点的管理员请求许可，并询问限制和预定停机。有些大学可能不让大批量邮件在繁忙时段运行。共享骨干的承载力并非发件人单方面决定。

请求本身通过 SMTP 送到服务器。信封里的 MAIL FROM 应指向能处理“还没到达 LISTSERV 就失败”的人；请求邮件的 RFC822 From 则接收后续投递问题和退信。若把列表投稿地址填进后者，失败通知可能再进列表，形成回路。两处地址相似，承担的故障阶段却不同。

协议把整件事写得很具体：JOB 卡、DISTRIBUTE MAIL 指令、带 BSMTP 标记的收件人表，然后是邮件正文。生产时 ECHO=NO 关掉资源使用报告；测试时 DEBUG=YES 展示拟定路线但不实际投递，TRACE=YES 则边投递边报告。RFC 的样例把三名收件人转交 UGA 站点，两名留给本地 SMTP。调试输出可以审查分组方案，却不会凭空证明终端读者收到了信。

网络规模越大，维护这张地图的劳动越难藏。DISTRIBUTE 省的是链路上的重复副本，靠的是有人定期更新节点、有人挑对入口、有人同意接收负载。两个月的期限把这份劳动钉在了制度和技术的交界处。