A new anti-spam measure currently under development, Sender Policy Framework (SPF), is attracting a lot of attention. Not only is it quick and inexpensive to implement, a recent trial by AOL indicates that it could generate the kind of widespread support fundamental for any anti-spam system to succeed.
SPF is designed to prevent forged email being sent by checking the sender is authorised to send email from the domain they're claiming to be from. That way, if a spammer attempts to send email from a faked address, the message will be rejected. Similarly, recent email-borne worms have pulled fake sender details from address books or Web page caches, and they wouldn't be able to use this trick.
There are two sides to SPF; checking incoming mail, and allowing others to check the mail you send. You do the former by using an SPF-enabled message transfer agent (MTA), and the latter by registering an SPF record in DNS. Publishing your own record is the easier half to do, so we'll deal with that first.
An SPF record is a single TXT entry in the DNS for each domain. This details which of the SPF mechanisms should be used to verify the authenticity of a message, and what should happen if there's no match. There are a number of mechanisms defined by the draft SPF standard, but the system is extensible, so that new mechanisms can be supported without having to rewrite the standard.
The most widely used mechanism will probably be 'MX', which states that any server designated a mail exchanger for your domain is allowed to send mail on its behalf. If you only have a single outward facing mail server this is the ideal mechanism, but it's probably still appropriate for most systems.
The 'PTR' mechanism instructs the receiver to check the domain name of the sending host through DNS, and see if this corresponds with the domain name being checked. If they match, the message is fine, but if they don't it's a forgery.
Next, the 'A' mechanism allows you to specify that any machine with an address entry in the DNS which matches your domain is allowed to send mail. This is slightly different to the PTR mechanism in that it doesn't require special PTR DNS records, but instead performs an exhaustive search. This also allows for the case where an ISP is using a single mail server as the mail sender -- but not receiver -- for several domains, which the PTR mechanism can't be used with.
