| Internet-Draft | Look-Alike Sender Detection | October 2026 |
| Ezema | Expires 30 April 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
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 [IC3]. 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.¶
The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. This document uses them sparingly, as it is informational.¶
A detector operating without a mail gateway can still compute:¶
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 [DETECTOR].¶
UTS-39 [UTS39] 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.¶
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 [RFC5890] 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.¶
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.¶
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 [UTS39] changes between Unicode versions and SHOULD be updated.¶
This document has no IANA actions.¶