On Mon, Sep 06, 2004 at 07:19:01PM -0400, Mark Jeftovic wrote:
I'm not sure the people behind this concept (SPF, RMX, et al) ever intended it to be the FUSSP, but a lot of the ensuing enthusiasm built it up to that.
Consider that the people behind SPF made this statement (upon introducing it): "Spam as a technical problem is solved by SPF." If, therefore, there is an overabundance of enthusiasm for that concept, then it seems to be very clear where full responsibility for that rests.
I've *never* viewed SPF as an "antispam" methodology, but considered it an inevitable utility of the DNS system. Other methods are evolving to deal with spam, don't confuse them with what SPF is, which is essentially an authentication/identification framework that has the ability to mitigate one of the more popularly used spam obfuscation techniques.
I'll agree with you that it may mitigate one of the more popularly used spammer obfuscation techniques, but that particular technique is a minor problem (considering spam/abuse as a whole) and not all that worth solving -- since *other* spammer obfuscation techniques which SPF (and DomainKeys and SenderID et.al.) don't address are already available and being used. (Why aren't they used more? Spammers haven't needed to. But if pressed, they will. Rapidly.) The bigger problem isn't the spammer obfuscation technique: it's the backscatter from all the mail systems which bounce instead of reject, Bouncing was not all *that* unreasonable until we started to operate in an environment with massive SMTP forgery (from spam/viruses/etc.) -- several years ago. It's now much more desirable to reject whenever possible, saving everyone bandwidth/cycles/grief. I don't think I like the idea of wallpapering over this problem with SPf/DomainKeys/etc.: I think I'd rather see those mail systems fixed to deal with the environment they find themselves in. [ Especially because the other spammer obfuscation techniques I referred to are available, and will be used if and when SPF or DomainKeys or any of these are widely deployed. Thus, mail systems will *still* inhabit an environment of massive forgery and should be prepared to deal with it as best they can...where I think one approach to that is "don't make it any worse". ] Yeah, that may be a lot of work to complete -- although there are a myriad of simple techniques available to at least mitigate it, if not eliminate it entirely, and any relief would be welcome.
That spammers are publishing SPF records is in no way indicative of an inherent flaw in SPF's objectives or a failure in its implementation, in fact, I welcome spammers who publish SPF data detailing the originating points of their email. If more "known spam domains" did this, a handy DNSBL could be constructed out of such data (with a few caveats of course, it would also potentially open the door to a type of DoS attack).
RHSBLs (i.e. DNSBLs which list domain names instead of IP addresses, thus "Right-Hand-Side BL's") have already been built. See www.surbl.org and www.ahbl.org, for example. But this tactic doesn't work -- as an anti-spam technique -- as well as we might hope, for three reasons: 1. Spammers have an [effectively] infinite supply of domains. This won't change because spammers who burn through domains rapidly (and thus need to purchase more) are some of the registrars' best customers. They're also early adopters of "obfuscated registration", so much so that it's becoming increasingly likely that any domain thus registered is declaring "intent to abuse". [1] 2. Spammers control a large -- as in tens of millions -- number of zombies. [2] This won't change because none of the three entities who could do anything about it (the zombies' former owners, consumer broadband ISPs, Microsoft) are willing to step up, admit there's a problem, and do whatever it takes to fix it. 3. Mail from a forged sender is operationally indistinguishable from mail from an unforged but unknown sender. [3] This won't change either. And because of #1, spammers have an essentially infinite number of domains to do it with, and because of #2, they have a large number of systems to do it from. And as a result, a *lot* of things that we could try, not just SPF/DomainKeys/et.al., just won't work. (Example? Oh, take the various "hashcash" ideas that have been floated: getting into a computing cycle contest with spammers is a guaranteed loss.) ---Rsk [1] For example, one group of pirate-software spammers appears to be burning through domains at the rate of one every 24-48 hours, and has been doing this for months. [2] It's hard to know how many systems are zombies, but "tens of millions" is probably the right order of magnitude. I did a back-of-the-envelope calculation a few months and came up with 10 to 20 million; Carl Hutzler (of AOL Policy Enforcement) provided an estimate of 50-100 million on Spam-L. We went back and forth a little bit about this, and while I don't want to try to speak for Carl, I think we agreed that the true number is probably in the middle: so let's say, 40 million just so we have a number to argue about. [3] This may not be clear, so let me illustrate by example. Consider two incoming pieces of SMTP traffic, which claim to be from: frooblebonker@yahoo.com and joe@56trf5.com respectively. If I tell you that the first one is forged -- and that the putative sender doesn't exist (or isn't really the person sending the message) and that the second one is unforged (and is actually correct) -- did I just do you any good *with respect to stopping spam*? For the first one: sure. You reject it, 'cause it's forged. Heck, even if it's not spam, and it may not be, you may decide to reject it anyway: using the anti-SMTP-forgery technlogy of your choice: SPF, DomainKeys, it doesn't matter. For the second one: no. Because knowing that sender is unforged/real doesn't, in and of itself, do you any good *with respect to stopping spam*. You ALSO need a way to know that 56trf5.com is a spam source domain. And you don't know that. Yet. So suppose I tell you that, too: "56trf5.com is probably controlled by a well-known spammer and so you might want to block traffic from it." Did I just do any good? Not really. Because tomorrow you will get SMTP traffic from: sam@78jh89.com and none of the things that you learned today *in and of themselves* are going to help you figure out what to do with that. Oh, it's unforged: it really IS from 78jh89.com. You can even confirm it with your favorite anti-SMTP-forgery technology, if you like. So what? It doesn't do you any good until I also tell you that 78jh89.com is another spammer-controlled domain. Lather, rinse, repeat hundreds of thousands (or more) times.