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.
for every article about new anti-spam schemes, I would now be richer than I would have been had I gotten $0.01 for every spam mail urging me to buy penis-enhancing pills.
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?
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.
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?
Life is like a sewer; what you get out of it depends on what you put into it...
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
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
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.
(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 -
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.
# 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!