| |
|
| Table of contents |
|
2 Implementation 3 Limitations and controversies 4 External links |
Normal SMTP without SPF allows any computer to send email claiming to be from anyone.
Thus, it's easy for spammers to send email from forged addresses.
This makes it much more difficult to trace back to where the spam truly comes from, and easy
for spammers to appear to be senders the receiver would ordinarily trust.
Many believe that the ability for anyone to forge "From" addresses is a security flaw in SMTP.
In contrast,
SPF allows an Internet domain to specify which machines are authorized to transmit e-mail for that domain.
For example, the owner of the wikipedia.org domain can designate which machines are authorized to
send email whose email address ends with "@wikipedia.org".
This information is specified using special codes in Domain Name Service (DNS) records
(and all Internet domains must support DNS anyway).
Receivers that implement SPF then ignore any email that claims to come from that domain but fails
to come from locations that domain authorizes.
SPF makes it more difficult for spammers to send spam, because if they simply forge
a "From" address from an address that implements SPF,
receivers that implement SPF will know to ignore the message.
SPF only keeps spammers from forging the domain names given in the From-addresses of an email.
If a spammer legitimately has an account in that domain, or owns the domain, they can still send email;
however, doing so makes the spam much easier to trace and prosecute, because they must reveal more about
their location. It also makes it easier for service providers to drop support.
The revelation of the spammer's true domain makes it much easier to automatically
"blacklist" a domain that sends spam.
Spammers can also use computer attacks (such as viruses) to force
authorized computers to send email, or use computer attacks against Internet infrastructure
(such as corrupting DNS or attacking BGP to subvert entire address blocks)
to take control over others' networks, however, such actions are
illegal in most countries, are more likely to initiate serious government investigation,
and the legal penalties for performing such attacks are often more severe than spamming by itself.
Another benefit of SPF is to people whose email addresses are being forged as "From" addresses.
People with these forged addresses typically receive a large mass of error messages, making it
more difficult to use email normally.
If these people use SPF to specify their legitimate senders, the number of error messages will
be reduced because receivers implementing SPF will know that the message is forged.
Note that SPF has advantages beyond SPF. In particular, if a sender provides SPF information, and
the receiver uses it, the receiver has some justification in believing that the email at least
came from the domain that it asserts it came from.
Implementing SPF has two parts:
The following methods are defined:
SPF normally only validates the domain of a from-address (the part after the "@" in the "From" email address).
Domains that share mail senders can forge each others' domain,
and mail forwarding systems may also allow other domains to also forge domains.
SPF does not validate that a given email actually comes from the claimed user.
SPF breaks inter-system SMTP forwarding (where an agent forwards email to someone else
without changing the "from" address). This is problem for forwarding services
(such as acm.com and pobox.com). One solution is for the SPF record to
specifically specify the forwarder as an allowed sender. A more general solution
is to switch from forwarding (where the envelope sender is preserved) to remailing
(where the envelope sender is changed).
Remailing is easy to implement in most systems, so this is not typically a serious problem.
Steve Bellovin has written a long email dated January 5, 2004, discussing some of his
concerns with SPF. Some of these include:
Bellovin notes that it would be more flexible to permit
delegation of individual user names to particular sending machines.
However, he also grants that it would probably not be affordable.
specifically noting that it would probably require too much public key cryptography.
Although he does not note it, there are many other complications to this
more flexible approach.
Supporting individual user delegation would require services to maintain each
entry, as well as requiring domains to manage each user account; an
extraordinary undertaking for many large domains.
In contrast, SPF requires adding only one line to a DNS entry, and only
needs to be changed under relatively rare conditions.
Also, SPF results can be cached for each domain, so SPF as specified
is far more efficient in terms of network bandwidth.
In spite of its limitations, many people have decided that the
pros of SPF outweigh its cons and have begun implementing SPF.
Anti-spam products such as SpamAssassin version 2.70 implement SPF.
Many mail transfer agents (MTAs) support SPF or have patches/plug-ins available
that support SPF, including Postfix, Sendmail, Exim, and Qmail.
Many prominent domains decided to post SPF data for their domains as of December 15, 2003,
including the W3C (who develop web standards) and
technical publisher O'Reilly.
Benefits
Implementation
Thus, the key issue in SPF is the specification for the new DNS information that domains set and receivers use.
The exact specifications may change, but as of writing, the records are laid out like this (in typical DNS-syntax):
wikipedia.org IN TXT "v=spf1 mx ptr -all"
"v=" defines the version of SPF used, the following words provides the methods to use to determine if a domain is eligible to send mail. The "mx" and "ptr" specify the systems permitted to send messages for
the given domain. The "-all" at the end specifies that, if the previous methods did not match,
reject the message as a forgery. Limitations and controversies
Bellovin's strongest concerns involve the underlying assumptions of SPF
(SPF's "semantic model"). When using SPF, the SPF DNS records
determine how a sender is allowed to send.
That means that the owner of the domain will control how senders
are allowed to send.
People who use "portable" email addresses
(such as email addresses created by professional organizations)
will be constrained to use the domain owner's SMTP sender, which may not
currently even exist.
Bellovin argues that many users using SPF will be
tied more strongly to their ISPs and/or their employers.
One counter to this concern by Bellovin is that those organizations
could simply create SMTP servers, and use
mechanisms to authenticate their users.