One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases

One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases

Speakers: Mengying Wu

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=44JhPK690c8

Overview

This research exposes a fundamental inconsistency in how the internet handles email identity: email providers treat alias addresses as the same identity (delivering them to one inbox), while online platforms treat them as distinct users. This mismatch enables two classes of attacks: alias multiplicity abuse (creating unlimited accounts from a single email) and alias misidentification attacks (tricking users into trusting emails from unfamiliar alias addresses).

The researchers studied 28 major email providers and found 12 with undocumented alias rules beyond the well-known Gmail plus-addressing. They tested 18 major platforms and found that none could defend against all alias rules -- at best, platforms detect the plus-suffix pattern. A user study with 304 participants revealed the most counterintuitive finding: users who believe they understand aliasing are the most vulnerable to misidentification attacks, with CS students showing a 35% susceptibility rate compared to 0% for those who had never heard of aliases.

Background

▶ Watch: Real-world alias abuse: infinite Copilot Pro memberships via Gmail (0:00)

Email addresses serve as the primary identity anchor for the internet -- used for account registration, identity verification, and password recovery. To improve usability, email providers introduced alias mechanisms that allow variations of an address to deliver to the same inbox without any configuration. The most well-known example is Gmail's plus-addressing ([email protected] delivers to [email protected]) and dot-ignoring ([email protected] delivers to [email protected]).

This practice has been known and exploited informally for years -- a Reddit thread from seven years ago with 11,000+ upvotes described using aliases to get repeated free trials. On Xiaohongshu (Red Notes), a Chinese social media platform with 300+ million users, posts sharing how to get infinite Copilot Pro memberships via Gmail aliases have been saved over 1,000 times.

At the protocol level, SMTP RFC requires the local part (username) of email addresses to be case-sensitive, but all 28 providers studied treat it as case-insensitive -- a protocol-level inconsistency that creates additional confusion.

Key Findings

▶ Watch: 28 email providers studied: 12 have undocumented alias rules (4:00)

12 email providers have undocumented alias rules. Beyond Gmail's well-known plus-addressing and dot-ignoring, 11 other providers implement alias mechanisms that are not publicly documented. Only Gmail fully documents its alias rules. For example, Eclipso allows prefix-based aliasing using special characters -- [email protected] routes to [email protected].

No platform fully defends against all alias rules. Of 18 major platforms tested, only 5 implement any form of alias detection, and their defenses are limited to detecting the plus-suffix pattern. None can handle the diverse alias rules across all 12 providers with alias mechanisms.

Protocol-level inconsistencies compound the problem. npm and PyPI treat the full email address (including domain part) as case-sensitive, violating SMTP's requirement that domain parts be case-insensitive. This creates additional avenues for creating duplicate accounts.

Over 1,000 base addresses have multiple npm accounts. Analysis of publicly available email data revealed widespread abuse, with one extreme case showing 139 alias accounts from a single email address, used for large-scale SEO campaigns on npm.

Self-confidence in understanding aliasing increases vulnerability. The user study found that participants who believed they understood aliasing were the most susceptible to misidentification attacks. Among CS students: those unaware of aliases had 0% susceptibility, while those who thought they understood had 35% susceptibility. Highly educated, male, and technical participants showed the highest risk.

21% of users had never heard of email aliasing. Among those aware, 42% failed attention validation checks in the study, but their rejection-by-default behavior actually made them safer.

Technical Deep Dive

▶ Watch: npm abuse: 139 alias accounts from one email for SEO campaigns (8:00)

The research covers two distinct attack surfaces:

Alias Multiplicity Abuse: An attacker creates multiple accounts on a platform using alias variations of a single email address. The platform treats each variation as a distinct user, while the email provider delivers all communications to one inbox. This enables: unlimited free trials, vote manipulation, SEO spam campaigns, and circumvention of per-user rate limits.

The alias rules vary dramatically across providers:

• Gmail: Plus-suffix (+suffix) and dot-ignoring (a.lice = alice)
• Eclipso: Prefix-based with special characters (!, etc.)
• Others: Various undocumented prefix, suffix, and character-based rules

Alias Misidentification Attack: Even when a user knows that aliases exist, the diversity and inconsistency of alias rules across providers makes it impossible to reliably determine whether an unfamiliar address belongs to a known contact. If Bob knows that Gmail supports plus-addressing, and receives an email from [email protected], Bob must know whether Protonmail also supports plus-addressing to assess whether this is really Alice.

The user study methodology presented participants with email addresses and asked them to identify which belonged to a known contact using specific email providers. The study controlled for demographics, technical background, and self-assessed alias knowledge to isolate the factors driving susceptibility.

The researchers developed OriginalMail, a tool that helps platforms and users resolve alias confusion by identifying the base address from any alias variation, implementing normalization across the known alias rules of all 12 providers.

Demo / Proof of Concept

▶ Watch: User study: CS students most vulnerable to alias misidentification (10:00)

The researchers demonstrated the practical impact through multiple channels:

Real-world npm abuse: Over 1,000 base email addresses with multiple aliased accounts were identified on npm, with the most extreme case showing 139 accounts from one email used for SEO campaigns.

Platform registration testing: Automated registration across 18 platforms using alias variations confirmed that none could fully prevent alias-based account multiplication. Even platforms with partial detection (plus-suffix) were bypassed using provider-specific alias rules.

User study (n=304): Demonstrated that the most technically knowledgeable users are paradoxically the most vulnerable to alias misidentification, due to overconfidence in their understanding of alias rules.

Xiaohongshu wild examples: Real posts with 1,000+ saves showing users actively exploiting alias mechanisms for free trial abuse on Copilot Pro and other services.

Defensive Implications

▶ Watch: Q&A: standardization challenges and SMTP VRFY command history (16:00)

The research provides concrete recommendations at multiple levels:

For email providers: Standardize and publicly document alias rules. Ideally, the industry should converge on a single alias convention (plus-suffix is the most widely implemented). The SMTP VRFY command was designed to resolve aliases but is essentially never implemented due to privacy concerns.

For platforms: Normalize email addresses before registration by stripping known alias components. Implement both client-side and server-side validation (the researchers found that some platforms perform alias detection only on the frontend, which can be bypassed by using the API directly). Send alerts to the base email address when alias registrations are detected.

For users: Do not assume you can correctly identify whether an unfamiliar email address is an alias of a known contact. When in doubt, reject. Self-confidence in understanding aliases actually increases vulnerability.

For the ecosystem: The fundamental problem is the lack of standardization. Until email providers agree on transparent, consistent alias rules, platforms cannot reliably defend against multiplicity abuse, and users cannot reliably identify aliases.

Key Takeaways

• 12 of 28 email providers have undocumented alias rules; only Gmail fully documents its aliasing behavior
• No major platform can defend against all alias rules -- at best, plus-suffix detection covers one pattern
• Users who believe they understand aliasing are the most vulnerable to misidentification (35% susceptibility for CS students vs. 0% for those unaware)
• Over 1,000 npm accounts trace to aliased addresses, with one email generating 139 accounts for SEO spam
• SMTP protocol requires case-sensitive local parts, but all providers treat them as case-insensitive, adding another confusion layer
• The OriginalMail tool helps identify base addresses from alias variations across known provider rules
• Industry-wide standardization of alias rules is the only comprehensive solution

About the Speaker(s)

Mengying Wu is a researcher at Peking University (PKU). The work was conducted in collaboration with researchers from Fudan University and Tsinghua University. The team focuses on email security, identity systems, and the intersection of protocol design with real-world security implications.