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

Confused

[IceFreak2000]

OK, I'm worried; unless I've completely missed something here, it seems as though the 'little guy' could get hit quite badly by SPF.

Let me explain; my domain is handled by a hosting provider here in the UK. Because I don't have a static IP address (and also because I don't want the hassle of handling a publicly visible SMTP server), I've set up a single mailbox with the hosting provider that acts as a catch-all account.

Locally, behind my firewall, I use fetchmail to retrieve the contents of this account, and I use qmail to distribute the mail into various IMAP folders; naturally I'm also using ClamAV and SpamAssassin as well.

All well and good, but the problem is that my domain hosting provider does not allow SMTP relay *at all*. Therefore, I use the SMTP relay service provided by my ADSL provider.

Obviously, neither my local qmail system nor my ADSL providers' SMTP relay will be listed in any SPF records; how will I be able to carry on locally managing my mail without automatically being rejected by SPF-aware mail servers?

Why not everyone use PGP ?

[johnjones]

explain this to me

if you are going to HAVE to use ESMTP why not add the ability to look up public key for domain ?

if you are doing the domain why not query for user ?
finger server or in DNS record ?

is this in the spec ?

in the future then everyone can use weak crypto for emails and not send everything plain text
(speak to the person in internet cafe or bussiness and they dont understand that their msg is transmited plaintext and maybe through other peoples servers who may or may not read the email )

it would be nice to say we thought of providing keys but people dont have to use them...

regards

John Jones

Re:Why not everyone use PGP ?

[Beryllium Sphere(tm)]

Why doesn't everyone use PGP already? It's been out since 1991. It's never had the success it deserves.

One issue that comes to mind is that signature verification is relatively expensive. Another is that it's fragile: regular PGP users often see their signatures fail to verify because an MUA changed the line wrapping. I think we need a standard for canonicalizing messages before hashing, but that's just my opinion.

"If you think cryptography can solve your problem, then you don't understand your problem and you don't understand cryptography." That's maybe a little rude but it's good to remember that crypto only changes one problem into a different problem. We'd have to manage the public keys, and we'd still be dealing with today's problem of insecure machines being taken over.

Re:good luck with that

[AKnightCowboy]

This scheme is as temporary as any other and it also prevents me from sending mail with my own computer, I will have to route my mail through my ISP's mail server in order to tag on to their SPF

What's your problem with doing that? If you're coming from DSL, cable, dialup, or some other residential service then you should be relaying through your ISP and your ISP should be blocking outbound port 25. It doesn't hurt you to relay through an additional hop and add an additional 5 seconds to your e-mail. If your ISP introduces intolerable delay then find a new one or complain that their service is unacceptable. If you're worried about relaying SSL mail to work for business purposes so you can post with your @work.com address then you should be using port 465 (smtps) anyway with authentication to connect to your work's mail server, authenticate via cram-md5 or even just a password so it opens relaying for you and then out you go.

SPF is well marketed....

[thogard]

Too bad its still broken:
# Its parsing is too complex
# No sane firewall is going to let TXT records through
# No sane firewall is going to let TCP DNS packets through
# The parsing can loop forever
# It will increase DNS scaning as spamers hunt for broken SPF records
# Its too complex to be implimented inside the MTA where it needs to be done
# It can't be properly parsed in sendmail
# ISO 8839 8859 59-15 utf-8 issues for domain names may kill some dns servers

Its a step in the right direction but its the wrong step.

Locate the servers off-shore instead

[FreeUser]

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.

Rather than give tacit support of software licenses to Microsoft (or anyone else), I'd rather just locate my DNS and mail server overseas, in a sane regime that doesn't recognize software patents, and use SPF irrespective of Microsofts intellectual property grab.

Microsoft obviously didn't invent anything here (the SPF folks did) ... they certainly should not be given government monopoly entitlements to the concept, nor if our corrupt government does grant them such entitlements, should anyone respect it. Locate the infrastructure off shore instead.

Have the patent issues been resolved?

[dwheeler]

The original SPF is, to my knowledge, clear of software patent problems. BUT Microsoft has quite publicly stated that they're pursuing patents on their caller-id approach. So if they've created a combined approach, the combined approach has all the patent concerns of Microsoft's original approach.

So what's the story on the patent claims? Boycott Email caller id still seems wary, and I see no evidence that Eben Moglen's concerns (such as incompatibility with the GPL) have been addressed.

Any such patent application is likely to be granted, since Microsoft has lots of $$$ to press their case and the patent office has neither the knowledge or time to determine if they're obvious or in any other way counter them.

I remember the joys of dealing with GIF patents. We're better off without this combined approach if the patent applications will make it unworkable.

So, what's the situation?