From/Sender Ambiguity
This attack exploits inconsistencies in how email clients and servers handle the From and Sender headers. By manipulating these headers, attackers can create emails that appear to be from legitimate senders while bypassing authentication mechanisms.
Attack Summary: Exploiting differences in how email clients display From vs. Sender headers and how authentication mechanisms validate them.
Background: From vs. Sender Headers
According to RFC 5322, email messages can have both a From header and a Sender header:
- From: Indicates the author(s) of the message (who wrote the content)
- Sender: Indicates the mailbox of the agent responsible for the actual transmission (who sent the message)
In most legitimate emails, the From and Sender headers are either the same or clearly related (e.g., From: marketing@company.com, Sender: no-reply@company.com). However, many email clients only prominently display the From header, while authentication mechanisms like SPF might validate the Sender header or the MAIL FROM envelope address.
From: ceo@company.com Sender: attacker@malicious.com Subject: Urgent Wire Transfer Please process the attached wire transfer immediately.
This inconsistency creates opportunities for attackers to manipulate how their emails are displayed to recipients while still passing certain authentication checks.
Attack Methodology
This attack involves creating emails with different From and Sender headers to exploit inconsistencies in how they are displayed and authenticated.
The most basic form of this attack involves setting different domains in the From and Sender headers.
Attack Example
Different From and Sender domains
How It Works
- Attacker creates an email with different From and Sender headers
- The From header contains the spoofed identity (ceo@target.com)
- The Sender header contains a domain the attacker controls (attacker.com)
- The MAIL FROM envelope address also uses the attacker's domain
- SPF checks validate the MAIL FROM address against the attacker's domain
- The SPF check passes because the attacker has valid SPF records
- Email clients prominently display the From header (ceo@target.com)
- Recipients see the email as coming from the CEO
This variant exploits how DMARC alignment checks work with From and Sender headers.
DMARC Bypass Example
Exploiting DMARC alignment
DMARC Alignment Issues
DMARC alignment can be affected by From/Sender ambiguity in several ways:
- Some implementations check alignment between the From header and the authenticated domain
- Others check alignment between the Sender header and the authenticated domain
- Some check both, requiring at least one to align
- The RFC is somewhat ambiguous about which should be used in all cases
- This ambiguity creates opportunities for attackers to bypass DMARC
This variant combines From/Sender ambiguity with display name spoofing for a more convincing attack.
Display Name Spoofing Example
Combining techniques for more effective spoofing
Client Display Variations
Different email clients display From/Sender information differently:
- Mobile clients: Often show only the display name in the inbox view
- Webmail: May show the display name prominently with the email address in smaller text
- Desktop clients: Vary widely in how they display From vs. Sender information
- Some clients: Show "on behalf of" or similar text when From and Sender differ
- Others: Don't display the Sender header at all in the user interface
Impact
This attack allows attackers to:
- Create emails that appear to be from legitimate senders while passing authentication checks
- Bypass some DMARC implementations by exploiting alignment ambiguities
- Target specific email clients with tailored spoofing techniques
- Conduct sophisticated phishing attacks that appear legitimate to recipients
Detection
Organizations can detect these attacks by:
- Implementing email security solutions that check for mismatches between From and Sender headers
- Configuring email gateways to flag or quarantine emails with suspicious header combinations
- Using email clients that clearly display both From and Sender information
- Training users to check the full email address, not just the display name
Mitigation
To protect against these attacks, organizations should:
- Implement strict DMARC policies: Use p=reject with strict alignment requirements
- Configure email gateways: Set up rules to detect and block From/Sender mismatches
- Use email clients: Deploy clients that clearly display both From and Sender information
- Train users: Educate users about checking the full email address and being suspicious of mismatches
- Implement additional authentication: Use additional authentication mechanisms beyond SPF/DKIM/DMARC
Testing
Security professionals can test for this vulnerability using the following approach:
- Create test emails with different combinations of From and Sender headers
- Send these emails to test accounts using different email clients
- Observe how different clients display the sender information
- Check if email authentication mechanisms detect or block the emails
- Document inconsistencies in how different systems handle the emails
References
- RFC 5322: "Internet Message Format." https://tools.ietf.org/html/rfc5322
- RFC 7489: "Domain-based Message Authentication, Reporting, and Conformance (DMARC)." https://tools.ietf.org/html/rfc7489
- Chen, J., Duan, H., Weaver, N., Paxson, V., & Jiang, J. (2021). "Measuring and Mitigating Email Sender Spoofing Attacks." In Proceedings of the 30th USENIX Security Symposium.
- Foster, I. D., Larson, J., Masich, M., Snoeren, A. C., Savage, S., & Levchenko, K. (2015). "Security by Any Other Name: On the Effectiveness of Provider Based Email Security." In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security.