Please Enter Your Search Term Below:
 Websearch   Directory   Dictionary   FactBook 
  Wikipedia: Sender Permitted From

Wikipedia: Sender Permitted From
Sender Permitted From
From Wikipedia, the free encyclopedia.

Sender Permitted From (SPF) is an extension to Simple Mail Transfer Protocol (SMTP), the standard Internet protocol for transmitting email. SPF makes it easy to counter most forged "From" addresses in email, and thus helps to counter e-mail spam. The combination is also called SMTP+SPF.

Benefits

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.

Implementation

Implementing SPF has two parts:

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.

The following methods are defined:

Limitations and controversies

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:

  • SPF uses of TXT records in DNS, which are supposed to be free-form text with no semantics attached. SPF proponents readily acknowledge that it would be better to have records specifically designated for SPF, but this choice was made to enable rapid implementation of SPF. It can take years to add a new record type. Once SPF is more established, a new record type could be added and transitioned to.
  • The SPF specification provides ways to avoid processing that a spammer could forge. For example, a spam engine could send email with a local-seeming HELO, MAIL FROM, and From: entries, in which case (per Example 3) SPF isn't to be used. Spam from abuse@ or postmaster@ can also bypass checks. This may require additional restrictions and changes in the specification.
  • Various other (fixable) problems exist in the current specification. It could be argued that this specification was rushed to make it rapidly available.
  • As of the time he wrote his message, there was no consensus that this is the right way to go. The major ISPs (AOL, Yahoo, MSN, etc.) have not bought into this scheme. Unless and until they do, it doesn't help much, either for their customers (who make up a substantial proportion of the user population) or for everyone else (since their addresses could be forged). It's worth noting that since this concern was raised, AOL has begun testing SPF.

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.

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.

External links


  

From Wikipedia, the free encyclopedia. 
Modified by Geona