Independent

sochimaezema00@gmail.com

Security phishing impersonation IDNA confusables Users of consumer platforms -- job boards, marketplaces, education and early-career services -- receive messages from other parties inside the platform, where no enterprise mail gateway inspects them. Attackers impersonate the platform's own brand and support staff, and pose as recruiters or counterparties, using look-alike domains and display names. This document describes considerations for detecting look-alike sender identities at the level of the individual message and its sender, rather than at the domain-registration level. It records two concrete pitfalls observed in deployed libraries: Unicode confusable "skeleton" equality alone does not catch all mixed-script look-alikes, and several input validators accept host names containing invisible format characters. This document is informational and specifies no protocol.

Introduction Enterprise anti-phishing controls assume a mail gateway positioned between the sender and the recipient. A large and growing share of impersonation and employment fraud reaches people who are contacted inside a consumer platform -- in in-app messages, notifications, and platform-relayed email -- where that assumption does not hold . The exposed population skews toward students and early-career users. This document is a set of engineering considerations, not a protocol. It describes signals a platform can compute about a single message and its sender, and two specific correctness pitfalls that defeat naive implementations. Terminology: a "protected identity" is a brand name, domain, or support handle the platform wishes to defend; a "look-alike" is a sender identity visually or structurally confusable with a protected identity.

Terminology The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. This document uses them sparingly, as it is informational.

Signals at the message and sender level A detector operating without a mail gateway can still compute:

1. Deterministic look-alike checks on the sender domain and on any domain embedded in a link host: Unicode confusable skeleton comparison , mixed-script detection, bounded edit distance to a protected domain, and detection of a protected or foreign domain placed inside an attacker-controlled host.
2. Sender-reputation features over the display name and address: a protected brand token appearing in the local part of a non-protected address, a brand display name on an unrelated domain, affix and subdomain patterns, and "lure" tokens.
3. Message-intent signals: a request to verify credentials, a redirect away from the platform, or a claim to the platform's own authority. These are the step an attacker needs and a benign sender rarely combines with a look-alike identity.

No single layer is sufficient; they are complementary, and a fused decision outperforms any one of them. An open-source reference implementation of these signals exists .

Pitfall 1: confusable skeleton equality is not enough UTS-39 defines a "skeleton" transform for confusable detection: two strings are confusable if their skeletons are equal. Implementations that test skeleton equality alone miss look-alikes whose confusable characters map to a non-ASCII Latin prototype. For example, the prototype of U+03BA GREEK SMALL LETTER KAPPA is U+0138, and the prototype of U+0442 CYRILLIC SMALL LETTER TE is U+1D1B: both Latin, neither ASCII. A brand spelled with such characters has a skeleton that is not equal to the ASCII brand skeleton, so equality does not fire. Detectors SHOULD combine skeleton comparison with mixed-script detection and a bounded edit distance between skeletons, rather than relying on skeleton equality to a protected string.

Pitfall 2: invisible format characters survive validation Host names and email domains that contain invisible Unicode format characters -- for example U+00AD SOFT HYPHEN, U+200B ZERO WIDTH SPACE, U+2060 WORD JOINER, U+FEFF -- are ignored or disallowed under IDNA2008 and UTS-46 processing, so such a string is not a valid domain and visually collapses to a different real domain. In a survey of widely used validation libraries, several reported such host names as valid while preserving the invisible character in the returned value, so downstream code received a look-alike as validated. Platforms SHOULD normalize host names with IDNA2008/UTS-46 before any equality or allow-list check, and SHOULD reject host labels that contain format (Cf) or default-ignorable code points.

Adversarial robustness Look-alike and intent signals degrade under cheap, label-preserving transformations: a single confusable glyph, leetspeak, inserted spacing, and machine paraphrase. Normalization (confusable folding and de-obfuscation) belongs in front of any cue- or token-based classifier, because such a classifier sees a different string after a confusable swap. Detectors that incorporate a language model SHOULD treat message text as untrusted and guard against prompt injection, and SHOULD NOT allow a model verdict to override deterministic sender evidence.

Security Considerations This entire document concerns the detection of impersonation. It describes detection signals, not evasion techniques. Deterministic checks can produce false positives on legitimate senders that share surface features (for example a university career office); a platform SHOULD fuse sender facts with intent before taking a high-friction action. Reference data for confusable mappings changes between Unicode versions and SHOULD be updated.

IANA Considerations This document has no IANA actions.

Normative References The Unicode Consortium Informative References U.S. Federal Bureau of Investigation, IC3