摘要

  • RFC 1459 允许前缀标明 IRC 消息的协议来源，但服务器必须查本地来源记录，并确认该来源属于消息抵达的那条链路。
  • 昵称唯一、客户已登记、入站分支匹配、消息获准转发是四项独立事实；没有一项能单独证明键盘前的人是谁。
  • 规则由每台服务器依其当时状态执行，且不匹配时可静默丢弃；要解释消息为何消失，必须保存消息之外的历史状态和时间。

名字在消息里，证据在消息外

RFC 1459 于 1993 年 5 月以实验性协议发布。IRC 已从 BBS 上的聊天工具发展成由客户和服务器组成的全球网络。表面上，它只是文本行：可选前缀、命令、参数，以 CR-LF 结束，总长不超过 512 个字符。实际负责送达的是服务器树。

前缀可以写服务器名，也可以写昵称，并在某些形式中附带用户名和主机。没有前缀时，服务器把当前连接视为来源。出现前缀时，规范称它表示消息的来源。

关键不在这个名称，而在后续检查。客户不应任意填写前缀；即使填写，也只能使用自己已经登记的昵称。接收服务器必须在内部数据库中找到前缀指向的来源，并核对该来源是否登记在消息实际到达的链路之后。来源不存在，或数据库认为它属于另一条链路，消息都要被静默忽略。

因此，语法正确只证明解析器看懂了结构。数据库命中只证明服务器当前认识这个对象。链路相符才证明该对象可以从这条关系出现。服务器随后作出的接纳决定，又与真正执行的转发不同。

“真实来源”是有边界的协议事实

这个机制确实阻止了直接冒名。一个本地客户不能只把别人的昵称写进前缀便获得对方的位置；相邻服务器也不能把已知来源从错误分支投射进来而不触发丢弃。

但检查到的是 IRC 拓扑中的来源，不是人的身份。昵称是当前网络状态里的定位符。服务器还保存主机、用户名和归属服务器，也可做 DNS 正反查、可选密码检查或 Ident 查询。RFC 1459 自己承认：没有密码时，很难可靠判断网络连接另一端究竟是谁，因此强烈建议服务器之间使用密码。

连接密码也不等于逐条消息的签名。它约束的是连接建立。昵称没有永久所有权，前缀没有密码学证明，用户名和主机字段也不能替代人的授权记录。最稳妥的说法只能是：在这一服务器当时所知的 IRC 状态里，这条消息声明的协议来源与入站关系一致。

昵称唯一性会随状态消失

当时每个客户要使用全网唯一、最长九个字符的昵称。唯一性让回复有目标，却不是永恒身份。

若服务器收到另一个相同昵称，RFC 1459 把它定义为昵称碰撞。分布式处理并不裁决谁“拥有”名字，而是删除各个实例并传播 KILL；若冲突来自直接连接的客户，服务器也可只拒绝新请求。系统维护的是无歧义命名空间，不是人格登记簿。

WHOWAS 能查近期昵称历史，但历史条目仍只是运行记录。服务器还要跟踪昵称变更，以减少 KILL、MODE、KICK 与改名并发时命中错误客户的风险。规范明确表示，错误作用仍可能发生。名称若脱离时间和会话，便会被误读成连续身份。

每台服务器都用自己的世界副本判断

IRC 的服务器组成树。来源查验不需要为每条消息访问中央登记处，而是依赖本地数据库。这使执行快速，却把副本的新旧程度变成安全边界。

服务器链路断开后，两侧会各自继续运行。频道成员、模式和昵称视图可能分化。连接恢复时，双方交换各自认为存在的状态。同一昵称可能在隔离的两侧分别出现；恢复后的碰撞并不自动说明哪一侧恶意。

一条抓包记录无法重现判定。调查者还需要到达时间、入站连接、对端身份、本地数据库版本、预期分支、实际分支和处置结果。后来看到的数据库即使完全一致，也不能证明早先的消息为何被丢弃。

这正是“现实层”区别：前缀是对象上的文字，来源登记是一条记录，链路归属是一项关系，接纳是决定，转发是动作，远端显示是观察结果。任何一层都不能替代下一层。

2000 年的拆分把后果写得更清楚

RFC 2810 把 IRC 架构单独描述，并指出每台服务器都保存全局状态副本，是限制网络规模的突出问题。副本并非只为列出在线用户；它也是来源检查的依据。

RFC 2812 保留了面向客户的规则：没有前缀，就从连接推定来源；客户若给出前缀，只能写登记昵称。RFC 2813 则细化服务器之间的处置。数据库没有来源时必须丢弃；未知服务器前缀还可能导致链路关闭。来源明明存在却登记在其他链路时，消息一律丢弃，并可能 KILL 客户或断开问题链路。

于是，一条来源矛盾会影响的不只是聊天文本。关闭链路可防止错误关系继续进入全网，却也会切断该分支上的合法客户。完整性保护和可用性结果必须分别记录。

RFC 2813 还说明，服务器 token 只在一条点对点对等连接上唯一，并非全局号码。这是同一类范围纪律：数值或名称离开赋予它意义的关系，就不再携带原证据。

一个十六进制错误没有改写运行语法

RFC 1459 把冒号的十六进制值误写为 0x3B；那其实是分号。正文里的字符和语法指向冒号，已验证勘误 4091 将数值改为 0x3A。

这一处小错说明，原始文档、维护后的勘误和实际解析程序是三份不同记录。原文证明当时发布了什么，勘误证明谁在何时确认了修正，运行代码证明互操作时使用了什么。不能为了保持“原样”而继续传播错误，也不能用后来正确的实现抹去文档曾经出错的事实。

TLS 保护的是另一条边界

早期 PASS 和 OPER 可在明文中传输。后来的服务器规范提出使用 TLS 一类流加密，RFC 7194 又为 IRC over TLS/SSL 登记默认端口。这可以保护覆盖链路上的凭据和内容，并可加强对端认证。

它不会自动修复来源关系。加密连接仍可能带来与本地数据库不相符的前缀；前缀相符也不能证明链路已加密。端口得到登记，更不证明某个网络实际部署、正确验签或成功送达了某条消息。

RFC 1459 的意义不在于完成所有身份问题，而在于没有让一个看似明确的名字承担所有证明。它只在名称、登记和来路相符时允许协议继续；人的身份、端到端完整性和读者接收仍在后面。