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.
Use your own domain for outgoing mail AND either do not publish an SPF record for it, or publish one pointing to your Internet Serive Provider's SMTP server.
If the DNS provider for your domain doesn't enable you to publish an SPF (needs a 'txt' record), you'll need to ask them to, or change providers. But something tells me the laggard will quickly figure it out, since SPF is nearing critical mass.
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
But usually those zombies connect directly to port 25 of the recipient's SMTP server. That would be prevented by SPF if the sender domain doesn't include the zombie machine's IP in its SPF record. If the zombie is actually using the user's proper (sender) domain and sending through the ISPs mail server, then SPF doesn't help directly, but it gives the ISP the power to simply monitor what is sent and shut the zombie down if spam is being sent.
HAND.
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.
Boycott Caller-ID for E-mail is still wary of the new, combined scheme. Neither Meng nor Microsoft has clarified whether the draconian patent schemes from Microsoft's earlier attempt still exist!
We need to pressure the people coming up with the standards to avoid patented schemes at all costs, or assign the patents to a neutral third-party with the mandate of using them defensively.
If you don't flag anything that doesn't match as a fail (-all at the end), then you won't see much difference. It also depends on the server receiving such spoofed emails actually doing checks against SPF records.
Most domains out there are defaulting to "neutral" or "softfail" as the default in their SPF records for now until sites that do mail forwarding or web mail (preserving the original envelope FROM address) implement SRS. If you have fairly solid control over where mail from your domain comes from, then you can go ahead and set the default to "fail".
All I want is a kind word, a warm bed and unlimited power.
All your questions are answered in the papers on SRS which were written by a professional cryptographer and security researcher at the University of Bath.
A lot of very smart people just like you have spent a lot of time thinking through the problems. Much of their thinking is captured in essays and FAQs available online.
http://www.libsrs2.org/docs/
If you run your own mailserver, you can setup port 587/tcp, which is the smtp-auth port. Configure your MTA to only accept authorized connections. SASL is very common for this. When your MTA connects it issues a STARTTLS, which encrypts the session, then it authenticates as you, and then your MTA can allow it to relay. The 'traveling executive' problem is now solved.
RFC 2554 for more information.