摘要

  • RFC 1173 是对 1990 年互联网“口头传统”的信息性记录，不是 IAB 政策，也不是可向所有站点下达命令的标准；它明说本地和区域规则可以补充或修改其中的惯例。
  • postmaster、NOC 或其他角色邮箱给报告找到一个目的地。它们不证明谁读了信、什么事情发生过，或接收方必须采取何种行动。

一张联系表背后的分布式结构

RFC 1173 的标题谈的是主机和网络管理者的责任，但开头并没有把互联网想象成一家公司。James VanBokkelen 将文本称为自己对互联网“口头传统”的总结；RFC Editor 的说明进一步指出，它不规定标准，也不是 IAB 的政策。本地和区域组件可以用自己的政策补充或修订这些惯例。这里的限定不是格式上的客气话，而是对权力范围的说明：文本在描述一种协作方式，并没有建立一套跨越资源边界的常设授权。

当时的协作有非常实际的理由。一个路由环路、错误的连通性通告、卡住的邮件中继、配置失误或短暂的断电，可能从一个站点的局部问题变成别处用户看到的不可达。看到“上午能到、现在到不了”的用户未必有路由表、日志、账户权限或机房信息。拥有这些材料的运营者则可能位于另一所机构，根本不知道有人已经看到了异常。网络需要的不只是传输数据包的路径，还需要把问题带到适当责任边界的路径。

RFC 1173 因而要求负责互联网组件的人能通过电子邮件和电话联系，并回应来自其他参与者的问题报告和诊断倡议。不过，它把这种安排放在去中心化的组织结构中：不同本地需要、不同资源所有者、不同运行环境，不会自然汇入一个万能服务台。文中关于“Ma Datagram”式单一供应者的玩笑正说明这一点。可达性不是统一指挥；它只是让协作有机会开始。

责任必须与本地能力相连

RFC 1173 对“网络管理者”的要求远不只是登记姓名。每个连入互联网的 IP 网络或子网应有一名或多名负责人，并向 Internet NIC 或本地、区域转接网络的 NIC 提供更新后的联系信息。更重要的是，负责人要么应对本地网络连接的每一台主机和路由器拥有系统管理权限，要么应当具有关闭、重启、物理断开或禁止某台异常主机转发 IP 数据报的权力和访问条件。

这段文字今天读来很直接，却界定了一个常被省略的事实：能采取补救措施的能力留在管理相关资源的一方。远端可以看到影响、提交报告、请求检查；它不会因为知道了一个管理员名字就取得对对方路由器的凭据，也不会因为问题听起来紧急就获得切断流量的权力。管理者之所以承担责任，是因为其位置把工具、运行语境和行动后果放在一起。

主机系统管理者的规定沿用同一逻辑。负责的人应拥有配置、运行和控制本系统访问所必需的权力、访问权和工具。只有责任没有能力，联系表会变成仪式；只有能力却脱离本地责任边界，干预会失去可追责性。RFC 1173 要求两者并存，却没有把它们推广成任何旁观者都可调用的权力。

这也意味着“有人可联系”不等于“结论已经成立”。管理员可能尚未读到邮件；报告可能遗漏关键上下文；收到报警并不自动证明应关闭主机。报告、核验与处置之间仍有一个不可省略的本地判断过程。

postmaster 是送达问题的入口

postmaster 让这种结构变得可见。RFC 1173 规定，处理本地网络以外邮件的互联网主机应维护名为 postmaster 的邮箱；它通常是处理投递问题的联络点。远端维护者可以把投递异常寄往这里，自动生成的邮件错误也可能在 reply-to 中指向它。文本要求定期读取该邮箱，因为无人查看的联系通道会让一个本地问题扩散成大量退信或丢信。

但邮箱的作用到此为止。一封信抵达邮箱，不代表某个特定的人已读信，不代表发件人的叙述完整，更不代表邮件系统的故障原因已经确定。未投递可能来自磁盘已满、别名错误、配额、域名解析、队列状态或发件人不可见的其他条件。postmaster 把观察送入能检查的本地空间；它本身不是事故报告的判决书。

1997 年的 RFC 2142 为这种角色邮箱形成了较系统的词汇。它将邮箱名称定义为联系某组织中适合某项服务或职能的人员的方式，列出 NOC、SECURITY、ABUSE、POSTMASTER 与 HOSTMASTER 等名称，并说明知名邮箱的范围是组织的域名。域名范围尤其关键：名称是在一个组织边界内找到预期职责的路径，并非全球身份凭据，更不是对其他域名资源下命令的接口。

RFC 5321 从 SMTP 的角度保留了同样克制的层次。能够转发或投递邮件的 SMTP 接收者必须为其服务的域接受不区分大小写的本地名称 postmaster，但在狭窄的安全例外下可以限制。这是接收邮件的传输行为。它没有承诺某人正在值班，没有承诺会认可一项主张，也没有承诺会把某项要求变成一次技术变更。

报告提供线索，不提供裁决

RFC 1173 也承认普通用户可能是最早发现问题的人。有人说“今天早上还可以访问”，可能正是运营者尚未看见的变化信号。可是文本并不让这句话承担完整的因果链。它将可能具有网络范围的问题区分为用户相关、主机相关和网络相关三类。这样的区分告诉读者：同一个表面症状并不自行选择原因、责任主体或补救方法。

用户相关问题可能涉及邮件列表行为、隐私或闯入尝试；主机相关问题可能是旧软件、错误配置或漏洞；网络相关问题可能是连通性通告、路由环路或黑洞。一封邮件未到或一个目的地不可达，不能只凭这些现象就在三类中选择一种。相关日志、配置、拓扑和资源范围仍须由有权查看它们的本地一方检查。

安全一节进一步避免了把报告道德化为结论。RFC 1173 说安全是主观的：一个站点认为的无害好奇，另一个站点可能视作敌意探测。它要求管理者认真对待其他站点的安全关切，同时又说每台主机的管理者最终对该主机的安全负责。认真聆听，不等于预先采纳；本地负责，也不等于统治别人的系统。

协作为什么需要保留空隙

从历史上看，RFC 1173 描绘的链条很短：有人观察到异常；一个已知角色地址承接消息；本地运营者将报告与自己能看到的证据相对照；该运营者在自己的资源范围内决定是否行动；其后才出现可解释、可沟通、也可被纠正的结果。每一步都保护不同的东西。

若把报告当证据，猜测会迅速变成技术后果；若把角色名称当身份，别名会被误作对人的断言；若把联系方式当控制权，求助会变成对外部资源的命令。RFC 1173 的分布式设计并非反对协调，而是拒绝让协调吞没证据、所有权和后果承担。

这份历史文本不能决定今天的值班安排、服务合同、适用法律、网络所有者、邮箱背后的身份或某次事件是否真实发生。它也不能证明当前部署、响应时间、入侵意图或处置成功。它让问题保持清晰：观察了什么？谁运行受影响资源？哪些本地记录可以证实或推翻报告？谁将承担一次错误变更的代价？这些问题必须在第一封报告之后回答，而不能由联系地址代答。

来源与证据边界

冻结来源包括 RFC 1173、2142 和 5321。RFC 1173 支持其信息性地位、去中心化语境、本地管理能力、postmaster 惯例、报告分类和安全的情境性；RFC 2142 支持域名范围内的角色邮箱；RFC 5321 支持 SMTP 对 postmaster 的接收要求。三者均不能证明当前可用性、身份、授权、事件、决定、部署或结果。