>I just don't know if I buy this. Yes, a system is susceptible to the >kind of attack you are describing. But I don't see it practical on a >large level. How do you suppose these spammers will enlist enough >machines (and remain anonymous for long enough) to fire off an attack >large enough to convince enough mail ops to abandon SPF just to accept >the SPAM? And then get their spam out?
They've already done it to cause C/R to be disabled. Remember last fall, when C/R was the One Big Solution That Would Solve Everything? I was having similar arguments with people claiming it was 100% effective, with 0% false positives, blah blah blah. Around that time, spammers decided to target a few systems that implemented it. Those systems thrashed and burned until the admins turned off C/R, or disappeared entirely. Now, people in favor of SPF are saying contradictory things about it, and I can't figure out what it is really supposed to accomplish. Is it an anti-spam measure? You seem to claim it is; wasn't someone else contradicting me earlier when *I* talked about it that way, saying it is merely an anti-forgery measure? I'm just standing back, taking a big, long look at the whole picture, and I frankly can't see what SPF buys anyone (aside from a smallish audience, namely, mid-to-large-sized ISPs with fairly static user bases) that's worth the costs of deployment and maintenance (which includes responding to attacks). >But even during the worst worm/virus episode/storm that was causing my >mail servers to cook and boil over while trying to filter everything, I >didn't just say "well, I'll just disable that virus and spam scanning >and let it all go through". Some people did that or similar things: they optimized their spam and virus scanning, or did it during SMTP time instead of afterwards, or found other ways to shut down spam and vermin sources before they really got going. Thing is, those measures are all basically localized, easily controlled, and therefore easily optimized. SPF doesn't share those particular attributes, and it doesn't take much to make your *system* unable to deal with incoming email even if your *computer* has plenty of time on your hands -- just enough incoming connections with well-chosen, nonrepeating domain names in the envelope-sender fields (MAIL FROM:<...>) in SMTP sessions. Such activity, at a sufficient pace, will cause your DNS cache to thrash, leading to problems for *all* its users, certainly all the incoming email handlers (SMTP servers) that share that cache. >I still say that someone trying to send out spam would be better off >just spending the ten dollars and set up SPF in their dns. If the point >is to send out spam. What you are describing sounds more like they just >want to break things. They would feel better using that energy for >something productive. Oh, I think you're right about that first part for most cases as well. It's the systems that aggressively use SPF to reject, bounce, or drop email deemed "forged", yet have substantial end-user bases they are protecting, that spammers might find worth targeting in order to convince the admins to disable SPF. There are plenty of other reasons to reject SPF as a useful anti-forgery tool, which I haven't really touched on (other than SRS, they include complexity of managing SPF information for some types of hosts, low degree of actual utility of what SPF calls "forgery", which is not really detection of forgery so much as lack of authorization to send email under a domain name, and so on). See other lists (like the qmail list) for those discussions, going back a few months at least. Personally, I've got no horses in this race; I'm willing to deal with most anything on my own system, able to implement pretty much any technology anybody comes up with, able to design my own approaches to solve these problems (just not particularly motivated to do it), and quite willing and able to make my own independent assessments of proposed technologies. And what I've come to believe is that any system that depends on assessing trust based on *incoming*, externally controlled information, or that predictably overreacts to a correspondingly small external stimulus, has some big strikes against it from the get-go. Such systems include C/R, SPF, DomainKeys, and im2000, among others. They'll all (probably) work reasonably well in the small; I believe they won't scale up sufficiently to deal with today's Internet, and are provably unable to scale up to, say, 10 billion users. I am trying to design (in my head) a sort of "ideal reverse DNS", from the ground up, that permits scalable lookups of externally-provided identifiers (i.e. domain names) in the context of something as large and as loosely managed as the Internet. So far, I have not been able to do it. The real-world problems to which it corresponds seem similarly unsolvable. -- James Craig Burley Software Craftsperson <http://www.jcb-sc.com>
