Summary

  • An individual Internet-Draft dated 27 October examines lookalike support and recruiter identities in platform messaging. It offers engineering considerations, with no protocol or IANA action.
  • The draft identifies two implementation traps: exact Unicode skeleton equality can miss some visual imitations, and some surveyed validators reportedly accept host names while preserving invisible format characters. It calls for combined sender, link and message-intent checks.

The dangerous label in a job-board inbox is not always a domain. It may be a display name that reads “Platform Support,” attached to a sender the platform never authorized to use it. The new lookalike-sender draft asks platforms to judge the individual message and sender: name, address, linked host and the request made to the recipient. A recipient's enterprise mail gateway does not sit between two accounts messaging inside an app. That puts the first meaningful check in the platform's own product.

The draft lists three groups of signals. Compare sender and link-host names with identities the platform protects. Examine whether a branded display name sits on an unrelated address, or whether a protected name appears in a strange local part or subdomain. Then read the requested action: credentials, a jump off-platform, or a claim to speak for the platform. Those signals become useful together. A university career office can legitimately share words with a recruiter; a name match alone is a poor reason to freeze its messages.

The first technical trap concerns a seemingly tidy Unicode test. UTS #39 defines a skeleton transform for comparing confusable strings and also describes mixed-script detection. The draft says exact equality of skeletons alone misses some visual imitations because characters can map to non-ASCII Latin prototypes. It gives Greek small kappa and Cyrillic small te as examples. A detector that compares only the final skeleton with the ASCII brand can let a plausible-looking name pass. The draft recommends adding mixed-script checks and bounded distance between skeletons. Those checks need a test set that includes legitimate mixed-script names.

The second trap is more embarrassing for a validation badge. The draft reports that several surveyed input validators accepted host names containing invisible format characters and returned the characters intact. It names U+00AD, U+200B, U+2060 and U+FEFF. RFC 5890 defines IDNA's domain-name framework, RFC 5892 sets code-point rules, and Unicode UTS #46 describes compatibility processing. The draft's instruction is practical: process the host under IDNA2008 or UTS-46 before an allow-list comparison, and reject labels containing format or default-ignorable code points. A “valid” return value that preserves an invisible hitchhiker gives downstream code the wrong object to trust.

This moves the control question from a distant naming registry to the platform's own protected-name list and message workflow. The platform decides which support handles and domains are its own, how to treat a similar student or recruiter, and when a warning becomes a hard block. A language-model classifier can add context, but the draft tells implementers to treat message text as untrusted and keep deterministic sender evidence ahead of a model verdict. The Datatracker entry remains an individual I-D Exists draft intended as Informational, with no new protocol.

The draft does not publish the tested validator names, versions or a reproducible input/output matrix. That matrix would show whether its invisible-character finding survives current library releases.