Summary

  • RFC 2377 用 DNS 派生的 dc 与既有 uid 避免新建全球名字登记，但明确指出邮件形态的 UID 可能没有有效邮箱；应用必须另查 mail 属性。
  • UID 的域名可以不同于 DN 的目录路径；同一 DN 可出现在独立管理的服务器上；DN 本身也不负责定位或认证 LDAP 服务。

最便宜的登记体系是已经存在的那一套

X.500 提供了分层与分布式目录模型，但传统命名方式要求机构在国家、地区或法律名称体系里取得位置。公司全称既长又陌生，常用人名则很快冲突。互联网增长远快于早期 X.500 试点时，这种额外登记成为部署摩擦。

1998 年发布的 RFC 2377 是 Informational 文档，不是强制标准。它建议把 acme.com 转成 dc=acme,dc=com 作为机构子树根，再用 uid 或 cn 命名叶节点。DNS、员工号、handle 与 RFC 822 邮箱标识已经在各自范围内解决了一部分冲突，目录可以借用这些成果。

一个 at 符号 符号没有创造投递事实

文档建议在某些场景选一个“distinguished”邮件标识作为人的 UID。这种值容易辨认，也常已存在于管理系统中。但它同时记录了一种实践：机构可能给所有员工分配邮件形态的唯一别名，即使其中少数人根本没有工作邮箱。

因此规范明确要求，目录应用不能假定 uid 就是有效邮箱，而应检查独立的 mail 属性。UID 回答“这个目录上下文里的哪个条目”；mail 提出联系方式声明；SMTP 路由与投递又产生后续凭证。认证主体与授权决定仍属于别的控制面。字符串中出现 at 符号，不会补齐这些证据。

两条域名路径可以有意分开

RFC 2377 允许 uid=external-mailbox-shaped-identifier 放在 dc=mis,dc=acme,dc=com 之下。DN 路径可服务于访问控制、分区或组织目录结构，而 UID 保留外部或更稳定的标识。调整目录结构不必强迫用户更换邮件地址。

这也否定了便捷的逆推：程序不能把 at 符号 后面的文本直接变成权威 DN，也不能从 DN 推出当前邮箱。规范只要求 dc 串联后形成已登记 DNS 名，以避免该目录层级中的名字冲突。DNS 登记不等于 LDAP 服务器认证，更不证明目录里的机构或人员身份。

DN 没有指定唯一服务器

配套的 RFC 2247 定义了纯 dc DN 与 DNS 名之间的可逆映射，却明确不定义如何凭域名找到 LDAP 服务器；它还警告，不可信服务器可能声称自己持有从未委派给它的命名上下文。

RFC 2377 设想的是松耦合“岛屿”。同一 DN 空间里的服务器可通过 referral 相连，跨岛时则由 LDAP URL 把主机、端口与 DN 组合。由此可见，endpoint 是 DN 之外的另一份证据。

作者也不认为竞争服务商环境能维持单一全球 DIT。独立管理的服务器可能为同一个现实对象保存属性不同、DN 相同的目录对象。目录对象只是属性集合，应用才负责把它与现实对象联系起来。

命名与查找也不相同。即使用 uid 组成 RDN，cn 仍适合搜索与展示。访问控制隐藏某些目录分支时，公开 DNS 名还可能泄露结构线索。复用已有登记减少摩擦，也会带入已有可见性。

RFC 4519 后来给 uid、dc、dcObject 与 uidObject 提供了权威定义。它修订的是 schema，不是证据等级：合规 UID 仍然不是邮箱、凭证、真人或授权结果。

复用名字，不升级权威

依照 Lu Heng 的现实分层，DNS 委派、结构化 DN、展示字符串、UID、mail、LDAP URL、认证响应、ACL 决定和投递结果必须分别保存。Running-Code Primacy 要求检查真实部署的服务器与邮件系统。Minimum Initial Specification 则说明 RFC 2377 的优点：先给出足以协作的约定，把未来结构与本地选择留给运营者。