==== Common Types of E-Mail Abuse where the Sender Address is Forged
[[Wikipedia:E-mail spam|Spammers]] want to avoid receiving ''non-delivery notifications (bounces)'' to their real addresses.
[[Wikipedia:Internet fraud|Fraudsters]] want to cover their tracks and remain anonymous.
[[Wikipedia:Computer worm|Computer worms]] want to cause confusion or just don’t care about which sender addresses they use.
[[Wikipedia:Phishing|Phishers]] (password fishers) want to impersonate well-known, trusted identities in order to steal passwords from users.
== The Problem: Sender Address Forgery
Today, nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets diminished and they have to disclaim liability for the abuse, or waste their time sorting out misdirected bounce messages.
You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address.
Sender address forgery is a threat to users and companies alike, and it even undermines the ''e-mail'' medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.
''But it does not have to be this way!''
==== Sender Addresses in E-Mails
Like paper mail letters, e-mail messages have at least two kinds of sender addresses: one on the envelope and one in the letterhead.
The '''envelope sender address''' (sometimes also called the ''return-path'') is used during the transport of the message from mail server to mail server, e.g. to return the message to the sender in the case of a delivery failure. It is usually not displayed to the user by mail programs.
The '''header sender address''' of an e-mail message is contained in the "From" or "Sender" header and is what is displayed to the user by mail programs. Generally, mail servers do not care about the header sender address when delivering a message.
== The Solution: SPF
The ''Sender Policy Framework (SPF)'' is an [[Wikipedia:Open standard|open standard]] specifying a technical method to prevent sender address forgery. More precisely, the [[Specifications|current version of ''SPF'']] --- called ''SPFv1'' or ''SPF Classic'' --- protects the ''envelope sender address'', which is used for the delivery of messages. See the box on the right for a quick explanation of the different types of sender addresses in e-mails.
(There are [[Related Solutions|other solutions]] that protect the ''header sender address'' or that do not care at all about who sent the message, only who originally wrote it.)
Even more precisely, ''SPFv1'' allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together: '''(1) the domain owner publishes''' this information in an ''SPF'' record in the domain's [[Wikipedia:Domain Name System|DNS]] [[Wikipedia:DNS zone|zone]], and when someone else's mail server receives a message claiming to come from that domain, then '''(2) the receiving server can check''' whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
Once you are confident about the authenticity of the sender address, you can finally "take it for real" and attach reputation to it. While IP-address-based reputation systems like ''[[http://www.spamhaus.org/sbl/|Spamhaus]]'' or ''[[http://www.spamcop.net|SpamCop]]'' have prevailed so far, reputation will increasingly be based on domains and even individual e-mail addresses in the future, too. Furthermore, additional kinds of policies are planned for a future version of ''SPF'', such as asserting that all of a domain's outgoing mail is ''S/MIME'' or ''PGP'' signed.
== An Example Policy
Let's look at an example to give you an idea of how ''SPF'' works. Bob owns the domain example.net. He also sometimes sends mail through his [[Frank_Ellermann/Google|GMail]] account and contacted GMail's support to identify the correct SPF record for GMail. Since he often receives bounces about messages he didn't send, he decides to publish an SPF record in order to reduce the abuse of his domain in e-mail envelopes:
> example.net. TXT "v=spf1 mx a:pluto.example.net include:aspmx.googlemail.com -all"
The parts of the ''SPF'' record mean the following:
| v=spf1 | ''SPF'' version 1 |
| mx | the incoming mail servers (MXes) of the domain are authorized to also send mail for example.net |
| a:pluto.example.net | the machine pluto.example.net is authorized, too |
| include:aspmx.googlemail.com | everything considered legitimate by gmail.com is legitimate for example.net, too |
| -all | all other machines are not authorized |
This example demonstrates but a small part of ''SPF's'' expressiveness. Do not take it as a guideline for building your own record --- things might not work out as you expect and legitimate messages might get blocked! Instead, learn more about the [[SPF Record Syntax|record syntax]], or get the complete picture by studying the [[Specifications|full specification]]. [[Support|Community support]] is available.
== Receiver-side Checking
The domain sender policies alone are not worth much --- it is the receiving mail servers that need to enforce them. Most mail servers support ''SPF'' checking either natively or through [[Implementations|extensions]]. Again, you can get [[Support|community support]].