摘要

  • 匿名 FTP 沿用 USER 与 PASS 的登录流程；公共档案可能接受 guest、电子邮箱地址或其他字符串作“密码”。
  • 邮箱惯例从档案管理员的礼貌请求进入 MIME 的访问说明和 1994 年的 FTP URL 规则；访客实际能做什么由匿名账户权限决定。

一扇向公众开放的门，门铃却问“密码是什么？”这听上去像管理系统留下的笑话，却是 1990 年代互联网档案馆的日常。访客输入用户名 anonymous，接着在密码栏填 guest 或自己的邮箱地址。屏幕上写着“密码”，操作却更像在前台留一张名片。判断门开到哪里，得看服务器为匿名账户设了哪些权限。

1985 年的 FTP 规范 RFC 959规定了 USER 与 PASS 命令。它们为具名账户服务，也能承载一个叫 anonymous 的公共账户。档案站点可让这个账户浏览指定目录、下载文件，同时限制上传和其他操作。协议继续按登录仪式提问，管理员则在账户权限上划出访客通道。一个密码提示框没有自动把公开文件变成私人物品。

给新手看的1992 年 RFC 1325给出简单方法：用户名填 anonymous，密码填 guest；文档还说不少系统接受任何字符串。到了1994 年的匿名 FTP 使用指南 RFC 1635，做法写得更细：guest 和电子邮箱都常见，有些档案明确要求邮箱，不接受 guest。作者把提供邮箱称为一种礼貌，管理员借此大致知道谁在用服务。指南中的 NASA NAIC 示例服务器会提示访客输入完整邮箱，随后展示访问档案、取回 rfc959.txt 的过程。这是一份当年的真实操作记录，也提醒读者各站规矩并不统一。

邮箱“密码”很快离开终端，进入其他技术文档。1993 年的 MIME 规范 RFC 1521在外部邮件正文的 anon-ftp 访问方式里，写入 anonymous 用户名和与用户邮箱对应的密码。1994 年 12 月的 URL 规范 RFC 1738则描述 FTP URL 客户端在服务器索要密码时，提供 anonymous 和用户的互联网邮箱地址。前台留言簿的一条习惯，变成别的格式和客户端也会遵循的操作说明。

“匿名”的幽默就在这里：访客没有个人账户，却在密码栏留下回信地址。站点想掌握一点来客线索，访客想把文件取走。这不是统一的身份核验制度；服务器有的收 guest，有的要求邮箱，有的接纳别的字串。真正限制访客的，是匿名账户可以读哪些目录、能否写入以及服务器怎样配置这些规则。

1997 年的 FTP 安全扩展 RFC 2228又给这段往事补上一层背景：普通 FTP 用户名与密码以明文发送；文档把匿名档案与私有账户密码被窃的风险区别开，同时强调完整性和保密等安全服务对公开文件访问仍有价值。邮箱填在 PASS 后面，不会凭空变成强身份凭据；开放档案也不会因此免于传输风险。

这个时代的互联网把共享文化塞进了现成的登录机器。机器问“密码”，管理员想要的是礼貌的到访痕迹，访客拿到的是受限的公共账户。许多文件就这样走出档案室。后来人看到那行提示，容易以为门锁决定一切；实际决定读者能走多远的，是门后哪些书架向客人开放。