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."
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).
Anybody familiar with this? Is there a RFC for Sender ID?
Paul Vixie's comment:
I'd have to disagree with Paul Vixie here. Most of the spam today comes through compromised home machines on a broadband line. Of course, spammers could include the zombie they're using in their SPF record and use their own domain in the "Purported Return Address", but that would make them so traceable that they might as well spam from their own systems.
So I'd definitely disagree that SPF/SenderID will not discourage spammers. It will certainly discourage the worst of them: the guys who don't want to be found out.
my webmail rightly lets me send with whatever From: field I choose
So I can emailwise be both at work and at play from the same webmail
for spamming from a zombie (with an IP of 111.222.123.124)
From: zombie@111.222.123.124
Subject: Stop spam now!
or it wouldn't be too much trouble to look up the MX record of 111.222.123.124 and set an appropriate From: header accordingly
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
oh well, something's got to give
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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?
1) If your provider's SMTP relay isn't listed in an SPF record, then it will still work (for now) until people start saying "i only accept mail from servers with valid SPF authentication".
2) When that day comes around, you can publish your own SPF info for your "vanity" domain using the sfp include syntax and pointing to your provider - basically saying "whoever can send mail for my provider's domain can send mail for my domain as well"
#!/usr/bin/english
The machine was taken over from Joe Sixpack in the first place.
He won't know why his box is just a bit slower than usual. Soo he thinks DSL is all bull because is hardly faster than his ol' dial-up.
Get a thousand zombies sending a hundred spam a minute and you see that its not so tough to send a hundred ACK signals as well...
Potential end result: 1,440,000,000 spams/day from ONE infected net.
Go after the spammer's clients instead. Spam and you get jail time and a whopping big fine, paid locally, regardless of the jurisdiction you're in.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
For a moment, neglect the high costs, complexity, worldwide legality and PKI problems of crypto, which are all solvable at some cost. They aren't the fundamental problem.
Strong authetication answers the question:
That's a very nice to know if you need to place a high level of trust in the message, such as correspondance from your bank. Today email is virually worthless (in the absence of PGP) for trusted messages.
Saddly, the answer to this question is not valuable for filtering out junk. The question that needs to be answered instead is:
PGP does not answer this question. Neither does Yahoo's DomainKeys. There are many circumstances where the signature can not be verified. You can not use the failure to verify a PGP signature as a reliable means to filter out junk.
SPF and MS Caller ID are designed to answer this second question reliably enough to discard forged messages. They answer this question for all domains that publish SPF records (aol.com, gmail.com, etc) regardless of whether SPF is widely adopted by the rest of the world.
When the claimed domain published a list of designated senders, and the sending MTA's IP number isn't among them, you can be certain the message is a forgey and discard it (or close the connection before the data phase, saving bandwidth).
PGP and other crypto signature schemes simply do not deliver this ability to detect forgey. They only detect authenticity.
PJRC: Electronic Projects, 8051 Microcontroller Tools
Your envelope FROM is not the same as your From: header. Get that through your skull and then come back.
(x) It is defenseless against brute force attacks
Explain: how would you brute force it? One way would be to search until you find a domain without SPF information and fake addresses from that. That will reduce the pool of domains you can fake, and be an incentive for them to start using it. In a way it's shifting the damage over to those that doesn't try to help solving the problem, they decide to be easy targets they take the consequenses.
(x) It will stop spam for two weeks and then we'll be stuck with it
It will stop spam from beeing sent with faked addresses from a domain, if the owners of that domain wishes it. That means I will never se a bounce for spam using my address if the recieving end uses SPF, and the reciever willl not see spam that fakes my address as its sender
(x) Users of email will not put up with it
Why not, all I have to do is configure my mail program to use the correct mailserver for outgoing mail
(x) The police will not put up with it
The police has never cared about anything to do with spam, why should they care about this?
(x) Requires immediate total cooperation from everybody at once
Bull. Mail (allegedly) from domains that doesn't publish SPF information will get through, and mail to recievers that doesn't check SPF will come through. Domain owners will be encouraged to implement this because they will se fever (misdirected) abuse reports. Users will be encouraged to implement this because they will see less spam
(x) Lack of centrally controlling authority for email
The owner of a domain is the central controlling authority for email from that domain, that's all you need
(x) Ease of searching tiny alphanumeric address space of all email addresses
Eventually all spam will use a sender address from domains without SPF informations (or nonexistent domains), people will start dumping mail from domains without SPF (or give it a high spamassassin score) and those domains will effectively be forced to implement SPF or see their users unable to send email
(x) Asshats
Which is why you have to use additional measures, such as scoring mail without SPF low, blacklisting domains and ISPS that allow spammers and other kinds of filters. There is no tool that will block ALL spam, but the right combination will reduce it drastically
(x) Unpopularity of weird new taxes
No tax involved
(x) Huge existing software investment in SMTP
It's compatible (actually uses) SMTP, no software has to be replaced. (Unless it already sucks)
(x) Willingness of users to install OS patches received by email
(x) Armies of worm riddled broadband-connected Windows boxes
And all the mail sent out to SPF using clients using from addresses with SPF domains will be dropped, eventually this number will rise as more people adopt SPF.
(x) Extreme profitability of spam
Making them work harder and reach less people will decrease the profitability, that will make the situation improve
(x) Extreme stupidity on the part of people who do business with spammers
(x) Dishonesty on the part of spammers themselves
Eventually the spammers will have fewer domains to use for sender addresses, they will have to buy domains (increasing cost) or use domains without SPF. Both can be blacklisted
(x) Outlook
This can be implemented serverside, outlook is not an issue
(x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
None has ever been standardised and tried large scale
(x) We should be able to talk about Viagra without being censored
You can as long as you don't forge the sender domain. But if you try to sell it to someone a complaint may well make you lose access to that domain
(x) Countermeasures must work if phased in grad
- We are the slashdot. Resistance is futile. Prepare to be moderated -
SRS/SPF still have a large number of problems to solve. SPF alone is very good idea, but the special-case of mail-forwarding is not compatible with the current design. As SPF breaks forwarding, SRS is an ugly hack which tries to repair the damage done.
I am not convinced that SRS does not introduce ugly bugs, which enables spammers to circumvent SPF alltogether.
Specifically I think SRS can as easily be forged as mails can be forged today, as noone hinders you to fake a forward which hasnt taken place in the first time. If this forward looks ok, you are in.
Now: Forging Spammer -> Recipient
SRS/SPF: Forging Spammer -> Recipient
^
|
Imaginary Origin
Why should this work at all? Please enlighten me.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
Your understanding is close. Those domains that *decide to* publish SPF records, Microsoft CID tickets, etc. will do so. The new software proposals will support both, although the SPF domain setup is vastly lighter weight.
For the foreseeable future, if you don't publish SPF, your email will still work. But if you do publish SPF, you help prevent forgery of your domain's name by spammers, people doing "joe jobs" to get you in trouble, and all the damn virus and worm email lately that pretends to be from you and gets you all the irritating bounces.
Because SPF acts in the first few packets sent in forged email, in the "MAIL FROM" line of SMTP transmissions that is normally processed via DNS to list the claimed name of the incoming host and its real domain name, there's very, very little extra processing and you can drop blocked connections extremely quickly. This can save a huge load from your mail server, which is a huge deal for domains like aol.com and hotmail.com and big sites whose mail servers are being hammered.
Remember, over 50% of all email is now spam. Anything so lightweight that will block so much of it for those of us who use that tool, and force the rest of the email to be so much more easily tracked as being from a forgery friendly domain, is a big deal. This also helps put a spike in the growth of "zombied" machines, by helping prevent them from being able to forge valid user's domains. Coupled with mail servers that insist that your domain does, in fact, exist in order to claim that your mail is from a real domain, it helps quite a lot.
# Its parsing is too complex
7 101"
Complex or not, it's working just fine with quite an array of software.
# No sane firewall is going to let TXT records through
A firewall would need to examine the contents of packets to differentiate a TXT record from a, say, A record or cname. Comparable wizardry is already being performed by mail servers world wide, on a vast scale:
[smegma@cartman smegma]$ host -t txt 84.137.116.38.sbl.spamhaus.org
84.137.116.38.sbl.spamhaus.org text "http://www.spamhaus.org/SBL/sbl.lasso?query=SBL1
# No sane firewall is going to let TCP DNS packets through
SPF does not rely on anything that every other app using DNS doesn't. Also see above.
# The parsing can loop forever
In a horribly written parser perhaps. The same could be said about IRC clients, Web Browsers and just about any application out there.
# It will increase DNS scaning as spamers hunt for broken SPF records
DNS is quite efficient. Unlike RBLs, SPF will work just fine with traditional SOA settings, so cache hits will be plentiful.
# Its too complex to be implimented inside the MTA where it needs to be done
Just where do you think it's already being implemented?
# It can't be properly parsed in sendmail
It is already being used with all popular MTAs, including sendmail, postfix, qmail, exim, courier and ms exchange.
# ISO 8839 8859 59-15 utf-8 issues for domain names may kill some dns servers
Huh?
Parsing complexity might become a bit of a concern with the advent of XML, but as of now, it's dead-simple.
3, Interesting? And I feel like I'm feeding a troll here!
ever heard of key signing ?
so you end up with a web of trust...
SPF and Caller ID are a solution until you end up sending emails from your outlook automatically...
oh wait thats been done before
OpenPGP and email clients that support it, go a long way to solving the problem i.e. set your boundrys
I trust bob
bob trusts jane
jane trusts bart
bart trusts lisa
so I think that I want only 3 degrees and everyone else has to tell me via phone fax and friends they want to email then I trust them and their friends...
works a bit like friendster and gmail invites only way of doing things I can see that will work
regards
John Jones
Yes you can if your work has it's email setup correcly with the SMTP Submission port (587) which is designed EXACTLY for this reason. Trivial to do with most clients and servers (exim on your home gateway and / or work server for example.)
Of course, he told me it would never work and that it was unreasonable to use DNS to provide such a service.
He's also dead-on right. There are many ways to simply bypass SPF; SPF-like schemes impose a number of limitations on regular email use; the use of DNS is a major part of the problem in SPF, as it's entirely inappropriate for a trusted transport.
The only reason anyone's deploying SPF, broken as it is, is because people will do *anything* at this point if someone promises them *any* reduction in spam -- look at the RIAA, and how they keep trying copy-protection scheme after copy-protection scheme. They've had PhDs doing studies come forward and say "there isn't any feasible way to copy-protect simple stereo audio as you're currently selling it", but they so badly want to believe that they keep buying into the latest scheme. ISPs get a huge amount of flak from customers over spam, and are more than willing to take even idiotic and nonfunctional measures if it (a) lets them believe that they're doing something that will be long-term effective and (b) lets their marketing people have something to trumpet about ("Earthlink's advanced spam-blocking technology")
May we never see th
Oh good.
Now everyone on his ADSL provider can send email from his domain as well. Great protection there.
How long before spammers start harvesting SPF records looking for easy targets?
SPF won't protect anyone but large companies with easily-recognizable, often-spoofed names (uh HOTMAIL, YAHOO).
Meanwhile, they make things harder for everyone else, while not actually protecting against spam. All I see in this thread is "Change your service provider!", "Rewrite your mailing list software!", "*You* change this, *You* change that".
Fuck that.
How about not breaking widely used protocols for meaningless bullshit. SMTP is totally b0rked, and everybody knows it, but a half-assed patch is not the answer.