摘要

  • 10 月 27 日的个人 Internet-Draft 讨论招聘、教育和交易平台私信里的仿冒客服与招聘者。它提出检测建议，没有制定新协议。
  • 草案指出两处实现陷阱：Unicode 骨架完全相等仍可能漏掉视觉近似名；部分被调查的验证库据称会接受并保留主机名里的不可见格式字符。判断应合并发送者、链接去向和消息意图。

假设普通账号把显示名改成“平台客服”，再发一条要求求职者点开链接的站内信。企业邮箱网关管不到这段站内对话。能核对账号权限、显示名称和链接去向的，是经营这个信箱的平台。新发布的仿冒发送者草案把检查对象放在每一条消息和发送者上：谁用了受保护的名称？发件地址属于哪里？链接通往什么主机？消息要用户交出什么？

草案把线索分成三组。第一组比对发件域名和链接主机与平台保护的名称；第二组看显示名、地址本地部分和子域名里有没有冒用品牌的痕迹；第三组看行动要求，例如索取凭据、把人带到站外，或自称拥有平台权威。单看一个词就封号，会误伤正常机构。大学就业办公室也可能使用与招聘者相似的名称。平台必须把“看起来像”与“正在借谁的权威办什么事”接起来。

第一处技术陷阱藏在 Unicode 的比较方法里。Unicode UTS #39提供视觉易混字符的“骨架”变换和混合文字检测。草案指出，只查骨架是否完全相等会漏掉某些近似写法：希腊小写 kappa 与西里尔小写 te 的映射原型是非 ASCII 的拉丁字符。拿最后得到的骨架与纯 ASCII 品牌名做一次等号判断，门卫可能认不出那块仿造的牌子。草案建议加上混合文字检查和骨架间的有界编辑距离。

第二处陷阱连宽度都没有。草案称，它调查的若干验证库会接受带有 U+00AD、U+200B、U+2060 或 U+FEFF 等不可见格式字符的主机名，并把字符原样留在返回值里。RFC 5890界定国际化域名框架，RFC 5892规定字符状态，Unicode UTS #46给出兼容处理。草案要求先按 IDNA2008 或 UTS-46 处理，再与允许名单比对，并拒绝含格式字符或默认可忽略码点的标签。验证器盖了“有效”章，下游若拿到仍藏字符的原串，章就盖错了对象。

平台的决定比域名登记记录更近一步：哪个账号可以用官方客服名，哪个链接属于自己的服务，何时只提醒，何时拦截。草案允许语言模型辅助判断，同时要求把消息文本视为不可信输入，确定性的发送者证据不能被模型一句评分推翻。Datatracker仍将这份文件列为个人草案 I-D Exists，目标状态是 Informational。

草案没有列出被测验证库的名称、版本和可复现的输入输出表。公开这张表，才能判断不可见字符问题在当前版本里有多普遍。