Email spoofing is the creation of email messages with a forged sender address - something which is simple to do because the core SMTP protocols do no authentication. Spam and phishing emails typically use such spoofing to mislead the recipient about the origin of the message.
A number of measures to address spoofing are available including: SPF, Sender ID, DKIM, and DMARC. Although their use is increasing, it is likely that almost half of all domains still do not have such measures in place.
When an SMTP email is sent the initial connection provides two pieces of address information:
- MAIL FROM: - generally presented to the recipient as the Return-path: header but not normally visible to the end user, and by default no checks are done that the sending system is authorized to send on behalf of that address.
- RCPT TO: - specifies which email address the email is delivered to, is not normally visible to the end user but may be present in the headers as part of the "Received:" header.
Once the receiving mail server signals that it accepted these two items, the sending system sends the "DATA" command, and typically sends several header items, including:
- From: Joe Q Doe <firstname.lastname@example.org> - the address visible to the recipient; but again, by default no checks are done that the sending system is authorized to send on behalf of that address.
- Reply-to: Jane Roe <Jane.Roe@example.mil> - similarly not checked
The result is that the email recipient sees the email as having come from the address in the From: header; they may sometimes be able to find the MAIL FROM address; and if they reply to the email it will go to either the address presented in the MAIL FROM: or Reply-to: header - but none of these addresses are typically reliable.
Use by spam and worms
Malware such as Klez and Sober and many more modern examples often search for email addresses within the computer they have infected, and use those addresses both as targets for email, but also to create credible forged From fields in the emails that they send, so that these emails are more likely to be opened. For example:
- Alice is sent an infected email and then the email is opened, triggering propagation.
- The worm finds the addresses of Bob and Charlie within Alice's address book.
- From Alice's computer, the worm sends an infected email to Bob, but forged to appear to have been sent by Charlie.
In this case, even if Bob's system detects the incoming mail as containing malware, he sees the source as being Charlie - while Alice remains unaware of the actual infection.
Historical legitimate use
In the early Internet, "legitimately spoofed" email was common. For example, a visiting user might use the local organization's SMTP server to send email from the user's foreign address. Since most servers were configured as "open relays", this was a common practice. As spam email became an annoying problem, this sort of "legitimate" uses fell out of favor.
The effect on mailservers
Traditionally, mail servers could accept a mail item, then later send a Non-Delivery Report or "bounce" message if it couldn't be delivered or had been quarantined for any reason. These would be sent to the "MAIL FROM:" aka "Return Path" address. With the massive rise in forged addresses, Best Practice is now to not generate NDRs for detected spam, viruses etc. When mail administrators fail to take this approach, their systems are guilty of sending "backscatter" emails to innocent parties - in itself a form of spam - or being used to perform "Joe job" attacks.
Mail administrators may be able to enable SSL/TLS in their mail transfer software. Using certificates in this manner increases the amount of authentication performed when sending mail.
Identifying the source of the email
Although email spoofing is often effective in forging the sender's real email address, the IP address source computer sending the mail can generally be identified from the "Received:" lines in the email header. In many cases this is likely to be an innocent third party infected by malware that is sending the email without the owners knowledge.
- Email authentication
- Sender Policy Framework (SPF)
- Computer virus
- Computer worm
- Chain email
- Joe job
- Website spoofing
- See e.g. UK tax website or Lloyds TSB Bank security advice
- "SPF Deployment Trends", Lars Eggert
- "DKIM Deployment Trends", Lars Eggert
- Unless they select to "View Internet Headers", "View Original", "View Raw", or something similar depending on their email client software.
- "A quick overview of SMTP", University of Toronto
- See RFC3834
- "e-mail impersonators: identifying “spoofed” e-mail", http://www.wwlegal.com/