摘要

  • 1977 年的 RFC 742 规定，客户端只发 CRLF，单台主机便可返回当时正在使用该系统的用户列表。
  • 这份列表由被查询的主机生成；1991 年的 RFC 1288 明确写入拒绝整表查询和由管理员挑选附加字段的控制权。

空行问的不是整个互联网

要理解 Name/Finger，可以从最短的请求开始：客户端连接一台主机，只发送回车和换行，然后等待。1977 年 12 月的 RFC 742 把这行空命令解释为：列出此刻正在使用这台系统的人。它问的是一个具体主机，不是扫描整个 ARPANET，也不是向中央目录查询谁“在线”。

Ken Harrenstien 写的 RFC 742 为当时已经运行在 SAIL、SRI 和 MIT 若干 ITS 系统上的 NAME、FINGER 程序描述网络接口。文档把空查询比作 TOPS-10 或 TENEX 上的本地 systat 状态命令。建议的列表可以包含用户全名和终端位置；作业名称和空闲时间也可能有用。按姓名查询则是另一种操作：系统可以显示当前会话，也可以对已注销的用户给出上次注销时间和一段由用户撰写的 plan 文本。

这里发生了查询尺度的变化。指定姓名时，提问者已经知道要问哪个账户；空查询要求主机列举一个集合。协议让这个问题很容易穿过网络，却没有把答案变成统一名册。RFC 742 明说回复会随主机而异，不要求固定格式。附录里的例子出现了终端、房间、作业和空闲时长，但它们证明的是文档举过这些例子，不是每个服务器都返回同一批字段。

主机状态不是身份凭证

一个用户名、一台终端和几分钟空闲时间，看上去很像客观记录。可 RFC 描述的是远端用户信息程序给出的可读报告，并没有定义一个独立机构来认证键盘前的人。它没有规定显示姓名与现实中的个人之间存在加密绑定，也没有测量全网用户的在线状态。把回复理解为主机对自身状态的陈述，是根据协议的范围和输出形式作出的分析；把它当成身份凭证或互联网完整普查，则超出了史料。

字段之间也并非同一种证据。登录名或全名可以帮助同事认出账户；终端位置和空闲时长可能暗示某人在哪里、是否正在工作；plan 文件可能由用户撰写，而会话状态由主机系统提供。同一条回复可能混合不同来源、更新时间和敏感程度的数据。RFC 742 把这种组合方式很大程度留给每个站点。

标准化跟在现有程序之后

接下来的变化不是推倒重来。1990 年 11 月的 RFC 1194 试图澄清双方应如何通信，同时避免使许多既有实现失效，也不额外施加不必要限制。它说当时最常见的实现似乎主要源于伯克利 BSD UNIX；这是带有时间范围的观察，不是部署统计。次月发布的 RFC 1196 做了少量修正和澄清。1991 年 12 月的 RFC 1288 随后取代了此前三份文件。

到那时，空查询的含义写得更清楚：{C} 请求列出所有在线用户，远端程序必须回答或明确拒绝。如果回答，至少要提供用户全名；管理员应能选择是否附加其他字段。安全章节也建议允许站点拒绝整张在线用户列表，并提醒读者用户资料可能敏感。RFC 1288 举例说明，某个实现会返回上次登录和读取邮件的时间、未读邮件状态以及最近一封邮件的发件人。这个例子展示一种披露路径，并不代表所有主机都这样运行。

管理员控制并不等于没有风险。被查询站点可以运行服务、拒绝宽泛列表，或限制返回字段。RFC 1288 还讨论实现层攻击，包括 Morris 蠕虫；这与信息披露是两条风险路径。程序存在漏洞并被用于入侵，不等同于一个正常工作的服务按操作方配置返回了信息。

网络传递问题，主机决定答案

协议把请求类型做得足够一致：客户端可以问一个账户，或者请某台主机给出当前用户列表。它没有统一回复的含义、完整性或新鲜度。这是互联网早期的一种设计边界：共享请求语法可以和本地数据控制并存。网络提供共同的提问方式，回答仍来自有状态的那台主机。

这些 RFC 没有统计有多少站点运行 Finger、空查询有多普遍、管理员是否使用拒绝选项，也没有证明每一条回复都及时更新。它们记录的是一种服务和其规范的演进，而不是全网采用率。更稳妥的历史结论是：从 1977 年起，一个简单网络请求就能让远端访问单台主机的在线用户报告；到 1991 年，标准已经把拒绝整表查询和本地选择字段明确描述为服务控制面的一部分。

资料来源