摘要

  • RFC 984 提议用一个持续联网的邮件库保存用户稳定的全局邮件状态；同一用户的多台个人电脑各有本地副本，联网时再同步。
  • 每封邮件分成约 100 字节的摘要和正文；小磁盘可装下全部摘要，再按空间取正文。批量模式排队保存离线动作，DMSP 操作必须原子完成并得到明确确认。

办公室的电脑关机了。家里还有一台。路上那台甚至坐在汽车后座——David Clark 和 Mark Lambert 在 1986 年 5 月的 PCMAIL 提案里真写了这个场景。人和机器到处走，邮件究竟住哪儿？他们让邮件住进一台长期联网、磁盘较大的中央仓库。个人电脑是访客；邮箱得有固定门牌。

这套安排来自 PC 的矛盾性格：便宜到一个人可能拥有几台，轻便到能带走，存储却十分拮据。原文举出的典型机器主存不到一兆字节，软盘大约装 360 千字节。让这样的电脑背上整箱邮件不现实。先给它一份目录，倒是办得到。

PCMAIL 把每封邮件拆成“摘要”和正文。摘要通常约 100 字节，与正文长短无关，装着邮件身份、大小、常用信头和状态标记。客户端可以保存所有摘要，磁盘有地方时再取正文。于是人能先看到“有这封信”，再决定什么时候搬运信的全部内容。那张小小目录卡片，是在硬件窘迫中腾出的活动空间。

空间问题解决了，时间问题来了。中央仓库持有稳定的全局状态，每台 PC 持有一份本地状态；离线时，两边会分叉。交互模式适合持续联网的电脑，改动即时写回仓库，新邮件也即时来到本机。批量模式允许本机先操作，把动作排队，重连时再送往仓库。DMSP 负责邮件操作及同步。几台电脑可以暂时拥有不同版本的“我的邮箱”。

重连那一刻，最怕含糊。DMSP 要求操作原子完成：要么全成，要么全败；没有明确确认便视为失败。连接突然中断时，删信动作不能在一边算完成、另一边算没发生。仓库还记录每台客户端漏掉哪些全局变化。文中描述的实现把一周没连上的客户端标为不活跃，回来时直接重置并发送完整全局状态，省去逐项补账的漫长过程。

RFC 编辑部记录注明提案发表于 1986 年 5 月，后来由 RFC 993 取代。原文自称供讨论的初步设计。它留下的清晰分工是：仓库负责记住，PC 负责移动，百字节摘要负责省地方，协议负责判定断线前后到底发生了什么。电脑可以下班，邮箱得有人守夜。