Lead Developer of SPF Anti-Spam Scheme Interviewed

penciling_in writes "CircleID has a great two-part interview with Meng Wong, lead developer of the anti-spam authentication scheme Sender Policy Framework (SPF). He has responded to various questions (which also touches on issues previously raised by Slashdot folks), including the merger with Microsoft's Caller ID, incompatibility of SPF with email forwarding services, and what he thinks about Yahoo's DomainKeys, as well as where he believes the fight against spam is headed. (He has also confirmed that the name SPF and references to sunblock are intentional!) In response to the first question in the interview on how SPF got started, Meng says: 'In 2002 Paul Vixie, the brains behind BIND, wrote a short paper titled 'Repudiating Mail-From'. That inspired two other proposals, 'Reverse MX' by Hadmut Danisch and 'Designated Mailer Protocol' by Gordon Fecyk. In late 2003 I combined the best of both proposals and called the result SPF.' Vixie replies to this reference in comments following the first article."

Comments

SPF

[pubjames]

My understanding of SPF is this:

the recipient checks that the sender has authoritiy to send out email for the domain, i.e. if you send an email from whatever.com via SMTP server 123.123.123.123, the recipient checks that 123.123.123.123 has the authority to send email for whatever.com by checking it's SPF record (which similar to an ordinary DNS record).

So, we all have to set up SPF records for our domains or our emails will get rejected by some ISPs. Is my understanding right?

Re:SPF

[merlyn]

The default is "permissive, use OTHER means to detect spam". So the system is entirely voluntary for participation. No "flag day".

However, right now, if someone claims to be "@stonehenge.com", and sends that mail from somewhere other than the machines from which such mail should originate, any SPF-checking-recipient will rightfully reject such mail. That's because I took about five minutes to add the right SPF record to my server.

SPF is not a comprehensive solution. It's merely a solution to help us from getting joe-jobbed, having spam "appear" to come from us. Until you voluntarily add SPF records for your domain, you will continute to get joe-jobbed unknowingly.

Re:SPF

[pjrc]

the recipient checks that the sender has authoritiy to send out email for the domain.....

Yep, that's right

So, we all have to set up SPF records for our domains or our emails will get rejected by some ISPs. Is my understanding right?

Nope, that's wrong.

Messages only get rejected when a SPF does exist for the claimed domain and the MTA transmitting the message is not a valid sender for the claimed domain. Messages are NOT rejected simply because the claimed domain fails to publish a SPF record.

If you do not publish a SPF record, no messages claiming to be from your domain get rejected. This is true today, and it is likely to remain true even after SPF is widely deployed.

Of course, if you have a domain name, it is certainly in your best interest to publish a SPF record. Well, that is if your all email transmits from certain servers or one of the many other very flexible ways SPF's syntax can specify. Publishing a SPF record is the only way you can cause SPF-aware receivers to reject messages that claim to be from your domain, but are actually forged by spammers, virus programs, phishing scammers, and so on.

Re:Why do I need a Microsoft license for this?

[arr28]

IANAL, but the text of this agreement seems to indicate that this implementation license applies to any products that "implement and are compliant with" Sender ID (section 1.2), and that Microsoft may subsequently terminate the license (section 3).

IANAL either but SPF predates Sender ID and the details were made public without licensing requirements. Therefore, I'm pretty sure that most jurisdications won't require you to have a license from Microsoft or anybody else to implement SPF.

Remember, there are already over 20,000 domains publishing with SPF plugins for the major MTAs. Just pop over to pobox for details.

Re:Vixie: SPF will not slow spam

[arr28]

Furthermore, SPF enables domain reputation systems such as GOSSiP (currently under design) which enable domain's to be given a "spaminess" score based on their previous behaviour. MTAs could choose to reject unreasonably spammy domains because they'd know that the email really was from that domian and the reputation was based on emails that were known to be from that domain.

Without SPF, you don't know who your email is really from so you can't do domain based reputation.

Re:Why do I need a Microsoft license for this?

[Anonymous Coward]

A new IETF Working Group (WG) has been formed to look into the subject and may eventually produce some RFCs. The WG will have its first meeting during the next IETF meeting in San Diego, Aug 1-6, 2004.

While it's not a RFC yet and nothing has been finalized, here's the latest on the subject in terms of a draft submitted by both Wong and MS:

http://www.ietf.org/internet-drafts/draft-ietf-m ar id-core-01.txt

Some related documents:
http://www.ietf.org/internet-drafts/dr aft-ietf-mar id-rationale-00.txt
http://www.ietf.org/internet- drafts/draft-ietf-mar id-csv-csa-00.txt
http://www.ietf.org/internet-dr afts/draft-ietf-mar id-csv-intro-00.txt

As for why you'd need a license for this, it may the case that MS has a number of pending patents on the concept (orginally termed Caller ID) and the license mentioned prior is meant to assure people that if this makes it out there as a standard, they will have a license to practice with having to pay royalties. How much trust can you put in that ...