Slashdot Mirror
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."
No these schemes are designed to work with SMTP.
It would be very difficult to replace something as as popular as SMTP. It would at least have to be backwards compatible with SMTP which means it would expose itself to the same problems as SMTP.
IMO SMTP does a good job apart from its obivous faults.
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?
See the RFC background reading page for links to SPF RFCs. To the best of my knowledge there is no SenderID RFC yet.
In the mean time (and it may be some time), it is advised that SPF records are published since Microsoft has agreed that SenderID will be back compatible with such records.
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.
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.
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.
m ar id-core-01.txt
r aft-ietf-mar id-rationale-00.txt- drafts/draft-ietf-mar id-csv-csa-00.txtr afts/draft-ietf-mar id-csv-intro-00.txt
...
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-
Some related documents:
http://www.ietf.org/internet-drafts/d
http://www.ietf.org/internet
http://www.ietf.org/internet-d
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
SPF is not an anti-spam system. SPF is an anti-joe-job system. It happens that the most frequent joe jobs tend to come from spammers, however:
1. Not all joe jobs are spam.
2. Most spam (looking at my bulk mail folder on Yahoo) doesn't involve joe jobs.
A number of people are equating this with anti-spam systems, and that's just wrong. I thought one of the most revealing answers in the interview above was:
What's signficant about this answer? It's that it doesn't answer the question. More specifically, it answers the first part of the question, but (rightfully) ignores the second part, because the second part of the question is a "Why are you still beating your wife?" question (a question based upon a false assumption.)Proper anti-spam systems are based upon dealing with unwanted email, not dealing with non-relevent characteristics. If you create a system that makes it easier to control who gets your email address (such as my solution, Yahoo!'s AddressGuard(tm), and TMDA), then you're implementing a relevent solution, because dealing with spam is about controlling who sends you email. Likewise, if you operate Bayesian, CRM114, Mail.app, etc, AI filters based upon spam, then you're coming up with a relevent (if imperfect) solution, and the solution can work if combined with a whitelist, especially if you can automate the generation of the whitelist through systems like Camram.
SPF isn't such a system, it's designed to deal with a totally different issue. Arguably, given that it breaks mailing lists and forwarding and has many other documentable faults, it really ought to be being used as a measure of last resort, though it's a good idea for mail receipients to implement the logic so that domains that are having these issues can make the choice when they find themselves being targetted.
It'd be nice if every solution to every problem on the net wasn't always promoted as an anti-spam solution...
You are not alone. This is not normal. None of this is normal.